From alexey.melnikov@isode.com Tue May 1 12:20:04 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 33A4921E8425 for ; Tue, 1 May 2012 12:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.069 X-Spam-Level: X-Spam-Status: No, score=-102.069 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 GvG3pczHz8rQ for ; Tue, 1 May 2012 12:20:02 -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 0070321E8370 for ; Tue, 1 May 2012 12:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335900001; d=isode.com; s=selector; i=@isode.com; bh=5O1/dJoTnwUqfbLx74VkebUBkSI2ltateIu59d8ksBc=; 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=KiKGaU80Fx+uQq6YDAH8vC+y58mDBmTFtF0heuLGLLyLM5aHbn0VA38QLvgYziiREn6ZHQ /a+/62t3gi/yNUUe/7HDdM7HCwpATtebdObnDc8jMy4bblbTW4ctfaRJ+zEWeRlhKeb8gK DlibbLFaMccQEL4iw5ofkjR6Slqdf4I=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 May 2012 20:20:00 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA0377F.6030603@isode.com> Date: Tue, 01 May 2012 20:20:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Nataraju A.B" References: <996C3E66-90B8-4C86-885C-AD436D94E61C@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040900040505000304080204" 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: Tue, 01 May 2012 19:20:04 -0000 This is a multi-part message in MIME format. --------------040900040505000304080204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On 29/04/2012 18:02, Nataraju A.B wrote: > 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. Ok, this makes more sense. > > 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. It is possible that some of these are indeed normative. Happy to review that once the document is reopened for update. But note that some of these sections introduce concepts informative, which are then defined normatively in later sections. No real conflict here. > > 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 >> > 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. > --------------040900040505000304080204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

On 29/04/2012 18:02, Nataraju A.B wrote:
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.
Ok, this makes more sense.

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.
It is possible that some of these are indeed normative. Happy to review that once the document is reopened for update. But note that some of these sections introduce concepts informative, which are then defined normatively in later sections. No real conflict here.

Thanks,
Nataraju A B

On Sun, Apr 29, 2012 at 9:55 PM, Alexey 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.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.




--
Thanks,
Nataraju A.B.


--------------040900040505000304080204-- From tyoshino@google.com Tue May 1 23:22: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 CD63A21E8013 for ; Tue, 1 May 2012 23:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, 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 N7dI4+PTAbZo for ; Tue, 1 May 2012 23:22:46 -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 4349521E8011 for ; Tue, 1 May 2012 23:22:46 -0700 (PDT) Received: by yhq56 with SMTP id 56so348546yhq.31 for ; Tue, 01 May 2012 23:22: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 :content-type:x-system-of-record; bh=kUU0qFxHATzDm8lYs2AmYTuYvtp+bX5JL9P67lUD59I=; b=EsHxhPouSXX9ocMsizPm9Cn5/nBdm15ZHoSclvQFgS4IERfZDMFglRwGDiAiuPrK99 KphMmefGU8jrLFKUEmfvbRq7OwXQX1mIEbzf4w4o40oztWSYh6zeA/ZBV290Rq8Qb9ip oSt3ZLTVmM5IPopP6DdARW23mx2uv0653KweP4THy3xr9V7nZLZF1uvrTZgVPPBub++R uO9FVD9AA1JmSUMvND9WdarkxXUaezohC5oiJKNAuLjw0n9l1PTYpaEKDI4MT+TPIz3s Z996b+j/vpRHDF96Wpj54L+AXPZkAfqTnTCEOwqxCIpG4c3veM0fq+aU19VYZ25w7jH4 jabw== 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=kUU0qFxHATzDm8lYs2AmYTuYvtp+bX5JL9P67lUD59I=; b=jXA9x5QHKvsbmwwvCssQ+KgLYIZEuOufZAf6/luRfm6bu3zm2nXIJ07Dv0Ws7zdyge GK7RzEzVxvIdSGp8tkqfzi7/JPc50rrUsYbWl42qBTZ1lxCq3jGu2MiCUE8Oa53g6dVp dH1i/TmxhysbNhwx34ZQbXB6Rsz06PrKnb9v6JF7X0cxa3eseMv0vMculPNHrf2EAguY BiErRflBulGcNMYKRRyNm5FtV2AAiSJsdvD/bPmZNStOxeWuks3XuecwlihayoS0c3va YxclgrEvyp3A8hLHPNs2kG5mSN9mB0cosLc3Rj+M+LZps0X2APoUdB7oG1gQA+cdGgiz wJdg== Received: by 10.50.156.133 with SMTP id we5mr3716924igb.64.1335939765463; Tue, 01 May 2012 23:22:45 -0700 (PDT) Received: by 10.50.156.133 with SMTP id we5mr3716918igb.64.1335939765372; Tue, 01 May 2012 23:22:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Tue, 1 May 2012 23:22:25 -0700 (PDT) In-Reply-To: <003f01cd22e7$f4a47220$dded5660$@noemax.com> References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> <4F9494FD.5070106@ducksong.com> <000301cd21f2$8ee30fa0$aca92ee0$@noemax.com> <003f01cd22e7$f4a47220$dded5660$@noemax.com> From: Takeshi Yoshino Date: Wed, 2 May 2012 15:22:25 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f23500928078204bf07b7f5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlwOQOvxUyqv2ViOrFMz1bL3Ym8D2Vog0tiDXsF3u/UXu6mUgF5x6QiNDVHIfnIFFPUzPFsP0U2Cq7njqwv+xxJrGiuirGMZVtmQeF5EWFTWGcl25RtNa1bXDSiG+9jNeEmSz/l 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, 02 May 2012 06:22:46 -0000 --e89a8f23500928078204bf07b7f5 Content-Type: text/plain; charset=ISO-8859-1 FYI, one more point we need to think about is channel-wise extension negotiation. E.g. if AddChannelRequest has per-frame compression extension request, the client must refrain from sending compressed frame until receiving AddChannelResponse. We can take this workaround for per-frame compression just because we made it frame-wise feature by introducing per-frame compressed bit. In general, we need to disallow use of mux with pre-response quota and channel-wise extension (if opening handshake with which may be accepted in different ways. i.e. "connection is accepted but the extension is rejected" and "connection is accepted with the extension enabled") together. Or the frame sent before receiving response will be mis-interpreted by the server. Takeshi --e89a8f23500928078204bf07b7f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI, one more point we need to think about is channel-wise extension negoti= ation.

E.g. if=A0AddChannelRequest has per-frame compression e= xtension request, the client must refrain from sending compressed frame unt= il receiving AddChannelResponse. We can take this workaround for per-frame = compression just because we made it frame-wise feature by introducing per-f= rame compressed bit. In general, we need to disallow use of mux with pre-re= sponse quota and channel-wise extension (if opening handshake with which ma= y be accepted in different ways. i.e. "connection is accepted but the = extension is rejected" and "connection is accepted with the exten= sion enabled") together. Or the frame sent before receiving response w= ill be mis-interpreted by the server.

Takeshi

--e89a8f23500928078204bf07b7f5-- From internet-drafts@ietf.org Wed May 2 00:53: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 8D97E11E8081; Wed, 2 May 2012 00:53:05 -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 4sbpXk3VeaO3; Wed, 2 May 2012 00:53:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B37521F86F5; Wed, 2 May 2012 00:53:05 -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.02 Message-ID: <20120502075305.22652.5859.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2012 00:53:05 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-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: Wed, 02 May 2012 07:53: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 : WebSocket Per-frame Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-websocket-perframe-compression-01.txt Pages : 15 Date : 2012-05-02 This specification defines a WebSocket extension that adds per-frame compression functionality to the WebSocket Protocol. It compresses the "Application data" portion of WebSocket data frames using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each frame. This specification provides one compression method available for the extension using DEFLATE. 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-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-perframe-compr= ession-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-perframe-compres= sion/ From tyoshino@google.com Wed May 2 00:56: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 6DFFE21F8796 for ; Wed, 2 May 2012 00:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.046, 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 bFddQ+0Cw3HM for ; Wed, 2 May 2012 00:56:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6D121F86EB for ; Wed, 2 May 2012 00:56:32 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so731118obb.31 for ; Wed, 02 May 2012 00:56:32 -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=KEcthadA0CnokVrYvD+A1Ir+tf6fUvEo0YjjYIdJxTA=; b=hl9kAFM+g4R5IE3tulbM1IdE7hTrdbZ0wZIZoOu6mtoECc/7TQqUif7z/nk4UoI5cf 5n2fCHFtHYZGXzdiJDbZJs0pZmUHarq5ao6Occ9cexMyZvZqTdxcVmyZmDOBe9fDae/b FWaKVp1xdiiQaHF7GQ6aDdeM7wQPENPXr0XxS0/uZCe61IKhvA/lidtgBct/jgU27fK0 JlVfjaXe3Zxx3D1Hd1ku6og+kKk2jNR4yMKzKkL6A0tLe8C0/sfF1nfIgABWKW84VAjO XVaVs+hXBeiIphZEpvWOhetd12zf6dJ67jNUn+b/Jo673/2YYJo+rVB5x3iMxiDBBq5L 5iRA== 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=KEcthadA0CnokVrYvD+A1Ir+tf6fUvEo0YjjYIdJxTA=; b=aYWV2jRs8e+Q8S/BrgSocIQVpB1ecMYlpdB1VxZ/FqnZmO8eFz618H+wtnkwWYLN05 Y/IbUoEFvejSFT6QZTsln4mqh4mMR62sQN5MygawvJEe05hRJ0LZjAp8Py0Ee2uge+yT UWF29xa88BZKJ2llhEE6C3yhJKTb17LbhnlZLzGKq8NJ1qXgPX+0F6TzEvBkT2np9xJS eYUtRt6PSgeiCBHIkb5UmONIwu8Ri0sya9OXR7xGLm9SM6RwLRJrwJdZ+0R+fC+Kq5tE BBS8baUTgoePp7KTbru4IzpHD68+C3H8R1IB9rQaU7KzJJoYbHj+xTWVWBu4jgjobm4R B/Hw== Received: by 10.50.184.133 with SMTP id eu5mr3934462igc.13.1335945392014; Wed, 02 May 2012 00:56:32 -0700 (PDT) Received: by 10.50.184.133 with SMTP id eu5mr3934453igc.13.1335945391883; Wed, 02 May 2012 00:56:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Wed, 2 May 2012 00:56:11 -0700 (PDT) In-Reply-To: References: <002001cd238c$8d5a6e80$a80f4b80$@noemax.com> From: Takeshi Yoshino Date: Wed, 2 May 2012 16:56:11 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=14dae93403c385c59304bf090625 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkwiWYC8PCL5034wmxIFeTg0gI0/mD2huPG2Fz5Ft5TEUZAz79//yRoVeehvqBfAEVcQc0nxfjVE3cjmRnpw6+Lu6FXodJGc6HJIdQrP0qCZDGEefWA09RSkAyprqPCTLjOZs7g 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: Wed, 02 May 2012 07:56:33 -0000 --14dae93403c385c59304bf090625 Content-Type: text/plain; charset=ISO-8859-1 Thanks all. I've updated the draft adopting option a) since Greg and John showed slight preference to a) and no one objected to a). --14dae93403c385c59304bf090625 Content-Type: text/html; charset=ISO-8859-1 Thanks all.

I've updated the draft adopting option a) since Greg and John showed slight preference to a) and no one objected to a).

--14dae93403c385c59304bf090625-- From tyoshino@google.com Wed May 2 01:15:06 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 8D91521F8AA3 for ; Wed, 2 May 2012 01:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, 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 45IL6qG0hOYU for ; Wed, 2 May 2012 01:15:05 -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 34D5A21F8AA2 for ; Wed, 2 May 2012 01:15:05 -0700 (PDT) Received: by ghbg16 with SMTP id g16so449157ghb.31 for ; Wed, 02 May 2012 01:15: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 :content-type:x-system-of-record; bh=mT7zN9bfhuqkhtk9814FkGTBbI7btM4k3wYnAcydSSQ=; b=cHmDnXtL1Yd4UHAzU+KWTRMuHimGMgPpZpC3pnKvcVE4i1jc+dbdVmH2mztxFn1FSP yE4H3cXzCe7AZWmTMG4ZNPM01VkIVC8F/MBYNRmmvtfeQ/YMjwtdTSyoSu2+44FsONqf BgkSpQxGvY4YfLpRPtFcSYDjrUvmDFSQqvvAtRRforq4z0nM2SiW26kRg2FPgCR8bVQr 3GR+BxRjxGL7/Rsa24G3AS3yYkDi89/583KqGQ/A+eOLVe+csIuTMi0C8G77rtUVDYMS t/eGtsxxpT6xuJP5F5UsKdQQNcrf67R5S1Av8ki3abqqEljDhlXm6C1k90Hudv7xi3Ig B2qg== 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=mT7zN9bfhuqkhtk9814FkGTBbI7btM4k3wYnAcydSSQ=; b=YZnoWhNDostVRJ8SfFONDMmsQtox26t4sWo4bs9Rx8dSrbrNdVB9TM+2dY3JqIUQ3c PHoZR332B33v3rwZgnPytffkVI6spziePbGLl6LUIDlWrgYw8e+Ya2uJxR0KR8PxzId+ f31tTKKzjjLV3Fcm6Tf/zTZWzRbEusxO4J2hHautpOIiC8vG/skQbHVNJxgE2VvCqMT6 785ARbPsqSTT4bhsW1Ygy8UVN7qnWehTbZ/3Q7ZRsomJpy/G1GbNus+8hrKFmz7L6e06 fEZFKhBWo1LtS+RRng81zBEw5VvDfwDV7u2o/uo07pPyG27u7eyzDPWqftkxCIM3ppca lgYQ== Received: by 10.50.220.138 with SMTP id pw10mr3775228igc.71.1335946504624; Wed, 02 May 2012 01:15:04 -0700 (PDT) Received: by 10.50.220.138 with SMTP id pw10mr3775222igc.71.1335946504513; Wed, 02 May 2012 01:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Wed, 2 May 2012 01:14:44 -0700 (PDT) In-Reply-To: <20120502075305.22652.5859.idtracker@ietfa.amsl.com> References: <20120502075305.22652.5859.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 2 May 2012 17:14:44 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=bcaec5555114d72a2d04bf0948f0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmXcLwJmfJ1XMqaRFlJei9WW+6AiM6ikqdkEKbxTrQ9FXsi8amVNN4o843u8syVzL6rybr8416HwgDwBUxtTahsvPTDXPcPTYQiJmhCz5J4m2HYnOF34MYspoT5y1qxTINmrBxE Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-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: Wed, 02 May 2012 08:15:06 -0000 --bcaec5555114d72a2d04bf0948f0 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Based on the feedbacks in this thread http://www.ietf.org/mail-archive/web/hybi/current/msg09605.html, I've updated the compression spec draft. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-perframe-compression-01.txt Changes from -00 are: - now we have one extension named "perframe-compress" which takes compression method(s) to use as an extension parameter named "method" -- Sec-WebSocket-Extensions: perframe-compress; method="deflate; max_window_bits=..." is equivalent to Sec-WebSocket-Extensions: deflate-frame; max_window_bits=... in version -00 -- this includes new IANA registry creation for method names - lots of rephrasing --bcaec5555114d72a2d04bf0948f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Based on the feedbacks in this thread=A0http:/= /www.ietf.org/mail-archive/web/hybi/current/msg09605.html, I've upd= ated the compression spec draft.


Changes from -00 are:
- now we have one exten= sion named "perframe-compress" which takes compression method(s) = to use as an extension parameter named "method"
-- Sec-= WebSocket-Extensions: perframe-compress; method=3D"deflate; max_window= _bits=3D..." is equivalent to Sec-WebSocket-Extensions: deflate-frame;= max_window_bits=3D... in version -00
-- this includes new IANA registry creation for method names
- lots of rephrasing

--bcaec5555114d72a2d04bf0948f0-- From wwwrun@rfc-editor.org Sun May 6 17:32:17 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 0228321F845C for ; Sun, 6 May 2012 17:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 3EHadISMs3b6 for ; Sun, 6 May 2012 17:32:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 94CF721F8448 for ; Sun, 6 May 2012 17:32:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A70F2B1E002; Sun, 6 May 2012 17:30:08 -0700 (PDT) To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, presnick@qualcomm.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com From: RFC Errata System Message-Id: <20120507003008.A70F2B1E002@rfc-editor.org> Date: Sun, 6 May 2012 17:30:08 -0700 (PDT) Cc: hybi@ietf.org, jesse.katzman@gmail.com, rfc-editor@rfc-editor.org Subject: [hybi] [Technical Errata Reported] RFC6455 (3215) 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, 07 May 2012 00:32:17 -0000 The following errata report has been submitted for RFC6455, "The WebSocket Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3215 -------------------------------------- Type: Technical Reported by: Jesse Katzman Section: 5.3 Original Text ------------- The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. Corrected Text -------------- Notes ----- I don't see how the client-to-server masking prevents "authors of malicious applications from selecting the bytes that appear on the wire". Maliciously changing the contents of a message simply requires a few more steps than it would without masking, as far as I can tell. I'm quite new at networking, so perhaps I'm missing something. Thank you. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) -------------------------------------- Title : The WebSocket Protocol Publication Date : December 2011 Author(s) : I. Fette, A. Melnikov Category : PROPOSED STANDARD Source : BiDirectional or Server-Initiated HTTP Area : Applications Stream : IETF Verifying Party : IESG From stpeter@stpeter.im Sun May 6 17:58: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 0FBBD21F84CF for ; Sun, 6 May 2012 17:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 azTuJDVK+qGc for ; Sun, 6 May 2012 17:58:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 64CAC21F84C8 for ; Sun, 6 May 2012 17:58:29 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C847E40058; Sun, 6 May 2012 19:13:40 -0600 (MDT) Message-ID: <4FA71E33.3020608@stpeter.im> Date: Sun, 06 May 2012 18:58:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: hybi@ietf.org References: <20120507003008.A70F2B1E002@rfc-editor.org> In-Reply-To: <20120507003008.A70F2B1E002@rfc-editor.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ifette+ietf@google.com, Gabriel.Montenegro@microsoft.com, jesse.katzman@gmail.com, presnick@qualcomm.com, barryleiba@computer.org Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3215) 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, 07 May 2012 00:58:30 -0000 IMHO this is not really a valid erratum, although it's a worthy topic for discussion if and when this working group (or a successor working group) decides to work on a document that might supersede RFC 6455. On 5/6/12 6:30 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC6455, > "The WebSocket Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3215 > > -------------------------------------- > Type: Technical > Reported by: Jesse Katzman > > Section: 5.3 > > Original Text > ------------- > The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. > > Corrected Text > -------------- > > > Notes > ----- > I don't see how the client-to-server masking prevents "authors of malicious applications from selecting the bytes that appear on the wire". > > Maliciously changing the contents of a message simply requires a few more steps than it would without masking, as far as I can tell. > > I'm quite new at networking, so perhaps I'm missing something. Thank you. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) > -------------------------------------- > Title : The WebSocket Protocol > Publication Date : December 2011 > Author(s) : I. Fette, A. Melnikov > Category : PROPOSED STANDARD > Source : BiDirectional or Server-Initiated HTTP > Area : Applications > Stream : IETF > Verifying Party : IESG > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From barryleiba@gmail.com Sun May 6 18:03:19 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3D621F853D for ; Sun, 6 May 2012 18:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 32qmUx7TkffH for ; Sun, 6 May 2012 18:03:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5F3021F851B for ; Sun, 6 May 2012 18:03:18 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8969302obb.31 for ; Sun, 06 May 2012 18:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mF/MRROiORy+ck7KIa/JA+4amsQlPkoHVE58u0LQf8Q=; b=R8cFZmNBKPHgH/+5oU0twLLmzIp9KU8bJxt+m6OzZFTzaX2wBubvAdu1jwteCAAOqD wXtwfCtnfafPmJeO3CLX0t8hxttndaecC3LcBSG1yDdHom9uCXUODjI/B87hb+QJnZ8R HtS2ZnY6GDDvY+EspQo5H4tFQLVlzAyUnpRFTe46B1SapEj7VDP/UVR8eS/9OJZXDR6Q e+EmtX2pMIpvrcnaGe1AZ5a93CPIMLbk4ugyoxIy0tD0s0FLkf3TmLt2f45BzWiNIyvw LZCRbQ6jG8KAFiphcegYs11zclATwb7tKp/E6Qq8Q53MuvHZYUhyOn7NN2AuX5koPBEW XqoA== MIME-Version: 1.0 Received: by 10.60.11.166 with SMTP id r6mr12676073oeb.2.1336352593464; Sun, 06 May 2012 18:03:13 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Sun, 6 May 2012 18:03:13 -0700 (PDT) In-Reply-To: <4FA71E33.3020608@stpeter.im> References: <20120507003008.A70F2B1E002@rfc-editor.org> <4FA71E33.3020608@stpeter.im> Date: Sun, 6 May 2012 21:03:13 -0400 X-Google-Sender-Auth: WzOmU4UccEWNTJCBjppfy1mCSkU Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, ifette+ietf@google.com, Gabriel.Montenegro@microsoft.com, jesse.katzman@gmail.com, presnick@qualcomm.com Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3215) 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, 07 May 2012 01:03:19 -0000 > IMHO this is not really a valid erratum, although it's a worthy topic > for discussion if and when this working group (or a successor working > group) decides to work on a document that might supersede RFC 6455. Absolutely -- not appropriate for the errata system. I'm going to reject this erratum, and suggest that the submitter participate in the HyBi working group instead. Barry, responsible AD > On 5/6/12 6:30 PM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6455, >> "The WebSocket Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6455&eid=3D3215 >> >> -------------------------------------- >> Type: Technical >> Reported by: Jesse Katzman >> >> Section: 5.3 >> >> Original Text >> ------------- >> The unpredictability of the masking key is essential to prevent authors = of malicious applications from selecting the bytes that appear on the wire. >> >> Corrected Text >> -------------- >> >> >> Notes >> ----- >> I don't see how the client-to-server masking prevents "authors of malici= ous applications from selecting the bytes that appear on the wire". >> >> Maliciously changing the contents of a message simply requires a few mor= e steps than it would without masking, as far as I can tell. >> >> I'm quite new at networking, so perhaps I'm missing something. =A0Thank = you. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol >> Publication Date =A0 =A0: December 2011 >> Author(s) =A0 =A0 =A0 =A0 =A0 : I. Fette, A. Melnikov >> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: BiDirectional or Server-Initiated HT= TP >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Applications >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi From jesse.katzman@gmail.com Sun May 6 18:06:12 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 D513521F8448 for ; Sun, 6 May 2012 18:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMq0xWVqWOum for ; Sun, 6 May 2012 18:06:12 -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 27B3521F84DF for ; Sun, 6 May 2012 18:06:04 -0700 (PDT) Received: by yenq13 with SMTP id q13so27325yen.31 for ; Sun, 06 May 2012 18:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=h3StGOHAcEWtp4Kb5KXM0ehxBZ1+DApOsa3AE3yV/5U=; b=Rd/h9CjVaR2sknw5OKu6lFX98E2GdyweGNpl5yrbEjfcoOAMyrvP9+I8PqoPqwmr5d NRIrsR8TjjrBO/sBQplim0h+Tsco1ZPyStZVq+/ZKIYXQ2OPhqFnJZh0YgLgcBs9sFll CN9HGLMjwnnbN5P6dUB/7yc0k4oHrPC4kavnQofl+6WxgdQNBgvS0xB/7aV4MY22UPz+ 52Kmp8mwF3+QTC363PpDI2EPKsJiP8Ugh0eQLkmkp2/u1u3aSvptDWNQpC2jXdfLXBEH /xFUpLE4YzYO6Q8uNrGO/uyaXuhAWnkBFc44cmHTVpjC8RMI69bF0wQ+/Y8HTl79w9Z2 4TnA== Received: by 10.50.158.134 with SMTP id wu6mr7282926igb.47.1336352763557; Sun, 06 May 2012 18:06:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.170.197 with HTTP; Sun, 6 May 2012 18:05:43 -0700 (PDT) In-Reply-To: References: <20120507003008.A70F2B1E002@rfc-editor.org> <4FA71E33.3020608@stpeter.im> From: Jesse Katzman Date: Sun, 6 May 2012 21:05:43 -0400 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=14dae9340387c435d504bf67df17 X-Mailman-Approved-At: Sun, 06 May 2012 18:14:08 -0700 Cc: hybi@ietf.org, ifette+ietf@google.com, Gabriel.Montenegro@microsoft.com, presnick@qualcomm.com Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3215) 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, 07 May 2012 01:08:39 -0000 --14dae9340387c435d504bf67df17 Content-Type: text/plain; charset=ISO-8859-1 Okay, thank you. Will do. 2012/5/6 Barry Leiba > > IMHO this is not really a valid erratum, although it's a worthy topic > > for discussion if and when this working group (or a successor working > > group) decides to work on a document that might supersede RFC 6455. > > Absolutely -- not appropriate for the errata system. I'm going to > reject this erratum, and suggest that the submitter participate in the > HyBi working group instead. > > Barry, responsible AD > > > On 5/6/12 6:30 PM, RFC Errata System wrote: > >> > >> The following errata report has been submitted for RFC6455, > >> "The WebSocket Protocol". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3215 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Jesse Katzman > >> > >> Section: 5.3 > >> > >> Original Text > >> ------------- > >> The unpredictability of the masking key is essential to prevent authors > of malicious applications from selecting the bytes that appear on the wire. > >> > >> Corrected Text > >> -------------- > >> > >> > >> Notes > >> ----- > >> I don't see how the client-to-server masking prevents "authors of > malicious applications from selecting the bytes that appear on the wire". > >> > >> Maliciously changing the contents of a message simply requires a few > more steps than it would without masking, as far as I can tell. > >> > >> I'm quite new at networking, so perhaps I'm missing something. Thank > you. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) > >> -------------------------------------- > >> Title : The WebSocket Protocol > >> Publication Date : December 2011 > >> Author(s) : I. Fette, A. Melnikov > >> Category : PROPOSED STANDARD > >> Source : BiDirectional or Server-Initiated HTTP > >> Area : Applications > >> Stream : IETF > >> Verifying Party : IESG > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > --14dae9340387c435d504bf67df17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, thank you. =A0Will do.

2012/5/6 Bar= ry Leiba <barryleiba@computer.org>
> IMHO this is not really a valid erratum, although it= 's a worthy topic
> for discussion if and when this working group (or a successor working<= br> > group) decides to work on a document that might supersede RFC 6455.
Absolutely -- not appropriate for the errata system. =A0I'm going= to
reject this erratum, and suggest that the submitter participate in the
HyBi working group instead.

Barry, responsible AD

> On 5/6/12 6:30 PM, RFC Errata System wrote:
>>
>> The following errata report has been submitted for RFC6455,
>> "The WebSocket Protocol".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.p= hp?rfc=3D6455&eid=3D3215
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Jesse Katzman <jesse.katzman@gmail.com>
>>
>> Section: 5.3
>>
>> Original Text
>> -------------
>> The unpredictability of the masking key is essential to prevent au= thors of malicious applications from selecting the bytes that appear on the= wire.
>>
>> Corrected Text
>> --------------
>>
>>
>> Notes
>> -----
>> I don't see how the client-to-server masking prevents "au= thors of malicious applications from selecting the bytes that appear on the= wire".
>>
>> Maliciously changing the contents of a message simply requires a f= ew more steps than it would without masking, as far as I can tell.
>>
>> I'm quite new at networking, so perhaps I'm missing someth= ing. =A0Thank you.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necess= ary, please
>> use "Reply All" to discuss whether it should be verified= or
>> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=
>>
>> --------------------------------------
>> RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
>> --------------------------------------
>> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol
>> Publication Date =A0 =A0: December 2011
>> Author(s) =A0 =A0 =A0 =A0 =A0 : I. Fette, A. Melnikov
>> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
>> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: BiDirectional or Server-Initia= ted HTTP
>> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Applications
>> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
>> Verifying Party =A0 =A0 : IESG
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi

--14dae9340387c435d504bf67df17-- From jat@google.com Sun May 6 20:01:04 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 C249221F8464 for ; Sun, 6 May 2012 20:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, 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 O4MDlJr6aLXq for ; Sun, 6 May 2012 20:01:04 -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 1333121F8441 for ; Sun, 6 May 2012 20:01:03 -0700 (PDT) Received: by yenq13 with SMTP id q13so67339yen.31 for ; Sun, 06 May 2012 20:01:03 -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=pCq9CFUdPgKeBW9X0q6ilp5zPqpUw1FRCKtu6jRRsUY=; b=NCJ0n79ALTNzn73vS8Wb3UFbg01jv0kSYdtYutCY/tjyii2ttp5meaSqKcTMXfeWBb uAqElHhEXMPwDMCD0hV8HpybExH9mlh8xrNXiX2NQIMnoBbeA38pgkdJ3/kCBxbwZNW0 00G9A6v0woBvUGICwomK1HaDt6EJQTPtDAq6llggLbo4KTGcI4h0XENAXWJl34UpymPH jhe3vOxZQP3RyeXSGMefPwMBto3sWSViYbY5PU2+4PICZlVKkXvRKn1un2Vat5ExX0Zx mGUBlqg1SolH1yZrZbJ4B/ApZSybTIQhbdlkLXIknNnfMQOhyzSgdsC5N6oJf7exGUY5 +7xw== 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=pCq9CFUdPgKeBW9X0q6ilp5zPqpUw1FRCKtu6jRRsUY=; b=Z3g5v260x4Zm13O9enxKgb/8pvu58l4fyfExG9pIhiNXBuQctzGfrw0wTJLgZ5pLDH JJ3upD6u61yIYt11+l4PVtFYxHc171k+sUwBR9AY2BP7NKcgGZIBcYr89WNvjbhnUn7g 41qdQPCNujEMm5TrZBwqIgkzTVX1Qc0ucBSWxSwzLxxXdLnjkATeG/BYRMp7nscD69nb UffSgHl++d8DkJlCZG02RjI/WTj0I60j3wCL0fx4PjypbJDzSVg3hYk7dL23m/pRPEwp ahqlRXzAZC9Z71KNYR6uwQloltyw2KwBiE6cVxvQZaLKAxKEfX3v3JOBUAdexRwukIkq UZYg== Received: by 10.43.131.201 with SMTP id hr9mr7440331icc.8.1336359663317; Sun, 06 May 2012 20:01:03 -0700 (PDT) Received: by 10.43.131.201 with SMTP id hr9mr7440325icc.8.1336359663203; Sun, 06 May 2012 20:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.9.169 with HTTP; Sun, 6 May 2012 20:00:42 -0700 (PDT) In-Reply-To: <20120507003008.A70F2B1E002@rfc-editor.org> References: <20120507003008.A70F2B1E002@rfc-editor.org> From: John Tamplin Date: Sun, 6 May 2012 23:00:42 -0400 Message-ID: To: jesse.katzman@gmail.com Content-Type: multipart/alternative; boundary=20cf307f34c804761b04bf697b69 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnpL6bLvZXlX5XYPTNCwrzk+NYeYcF/CcnNC9Fjgvrt1padvcngx2CxYah/n6TsL3bgcD+HfVfepcx9cPEekoiBsqh1ESQnRJVssXdlhldIm55dblD7AZUDN7tkN1AC/tzBcXJ1 Cc: hybi@ietf.org Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3215) 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, 07 May 2012 03:01:04 -0000 --20cf307f34c804761b04bf697b69 Content-Type: text/plain; charset=UTF-8 On Sun, May 6, 2012 at 8:30 PM, RFC Errata System wrote: > Type: Technical > Reported by: Jesse Katzman > > Section: 5.3 > > Original Text > ------------- > The unpredictability of the masking key is essential to prevent authors of > malicious applications from selecting the bytes that appear on the wire. > > Corrected Text > -------------- > > > Notes > ----- > I don't see how the client-to-server masking prevents "authors of > malicious applications from selecting the bytes that appear on the wire". > > Maliciously changing the contents of a message simply requires a few more > steps than it would without masking, as far as I can tell. > Masking the client->server frames was heavily debated on this list for months -- I encourage you read the archives rather than rehashing the debate. Basically, WebSockets is unique in that you need to protect the network infrastructure, even if you have hostile code running in the client, full hostile control of the server, and the only piece you can trust is the client browser. By having the browser generate a random mask for each frame, the hostile client code cannot choose the byte patterns that appear on the wire and use that to attack vulnerable network infrastructure. -- John A. Tamplin Software Engineer (GWT), Google --20cf307f34c804761b04bf697b69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 6, 2012 at 8:30 PM, RFC Errata Syste= m <rfc-editor@rfc-editor.org> wrote:
Type: Technical
Reported by: Jesse Katzman <j= esse.katzman@gmail.com>

Section: 5.3

Original Text
-------------
The unpredictability of the masking key is essential to prevent authors of = malicious applications from selecting the bytes that appear on the wire.
Corrected Text
--------------


Notes
-----
I don't see how the client-to-server masking prevents "authors of = malicious applications from selecting the bytes that appear on the wire&quo= t;.

Maliciously changing the contents of a message simply requires a few more s= teps than it would without masking, as far as I can tell.
<= div>
Masking the client->server frames was heavily debated= on this list for months -- I encourage you read the archives rather than r= ehashing the debate.

Basically, WebSockets is unique in that you need to pro= tect the network infrastructure, even if you have hostile code running in t= he client, full hostile control of the server, and the only piece you can t= rust is the client browser. =C2=A0By having the browser generate a random m= ask for each frame, the hostile client code cannot choose the byte patterns= that appear on the wire and use that to attack vulnerable network infrastr= ucture.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--20cf307f34c804761b04bf697b69-- From jesse.katzman@gmail.com Mon May 7 22:00: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 4CB0421F84BF for ; Mon, 7 May 2012 22:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.215, 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 WjOJFLUxrfHz for ; Mon, 7 May 2012 22:00:36 -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 B76B021F84A6 for ; Mon, 7 May 2012 22:00:34 -0700 (PDT) Received: by yhq56 with SMTP id 56so5957033yhq.31 for ; Mon, 07 May 2012 22:00:28 -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=mmoiomyiL3XD0lDV9Zic4dtJm2XYR9TvTH6oP25MpZI=; b=IzWPpj8qejV2S6oVgTJu4qv+wx4GTw44ABhHDepim5MrnjWksXRdB4UbiwhoNTxfgz b5FoEzEikQvBGRbSRy+nr2kZ1cKEni4MtSAAVm/dGt2z0f+sXqPqaNAnEkCIT06hSiAO iaAOSHUlhKcBzYrkkmQ8zI1Of93go2oQzvoy24Qqj2FfcypAdR+tzRddYb3DAzzgyhCU t46MBvl8FsL8HeFXmBc6CHGHxCQ7RQFw6gkpr+MNIx5zsid2BuQ/Vg/ZAcHx//2rd2eh SFrLjadrRyQqmll67xU8O0A+FvL7H5s6a4SzKVD31FU/pd04XviazdKKp0G037fCN0PM UGMw== MIME-Version: 1.0 Received: by 10.50.158.134 with SMTP id wu6mr9974669igb.47.1336453227731; Mon, 07 May 2012 22:00:27 -0700 (PDT) Received: by 10.231.170.197 with HTTP; Mon, 7 May 2012 22:00:27 -0700 (PDT) Received: by 10.231.170.197 with HTTP; Mon, 7 May 2012 22:00:27 -0700 (PDT) In-Reply-To: References: <20120507003008.A70F2B1E002@rfc-editor.org> Date: Tue, 8 May 2012 01:00:27 -0400 Message-ID: From: Jesse Katzman To: John Tamplin Content-Type: multipart/alternative; boundary=14dae9340387e5da4604bf7f4342 X-Mailman-Approved-At: Mon, 07 May 2012 22:02:02 -0700 Cc: hybi@ietf.org Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3215) 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, 08 May 2012 05:00:38 -0000 --14dae9340387e5da4604bf7f4342 Content-Type: text/plain; charset=ISO-8859-1 Hi John, Thank you for the explanation. I didn't realize it meant an in-browser application. I understand now. Thanks again, Jesse On May 6, 2012 11:01 PM, "John Tamplin" wrote: > On Sun, May 6, 2012 at 8:30 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> Type: Technical >> Reported by: Jesse Katzman >> >> Section: 5.3 >> >> Original Text >> ------------- >> The unpredictability of the masking key is essential to prevent authors >> of malicious applications from selecting the bytes that appear on the wire. >> >> Corrected Text >> -------------- >> >> >> Notes >> ----- >> I don't see how the client-to-server masking prevents "authors of >> malicious applications from selecting the bytes that appear on the wire". >> >> Maliciously changing the contents of a message simply requires a few more >> steps than it would without masking, as far as I can tell. >> > > Masking the client->server frames was heavily debated on this list for > months -- I encourage you read the archives rather than rehashing the > debate. > > Basically, WebSockets is unique in that you need to protect the network > infrastructure, even if you have hostile code running in the client, full > hostile control of the server, and the only piece you can trust is the > client browser. By having the browser generate a random mask for each > frame, the hostile client code cannot choose the byte patterns that appear > on the wire and use that to attack vulnerable network infrastructure. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --14dae9340387e5da4604bf7f4342 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi John,

Thank you for the explanation.=A0 I didn't realize it meant an in-br= owser application.=A0 I understand now.

Thanks again,
Jesse

On May 6, 2012 11:01 PM, "John Tamplin"= ; <jat@google.com> wrote:
On Sun, May 6, 2012 at 8:30 PM, RFC Errata Syste= m <rfc-editor@rfc-editor.org> wrote:
Type: Technical
Reported by: Jesse Katzman <jesse.katzman@gmail.com>

Section: 5.3

Original Text
-------------
The unpredictability of the masking key is essential to prevent authors of = malicious applications from selecting the bytes that appear on the wire.
Corrected Text
--------------


Notes
-----
I don't see how the client-to-server masking prevents "authors of = malicious applications from selecting the bytes that appear on the wire&quo= t;.

Maliciously changing the contents of a message simply requires a few more s= teps than it would without masking, as far as I can tell.
<= div>
Masking the client->server frames was heavily debated= on this list for months -- I encourage you read the archives rather than r= ehashing the debate.

Basically, WebSockets is unique in that you need to pro= tect the network infrastructure, even if you have hostile code running in t= he client, full hostile control of the server, and the only piece you can t= rust is the client browser. =A0By having the browser generate a random mask= for each frame, the hostile client code cannot choose the byte patterns th= at appear on the wire and use that to attack vulnerable network infrastruct= ure.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--14dae9340387e5da4604bf7f4342-- From internet-drafts@ietf.org Tue May 8 04:28: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 CA5AD21F8542; Tue, 8 May 2012 04:28:57 -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 GivlZ4+DYOp0; Tue, 8 May 2012 04:28:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6727C21F84A6; Tue, 8 May 2012 04:28: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.02 Message-ID: <20120508112857.17767.32040.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2012 04:28:57 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-02.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 11:28:58 -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-02.txt Pages : 16 Date : 2012-05-08 This specification defines a WebSocket extension that adds per-frame compression functionality to the WebSocket Protocol. It compresses the "Application data" portion of WebSocket data frames using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each frame. This specification provides one compression method available for the extension using DEFLATE. 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-02.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-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-perframe-compres= sion/ From tyoshino@google.com Tue May 8 04:33:21 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 5095321F854F for ; Tue, 8 May 2012 04:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.040, 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 HkIrLAlgID0a for ; Tue, 8 May 2012 04:33:20 -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 BD04421F8546 for ; Tue, 8 May 2012 04:33:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so6281977yhq.31 for ; Tue, 08 May 2012 04:33:20 -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=bCi1Fwv2Q6/D+ljmRlKdNOJTb8Mn5wZEz3Sc9Zou0L0=; b=WbEcunrKkqYCB1Lly3T3RIKBURDSQST6IqHS4+25iUYwHxy4Xr90fMkhFH0If9UP4T tMTJcC367jHfsToAuRVhaXntgXsY0hGngy7FDb8vW/pE+lAx/JbYl2Oe0XyjUqWor+85 amCofPxe7UerKpKp6HHUxNqAtYnD5xJqODUj+A0iqNJwhnLwT0k0su3eueO5pF5GQOCI uhrkyzv/u4OluiebWvw1vU1Q1GotOf1njCGuLHYTGyKZEzcD6U3hdQEZPXsb+e/POHGV B3w1jtDx+OXALfom47VDEr4mCesqTtW8Bgahq4wxaeE4E8Asb9wOSwogPpyenNbHRzuK B1eQ== 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=bCi1Fwv2Q6/D+ljmRlKdNOJTb8Mn5wZEz3Sc9Zou0L0=; b=ZZMwBHYPHq/oOcsOBHWpY8G+qZNs1wLtxWZG+HkFdgtEucPwmQ9RkvNyiJ8jGs0+yV 8EBbjg+OvZ8rKe/kR+LVASSy5D05tlv4ZCG8UBZSgLmVsppkYHxK+tVKew7VJpG8TNfx 52m2SNbGOkj6xhZZd9lg4Icd/1fymoRv7rH59GFhd2Bioe29R/PPHWicK6q3yTSaFc/E Bkb73NbFHt5TOFTD+J6E3+VPsDEvuCk55Fv9zLcVfkmRfl9GYo3rHr2v9ibbiXfLap32 rXaGDIpdy3sihcUi03OZzMm6WTHzjDsxA6jP94PiNWxwQsE6R+WkjRP06JxYffrFO79F flJQ== Received: by 10.50.222.137 with SMTP id qm9mr139487igc.64.1336476800154; Tue, 08 May 2012 04:33:20 -0700 (PDT) Received: by 10.50.222.137 with SMTP id qm9mr139481igc.64.1336476800068; Tue, 08 May 2012 04:33:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Tue, 8 May 2012 04:32:59 -0700 (PDT) In-Reply-To: <20120508112857.17767.32040.idtracker@ietfa.amsl.com> References: <20120508112857.17767.32040.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Tue, 8 May 2012 20:32:59 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae9341073eb2c7704bf84c065 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm3O721k7DHTvy0aucf3coKHU9e06AWqoMp0M11bvUxh1aV4YQQeyXrTbRC22d1pQLlNp/f7WLBcU0O8foqVv8YcK5IZ3hLFzB963JPgMn/y1AiyfKKdCds4NzixOrJP5Fv7l+T Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-02.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 11:33:21 -0000 --14dae9341073eb2c7704bf84c065 Content-Type: text/plain; charset=ISO-8859-1 Minor update Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-perframe-compression-02.txt Changes - clarified that the order of method definitions means preference - fixed simplest header example (separator between method name and parameters is ";" not ":") - added header examples --14dae9341073eb2c7704bf84c065 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Minor update


Changes
- clarified that the order of m= ethod definitions means preference
- fixed simplest header exampl= e (separator between method name and parameters is ";" not "= :")
- added header examples

--14dae9341073eb2c7704bf84c065-- From toyoshim@google.com Tue May 8 21:02:36 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4521F8522 for ; Tue, 8 May 2012 21:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 aurAtxEmvXUS for ; Tue, 8 May 2012 21:02:35 -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 1D2EC21F8525 for ; Tue, 8 May 2012 21:02:34 -0700 (PDT) Received: by lagj5 with SMTP id j5so5393319lag.31 for ; Tue, 08 May 2012 21:02:33 -0700 (PDT) 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-system-of-record; bh=t+lM58SSINWTaBF6zG/C5XfL+YpnGO63P02d7u/+lxk=; b=RczeffG2C838H2Lt4PzGQ8w5R8H6PWrb/uUsTEp5JWvJjIi6bSFKw9gdTQ/qG8LDLk E3bToFJfBtUuBFu3PvqKTIObMU0k0PvcdvLRXN3iPQY5xcPdxdWJ75r2CmcPRZ0lgtje yua/KLwbXP7YLNihJ2XBSzuX0MdDxWT3h/BCxNDjP/vVNxeOxy9qgHpxgXKoKTN2BsZQ 3QN+ucMJ/Gjw4I6BN1wVdd6OD7STl4RK0N1eRu0TguXSTyvmls1+HGFFXkkq65acZHdr mLuTKZ6ZwA+D0oCybQOSFmtYgzjyEG7Isa0+sTeVvqS4kAiVdiV34fYq2M5dO2g9GkLL btXg== 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-system-of-record:x-gm-message-state; bh=t+lM58SSINWTaBF6zG/C5XfL+YpnGO63P02d7u/+lxk=; b=LH9VoMnDnwoOt3pUdeaVqk5L1o2kqoZLWZT82rwYXlnnVJLrIXzECU8zrBLoBdKkmu tukGe1J6FWYNm3wUWT6D1l/TRc4YjubCCHOn65FSOkE9lSz2oZl/fBQpEKne2cK4KPsJ IjsHPT+j4p1V5mJT6ZOOY7gL3IJJfxylIMSACjpbWleAFXWReXwGBIWbjUYu2roR4tAK RCv8J56o2PEw/GxkRRJ06x2HkdOIPLSkZnXBU+6GhvE2d3Nnq2RNSLYM3nnCZtjrr+iG FOJryJWkwtbNtA0hYeOJvtj9fLTeeNz/3be6Z6l8RhmlHzUC43UFv7meOqj6IuwriRRz 3MxQ== Received: by 10.152.145.169 with SMTP id sv9mr20005704lab.12.1336536153851; Tue, 08 May 2012 21:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr20005696lab.12.1336536153750; Tue, 08 May 2012 21:02:33 -0700 (PDT) Sender: toyoshim@google.com Received: by 10.112.49.201 with HTTP; Tue, 8 May 2012 21:02:33 -0700 (PDT) In-Reply-To: <4ED4E9CB.3040106@isode.com> References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> Date: Wed, 9 May 2012 13:02:33 +0900 X-Google-Sender-Auth: Sve_sFHgKC9s6IsNkGBOZOzSLQI Message-ID: From: Takashi Toyoshima To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlmMUMlimGPxlB8S5cQiMR0bncXsxWZgu/+eDI8kWreoE8y5MD1Aw1KiXrSOhbm8viig0eucdM52TsCIUcDPNsZC55IctDncr2Bp3NFZjkmSAAMEm6iXCdOXQIe5Jp9tDcQFngi Cc: hybi@ietf.org, Peter Thorson Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 04:02:36 -0000 Hi hybi, Is this discussion valid also for browser side implementation? My concern is that what error code should be sent if a browser got an internal error. On Tue, Nov 29, 2011 at 11:18 PM, Alexey Melnikov wrote: > Peter Thorson wrote: >> >> This issue came up while polishing up the error handling code for my WS >> implementation. There doesn't seem to be a websocket close code equivale= nt >> to HTTP 500/Internal server error. >> >> I would like to handle situations where my endpoint catches an internal >> logic error and knows that continuing the connection will probably resul= t in >> bad/unknown behavior but knows that it is safe enough to close the >> connection cleanly. >> >> Example: I am a server and my handler for processing websocket messages = is >> interpreted code and that code has a syntax error. The websocket server >> itself is fine and can safely close the connection but clearly cannot >> process messages until someone fixes the missing semicolon somewhere. In= an >> HTTP server I would return 500/Internal Server error to indicate that >> something on the server end screwed up and that there is probably more >> information in the server log files to diagnose further. >> >> None of the current close codes (except 1006/abnormal closure - which >> isn't allowed on the wire) really fit. I'd rather not just drop the >> connection uncleanly/send back empty close frame since that provides no >> information about what happened and makes figuring out whose logs I shou= ld >> be looking at as an end application developer difficult. Browsers only >> report the status code itself and not the reason so sending a normal/goi= ng >> away error code with a more specific reason is less helpful. What are ot= her >> implementations doing in this case? Would another close code for interna= l >> server error make sense? > > Let's use 1011 for this (Unless I already suggested it be used for someth= ing > else. Please correct me if I did.): > > 1011 > =A0 =A0 =A01011 indicates that a server is terminating the connection > =A0 =A0 =A0because it has encountered an unexpected condition which preve= nted > =A0 =A0 =A0it from fulfilling the request. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From tyoshino@google.com Tue May 8 22: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 DF76621F84DE for ; Tue, 8 May 2012 22:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ScBwKOzS6m-0 for ; Tue, 8 May 2012 22:12:41 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2021F84D6 for ; Tue, 8 May 2012 22:12:40 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2336912ggm.31 for ; Tue, 08 May 2012 22:12:40 -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=nTEDi3lMF+PzhMub7X2X4Fi45ras8NF7hcomFLY0xm0=; b=DHxYQTAjUHT5skM0lOjUa68vRisSaB69HmPMHVJPSmNNXIRtbvbnqt6+odDMAjG79U ACU96lSL/1T7h4tfIxXEIl/c6/AJIYgJ50wVPp3+BqbpkKR4wXt4vg5RB2pcEyhaw1sh mqB2Or70mO125xaaGeOmomNl0srxl9QZscIomVks7tXWalQ1SQGrM5xgC2YLB4gIQAFK Po44Y/PMp+dwAjNL9aI6oXXxSTSRzsYT+p3BmW3EyxgVBGA2Ac3sHY9p0ZzjZKpkdNWd jj7zGbcC627ZQJ1aNg/9kTh/ZyWXz+5/f/Lpk/S2zz4A/mMNsZuIK7hWwgm9JHMYzsaH oeVw== 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=nTEDi3lMF+PzhMub7X2X4Fi45ras8NF7hcomFLY0xm0=; b=DqapqjwnHyBc5VOfJryxsUfsFWNuB2IOtuwyFsDA+d9TbdWBrTUdglGtvN+xI2fM6l QzFhbZM5j7Gqz0DRtRgzSi3A0/fFtALZpnvLrkdJrttkMuhYa65lLetX3pM6ZbNiCGo7 1ie72Eqam0NMBCvpJY9P7bYiPHiJxYIXymiWZtKIutz+ZqwWOJRrJ/h8BvxX/QgrhjBB JkmMA5vKOzqfJQp8jUYKKQyIIAqS2WM4ScoQLe54PLbsJgMfpBRpCHfNm0UmJY9TPXup b9R1oyL5Pj6JDfCKJ46qvXDh6ddjWFK+nU6oFie35tX2Kf3wpSlYWAfQwSNz0c8t08og P3OQ== Received: by 10.50.222.137 with SMTP id qm9mr1971280igc.64.1336540360425; Tue, 08 May 2012 22:12:40 -0700 (PDT) Received: by 10.50.222.137 with SMTP id qm9mr1971275igc.64.1336540360349; Tue, 08 May 2012 22:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Tue, 8 May 2012 22:12:19 -0700 (PDT) From: Takeshi Yoshino Date: Wed, 9 May 2012 14:12:19 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae93410736817c704bf938d89 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkSdNHf6ZpGWmyBnqbf1septFbboKT1edaAc+ahFAqaZ+mEaO/4LadVNCHVbv8pLWQr0d+/Z+ZEn5oTf1X66RDLcrhr0gbY0I8QVI1QjCIQKImqL6/AjLgUfp+vz4OKM4FGugdu Subject: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 09 May 2012 05:12:42 -0000 --14dae93410736817c704bf938d89 Content-Type: text/plain; charset=ISO-8859-1 Hi, Endpoints MUST NOT send a close frame with close code of 1005, 1006 or 1015. What should we do when received such a frame from a broken endpoint? It seems there's no text specifying this. I think this should be taken as protocol error. The endpoint received such a bad close frame should _Fail the WebSocket Connection_ and invoke onclose() with code=1006 and wasClean=false. Thoughts? Takeshi --14dae93410736817c704bf938d89 Content-Type: text/html; charset=ISO-8859-1
Hi,

Endpoints MUST NOT send a close frame with close code of 1005, 1006 or 1015.

What should we do when received such a frame from a broken endpoint? It seems there's no text specifying this.

I think this should be taken as protocol error. The endpoint received such a bad close frame should _Fail the WebSocket Connection_ and invoke onclose() with code=1006 and wasClean=false.

Thoughts?

Takeshi
--14dae93410736817c704bf938d89-- From arman@noemax.com Wed May 9 02:08: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 7872A21F85B4 for ; Wed, 9 May 2012 02:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, MISSING_MIMEOLE=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 BqzREdkZDOzv for ; Wed, 9 May 2012 02:08:32 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2723D21F85A8 for ; Wed, 9 May 2012 02:08:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1336554505; x=1337159305; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=Y+G+pFE3hAH7l0fz6+znmNGm46I=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=zLkvzCs5lHSX28UVgTxhUrATmZ/WEXFes6RVianlrTeWDuUYNl3aj277hS/5Lu1EF8eG2wze+GIx4iAT1F6XAbRh3MfyVZmXERI2hok02tFvuoE7Szq5m1tiEsjNYvtcA32tuhAUGdlUUjZoSWbbOTT2RkWDUSYW7QypSeRyTok= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id TOR30124; Wed, 09 May 2012 12:08:24 +0300 From: "Arman Djusupov" To: "'Takashi Toyoshima'" , "'Alexey Melnikov'" References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> In-Reply-To: Date: Wed, 9 May 2012 12:08:12 +0300 Message-ID: <000001cd2dc3$47206370$d5612a50$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 14.0 Importance: High Thread-Index: AQIc7uc3s94HhOFEXTbWy+U/mTL0ywGYB2NHAu5V0q6V/XUnoA== Content-Language: en-us Cc: hybi@ietf.org, 'Peter Thorson' Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 09:08:33 -0000 Since WS is a duplex transport it should not differentiate the client = from the server except during the handshake phase. I think we should assume = that in this context the server is not meant to be the side that accepts a connection but the side that processes the message. It should be correct = to use 1011 both on the server and on the client side. For this reason the specification might need a change in the error code name and = description; suggestion: >From : "Internal Server Error" To: "Internal Error" Description, from : "1011 indicates that a server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request." To: "1011 indicates that a remote endpoint is terminating the = connection because it encountered an unexpected condition that prevented it from fulfilling the request." =20 With best regards, Arman -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takashi Toyoshima Sent: Wednesday, May 09, 2012 7:03 AM To: Alexey Melnikov Cc: hybi@ietf.org; Peter Thorson Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error Hi hybi, Is this discussion valid also for browser side implementation? My concern is that what error code should be sent if a browser got an internal error. On Tue, Nov 29, 2011 at 11:18 PM, Alexey Melnikov wrote: > Peter Thorson wrote: >> >> This issue came up while polishing up the error handling code for my=20 >> WS implementation. There doesn't seem to be a websocket close code=20 >> equivalent to HTTP 500/Internal server error. >> >> I would like to handle situations where my endpoint catches an=20 >> internal logic error and knows that continuing the connection will=20 >> probably result in bad/unknown behavior but knows that it is safe=20 >> enough to close the connection cleanly. >> >> Example: I am a server and my handler for processing websocket=20 >> messages is interpreted code and that code has a syntax error. The=20 >> websocket server itself is fine and can safely close the connection=20 >> but clearly cannot process messages until someone fixes the missing=20 >> semicolon somewhere. In an HTTP server I would return 500/Internal=20 >> Server error to indicate that something on the server end screwed up=20 >> and that there is probably more information in the server log files = to diagnose further. >> >> None of the current close codes (except 1006/abnormal closure - which = >> isn't allowed on the wire) really fit. I'd rather not just drop the=20 >> connection uncleanly/send back empty close frame since that provides=20 >> no information about what happened and makes figuring out whose logs=20 >> I should be looking at as an end application developer difficult.=20 >> Browsers only report the status code itself and not the reason so=20 >> sending a normal/going away error code with a more specific reason is = >> less helpful. What are other implementations doing in this case?=20 >> Would another close code for internal server error make sense? > > Let's use 1011 for this (Unless I already suggested it be used for=20 > something else. Please correct me if I did.): > > 1011 > =A0 =A0 =A01011 indicates that a server is terminating the connection > =A0 =A0 =A0because it has encountered an unexpected condition which=20 > prevented > =A0 =A0 =A0it from fulfilling the request. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From arman@noemax.com Wed May 9 02:16:06 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 297BD21F85BE for ; Wed, 9 May 2012 02:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 ki6nYmo39Te6 for ; Wed, 9 May 2012 02:16:04 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7C25121F85BD for ; Wed, 9 May 2012 02:16:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1336554963; x=1337159763; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=WsrzRXCAB46T5FY0IUAM1CxK0i4=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=FU1KAqKucNImn4Y48SQmRoudZvwzMnlxVgjE/GSr7BJn9wiiSGnQfOENHiKcySzm6wamUm2EPCxX+c9eFSBxn8577dJ7XMaWIptHMJ5WCGLVmh8fZPB+5xO6lW8mWh0FANNBui2M8qLfpZOCUpE1UWUVg9+RVX93eKAbm0zIjaM= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id TOZ39502; Wed, 09 May 2012 12:16:02 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Wed, 9 May 2012 12:15:50 +0300 Message-ID: <000401cd2dc4$581455a0$083d00e0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01CD2DDD.7D629F10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHUE29/d9SwNWfHKAsmTPfvXQs8RJazYKtw Content-Language: en-us Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 09 May 2012 09:16:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0005_01CD2DDD.7D629F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. The connection is getting closed anyway, such an event only requires to be logged and somehow reported to the application. The handling that you suggested would do fine. A more "kind" alternative would be to send a close frame with 1002 "Protocol Error" so that the remote side would be able to realize that there is something wrong with their implementation, provided of course that they log close frame codes. With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Wednesday, May 09, 2012 8:12 AM To: hybi@ietf.org Subject: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 Hi, Endpoints MUST NOT send a close frame with close code of 1005, 1006 or 1015. What should we do when received such a frame from a broken endpoint? It seems there's no text specifying this. I think this should be taken as protocol error. The endpoint received such a bad close frame should _Fail the WebSocket Connection_ and invoke onclose() with code=1006 and wasClean=false. Thoughts? Takeshi ------=_NextPart_000_0005_01CD2DDD.7D629F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes. The connection is getting closed anyway, such an event only = requires to be logged and somehow reported to the application. The = handling that you suggested would do fine.

 

A more “kind” alternative would be to send a close frame = with 1002 “Protocol Error” so that the remote side would be = able to realize that there is something wrong with their implementation, = provided of course that they log close frame = codes.

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Wednesday, May 09, 2012 8:12 = AM
To: hybi@ietf.org
Subject: [hybi] RFC6455 = clarification: when received close code of 1005, 1006, = 1015

 

Hi,

 

Endpoints MUST NOT send a close frame with close code = of 1005, 1006 or 1015.

 

What should we do when received such a frame from a = broken endpoint? It seems there's no text specifying = this.

 

I = think this should be taken as protocol error. The endpoint received such = a bad close frame should _Fail the WebSocket Connection_ and invoke = onclose() with code=3D1006 and = wasClean=3Dfalse.

 

Thoughts?


Takeshi

------=_NextPart_000_0005_01CD2DDD.7D629F10-- From webmaster@zaphoyd.com Wed May 9 07:57: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 7580121F8522 for ; Wed, 9 May 2012 07:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Tzl5W6mKkfV9 for ; Wed, 9 May 2012 07:57:12 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFEE11E8072 for ; Wed, 9 May 2012 07:57:12 -0700 (PDT) Received: from belgaer.uchicago.edu ([128.135.45.61]:59269) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SS8K7-0000j4-KL; Wed, 09 May 2012 10:57:03 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Peter H Thorson X-Priority: 1 (Highest) In-Reply-To: <000001cd2dc3$47206370$d5612a50$@noemax.com> Date: Wed, 9 May 2012 09:57:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B4EB3BD-9AD7-4482-B7CB-A5652FE23327@zaphoyd.com> References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> <000001cd2dc3$47206370$d5612a50$@noemax.com> To: Arman Djusupov X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: 'Takashi Toyoshima' , hybi@ietf.org Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:57:13 -0000 Hi All, My apologies for the confusion here. A number of people have asked about = this recently. My original proposal for this code = (http://www.ietf.org/mail-archive/web/hybi/current/msg09280.html) had it = named "Internal Endpoint Error" in recognition of the fact that unlike = HTTP, websocket was a bidrectional system where both "client" and = "server" could be expected to have internal errors. I didn't pay close = enough attention to the final wording that went into the RFC, which = definitely implies that it is an asymmetric server only code. This was = not the original intention. I absolutely agree that 1011 should be used by both clients and servers. = That is how my implementations behave and how the Autobahn test suite = close handshake tests interpret the spec. If there are opportunities to = amend the spec to clarify this, renaming to Internal Endpoint Error or = Internal Error and removing "server" would reduce this confusion and be = a good idea. Peter On 2012-May-9, at 4:08, Arman Djusupov wrote: >=20 > Since WS is a duplex transport it should not differentiate the client = from > the server except during the handshake phase. I think we should assume = that > in this context the server is not meant to be the side that accepts a > connection but the side that processes the message. It should be = correct to > use 1011 both on the server and on the client side. For this reason = the > specification might need a change in the error code name and = description; > suggestion: >=20 >=20 > =46rom : "Internal Server Error" To: "Internal Error" >=20 > Description, from : > "1011 indicates that a server is terminating the connection = because > it encountered an unexpected condition that prevented it from > fulfilling the request." > To: > "1011 indicates that a remote endpoint is terminating the = connection > because it encountered an unexpected condition that prevented it > from fulfilling the request." >=20 > With best regards, > Arman >=20 > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf = Of > Takashi Toyoshima > Sent: Wednesday, May 09, 2012 7:03 AM > To: Alexey Melnikov > Cc: hybi@ietf.org; Peter Thorson > Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal = Server > Error >=20 > Hi hybi, >=20 > Is this discussion valid also for browser side implementation? > My concern is that what error code should be sent if a browser got an > internal error. >=20 > On Tue, Nov 29, 2011 at 11:18 PM, Alexey Melnikov > wrote: >> Peter Thorson wrote: >>>=20 >>> This issue came up while polishing up the error handling code for my=20= >>> WS implementation. There doesn't seem to be a websocket close code=20= >>> equivalent to HTTP 500/Internal server error. >>>=20 >>> I would like to handle situations where my endpoint catches an=20 >>> internal logic error and knows that continuing the connection will=20= >>> probably result in bad/unknown behavior but knows that it is safe=20 >>> enough to close the connection cleanly. >>>=20 >>> Example: I am a server and my handler for processing websocket=20 >>> messages is interpreted code and that code has a syntax error. The=20= >>> websocket server itself is fine and can safely close the connection=20= >>> but clearly cannot process messages until someone fixes the missing=20= >>> semicolon somewhere. In an HTTP server I would return 500/Internal=20= >>> Server error to indicate that something on the server end screwed up=20= >>> and that there is probably more information in the server log files = to > diagnose further. >>>=20 >>> None of the current close codes (except 1006/abnormal closure - = which=20 >>> isn't allowed on the wire) really fit. I'd rather not just drop the=20= >>> connection uncleanly/send back empty close frame since that provides=20= >>> no information about what happened and makes figuring out whose logs=20= >>> I should be looking at as an end application developer difficult.=20 >>> Browsers only report the status code itself and not the reason so=20 >>> sending a normal/going away error code with a more specific reason = is=20 >>> less helpful. What are other implementations doing in this case?=20 >>> Would another close code for internal server error make sense? >>=20 >> Let's use 1011 for this (Unless I already suggested it be used for=20 >> something else. Please correct me if I did.): >>=20 >> 1011 >> 1011 indicates that a server is terminating the connection >> because it has encountered an unexpected condition which=20 >> prevented >> it from fulfilling the request. >>=20 >>=20 >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From alexey.melnikov@isode.com Wed May 9 12:57: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 332CC11E80CA for ; Wed, 9 May 2012 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.711 X-Spam-Level: X-Spam-Status: No, score=-102.711 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 6PgYrS-cVzFV for ; Wed, 9 May 2012 12:57:10 -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 7A9FB11E8079 for ; Wed, 9 May 2012 12:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336593422; d=isode.com; s=selector; i=@isode.com; bh=BH7heKhiUabK3W8ioMwXYpVcxpjFCEygblZkc7pomw4=; 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=GER20Huo34RS2vxQh9Crube4QpMx8kBtf5of98el9XnnPS+3JmjUA+FJM0t6irlLCJ4/Zq xQCZuu/4IVqWuMYRQVpAzRohH3qTaZqTNw+aB+LRiLyuN0RYh8RBxdXWTTWFqh6ydrTAzP XopWWD+CCvdD22Je0TWWYDNnLsYpIeQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 9 May 2012 20:57:01 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FAACC40.6040308@isode.com> Date: Wed, 09 May 2012 20:57:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Takeshi Yoshino References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 09 May 2012 19:57:11 -0000 On 09/05/2012 06:12, Takeshi Yoshino wrote: > Hi, Hi Takeshi, > Endpoints MUST NOT send a close frame with close code of 1005, 1006 or > 1015. > > What should we do when received such a frame from a broken endpoint? > It seems there's no text specifying this. I think Garbage-In-Garbage-Out rule applies here, but as this affect the WebSocket API, you are right we should clarify this. > I think this should be taken as protocol error. The endpoint received > such a bad close frame should _Fail the WebSocket Connection_ and > invoke onclose() with code=1006 and wasClean=false. 1006 seems as good of a code for this as any. Does "wasClean=false" matter in this case? Alternatively, we can reserve a new "you lied to me about your reason" close code. > Thoughts? > > Takeshi From tyoshino@google.com Wed May 9 19:52: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 95FFA9E800C for ; Wed, 9 May 2012 19:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.035, 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 0-cZrDazqL35 for ; Wed, 9 May 2012 19:52: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 0A5799E800B for ; Wed, 9 May 2012 19:52:04 -0700 (PDT) Received: by yenq13 with SMTP id q13so1209666yen.31 for ; Wed, 09 May 2012 19:52: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=i6D3BbKCF8fgi+RO/9WNltcV9QfHRyMgyEuaewM/VUU=; b=odKw2FV6FPlP4RkML+PBC8oqrUANzGxGQN0NEbPRgF17XlX81SSPt0O3ycm72Hxc2f DLwi7NhOFJXeNXZwQvoKegs9Vtu1HIA5yacHOUqGhISWFX2HVU3wag7f4pv+SitwsIpw kGiO8l9riSXVZtukdMVZTT56HukSjZZ0vDdbwZ/Bqi3x0sCfLM1nP9pxA2etDuxHhQmk 3SIpaQx439Fyir95yhQZoOGu3EnrFoUJdFQrEh6sHVZz3t3vpQOPuxXxjKmAqf+umNTE bhegzk1sb87ECMdShVoHIsB5jYtGrP87tuQ9bwvTCYdaYAHReFvQ0gzlvbPatHFHRiT4 d4BQ== 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=i6D3BbKCF8fgi+RO/9WNltcV9QfHRyMgyEuaewM/VUU=; b=JE9vl7+eKgrM8mXe0fPimSjHEh147MLOd1yZKE5cGaLTJ006Q0yeOZTpUIelQ51HeI e08vEQcTHa4JVSvzkXq9jLnqWPVYExXG5y++tCq4Um39kGwzQq03W3f6tQw2gzYWYeRT LCgnKkJwr7HwEHNpvzSQrHdDBOsn4xQYvOZkvGyepVRQZ8rhhXzVLkUuxQbyeu+U39ZC uzSMIUwW/X3fVp0+/kt5P4VPkLV/3/X4a0SgOB0WhlUkOyEUZEIEQwV4+EqMIxrSF0lZ jwWt6SzG/ps0HH5SR4JScTB50m9PhewZtPzL/yI6RSdI+R6LwyU2ga5Fj5k9odYSpfnV FsyQ== Received: by 10.50.158.234 with SMTP id wx10mr2671430igb.71.1336618324367; Wed, 09 May 2012 19:52:04 -0700 (PDT) Received: by 10.50.158.234 with SMTP id wx10mr2671425igb.71.1336618324231; Wed, 09 May 2012 19:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Wed, 9 May 2012 19:51:43 -0700 (PDT) In-Reply-To: <4FAACC40.6040308@isode.com> References: <4FAACC40.6040308@isode.com> From: Takeshi Yoshino Date: Thu, 10 May 2012 11:51:43 +0900 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=14dae93410a96a84fe04bfa5b4b4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmDOr7h6A5sIN0v+rEmI5a4YGma//oJFb9dTvwCTI3OJpMnEtuu5u+Y4IPNlMxeIi432h394u4QGajo8KKtOIdUiZWE6U7l8u8+gTdSy2ZY8wSpx5KaIecpVz0WlltzF8fhyHEj Cc: hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 10 May 2012 02:52:05 -0000 --14dae93410a96a84fe04bfa5b4b4 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, On Thu, May 10, 2012 at 4:57 AM, Alexey Melnikov wrote: > I think this should be taken as protocol error. The endpoint received such >> a bad close frame should _Fail the WebSocket Connection_ and invoke >> onclose() with code=1006 and wasClean=false. > > 1006 seems as good of a code for this as any. Does "wasClean=false" > matter in this case? > As the received close frame is considered to be broken, we should not take this as successful completion of closing handshake. I think it should be taken as "_The WebSocket Connection is Closed_ but not _cleanly_" which results in wasClean=false for the WebSocket API's case. > Alternatively, we can reserve a new "you lied to me about your reason" > close code. > We can. But as Arman suggested, we can also just use the existing code 1002 to tell the remote endpoint that it's broken when the closing handshake initiator is the remote endpoint. --14dae93410a96a84fe04bfa5b4b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexey,

On Thu, May 10, 2012 at 4:57 AM, Alexey Me= lnikov <alexey.melnikov@isode.com> wrote:
I think this should be taken as protocol error. The endpoint received such = a bad close frame should _Fail the WebSocket Connection_ and invoke onclose= () with code=3D1006 and wasClean=3Dfalse.
1006 seems as good of a code for this as any. Does "wasClean=3Dfalse&q= uot; matter in this case?

As the receiv= ed close frame is considered to be broken, we should not take this as succe= ssful completion of closing handshake. I think it should be taken as "= _The WebSocket Connection is Closed_ but not _cleanly_" which results = in wasClean=3Dfalse for the WebSocket API's case.
=A0
Alternatively, we can reserve a new "you lied to me about your reason&= quot; close code.

We can. But as Arman = suggested, we can also just use the existing code 1002 to tell the remote e= ndpoint that it's broken when the closing handshake initiator is the re= mote endpoint.

--14dae93410a96a84fe04bfa5b4b4-- From tyoshino@google.com Wed May 9 22:25: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 E0DC121F85AE for ; Wed, 9 May 2012 22:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.033, 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 YQ2nJq95RYgi for ; Wed, 9 May 2012 22:25: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 E52FE21F851B for ; Wed, 9 May 2012 22:25:08 -0700 (PDT) Received: by lagj5 with SMTP id j5so895137lag.31 for ; Wed, 09 May 2012 22:25:07 -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=X9wQiiVoCLmdDLbd08mPzCTA2Ds4Pgtqg3xpsuhx8IU=; b=arskKzNO1NRL2vuLBwFq1Cm7xKZ5pwOeQzyUNGWtxX18nkWLUKjJ4b1XNmhVSwSeqL kxTptKCzCC3TybjnEg0uoVfO2vDQBH8bsmV0ceXBgh+zVxs2tmIDcPZppVZCRPqQdiLp 9vgxU/Kfn0e8+K88lb+lrSdY3hPw/WSQBV+GjE1v/4N4KvA69zQCMJ9P/DkFXykNSsUi msMUCVMItujqXew0JPKPA6LWd9i7itx6CPJs0o7l8UiCxbBDFNMz8aK4+I90aNIffs4i Ojr01oszHE/0YXpLhapZ0AxKrKn8O6Q1Tib4LLJHTpkJKX9itXU5KG7jtLZOr0iatdrg O7bg== 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=X9wQiiVoCLmdDLbd08mPzCTA2Ds4Pgtqg3xpsuhx8IU=; b=KxCqDOk6/82C8LEOT3ZsdM4V0OGKBMIU37bPd6NRG3JW3AxYWfqayx/waFtyShL+FB g4uDJN3IvsxpKsSshFluUOaD//0i7iEJdC7tRjlI03ZbMxsSvK2Wx4D/29oRaHVdHyfo kXqWwJYA3lXWpa4RFLfSgPGtVcZ3yeBN5lxKtkHo/FYeiQjbTh6nz+svAhxy4QXZs0Ys gA2212xgJFiLcbSU1Ko1FC441h9ForUvXQAiFllBeVbzaf0pR6hoKwdsczOrhNdeibzr F1Pi4UvBpDFx2UnjeMT/B9rACphUyBQqL//6klh7bRFAl+A7eZ/QJzeNaH9S6Mbmuq5y vqbA== Received: by 10.112.49.131 with SMTP id u3mr1402217lbn.14.1336627507839; Wed, 09 May 2012 22:25:07 -0700 (PDT) Received: by 10.112.49.131 with SMTP id u3mr1402205lbn.14.1336627507676; Wed, 09 May 2012 22:25:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.165 with HTTP; Wed, 9 May 2012 22:24:47 -0700 (PDT) In-Reply-To: <4B4EB3BD-9AD7-4482-B7CB-A5652FE23327@zaphoyd.com> References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> <000001cd2dc3$47206370$d5612a50$@noemax.com> <4B4EB3BD-9AD7-4482-B7CB-A5652FE23327@zaphoyd.com> From: Takeshi Yoshino Date: Thu, 10 May 2012 14:24:47 +0900 Message-ID: To: Peter H Thorson Content-Type: multipart/alternative; boundary=bcaec554001acac62b04bfa7d717 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6I8Hg/R66Poiu8NdxAulKydeyXpbVQYXuaTAaD04DpqkXbA0fBrVQ8FPAKBDHXTEAmXdAHzp2nPDBG2Zcd7w4liZa0Pn/k0/58b5AkgD+Zn4spOugMXxqCF/k4WhS95bD1wCZ Cc: Takashi Toyoshima , hybi@ietf.org Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 05:25:10 -0000 --bcaec554001acac62b04bfa7d717 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson wrote: > I absolutely agree that 1011 should be used by both clients and servers. > That is how my implementations behave and how the Autobahn test suite close > handshake tests interpret the spec. If there are opportunities to amend the > spec to clarify this, renaming to Internal Endpoint Error or Internal Error > and removing "server" would reduce this confusion and be a good idea. +1 Takeshi --bcaec554001acac62b04bfa7d717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson= <webmaster@zaphoyd.com> wrote:
I absolutely agree that 1011 should be used by both clients and servers. Th= at is how my implementations behave and how the Autobahn test suite close h= andshake tests interpret the spec. If there are opportunities to amend the = spec to clarify this, renaming to Internal Endpoint Error or Internal Error= and removing "server" would reduce this confusion and be a good = idea.

+1

Takeshi
--bcaec554001acac62b04bfa7d717-- From internet-drafts@ietf.org Wed May 9 22:37: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 7D0D121F85B4; Wed, 9 May 2012 22:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0RMnedB4O8q; Wed, 9 May 2012 22:37:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4421F8518; Wed, 9 May 2012 22:37:09 -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.02 Message-ID: <20120510053709.32518.49769.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 22:37:09 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 05:37:10 -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-03.txt Pages : 16 Date : 2012-05-09 This specification defines a WebSocket extension that adds per-frame compression functionality to the WebSocket Protocol. It compresses the "Application data" portion of WebSocket data frames using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each frame. This specification provides one compression method available for the extension using DEFLATE. 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-03.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-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-perframe-compres= sion/ From tyoshino@google.com Wed May 9 22:47: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 A2F2B21F8517 for ; Wed, 9 May 2012 22:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.032, 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 vlpaJ+o9EHb4 for ; Wed, 9 May 2012 22:47:04 -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 6EAFC21F8516 for ; Wed, 9 May 2012 22:47:04 -0700 (PDT) Received: by lagj5 with SMTP id j5so906321lag.31 for ; Wed, 09 May 2012 22:47:03 -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=wvm3wJWatjypf+i8yuNwDGUrUUX++nfEqcN4t1d/WbA=; b=W3QqXIZYGpuPo+lt2UWsdY9eSWkwyZAYgxKXNSGnlVH1nDq1C1lKBMQDt+/8+fpcrD xWglzQWy9YqAfzGXwBFyarHNmE1i14R4SW0yBnBlhWeEUBi4lT9zU7wwv86MTz0kyWXP 72mlEHmy+L2faiVAQF/5cM2vkCb3jNQs8mTWP/VrjDLINstR+bZX94swaX770SMp0pdl L6MAzktK/77Z7u0CmTSkFp+KjA8+4rcv3FiisSv3ALyTLLZLuDJhyAPNC49FqRiW32Er +uTSoMGtilt6oW4hzeWIa39XLw1aXpa0IlxY7GOqbMm27SPFqEmKz4kUG+6QI0hmo81G guPA== 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=wvm3wJWatjypf+i8yuNwDGUrUUX++nfEqcN4t1d/WbA=; b=BTjBcH0TB3BHOshNvUfiNX+BJ2ojZUeO6F5OWr4Naz7l2X2wKgJsyo8lmQ1yVoc9NL XWb0DtHbhn6CuDPtwuDMf5YZdCzCib+axFz8N8ZAhdLBGWU4Qpq5BndCk7O5lUueHq82 wLyiZLGConAMgO8GUUQob7KsLTreWuvQJTOskjsZMyWAnIIx3wEtBSLHVGbzAYiLdpQb erAT6E3uT18YzWfovqk6FqL/E34JSIxvk96J6kem3mPk3PtkLg2NOOUy6HTncDkY3S9o I6Ysa68IzjZrRWWpkjWMHl/DE9X6SIx0YducHcjVwjjR7JhBR4uTTDYbyLdL0xoaOIyq hgNw== Received: by 10.152.111.200 with SMTP id ik8mr1962lab.15.1336628823461; Wed, 09 May 2012 22:47:03 -0700 (PDT) Received: by 10.152.111.200 with SMTP id ik8mr1952lab.15.1336628823336; Wed, 09 May 2012 22:47:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.165 with HTTP; Wed, 9 May 2012 22:46:43 -0700 (PDT) In-Reply-To: <20120510053709.32518.49769.idtracker@ietfa.amsl.com> References: <20120510053709.32518.49769.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 10 May 2012 14:46:43 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d040891313625b804bfa8267e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkBGLvZ0Hvx2P9d3BVAFu/J7lFvlzZ59et1Wzlz6gksDA9/20I8RrLEQRsnZ4pq1fLrtutQQQrYxo1YAPnb74fisKHv1yUERlfq/YOd724W4EtWzjMIGKJ0c0QjYZLmevYM1w7P Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-03.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 05:47:05 -0000 --f46d040891313625b804bfa8267e Content-Type: text/plain; charset=ISO-8859-1 Hi, I've published a new draft -03 of compression spec. Sorry for updates in a row. Since the typo on the token name is serious, I did it now. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-perframe-compression-03.txt Changes - typo on extension token name "perframe-comrpess" -> "perframe-compress" - typos and English grammar Thanks to Peter Thorson for reviewing and reporting issues. Takeshi --f46d040891313625b804bfa8267e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I've published a new draft -03 of compression sp= ec.=A0Sorry for updates in a row. Since the typo on the token name is serio= us, I did it now.
- typo on extension token name = "perframe-comrpess" -> "perframe-compress"
- typos and English grammar

Thanks to Peter = Thorson for reviewing and reporting issues.

Takeshi
--f46d040891313625b804bfa8267e-- From alexey.melnikov@isode.com Thu May 10 00:57: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 7249421F85D4 for ; Thu, 10 May 2012 00:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.139 X-Spam-Level: X-Spam-Status: No, score=-101.139 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, 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 FFJ36dozEOqS for ; Thu, 10 May 2012 00:57:53 -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 8161A21F85C3 for ; Thu, 10 May 2012 00:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336636670; d=isode.com; s=selector; i=@isode.com; bh=4i+huwltsaSbnC8T5rboWApLeC4SVKnhZMmCgzdZF74=; 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=GMjYSOD+rDuBY52M6hNL7p5umqAqWk5VJ0wecFTFN4yBOybwn7u7uiaxKXLcC8xMgSenOM XQD9l+SAIGUw1uoxJhksJlv+YXAxM7Zw9xbgblidjYUOIRc5QLodJM9/ZL2V+a+QmAh46E Q3KTgS7QQl5hQWbLlSeDDSKBgFiGVAE=; Received: from [188.29.120.70] (188.29.120.70.threembb.co.uk [188.29.120.70]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 10 May 2012 08:57:50 +0100 References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> <000001cd2dc3$47206370$d5612a50$@noemax.com> <4B4EB3BD-9AD7-4482-B7CB-A5652FE23327@zaphoyd.com> In-Reply-To: Message-Id: <61AED05D-0D26-4DDB-A1BC-8F8E20931D63@isode.com> X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Thu, 10 May 2012 08:57:36 +0100 To: Takeshi Yoshino MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-5EF98D2B-8F6C-4828-81A4-AE62EB41032E Cc: Takashi Toyoshima , "hybi@ietf.org" , Peter H Thorson Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 07:57:54 -0000 --Apple-Mail-5EF98D2B-8F6C-4828-81A4-AE62EB41032E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 10 May 2012, at 06:24, Takeshi Yoshino wrote: > On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson w= rote: > I absolutely agree that 1011 should be used by both clients and servers. T= hat is how my implementations behave and how the Autobahn test suite close h= andshake tests interpret the spec. If there are opportunities to amend the s= pec to clarify this, renaming to Internal Endpoint Error or Internal Error a= nd removing "server" would reduce this confusion and be a good idea. >=20 > +1 It looks like everybody is in agreement on this change. As the Designated Ex= pert for the registry I will ask IANA to update the definition. --Apple-Mail-5EF98D2B-8F6C-4828-81A4-AE62EB41032E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hi,

On 10 May 2012, at 06:24, Takeshi Yoshino <tyoshino@google.com> wrote:

On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson <webmaster@zaphoyd.com> wrote:
I absolutely agree that 1011 should be used by both clients and servers. That is how my implementations behave and how the Autobahn test suite close handshake tests interpret the spec. If there are opportunities to amend the spec to clarify this, renaming to Internal Endpoint Error or Internal Error and removing "server" would reduce this confusion and be a good idea.

+1

It looks like everybody is in agreement on this change. As the Designated Expert for the registry I will ask IANA to update the definition.

--Apple-Mail-5EF98D2B-8F6C-4828-81A4-AE62EB41032E-- From toyoshim@google.com Thu May 10 21:52:12 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 88A0321F84CE for ; Thu, 10 May 2012 21:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2vnNBrvmJJ+S for ; Thu, 10 May 2012 21:52:11 -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 348EE21F84C8 for ; Thu, 10 May 2012 21:52:04 -0700 (PDT) Received: by lagv3 with SMTP id v3so416336lag.31 for ; Thu, 10 May 2012 21:52:04 -0700 (PDT) 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 :x-system-of-record; bh=cK4Ji0e23fnjuGiaR5oOq+Yrh/VfBB9Spi261TC30GE=; b=Js5QY/8nYC7yDzF7kfDskUDVzwH/1Vt8RA34yxw59wQnSHMMHOZkKwKcYyAgxtGQgo uC72b4Afmmm1qpZEaDxgJEFs9x4629Drnpwd4xjS/KNlYIdsFUIrZ5Bvk1MG2R3tx6+Q 19yaRted2afWEbbGJTIt+zm0oXczrotLnJE6zx++zI7ydXCAawNX09v4ive+wAd/IP+E htBHamwRgDO3fAMnzsyvObkjQVjWvEPgVb4P8m/kAJ8jDlP5IZ3mAigl/it5oBkjpyR0 WfvnSRYj/kn1IVgoFWNHYe7zR2zPEY/uVyNVordrRwA5+eAxzIyT+KhVFh+TzrUu80wb 9SPQ== 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 :x-system-of-record:x-gm-message-state; bh=cK4Ji0e23fnjuGiaR5oOq+Yrh/VfBB9Spi261TC30GE=; b=BpCgy3MHDCBfBlAhBNF90fw2i4gLDHDdjLfjV/SFd4QIriKKUH4z+Qh9gRiKN7LV/V 3rpj8uBUSX0Ue9aOTjBKPEwRlk9Yi0xUDTY0shu2saV7YmWrlOgiXPFaxB0+h3g6ghIC NEKs1ZOKrPM9jLpNmTkKf9DZfSDBrVV+YZumrrILQfiwfCVS3ArZonOCgo5J1I2h/JE8 wgOfR9JS7Brl7EqAGTI+rQL8wUC+acwWxTrOWRq5I4wo1Ex54Pqx3yce4NaZR4dbvc0Q fBDwP/+yC5e02c2MbT4IF4MsLqiqzEQRDWmePKKeb8lM1BEZGfDgGsq9pNgLnPtH4QVm LFSA== Received: by 10.112.49.131 with SMTP id u3mr3437695lbn.14.1336711924153; Thu, 10 May 2012 21:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.49.131 with SMTP id u3mr3437685lbn.14.1336711923995; Thu, 10 May 2012 21:52:03 -0700 (PDT) Sender: toyoshim@google.com Received: by 10.112.49.201 with HTTP; Thu, 10 May 2012 21:52:03 -0700 (PDT) In-Reply-To: <61AED05D-0D26-4DDB-A1BC-8F8E20931D63@isode.com> References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> <000001cd2dc3$47206370$d5612a50$@noemax.com> <4B4EB3BD-9AD7-4482-B7CB-A5652FE23327@zaphoyd.com> <61AED05D-0D26-4DDB-A1BC-8F8E20931D63@isode.com> Date: Fri, 11 May 2012 13:52:03 +0900 X-Google-Sender-Auth: ulG9SEaHr9MeL-1OrW0juJQXBBQ Message-ID: From: Takashi Toyoshima To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnpSqWwI4MowAzfJHOcZOpqcuT1Rtr4Dok/VvX4FfXXO9CVqou3HgZBNAptAvwzvosFNhTsS8nmFkup2Su7Zzd56R1MZu/OqB3SnV9kYqKOGKZEFNIIs5gIsiUbNCQrBuJjNLGq Cc: "hybi@ietf.org" , Peter H Thorson Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 04:52:12 -0000 Thank you Alexey, and persons who post comments. Cheers, On Thu, May 10, 2012 at 4:57 PM, Alexey Melnikov wrote: > Hi, > > > On 10 May 2012, at 06:24, Takeshi Yoshino wrote: > > On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson > wrote: >> >> I absolutely agree that 1011 should be used by both clients and servers. >> That is how my implementations behave and how the Autobahn test suite close >> handshake tests interpret the spec. If there are opportunities to amend the >> spec to clarify this, renaming to Internal Endpoint Error or Internal Error >> and removing "server" would reduce this confusion and be a good idea. > > > +1 > > > It looks like everybody is in agreement on this change. As the Designated > Expert for the registry I will ask IANA to update the definition. > From tyoshino@google.com Thu May 10 22:55:37 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 B5E2821F8637 for ; Thu, 10 May 2012 22:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.030, 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 RMVA-74KL-57 for ; Thu, 10 May 2012 22:55:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF2DE21F862F for ; Thu, 10 May 2012 22:55:36 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so3356860obb.31 for ; Thu, 10 May 2012 22:55:36 -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=bRXlx2leUsWyPkeXJR9lLwjxAvzIS+BnwFoiwqGn630=; b=f6FUF9qWQIs3/xktUB40ml/Fv4J9TGXoxLI+Of3CuvZZ4zUAazCm8XBavsrZ/16ydg cLA7TaTPZEE+YfdXR7qQKqJrJMuGpf0AtBd21I2XBURY7snyfoTCFh2OJnWz/nITFTi0 ZCX1LtjYEorXlXs+goBvZlq5pwLWt7RGS6DrtQDqIRnDmfFypRyinI8lbJqFkc7bwrNm JN+1fXraa8fqeF45b2sjTKHYm4diB4caDMI7JGmOfUVHXT+gtBJsnvu6SRnIZ4Wyp3r2 o/kzWMS0atJVCAfi3HrQVwKHPwKorl0R+l9dD4dkkqnULvMH+bH/SLBy9ByPoB1uhUvS rr+w== 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=bRXlx2leUsWyPkeXJR9lLwjxAvzIS+BnwFoiwqGn630=; b=b4ypWp4xnTzCzwQkapGHQhFjhlPdv2HaxTMeyvoWOVwzFCC0r6b3EoLqpOZqWQ+/vK 0nhlDze0HnEQdDMpl9Os9rJR8u9eqCZWkAXhVDmf6+Ok5BBjoTsZgTjDqlwtOKuKSw41 oBDA+ZiAH6nXeUx7C2owIrvz1lAFZ62s2SdsYrKDfXfNgr31J9kYjmmfX70UAfZ7v5M6 CR0XUAVoPS5hhorKfAsSKN2Qetn8Olzs0INyinOrZ9j9LwT1yvhJZRHZZYd4qjANBJei 5Sg6HtOWjOClUzEid4HKJ7OtYk8yuTuhBpgWJU9QrHk+BasTfpY870uDd567Cmgimmtz iE0A== Received: by 10.50.40.202 with SMTP id z10mr871548igk.64.1336715736209; Thu, 10 May 2012 22:55:36 -0700 (PDT) Received: by 10.50.40.202 with SMTP id z10mr871541igk.64.1336715736063; Thu, 10 May 2012 22:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Thu, 10 May 2012 22:55:15 -0700 (PDT) From: Takeshi Yoshino Date: Fri, 11 May 2012 14:55:15 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae9340ca99d1d3d04bfbc6235 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6cy+FEfgIZhyk3l6uv8VeVw4Cmyd3pzwR+ygtk1E42nTnSvBUFN5GKBJbU4jWutE4tZCD3L4FBIW3m6S0usTUZQu6VWSo5xp9XQGcRVWm257mG9gcORHwR/9fpyO5HHokjrBU Subject: [hybi] Handling multiple compression method entries of the same extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 05:55:37 -0000 --14dae9340ca99d1d3d04bfbc6235 Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm going to clarify whether multiple method descriptions with the same method name is allowed to be listed in the perframe-compress's method parameter or not. The benefit of allowing multiple entries is that the client can offer the same extension with different parameter settings to try to use the best parameter both endpoints can agree. There's also a problem with this. The client cannot identify which of the entries has been accepted by the remote endpoint. Options we can take are: ---- 1-a) disallow use of multiple entries 2-a) tag requested methods Request: perframe-compress: method="deflate; id=0; foo=200, deflate; id=1; foo=100, deflate; id=2; foo=0" Response: perframe-compress: method="deflate; id=1; bar=3.14" 2-b) put "rejected" that means the method placed at the corresponding position in the requested-method-list has been rejected. Request: perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0" Response: perframe-compress: method="rejected, deflate; bar=3.14, rejected" 2-c) send back not a method description but the index of the description to accept and server-side parameter Request: perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0" Response: perframe-compress: accept=1; bar=3.14 2-d) ack the requested parameters by echoing them back to make the accepted-method-desc self-contained (describing all negotiated parameters) Request: perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0" Response: perframe-compress: method="deflate; foo=100; bar=3.14" ---- My preference is 2-d). I'll rename max_window_bits and no_context_takeover by prefixing them. What do you think? --14dae9340ca99d1d3d04bfbc6235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I'm going to clarify whether multiple= method descriptions with the same method name is allowed to be listed in t= he perframe-compress's method parameter or not.

The benefit of allowing multiple entries is that the client can offer = the same extension with different parameter settings to try to use the best= parameter both endpoints can agree.

There's a= lso a problem with this. The client cannot identify which of the entries ha= s been accepted by the remote endpoint.

Options we can take are:

----<= /div>

1-a) disallow use of multiple entries
2-a) tag requested methods
Request:
perfra= me-compress: method=3D"deflate; id=3D0; foo=3D200, deflate; id=3D1; fo= o=3D100, deflate; id=3D2; foo=3D0"
Response:
perframe-compress: method=3D"deflate; id=3D1;= bar=3D3.14"

2-b) put "rejected" th= at means the method placed at the corresponding position in the requested-m= ethod-list has been rejected.
Request:
perframe-compress: method=3D"deflate; foo= =3D200, deflate; foo=3D100,=A0deflate; foo=3D0"
Response:
perframe-compress: method=3D"rejected, deflate; bar=3D3.14, re= jected"

2-c) send back not a method description but the i= ndex of the description to accept and server-side parameter
=
Request:
perframe-compress: method=3D"deflate; foo=3D20= 0, deflate; foo=3D100,=A0deflate; foo=3D0"
Response:
perframe-compress: accept=3D1; bar=3D3.14

2-d) ack the requested parameters by echoing t= hem back to make the accepted-method-desc self-contained (describing all ne= gotiated parameters)
Request:
perframe-compress: method=3D"deflate; foo= =3D200, deflate; foo=3D100, deflate; foo=3D0"
Response:
perframe-compress: method=3D"deflate; foo=3D100; bar=3D3.14"= ;

----

My preference is 2-d). I'll rename max_window_bits = and no_context_takeover by prefixing them.

What do= you think?

--14dae9340ca99d1d3d04bfbc6235-- From arman@noemax.com Fri May 11 06:41: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 92D9521F85D2 for ; Fri, 11 May 2012 06:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 AOJd9CHz5RRL for ; Fri, 11 May 2012 06:41:44 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 75F0221F8541 for ; Fri, 11 May 2012 06:41:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1336743699; x=1337348499; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=wO/utJhOJ6PBlSIB+9r5cB1KL9A=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=mE058uOfdVyObcU2LlLeayUpCs0Yp2AX7GYhLM+1xXYiDUw2kKUsDUMaKBTmnD9vHWmckzEJE4BqNQPPLLKVXrkMHiGxh6gkNXYY8qD91wZgaIRGHyn2O9WMcF0N7ejIP0qUvOTLVZxe7pHnsP9GGpvuyI7lBvoyh4PcuE6dD1w= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id VSA31237; Fri, 11 May 2012 16:41:37 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Fri, 11 May 2012 16:41:22 +0300 Message-ID: <001f01cd2f7b$c4dbbb70$4e933250$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CD2F94.EA2B1650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6gKbDLqkDLapj3qEgYq6eE5eHzpVp9bKg Content-Language: en-us Subject: Re: [hybi] Handling multiple compression method entries of the same extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 13:41:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CD2F94.EA2B1650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree on the 2-d) choice. What I just don't understand is why you have to prefix max_window_bits and no_context_takeover? Note that there is another point which needs to be clarified. Theoretically the max_window_bits and no_context_takeover can even be asymmetric. It is possible to implement this extension in such a manner that there is context takeover in one direction and no content takeover in the other direction. Unless I missed something, the spec does not require the server to use exactly the same parameters as the client requested. "a server MUST include an element with the "perframe-compress" extension token as its extension identifier in the "Sec-WebSocket-Extensions" header in its opening handshake. The element MUST contain exactly one extension parameter named "method". The value of the "method" extension parameter MUST be a compression method description. The compression method description MUST be a *valid response* for any of the methods listed by the client in its opening handshake." So it's a bit unclear what is a Valid response, obviously thought it is compression method specific. "An endpoint that received this parameter MUST NOT use LZ77 sliding window size greater than the size specified by this parameter to *build frames*." So this parameter affects only outbound frames and each side sets the maximum window size for the remote side, but those parameters are not currently required to be the same. For example, the client can limit the server to 12bit window, while the server can set the client maximum to 15; that would mean that the client is free to use a larger window for sending messages, while the server has to stick to lower values. There are cases in which such a design does make sense. We need to clarify if the parameters must be symmetric or if they may be asymmetric. If we limit the parameters to be symmetric, I believe this limitation should specific to the "deflate" method, because other compression methods might actually favor an asymmetric configuration. By using option 2-d) an asymmetric configuration is possible. Personally I would even like to suggest that we support the asymmetric use of compression methods (i.e. a different compression method in each direction) but I'm afraid that someone might point his flame thrower at me :) Anyone else care to support this? (the asymmetric compression methods, not the flame thrower.) With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Friday, May 11, 2012 8:55 AM To: hybi@ietf.org Subject: [hybi] Handling multiple compression method entries of the same extension Hi, I'm going to clarify whether multiple method descriptions with the same method name is allowed to be listed in the perframe-compress's method parameter or not. The benefit of allowing multiple entries is that the client can offer the same extension with different parameter settings to try to use the best parameter both endpoints can agree. There's also a problem with this. The client cannot identify which of the entries has been accepted by the remote endpoint. Options we can take are: ---- 1-a) disallow use of multiple entries 2-a) tag requested methods Request: perframe-compress: method="deflate; id=0; foo=200, deflate; id=1; foo=100, deflate; id=2; foo=0" Response: perframe-compress: method="deflate; id=1; bar=3.14" 2-b) put "rejected" that means the method placed at the corresponding position in the requested-method-list has been rejected. Request: perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0" Response: perframe-compress: method="rejected, deflate; bar=3.14, rejected" 2-c) send back not a method description but the index of the description to accept and server-side parameter Request: perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0" Response: perframe-compress: accept=1; bar=3.14 2-d) ack the requested parameters by echoing them back to make the accepted-method-desc self-contained (describing all negotiated parameters) Request: perframe-compress: method="deflate; foo=200, deflate; foo=100, deflate; foo=0" Response: perframe-compress: method="deflate; foo=100; bar=3.14" ---- My preference is 2-d). I'll rename max_window_bits and no_context_takeover by prefixing them. What do you think? ------=_NextPart_000_0020_01CD2F94.EA2B1650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree on the 2-d) choice. What I just don’t understand is why = you have to prefix max_window_bits and = no_context_takeover?

 

Note that there is another point which needs to be clarified. = Theoretically the max_window_bits and no_context_takeover can even be = asymmetric. It is possible to implement this extension in such a manner = that there is context takeover in one direction and no content takeover = in the other direction. Unless I missed something, the spec does not = require the server to use exactly the same parameters as the client = requested.

 

“a server MUST include an element with the = "perframe-compress" extension token as its extension = identifier in the "Sec-WebSocket-Extensions" header in its = opening handshake.  The element MUST contain exactly one extension = parameter named "method".  The value of the = "method" extension parameter MUST be a compression method = description.  The compression method description MUST be a *valid = response* for any of the methods listed by the client in its opening = handshake.”

 

So it’s a bit unclear what is a Valid response, obviously = thought it is compression method specific.

 

“An endpoint that received this parameter MUST NOT use LZ77 = sliding window size greater than the size specified by this parameter to = *build frames*.”

 

So this parameter affects only outbound frames and each side sets the = maximum window size for the remote side, but those parameters are not = currently required to be the same. For example, the client can limit the = server to 12bit window, while the server can set the client maximum to = 15; that would mean that the client is free to use a larger window for = sending messages, while the server has to stick to lower values. There = are cases in which such a design does make = sense.

 

We need to clarify if the parameters must be symmetric or if they may = be asymmetric. If we limit the parameters to be symmetric, I believe = this limitation should specific to the “deflate” method, = because other compression methods might actually favor an asymmetric = configuration.

 

By using option 2-d) an asymmetric configuration is possible. =

 

Personally I would even like to suggest that we support the = asymmetric use of compression methods (i.e. a different compression = method in each direction) but I’m afraid that someone might point = his flame thrower at me :) Anyone else care to support this? (the = asymmetric compression methods, not the flame = thrower…)

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Friday, May 11, 2012 8:55 = AM
To: hybi@ietf.org
Subject: [hybi] Handling = multiple compression method entries of the same = extension

 

Hi,

 

I'm going to clarify whether multiple method = descriptions with the same method name is allowed to be listed in the = perframe-compress's method parameter or not.

 

The benefit of allowing multiple entries is that the = client can offer the same extension with different parameter settings to = try to use the best parameter both endpoints can = agree.

 

There's also a problem with this. The client cannot = identify which of the entries has been accepted by the remote = endpoint.

 

Options we can take are:

 

----

 

1-a) disallow use of multiple = entries

 

2-a) tag requested methods

Request:

perframe-compress: method=3D"deflate; id=3D0; = foo=3D200, deflate; id=3D1; foo=3D100, deflate; id=3D2; = foo=3D0"

Response:

perframe-compress: method=3D"deflate; id=3D1; = bar=3D3.14"

 

2-b) put "rejected" that means the method = placed at the corresponding position in the requested-method-list has = been rejected.

Request:

perframe-compress: method=3D"deflate; foo=3D200, = deflate; foo=3D100, deflate; = foo=3D0"

Response:

perframe-compress: method=3D"rejected, deflate; = bar=3D3.14, rejected"

 

2-c) send back not a method description but the index = of the description to accept and server-side = parameter

Request:

perframe-compress: method=3D"deflate; foo=3D200, = deflate; foo=3D100, deflate; = foo=3D0"

Response:

perframe-compress: accept=3D1; = bar=3D3.14

 

2-d) ack the requested parameters by echoing them back = to make the accepted-method-desc self-contained (describing all = negotiated parameters)

Request:

perframe-compress: method=3D"deflate; foo=3D200, = deflate; foo=3D100, deflate; foo=3D0"

Response:

perframe-compress: method=3D"deflate; foo=3D100; = bar=3D3.14"

 

----

 

My preference is 2-d). I'll rename max_window_bits and = no_context_takeover by prefixing them.

 

What do you think?

 

------=_NextPart_000_0020_01CD2F94.EA2B1650-- From tyoshino@google.com Fri May 11 07:31:26 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 2A01721F8715 for ; Fri, 11 May 2012 07:31:26 -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 mzDcEnM3Ky5w for ; Fri, 11 May 2012 07:31:25 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4C221F860B for ; Fri, 11 May 2012 07:31:24 -0700 (PDT) Received: by werf13 with SMTP id f13so1428035wer.31 for ; Fri, 11 May 2012 07:31:24 -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=ftDSi6p8pnKffvPtIynMIVoD6MBKmFT7zsy1Xl8ecaw=; b=pzppJ2SmqRD3p20XEFyQdyz7D230k0QBc8N20tXoQE47BjpsKg5I6+MCcbpefrNtK/ 9t421T0KDHoufTY4VekwzGYg1+HV+UTSfIxN9PZaHK0UazoHyjtbM6oqa/SZOF8SHhJr 9W+D40TiBvqPs4GgdaF7gOSbgBFxgcGpYUSnDcHnJn2iOya3MubtaVreCH4tl1bCxpft wbxvmbSxc2Y7CuuUKqiFHGzwTz5jtOY/ZZD1lhcXZy0dI4BjqwmlO6RcXwYUTn3KG7si R9Ky2ZEM2fWyou49Fl60yNrJzxVvaFmDm8ZtTQf9GYePQr6w5kSUcSQoIWvoHeHs8U8e E0Cw== 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=ftDSi6p8pnKffvPtIynMIVoD6MBKmFT7zsy1Xl8ecaw=; b=nnDwBkWpLPnqNCt/Cr+4KlTy+Hbyd7QjfyZzkCINNaZUKi8bF3sijBOyj9vkvEHlbD dq8kVqtXbglJWpUsHQa8GaDMO2DINgpuUOsIMPsCrKlsrM7CMKBWzNqIvTNJiOnTfqIf bErchpHHvtMvGpB/g3jOwQP1+nNO0YTizWEAe0guId09uXwGFauk/ST6hYq9I0gKCNZc OQltjoVArLEkOApeCFd1RNBLEvKlMiFVMYvu7ltnFiHtx4RxB4R7mJMy9pQZ6ucgSrY7 6T5dHNfHjiYdyjQ4rV2NWhq4gj3DQBnOq21IcI7YsfCmfsYVDSctGX1MdoxVcYls5bzZ rT/w== Received: by 10.50.222.137 with SMTP id qm9mr1780118igc.64.1336746683383; Fri, 11 May 2012 07:31:23 -0700 (PDT) Received: by 10.50.222.137 with SMTP id qm9mr1780107igc.64.1336746683253; Fri, 11 May 2012 07:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Fri, 11 May 2012 07:31:02 -0700 (PDT) In-Reply-To: <001f01cd2f7b$c4dbbb70$4e933250$@noemax.com> References: <001f01cd2f7b$c4dbbb70$4e933250$@noemax.com> From: Takeshi Yoshino Date: Fri, 11 May 2012 23:31:02 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae934107335c2c304bfc397ec X-System-Of-Record: true X-Gm-Message-State: ALoCoQmSse927HqrVVEc6tKKD46o72TCrvvJ+LUaBEiOLOPfgumJNri/8gJ78coeQFGUqGZqXy3CFyFTDVdGSYveksbv2F4/KS+I/4CTvdtQXvSTOUhNc0RlqKuENip14DCYxlYPiOxJ Cc: hybi@ietf.org Subject: Re: [hybi] Handling multiple compression method entries of the same extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 14:31:26 -0000 --14dae934107335c2c304bfc397ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2012 at 10:41 PM, Arman Djusupov wrote: > Agree on the 2-d) choice. What I just don=92t understand is why you have = to > prefix max_window_bits and no_context_takeover?**** > > ** > If we take 2-d), we'll echo back requested client parameters while sending the server parameters. So, we need to add prefixes to distinguish them. The example for 2-d) will be like the following for the "deflate" method. Request: perframe-compress: method=3D"deflate; s2c_max_window_bits=3D15" Response: perframe-compress: method=3D"deflate; s2c_max_window_bits=3D15, c2s_max_window_bits=3D8" Note that there is another point which needs to be clarified. Theoretically > the max_window_bits and no_context_takeover can even be asymmetric. It is > possible to implement this extension in such a manner that there is conte= xt > takeover in one direction and no content takeover in the other direction. > Unless I missed something, the spec does not require the server to use > exactly the same parameters as the client requested. > That's exactly what I intended to mean. > ** > > =93a server MUST include an element with the "perframe-compress" extensio= n > token as its extension identifier in the "Sec-WebSocket-Extensions" heade= r > in its opening handshake. The element MUST contain exactly one extension > parameter named "method". The value of the "method" extension parameter > MUST be a compression method description. The compression method > description MUST be a *valid response* for any of the methods listed by t= he > client in its opening handshake.=94**** > > ** ** > > So it=92s a bit unclear what is a Valid response, obviously thought it is > compression method specific. > OK. I'll fix it. > ** > > =93An endpoint that received this parameter MUST NOT use LZ77 sliding win= dow > size greater than the size specified by this parameter to *build frames*.= =94 > **** > > ** ** > > So this parameter affects only outbound frames and each side sets the > maximum window size for the remote side, but those parameters are not > currently required to be the same. For example, the client can limit the > server to 12bit window, while the server can set the client maximum to 15= ; > that would mean that the client is free to use a larger window for sendin= g > messages, while the server has to stick to lower values. There are cases = in > which such a design does make sense. > Yes. --14dae934107335c2c304bfc397ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, May 11, 2012 at 10:41 PM, Arman Djusupov= <arman@noemax.com> wrote:

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Agree on the 2-d) choice. What I just don=92t und= erstand is why you have to prefix max_window_bits and no_context_takeover?<= u>

<= /blockquote>

If we take 2-d), we'll echo back reques= ted client parameters while sending=A0the server parameters. So, we need to= add prefixes to distinguish them.=A0The example for 2-d) will be like the = following for the "deflate" method.

Request:
perframe-compress: method=3D&qu= ot;deflate; s2c_max_window_bits=3D15"
Response:
pe= rframe-compress: method=3D"deflate; s2c_max_window_bits=3D15, c2s_max_= window_bits=3D8"

Note that there = is another point which needs to be clarified. Theoretically the max_window_= bits and no_context_takeover can even be asymmetric. It is possible to impl= ement this extension in such a manner that there is context takeover in one= direction and no content takeover in the other direction. Unless I missed = something, the spec does not require the server to use exactly the same par= ameters as the client requested.


That's exactly what I intended t= o mean.
=A0

=93a server MUST include an elem= ent with the "perframe-compress" extension token as its extension= identifier in the "Sec-WebSocket-Extensions" header in its openi= ng handshake.=A0 The element MUST contain exactly one extension parameter n= amed "method".=A0 The value of the "method" extension p= arameter MUST be a compression method description.=A0 The compression metho= d description MUST be a *valid response* for any of the methods listed by t= he client in its opening handshake.=94

=A0<= /p>

So it=92s a bit unclea= r what is a Valid response, obviously thought it is compression method spec= ific.


OK. I'll fix it.
=A0

=93An endpoint that received thi= s parameter MUST NOT use LZ77 sliding window size greater than the size spe= cified by this parameter to *build frames*.=94

=A0<= /p>

So this parameter affe= cts only outbound frames and each side sets the maximum window size for the= remote side, but those parameters are not currently required to be the sam= e. For example, the client can limit the server to 12bit window, while the = server can set the client maximum to 15; that would mean that the client is= free to use a larger window for sending messages, while the server has to = stick to lower values. There are cases in which such a design does make sen= se.=A0


Yes.

--14dae934107335c2c304bfc397ec-- From webmaster@zaphoyd.com Fri May 11 10:24: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 5BB4D21F8675 for ; Fri, 11 May 2012 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 gLAJMtUww7QC for ; Fri, 11 May 2012 10:24:14 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 772BB21F867E for ; Fri, 11 May 2012 10:24:14 -0700 (PDT) Received: from 143.sub-166-249-128.myvzw.com ([166.249.128.143]:14749 helo=[10.167.111.29]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SStZc-0004Gf-Hd for hybi@ietf.org; Fri, 11 May 2012 13:24:13 -0400 From: Peter Thorson Content-Type: multipart/alternative; boundary=Apple-Mail-9683C305-E7B6-4D61-88F8-CEEE27C6C3EF X-Mailer: iPad Mail (9B176) Message-Id: Date: Fri, 11 May 2012 12:24:01 -0500 To: "hybi@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Subject: [hybi] RSV bits in extensions 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, 11 May 2012 17:24:15 -0000 --Apple-Mail-9683C305-E7B6-4D61-88F8-CEEE27C6C3EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is the intention of the RSV registration to prevent the reuse of RSV bits or= simply to catalog their use and help determine potential conflicts? In the case that an endpoint gets a handshake request for two extensions wit= h incompatible RSV bit registrations what is the expected behavior? Just pic= k one? Return an incompatible extension code? Return protocol error? Somethi= ng else? Peter Thorson --Apple-Mail-9683C305-E7B6-4D61-88F8-CEEE27C6C3EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Is the intention of the RSV regi= stration to prevent the reuse of RSV bits or simply to catalog their use and= help determine potential conflicts?

In the case th= at an endpoint gets a handshake request for two extensions with incompatible= RSV bit registrations what is the expected behavior? Just pick one? Return a= n incompatible extension code? Return protocol error? Something else?
<= div>
Peter Thorson
= --Apple-Mail-9683C305-E7B6-4D61-88F8-CEEE27C6C3EF-- From gregw@intalio.com Fri May 11 12:03:36 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ECD21F8717 for ; Fri, 11 May 2012 12:03:36 -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=[AWL=-0.000, 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 FPj1V-g78ssc for ; Fri, 11 May 2012 12:03:36 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 10A5C21F8576 for ; Fri, 11 May 2012 12:03:35 -0700 (PDT) Received: by qabj40 with SMTP id j40so2085855qab.15 for ; Fri, 11 May 2012 12:03:35 -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=HRSx9rmABL1Gh00B00yIVfO3DZrIC9ksQ6PqAdFgasc=; b=XHYPTpaAdteWPH4CrrJECYiKKElOb3wLR9vsVKUMd1mwlMhC3MtKOGsLu/mGSCrkBU xr1XHFKbeFgPO0Jj7cE8vJqW7Z6U2gvMO5XV1BD6yw8QLqGdFIx1lJSDxlEr2dbSASEg OuWtnig80zW/x5i+QgEMJqiOYoUf1tm7/nj/hb+cTU3pPPFbtYSHhLWhm4RWfPwdneqM OZareMK4qYuRcygds4k3wGDgCO3zAD6JEPQkA1H19z0dk88Eoz+7grCPkMb8Lijy9Sxj 2zyrcCKws9eg+8N9u06fzhEvRZ4Autc9YliRI8+gVz+treyhHjVKLxEMTqO/UiAA2RIA GYJg== MIME-Version: 1.0 Received: by 10.224.185.204 with SMTP id cp12mr20020340qab.42.1336763015588; Fri, 11 May 2012 12:03:35 -0700 (PDT) Received: by 10.229.68.99 with HTTP; Fri, 11 May 2012 12:03:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 May 2012 21:03:35 +0200 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnLYI2/jWhaXrKYWHah6YLbNvwxVsSCKu/fMUzcVItr1XjGaVzOkVkJ79E58vqwaSuIR3yB Cc: hybi@ietf.org Subject: Re: [hybi] Handling multiple compression method entries of the same extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:03:36 -0000 2-d looks fine to me. cheers From webmaster@zaphoyd.com Fri May 11 14:40:51 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3021F8666 for ; Fri, 11 May 2012 14:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 knZT0wnZ0aIj for ; Fri, 11 May 2012 14:40:50 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0A221F865B for ; Fri, 11 May 2012 14:40:50 -0700 (PDT) Received: from 49.sub-166-250-227.myvzw.com ([166.250.227.49]:5593 helo=[10.172.117.131]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SSxZw-0000Hp-DY; Fri, 11 May 2012 17:40:49 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B176) From: Peter Thorson Date: Fri, 11 May 2012 16:40:45 -0500 To: Takeshi Yoshino X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" Subject: Re: [hybi] Handling multiple compression method entries of the same extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:40:51 -0000 If this functionality is to be included I think 2-d is the best option. I am mildly concerned about the increasing complexity of the perframe-compre= ss extension handshake. Is this sort of negotiation common for compression i= n other protocols? Peter Thorson On May 11, 2012, at 0:55, Takeshi Yoshino wrote: > Hi, >=20 > I'm going to clarify whether multiple method descriptions with the same me= thod name is allowed to be listed in the perframe-compress's method paramete= r or not. >=20 > The benefit of allowing multiple entries is that the client can offer the s= ame extension with different parameter settings to try to use the best param= eter both endpoints can agree. >=20 > There's also a problem with this. The client cannot identify which of the e= ntries has been accepted by the remote endpoint. >=20 > Options we can take are: >=20 > ---- >=20 > 1-a) disallow use of multiple entries >=20 > 2-a) tag requested methods > Request: > perframe-compress: method=3D"deflate; id=3D0; foo=3D200, deflate; id=3D1; f= oo=3D100, deflate; id=3D2; foo=3D0" > Response: > perframe-compress: method=3D"deflate; id=3D1; bar=3D3.14" >=20 > 2-b) put "rejected" that means the method placed at the corresponding posi= tion in the requested-method-list has been rejected. > Request: > perframe-compress: method=3D"deflate; foo=3D200, deflate; foo=3D100, defla= te; foo=3D0" > Response: > perframe-compress: method=3D"rejected, deflate; bar=3D3.14, rejected" >=20 > 2-c) send back not a method description but the index of the description t= o accept and server-side parameter > Request: > perframe-compress: method=3D"deflate; foo=3D200, deflate; foo=3D100, defla= te; foo=3D0" > Response: > perframe-compress: accept=3D1; bar=3D3.14 >=20 > 2-d) ack the requested parameters by echoing them back to make the accepte= d-method-desc self-contained (describing all negotiated parameters) > Request: > perframe-compress: method=3D"deflate; foo=3D200, deflate; foo=3D100, defla= te; foo=3D0" > Response: > perframe-compress: method=3D"deflate; foo=3D100; bar=3D3.14" >=20 > ---- >=20 > My preference is 2-d). I'll rename max_window_bits and no_context_takeover= by prefixing them. >=20 > What do you think? >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From tyoshino@google.com Mon May 14 22:12: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 0B5E121F84D9 for ; Mon, 14 May 2012 22:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.029, 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 el+J4cgMnY09 for ; Mon, 14 May 2012 22:12:48 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11AF421F84D5 for ; Mon, 14 May 2012 22:12:47 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2360166ggn.31 for ; Mon, 14 May 2012 22:12:47 -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=XXV5CNNyPV3QjxAAG3ST35FvmZGeOv512tpresYOeGY=; b=eGlCglyHnuBcWLHkZCUofrxiy9v87sXFdPty92f9qWXqd4HsmrEV/B9MOqOSJ103Xu sgvtblW7C009Qg10OZ51OXtT33LgR3BTT4i/YqsOy5xeKqszOlmJpd1hcw0+4PiAKwJB wO2iIwvlzHIFgi3cbO05QbKgxJ8O1tVvZeXusAPiHMwdvSK6TTnKVwqsNMshvQjzeX1C kYgirrjhGE964dYW0DqJrsC7hXdtU+4cdSYQH+AQ6mJLSrqjiv0SWflu0sv4J94cPsqT RLki73U0FRkKwB7x6+dEPdxDUUrqF7JQ7OKCsh+9LFXSVxwnD1YKv7e4uxBsUBcsFQdF 15Kw== 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=XXV5CNNyPV3QjxAAG3ST35FvmZGeOv512tpresYOeGY=; b=CdEDgyv4XfFfJx3cUch8kr3r9NJQIw9LJuUe3fq7sctxRZ7NN10azIbkTCxD5cOE3S ZilNcS6CYXGkoL9g294+FruSRG6mFQbSttVsnBsYl9cNbo6dtVKCUXVGQuQ92hj7QpHT XgZnH7LJutHZVN6y5a1IWecsXlw9iA5P7/JZlgRbsdtEMmkwLyNG7PQn2RX90WBcmeHk 9w6ShLzwtwRp9Trzhx7RKG6Mc/QxTFGfG1r9BOJTH2FJ+BZpAFEyTrzJ94SvZhL20/Cm DxNF1loGne1y+qPLlmVoU/SiRcOp/1XZAa4TC65rq0qbVVSCQ7ysaEYufFdmiTXc46gM 8iNA== Received: by 10.50.36.227 with SMTP id t3mr5991513igj.13.1337058767499; Mon, 14 May 2012 22:12:47 -0700 (PDT) Received: by 10.50.36.227 with SMTP id t3mr5991507igj.13.1337058767406; Mon, 14 May 2012 22:12:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Mon, 14 May 2012 22:12:26 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 15 May 2012 14:12:26 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=14dae9340d31e0057104c00c40f0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn9+9e3xqncsPY88P6u5hgueaOH1HPVIaaedR7SqPLW0567enq1ZPCEupmSmYsVqf+JnyT9pDEH7InkHm7UYHtF9wwT3Z/UcGGfkRwVZgYWtXBSTuaixEymLT8W/fiaT2K4rEre Cc: "hybi@ietf.org" Subject: Re: [hybi] Handling multiple compression method entries of the same extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 05:12:49 -0000 --14dae9340d31e0057104c00c40f0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 12, 2012 at 6:40 AM, Peter Thorson wrote: > If this functionality is to be included I think 2-d is the best option. > > I am mildly concerned about the increasing complexity of the > perframe-compress extension handshake. Is this sort of negotiation common > for compression in other protocols? > Suggesting multiple methods and asking the remote peer to choose one from them and echoing it back is adopted by HTTP for content coding negotiation (Accept-Encoding and Content-Encoding header). I'm not sure if this kind of additional compression parameters is common. --14dae9340d31e0057104c00c40f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 12, 2012 at 6:40 AM, Peter Thorson <= span dir=3D"ltr"><webmaster@zaphoyd.com> wrote:
If this functionality is to be included I think 2-d is the best option.

I am mildly concerned about the increasing complexity of the perframe-compr= ess extension handshake. Is this sort of negotiation common for compression= in other protocols?

Suggesting mu= ltiple methods and asking the remote peer to choose one from them and echoi= ng it back is adopted by=A0HTTP for content coding negotiation (Accept-Enco= ding and Content-Encoding header).

I'm not sure if this kind of additional = compression parameters is common.
--14dae9340d31e0057104c00c40f0-- From wwwrun@rfc-editor.org Wed May 16 02:12:22 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 75AF821F848A for ; Wed, 16 May 2012 02:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 zLoG-gJP6vkY for ; Wed, 16 May 2012 02:12:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 239DC21F86D3 for ; Wed, 16 May 2012 02:12:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1F3E7B1E003; Wed, 16 May 2012 02:09:33 -0700 (PDT) To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, presnick@qualcomm.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com From: RFC Errata System Message-Id: <20120516090933.1F3E7B1E003@rfc-editor.org> Date: Wed, 16 May 2012 02:09:33 -0700 (PDT) Cc: hybi@ietf.org, rfc-editor@rfc-editor.org Subject: [hybi] [Technical Errata Reported] RFC6455 (3227) 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, 16 May 2012 09:12:22 -0000 The following errata report has been submitted for RFC6455, "The WebSocket Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3227 -------------------------------------- Type: Technical Reported by: Alexey Melnikov Section: 7.4.1 Original Text ------------- 1011 1011 indicates that a server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request. Corrected Text -------------- 1011 1011 indicates that a remote endpoint is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request. Notes ----- As per the discussion in the WG (See ) the meaning of this error close code should be extended to cover clients as well. As the Designated Expert for the WebSocket close code registry I've approved the corresponding change to the IANA registry. This should be "hold for update" for rfc6455bis. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) -------------------------------------- Title : The WebSocket Protocol Publication Date : December 2011 Author(s) : I. Fette, A. Melnikov Category : PROPOSED STANDARD Source : BiDirectional or Server-Initiated HTTP Area : Applications Stream : IETF Verifying Party : IESG From alexey.melnikov@isode.com Wed May 16 02:22: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 1761A21F8568 for ; Wed, 16 May 2012 02:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 1MyiyX5cq4t6 for ; Wed, 16 May 2012 02:22:42 -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 BFB6A21F8567 for ; Wed, 16 May 2012 02:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337160159; d=isode.com; s=selector; i=@isode.com; bh=SaS98Y9sJk2a7dNwv8cmQVxX+MTEoPDK/OXRsFcucv4=; 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=O5dQITwArbFs1uHdUsar1WzVSBcWkKKVKIybB/moG39FFFys8vjFBADzTo/zRQ6/Tu/l0a CnEZBBsXon6vSJK5n9p/rZg8E7RjPZGnLs1y3I9qDCPDdCnVMhL1oSTSvqHVIHR5eSVCAl z0Y6f/RAx+FsuH+fPBW94Z2FEPk/0Gw=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 May 2012 10:22:38 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FB37226.8040705@isode.com> Date: Wed, 16 May 2012 10:23:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Hybi References: <4FB3716F.2090609@isode.com> In-Reply-To: <4FB3716F.2090609@isode.com> X-Forwarded-Message-Id: <4FB3716F.2090609@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070506060200030305080207" Subject: [hybi] Fwd: Update to the "WebSocket Close Code Number" Registry 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, 16 May 2012 09:22:47 -0000 This is a multi-part message in MIME format. --------------070506060200030305080207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've requested the change to the definition from IANA. I've discovered that IANA only records short descriptions, so I've also submitted an Erratum to keep track of this change for future updates of RFC 6455. -------- Original Message -------- Subject: Update to the "WebSocket Close Code Number" Registry Date: Wed, 16 May 2012 10:20:47 +0100 From: Alexey Melnikov To: iana@iana.org Dear IANA, As the Designated Expert for "WebSocket Close Code Number Registry" (http://www.iana.org/assignments/websocket/websocket.xml#close-code-number-rules), I would like to request the following change for the 1011 Status Code: OLD meaning: Internal Server Error NEW meaning: Internal Error (I.e basically drop the word "Server"). If you want to add an extra reference, you can use the following link to the mailing list discussion: http://www.ietf.org/mail-archive/web/hybi/current/msg09628.html --------------070506060200030305080207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've requested the change to the definition from IANA. I've discovered that IANA only records short descriptions, so I've also submitted an Erratum to keep track of this change for future updates of RFC 6455.

-------- Original Message --------
Subject: Update to the "WebSocket Close Code Number" Registry
Date: Wed, 16 May 2012 10:20:47 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: iana@iana.org


Dear IANA,
As the Designated Expert for "WebSocket Close Code Number Registry"
(http://www.iana.org/assignments/websocket/websocket.xml#close-code-number-rules), 
I would like to request the following change for the 1011 Status Code:

OLD meaning:

Internal Server Error

NEW meaning:

Internal Error

(I.e basically drop the word "Server"). If you want to add an extra 
reference, you can use the following link to the mailing list discussion:

http://www.ietf.org/mail-archive/web/hybi/current/msg09628.html

--------------070506060200030305080207-- From alexey.melnikov@isode.com Wed May 16 02:40: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 0BBDF21F8759 for ; Wed, 16 May 2012 02:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 fKvtrmnMWbdl for ; Wed, 16 May 2012 02:40:39 -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 D2FC221F870B for ; Wed, 16 May 2012 02:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337161237; d=isode.com; s=selector; i=@isode.com; bh=vUy9gYz40FBgeWL7zbce98JTD2Z0dWDsK3aCKNC7hwY=; 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=OqaeANTNYgU20hUBe0kzO2QdRs1SIAnrPBpFl3Qw81ABj7ZWx6Ne34JG7KOchEcjw76u4P JeBjIsoMWa6XL7CLiCv3zkFVI8N0h3BLgw6eL4YT0MUVgzS4kjIiy1i+baV//uDqQANCBe aLvFXZ8EOJL+ady40T8F9V7iRRGbzEI=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 May 2012 10:40:37 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FB3765D.5060308@isode.com> Date: Wed, 16 May 2012 10:41:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Hybi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Additional WebSocket Close Error Codes 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, 16 May 2012 09:40:47 -0000 Hi WG, I am sorry I didn't followup on this when the following 2 codes were suggested (See ): 1012/Service Restart 1012 indicates that the service is restarted. a client may reconnect, and if it choses to do, should reconnect using a randomized delay of 5 - 30s. Use case: restart a service with 100k clients connected clients present an informative user notification ("service restarting .. reconnecting in N secs) clients should not reconnect all at exactly the same time .. thus the randomized delay 1013/Service Overload 1013 indicates that the service is experiencing overload. a client should only connect to a different IP (when there are multiple for the target) or reconnect to the same IP upon user action. Use case: clients present an informative user notification ("service overload .. try later or try different IP) ----- Do people use these and is there still some interest in registering them? Best Regards, Alexey From arman@noemax.com Thu May 17 02:06: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 1934921F861F for ; Thu, 17 May 2012 02:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 zT8HXO7xaYOV for ; Thu, 17 May 2012 02:06:03 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2021F861C for ; Thu, 17 May 2012 02:06:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1337245558; x=1337850358; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=VsWSAiGRCTz+dOvO52+gnesTODk=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=M0/LHpvZWJSRJuumUyjHMslyhbpTBeL0suZTJVBtkgUQNTU/SjZFVW9/mxXOmjlket5/dG1EIOUVgb/s4ltGCW9Dno1VtFRn37DkL32EzwD8YA8MjXX0bN67euX0DOCOb97Een2tuGQo1Phk0jHXhjOtlTywlkruwaUrYbmPP0w= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id BOW92157; Thu, 17 May 2012 12:05:57 +0300 From: "Arman Djusupov" To: "'Alexey Melnikov'" , "'Hybi'" References: <4FB3765D.5060308@isode.com> In-Reply-To: <4FB3765D.5060308@isode.com> Date: Thu, 17 May 2012 12:05:48 +0300 Message-ID: <001401cd340c$446034e0$cd209ea0$@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: AQGn5U20RX9qe93aljPngTG1eIMAF5cYTViQ Content-Language: en-us Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 17 May 2012 09:06:05 -0000 Yes. These status codes do make sense and it is preferable to have them standardized. With best regards, Arman -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Wednesday, May 16, 2012 12:42 PM To: Hybi Subject: [hybi] Additional WebSocket Close Error Codes Hi WG, I am sorry I didn't followup on this when the following 2 codes were suggested (See ): 1012/Service Restart 1012 indicates that the service is restarted. a client may reconnect, and if it choses to do, should reconnect using a randomized delay of 5 - 30s. Use case: restart a service with 100k clients connected clients present an informative user notification ("service restarting .. reconnecting in N secs) clients should not reconnect all at exactly the same time .. thus the randomized delay 1013/Service Overload 1013 indicates that the service is experiencing overload. a client should only connect to a different IP (when there are multiple for the target) or reconnect to the same IP upon user action. Use case: clients present an informative user notification ("service overload .. try later or try different IP) ----- Do people use these and is there still some interest in registering them? Best Regards, Alexey _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From jduell.mcbugs@gmail.com Thu May 17 21:20: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 CD2C621F86A3 for ; Thu, 17 May 2012 21:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIT7KNf2Yhn6 for ; Thu, 17 May 2012 21:20:25 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98C21F860D for ; Thu, 17 May 2012 21:20:25 -0700 (PDT) Received: by qadz3 with SMTP id z3so6197258qad.10 for ; Thu, 17 May 2012 21:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=dVM9vCLP5D94eZF9WadMaN4GtGR1UDL49vheRoc4Y7w=; b=xMOygBtkoqGQtfNQI+xWCLfxHND6eZeUXiBhmFrrlkX/mVEU4ogf7HJoX9DsC4ApHk fXV7OPqKOlUsxG+wpNryqMxw7Pfkw6J4tAg+rZvprbeRTAI7HrdnQM6og9w4xQMcE+bQ YydPxGok7RwBOzGmRoCZ6a+FqGwLMIOhztibXRDlG690u5MrGvXmN+FLkc4Jv0scafzo UQeRzcoH0rJJ6eqfGbN/BZ1lkEshbbU6pGhUbVdTxbamdSbTD4g3JxP9DjwugUiYPWnL lMZQCx0KAHBIAXaU5hMONaA8vQI1nit7wk7IMoWCGAkhdfwVIdBkD1eDp9wfJMET0E+Z zb0A== Received: by 10.229.173.103 with SMTP id o39mr4656466qcz.111.1337314824693; Thu, 17 May 2012 21:20:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.198.26 with HTTP; Thu, 17 May 2012 21:20:04 -0700 (PDT) From: Jason Duell Date: Thu, 17 May 2012 21:20:04 -0700 Message-ID: To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Yet more additional WebSocket Close Error Codes 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, 18 May 2012 04:20:25 -0000 I'm wondering if there are two more close codes that would be useful, to indicate 1) remote server not reachable 2) client/browser has too many websockets open already (try later) Re: #1: Both Web Socket specs are a little vague IMO on how JS is notified when the targeted web socket server is down/nonexistent/etc. Firefox is firing an 'error' event when this happens, based AFAICT on the language here in the W3C spec: "if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection" Chrome is not calling onerror for this, so we have a difference here. The language in the spec isn't really clear if this covers the connection-never-happened case. Both Chrome and Firefox (haven't tested other browsers/clients) are then calling close with code=1006, which seems the best code available in RFC 6455, but the language there isn't great either: "to indicate that the connection was closed abnormally, e.g., without sending or receiving a Close control frame." Of course the connection wasn't actually "closed" at all, normally or not. There's essentially no mention in either spec of what happens when there never was any connection to the server.. It would be useful to be clear about whether onerror should be called here. I'm also wondering if it would be useful to have a dedicated error code for this case ("server not available'). Re: #2: I expect every browser that implements websockets will have some limit on the number of websockets it allows to be open at once (to prevent DoS attacks if nothing else). I'm not sure of what the right close code for this is. Ideas? Perhaps we could also use a dedicated code for this case too. Jason Duell Mozilla From julian.reschke@gmx.de Fri May 18 03:54: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 6A51B21F865D for ; Fri, 18 May 2012 03:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 p2qpFwhnTQzW for ; Fri, 18 May 2012 03:54:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6F8B221F848E for ; Fri, 18 May 2012 03:54:37 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2012 10:54:36 -0000 Received: from p54BB26EE.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.38.238] by mail.gmx.net (mp070) with SMTP; 18 May 2012 12:54:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+zwF1QO3azgODsvmB8zIklvAEcJLAmdme73KWngr qhJWtPnW9IiK1C Message-ID: <4FB62A69.4040604@gmx.de> Date: Fri, 18 May 2012 12:54:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jason Duell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] Yet more additional WebSocket Close Error Codes 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, 18 May 2012 10:54:38 -0000 On 2012-05-18 06:20, Jason Duell wrote: > I'm wondering if there are two more close codes that would be useful, > to indicate > > 1) remote server not reachable > > 2) client/browser has too many websockets open already (try later) > > Re: #1: Both Web Socket specs are a little vague IMO on how JS is > notified when the targeted web socket server is down/nonexistent/etc. > > Firefox is firing an 'error' event when this happens, based AFAICT on > the language here in the W3C spec: > > "if the status code received from the server is not 101 (e.g. it is > a redirect), the user agent must fail the websocket connection" Well, no status code was received at all; so this doesn't seem to help :-) > Chrome is not calling onerror for this, so we have a difference here. > The language in the spec isn't really clear if this covers the > connection-never-happened case. I think it is; but I agree that the behavior for the other case should be specified at all. > ... Anyway; I think this should be raised as a WSAPI problem. Best regards, Julian From jduell.mcbugs@gmail.com Fri May 18 14:54:06 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 5C2B221F85D7 for ; Fri, 18 May 2012 14:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 xswsSbjfOHqa for ; Fri, 18 May 2012 14:54:06 -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 D46BE21F8593 for ; Fri, 18 May 2012 14:54:05 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2763807qcs.31 for ; Fri, 18 May 2012 14:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=BotM05Z/c30kM+KZruh5QDL7XulQjN6q195YHCoXCmY=; b=zBwMOc0ERZt8aCYmghFMYJ1zA9FJZdCgUPT7ruL1AiagQ1jFJVyPT65qfotOU7rNJV AgqAmNNz0sdeEOJbGsiD9TlEf/v5+qsnt5aWAXYMb2yRNKzT3DEqaXGUuqcSNSSBDEXc cCApyCnN5KGqlxehGRbnJG7WdhGtzVt1ZkdozG4husWx/xyFmpnoIMcmoDuHMOZBimWJ FAfKLjqdgaM27uYDGcrfwQKXLSfPSo+QcCboMNfz2xBctm8s99gAYxxSHJcdh1pKzztU F0TGDyD0Ww/mbbg9y/ngr1eZezHYWK2fVnuvYVRXheg/WeLUCGhOGCJwx0iyeFHzvRz1 zHqw== Received: by 10.224.217.9 with SMTP id hk9mr25691332qab.59.1337378045399; Fri, 18 May 2012 14:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.198.26 with HTTP; Fri, 18 May 2012 14:53:45 -0700 (PDT) In-Reply-To: <4FB62A69.4040604@gmx.de> References: <4FB62A69.4040604@gmx.de> From: Jason Duell Date: Fri, 18 May 2012 14:53:45 -0700 Message-ID: To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Yet more additional WebSocket Close Error Codes 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, 18 May 2012 21:54:06 -0000 >> Chrome is not calling onerror for this, so we have a difference here. >> The language in the spec isn't really clear if this covers the >> connection-never-happened case. > > I think it is; So you think the behavior for "server not available" is clear in the spec? Which flavor (call onerror or not)? > but I agree that the behavior for the other case should be > specified at all. I couldn't quite parse this either. Is that support (or the opposite) for a code for "too many websockets open", or something else? > Anyway; I think this should be raised as a WSAPI problem. Yes, most of the wordsmithing needs to happen there (and as soon as their mail server starts accepting my mail I'll have a post about this there). But the list of close codes (including pseudo-codes that never go on the net) has so far been maintained more on this list, so I figured I'd ask here too. best, Jason From jduell.mcbugs@gmail.com Fri May 18 16:36: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 1BF8421F85DF for ; Fri, 18 May 2012 16:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FndEJ5dkjkPO for ; Fri, 18 May 2012 16:36:29 -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 985E121F85D6 for ; Fri, 18 May 2012 16:36:22 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2804111qcs.31 for ; Fri, 18 May 2012 16:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=LwIy5oHi9jeT/TX0L12gO1o8Qw8IpjxxK8vkHYGXzvg=; b=f7bkuWPp9Xg0wEG04MJQvnOGz6in2UfvRwxmv3D4KvJmPude7sTKRBgI9rbeY0ExU3 3HKYcE4ohk1OI8FeQ0DqNSo8m5swKPKyu6zi/qZJrpbUYBk3V64rhNIBd7f2lncMQdzJ rbxFe6D3++jeTufYbHkeLVlZhU68nl/YqtmxbSfRlwnHU8YRJ2+6hcAoiFqbf5lZ6Cgu PcjHr4KRHnXVQvTxWImKffPmOIblHPZk+3oP+ZeMWgzwUnok5w/9WQE80x4xM10nE68r kGP5y/kCbjaaYC4qOPkvmaf1Z+/AfTRqjFJzQWiMvQ89d/+y5tFRQCsCR/szJfjYu2d8 hgLQ== Received: by 10.224.217.9 with SMTP id hk9mr26060263qab.59.1337384182126; Fri, 18 May 2012 16:36:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.198.26 with HTTP; Fri, 18 May 2012 16:36:01 -0700 (PDT) In-Reply-To: References: <4FB62A69.4040604@gmx.de> From: Jason Duell Date: Fri, 18 May 2012 16:36:01 -0700 Message-ID: To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Yet more additional WebSocket Close Error Codes 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, 18 May 2012 23:36:30 -0000 >>> Chrome is not calling onerror for this, so we have a difference here. >>> The language in the spec isn't really clear if this covers the >>> connection-never-happened case. >> >> I think it is; Perhaps you were referring to "If the establish a WebSocket connection algorithm fails, it triggers the fail the WebSocket connection algorithm, which then invokes the close the WebSocket connection algorithm." That clearly implies onerror should be called when the remote server connection fails. It looks like Chromium is going to change to call onerror here too: http://code.google.com/p/chromium/issues/detail?id=128057 But: I still don't see any clear language in either spec on what error code should be used, and think that this is a common enough case to merit it's own code, or at least clearer language that 1006 should be used. Jason From julian.reschke@gmx.de Sat May 19 01:38:14 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 599A721F8675 for ; Sat, 19 May 2012 01:38:14 -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 lIT8Xlbfw9Ez for ; Sat, 19 May 2012 01:38:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6DEB021F8674 for ; Sat, 19 May 2012 01:38:13 -0700 (PDT) Received: (qmail invoked by alias); 19 May 2012 08:38:11 -0000 Received: from p54BB37D5.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.55.213] by mail.gmx.net (mp010) with SMTP; 19 May 2012 10:38:11 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/VmIQArp7VEDzbHQ4UR4GTb/v7wrWb1/s7pDNu8I NTi5g0l9DtK1ee Message-ID: <4FB75BF1.1050407@gmx.de> Date: Sat, 19 May 2012 10:38:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jason Duell References: <4FB62A69.4040604@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] Yet more additional WebSocket Close Error Codes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 08:38:14 -0000 On 2012-05-18 23:53, Jason Duell wrote: >>> Chrome is not calling onerror for this, so we have a difference here. >>> The language in the spec isn't really clear if this covers the >>> connection-never-happened case. >> >> I think it is; > > So you think the behavior for "server not available" is clear in the > spec? Which flavor (call onerror or not)? I think it is clear in that it talks about a response code, so does not deal with the case you are referring to. >> but I agree that the behavior for the other case should be >> specified at all. > > I couldn't quite parse this either. Is that support (or the > opposite) for a code for "too many websockets open", or something > else? It's support for defining the API behavior for connection problems. >> Anyway; I think this should be raised as a WSAPI problem. > > Yes, most of the wordsmithing needs to happen there (and as soon as > their mail server starts accepting my mail I'll have a post about this > there). But the list of close codes (including pseudo-codes that > never go on the net) has so far been maintained more on this list, so > I figured I'd ask here too. Agreed. Best regards, Julian From tyoshino@google.com Mon May 21 00:46:22 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 D035721F85B5 for ; Mon, 21 May 2012 00:46:22 -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 zn3Nc0PawKM8 for ; Mon, 21 May 2012 00:46:22 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4539D21F84A6 for ; Mon, 21 May 2012 00:46:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so365668ghb.31 for ; Mon, 21 May 2012 00:46:21 -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=XtQtz2HViXYfkGGtC7Oo3S30MCsTkRvpGOHnehLLGtw=; b=hpaabQSo5sRVPPvWyJCT9qsaQzTugOx/aXoTny7Pi7T4hlOFWZCkkssgfFX00zOEfl oLas8Hyt2562wE68TvkXfrGoz02My8WpkINQ/myz8p2xO2SMcn+bPCyjwcEEYr8Pok+F FqYp7pyo9BQ/wTRfSrrwZrfPPNzFk5s6Ctkz4zo0bAeeYlfY8X1PHyQLjbolblaXdWkc F1IdCFcf8KqqDVpIKF/9lXhpBPclF9UfmdCk6B4FQuZCzaMb1znQbwJnANDOvN3hYE0G 70c9r5uDXrW9Dxr/H98mcjssNgW0SES5M+KKvFdBytkUtTdwqMv3ci/+bk4IYvv4IdW8 LQYQ== 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=XtQtz2HViXYfkGGtC7Oo3S30MCsTkRvpGOHnehLLGtw=; b=ESoIZNLQ+7HPZS3y2MVeOCdNUOnLG6TNCVPghIxT+nkhJrfp4Uew05EzsT0Ova0Pui ENSh4JH6bv09qUcm2wlZq8sf0ft8nGNC18s3vv8lxYmV80D9DLZ1RS4dRaRIH5Eci7bN eoBXaxXka464sg2APgb4A/OBoTYgoextSUd7/pUJ1NaCDyAOiQMctzNpKF5ZWXDsevws aW/jIZ43w1vFofqGRrb2FMkb227m/nydeJiIlU/1YnfAvJu53brVRsqhgLp3osUrXqH7 I4XNmTGFoRyWoySqS5AQyCUbiaV/EWJlpnOBwlWPt+oSLh7GH+9dQnmOyK/Gcw9Ytu5X 59lw== Received: by 10.50.222.137 with SMTP id qm9mr5923226igc.64.1337586381410; Mon, 21 May 2012 00:46:21 -0700 (PDT) Received: by 10.50.222.137 with SMTP id qm9mr5923221igc.64.1337586381304; Mon, 21 May 2012 00:46:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Mon, 21 May 2012 00:46:00 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 21 May 2012 16:46:00 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=14dae93410731d32bc04c0871949 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm4m5Pz6AM4yC2w/h2/olegD63zJJAlKxnpgcOwj22xq42x3WKMOehVZCQIXdVZPLmJJUftLFNNMeI+gWYFmxCPxG+cFOUPVMgOX7zb6Ad9gK4/YKZWe/+jBf1FS8wABlAJz3bY Cc: "hybi@ietf.org" Subject: Re: [hybi] RSV bits in extensions 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, 21 May 2012 07:46:22 -0000 --14dae93410731d32bc04c0871949 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 12, 2012 at 2:24 AM, Peter Thorson wrote: > Is the intention of the RSV registration to prevent the reuse of RSV bits > or simply to catalog their use and help determine potential conflicts? > My understanding is - it's to get the allocation widely known to prevent unexpected confliction, complication. - it doesn't disallow use of the same bit by multiple extensions completely. > In the case that an endpoint gets a handshake request for two extensions > with incompatible RSV bit registrations what is the expected behavior? Just > pick one? Return an incompatible extension code? Return protocol error? > Something else? > I think - it's ok to request two or more mutually incompatible extensions - it's ok that the server accept the client by picking one of them. - if the client requested two or more mutually incompatible extensions and the server acked two or more of them, the client must fail. Takeshi --14dae93410731d32bc04c0871949 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 12, 2012 at 2:24 AM, Peter Thorson <<= a href=3D"mailto:webmaster@zaphoyd.com" target=3D"_blank">webmaster@zaphoyd= .com> wrote:
Is the intention of the RSV registration to = prevent the reuse of RSV bits or simply to catalog their use and help deter= mine potential conflicts?

My u= nderstanding is
- it's to get the allocation widely known to prevent unexpected co= nfliction, complication.
-=A0it doesn't=A0disallow use of the= same bit by multiple extensions completely.
=A0
In the case that an endpoint gets a han= dshake request for two extensions with incompatible RSV bit registrations w= hat is the expected behavior? Just pick one? Return an incompatible extensi= on code? Return protocol error? Something else?

I think
- it&#= 39;s ok to request two or more mutually incompatible extensions
-= it's ok that the server accept the client by picking one of them.
- if the client requested two or more mutually incompatible extensions= and the server acked two or more of them, the client must fail.

Takeshi
--14dae93410731d32bc04c0871949-- From gregw@intalio.com Mon May 21 03:35: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 5E40E21F860F for ; Mon, 21 May 2012 03:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 qjsRvJQssl8J for ; Mon, 21 May 2012 03:35:48 -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 8622B21F85F7 for ; Mon, 21 May 2012 03:35:48 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3807847qcs.31 for ; Mon, 21 May 2012 03:35: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bHwTWyg7Oxlzb8FbGXEUvfB/jgTcjvT0cXaLgCLvBtc=; b=Y3dwLcwTd1f33MWN3tVcrmRKDHn1Tm/bS8lhd2AhRCjZsRaYgBHyjE+2nF+jvjBPJ+ 8uuIXhpKcDXDOr/XiFqAuMdicc6vyPGSe8LgZfDEj/veN9arvTvxfjWzBbE9Ni3towB2 qoMBOgdrd+hEd7DFwaOHEIHjS4aL2rXtbaa9uPbgnsWa6p4T3lqtAwBKw4EoW4a2QGsa Ts8gcIi8cVQDL5fTz6FDmzXf60FPElwAkGQX/u1P846jESp62FaxedhPgHXDuKQuJT+r NTLcXvSqs9bc8ocEWk0IvfnofpRd6ID+kZmVO5f1g3/tv4l7APKgAd1fm5f1Tlw7qQqG B7FA== MIME-Version: 1.0 Received: by 10.229.136.17 with SMTP id p17mr9954371qct.151.1337596547834; Mon, 21 May 2012 03:35:47 -0700 (PDT) Received: by 10.229.72.97 with HTTP; Mon, 21 May 2012 03:35:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 May 2012 12:35:47 +0200 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=00248c70f9f11624f404c089770c X-Gm-Message-State: ALoCoQkC9cdUQQsVpKAFDBixZV6fZslIe2pdKJuKo+Po4nUAjWDVAKtCaj67X2mXn+pYQ3sfuu3m Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] RSV bits in extensions 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, 21 May 2012 10:35:49 -0000 --00248c70f9f11624f404c089770c Content-Type: text/plain; charset=ISO-8859-1 In practise, I believe this means that the RSV bits are of very very limited use to 3rd party extensions and really have been reserved for extensions developed by this WG. For example RSV1 will effectively become the compression bit once the per-frame-compession draft is accepted and RSV1 will only be able to be used by other extensions that are obviously mutually exclusive to per-frame-compression (such as stream compression) I'm not saying this is a bad thing... it's probably good to have these bits available for standard extensions without the need for the complexity of dynamic bit allocations. It just means that 3rd party extension should really avoid using these bits and put their own flags in the payload.... unless somebody wants to define the unlimited-reserved-bit extension to be used with other extension :) cheers On 21 May 2012 09:46, Takeshi Yoshino wrote: > On Sat, May 12, 2012 at 2:24 AM, Peter Thorson wrote: > >> Is the intention of the RSV registration to prevent the reuse of RSV bits >> or simply to catalog their use and help determine potential conflicts? >> > > My understanding is > - it's to get the allocation widely known to prevent unexpected > confliction, complication. > - it doesn't disallow use of the same bit by multiple extensions > completely. > > >> In the case that an endpoint gets a handshake request for two extensions >> with incompatible RSV bit registrations what is the expected behavior? Just >> pick one? Return an incompatible extension code? Return protocol error? >> Something else? >> > > I think > - it's ok to request two or more mutually incompatible extensions > - it's ok that the server accept the client by picking one of them. > - if the client requested two or more mutually incompatible extensions and > the server acked two or more of them, the client must fail. > > Takeshi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --00248c70f9f11624f404c089770c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In practise, I believe this means that the RSV bits are of very very limite= d use to 3rd party extensions and really have=A0 been reserved for extensio= ns developed by this WG.=A0=A0=A0 For example RSV1 will effectively become = the compression bit once the per-frame-compession draft is accepted and RSV= 1 will only be able to be used by other extensions that are obviously mutua= lly exclusive to per-frame-compression (such as stream compression)

I'm not saying this is a bad thing... it's probably good to hav= e these bits available for standard extensions without the need for the com= plexity of dynamic bit allocations.=A0=A0=A0=A0 It just means that 3rd part= y extension should really avoid using these bits and put their own flags in= the payload.... unless somebody wants to define the unlimited-reserved-bit= extension to be used with other extension :)

cheers



On 21 May 2012 09:46, = Takeshi Yoshino <tyoshino@google.com> wrote:
On Sat, May 12, 2012 at 2:24 AM, Peter Thorson <webmaster@zaphoyd.com> wrote:
Is the intention of the RSV registration to = prevent the reuse of RSV bits or simply to catalog their use and help deter= mine potential conflicts?

My understanding is
- it's to get the allocation widely known to prevent unexpected co= nfliction, complication.
-=A0it doesn't=A0disallow use of the= same bit by multiple extensions completely.
= =A0
In the case that an endpoint gets a han= dshake request for two extensions with incompatible RSV bit registrations w= hat is the expected behavior? Just pick one? Return an incompatible extensi= on code? Return protocol error? Something else?

I think
= - it's ok to request two or more mutually incompatible extensions
=
- it's ok that the server accept the client by picking one of them= .
- if the client requested two or more mutually incompatible extensions= and the server acked two or more of them, the client must fail.

Takeshi

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


--00248c70f9f11624f404c089770c-- From gregw@intalio.com Mon May 21 03:45: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 BB40D21F8518 for ; Mon, 21 May 2012 03:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 C5R7vvb33TP7 for ; Mon, 21 May 2012 03:45:05 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6021F84A2 for ; Mon, 21 May 2012 03:45:04 -0700 (PDT) Received: by qabj40 with SMTP id j40so1791047qab.15 for ; Mon, 21 May 2012 03:45:04 -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=H9O1+5Mcf35kCQLK1Ag1xzXi0u/asD8M0BUeTo08PiY=; b=jtb6T7sd1l8YixMxoeXGghBRAuNDI4P3tcaepiMWjR8xSD0RSL5CWmS+GBsIBur7Il HZCNWYQgYPV+CvT9Oklai7+XPL/Wwe1okGEDMbAt/6pg6bmg6JVYnr/jePZySK18dRmk Dkj9AcXYdfRj9wQQBjQUDxaC4dkK0B5ObF8RdC1O29sx7tfSdGH8WBdFpvra9YaqRInd yr0RzNrHsqaQT0/symKEcQ5Ujakoh9udZl4jiH+DMIl+fcwVlnK16ABqrMrNvjZWWI5C Kb7i/UZ8g5E6ZzrxuXkFyMGXp94qC1NZyASB0p8H7F7zk/5X3d17XvggGlyXpIIyF8Rp 3ewA== MIME-Version: 1.0 Received: by 10.224.181.84 with SMTP id bx20mr37641495qab.77.1337597104178; Mon, 21 May 2012 03:45:04 -0700 (PDT) Received: by 10.229.72.97 with HTTP; Mon, 21 May 2012 03:45:04 -0700 (PDT) In-Reply-To: <001401cd340c$446034e0$cd209ea0$@noemax.com> References: <4FB3765D.5060308@isode.com> <001401cd340c$446034e0$cd209ea0$@noemax.com> Date: Mon, 21 May 2012 12:45:04 +0200 Message-ID: From: Greg Wilkins To: Arman Djusupov Content-Type: multipart/alternative; boundary=20cf30334b573f466804c089985b X-Gm-Message-State: ALoCoQmoJHT4BcLII2iYxPIS7V2Pgg2XAr3f3jDaB7eU6v3GngcDbfFmIEtOpKmVORVxw6aXoUX6 Cc: Hybi Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 21 May 2012 10:45:05 -0000 --20cf30334b573f466804c089985b Content-Type: text/plain; charset=ISO-8859-1 They both look reasonable. On 17 May 2012 11:05, Arman Djusupov wrote: > Yes. These status codes do make sense and it is preferable to have them > standardized. > > With best regards, > Arman > > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Alexey Melnikov > Sent: Wednesday, May 16, 2012 12:42 PM > To: Hybi > Subject: [hybi] Additional WebSocket Close Error Codes > > Hi WG, > I am sorry I didn't followup on this when the following 2 codes were > suggested (See > ): > > 1012/Service Restart > 1012 indicates that the service is restarted. a client may reconnect, > and if it choses to do, should reconnect using a randomized delay of 5 - > 30s. > > Use case: > restart a service with 100k clients connected > clients present an informative user notification ("service restarting .. > reconnecting in N secs) > clients should not reconnect all at exactly the same time .. thus the > randomized delay > > > 1013/Service Overload > 1013 indicates that the service is experiencing overload. a client > should only connect to a different IP (when there are multiple for the > target) or reconnect to the same IP upon user action. > > Use case: > clients present an informative user notification ("service overload .. > try later or try different IP) > > ----- > > Do people use these and is there still some interest in registering them? > > Best Regards, > Alexey > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --20cf30334b573f466804c089985b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
They both look reasonable.

On 17 May = 2012 11:05, Arman Djusupov <arman@noemax.com> wrote:
Yes. These status codes do make sense and it is preferable to have them
standardized.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [m= ailto:hybi-bounces@ietf.org] O= n Behalf Of
Alexey Melnikov
Sent: Wednesday, May 16, 2012 12:42 PM
To: Hybi
Subject: [hybi] Additional WebSocket Close Error Codes

Hi WG,
I am sorry I didn't followup on this when the following 2 codes were suggested (See
<http://www.ietf.org/mail-archive/web/hybi/current/ms= g09284.html>):

1012/Service Restart
1012 indicates that the service is restarted. a client may reconnect,
and if it choses to do, should reconnect using a randomized delay of 5 - 30s.

Use case:
restart a service with 100k clients connected
clients present an informative user notification ("service restarting = ..
reconnecting in N secs)
clients should not reconnect all at exactly the same time .. thus the
randomized delay


1013/Service Overload
1013 indicates that the service is experiencing overload. a client
should only connect to a different IP (when there are multiple for the
target) or reconnect to the same IP upon user action.

Use case:
clients present an informative user notification ("service overload ..=
try later or try different IP)

-----

Do people use these and is there still some interest in registering them?
Best Regards,
Alexey

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

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

--20cf30334b573f466804c089985b-- From twisolar@gmail.com Mon May 21 04:15:22 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 1E82D21F85E6 for ; Mon, 21 May 2012 04:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh5jhxOcWp2W for ; Mon, 21 May 2012 04:15:21 -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 24F9221F85E3 for ; Mon, 21 May 2012 04:15:21 -0700 (PDT) Received: by yhq56 with SMTP id 56so5016115yhq.31 for ; Mon, 21 May 2012 04:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=y1E4zOU5OybxUpIeyndNpDtCNOsoMuc9AiKrti2Lj3Y=; b=0dE+q25rQCOBulztSLYneQTL33V8KQces7Mrz9nfpQore9hKXeGqza7sDBCWbZYL9B KY3NmZGWUvRkZUI3yHS36vuy6tD3k/44vPdVqosgH9WG0hsvzhQiRcQcSToWn/0VajE7 9AD+o65Yfgc8oTUiEH1HpEb9AEIvMUhw2PdKTwq4zSROE3Txm/eP8q+2afnbkwYxMQXr IVF71BvnaYuyk1ByAB8WBttksLLy8AAWeF0NXO21bvnSoks2m+kO7ZlduR6MfGs9+HGy KdQZGQdQLDterkX/IzprFSGXrmRF7kIH3zDAy/FS0/jq97egQlBIq6QS6AK6yfatNN/k E8Qg== Received: by 10.50.222.200 with SMTP id qo8mr6296725igc.20.1337598920456; Mon, 21 May 2012 04:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.94.226 with HTTP; Mon, 21 May 2012 04:14:50 -0700 (PDT) In-Reply-To: References: From: Jonathan Castello Date: Mon, 21 May 2012 04:14:50 -0700 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] RSV bits in extensions 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, 21 May 2012 11:15:22 -0000 On the other hand, an extension could allocate an RSV bit only for specific opcodes. If per-frame compression was only defined on text and binary frames, RSV1 could be used by another extension on other opcodes. This kind of scoping less solves the problem than it does push it to the number of available opcodes, but it is an option. Incidentally, this is my first message to the list. Hello! ~Jonathan Castello On Mon, May 21, 2012 at 3:35 AM, Greg Wilkins wrote: > In practise, I believe this means that the RSV bits are of very very limi= ted > use to 3rd party extensions and really have=A0 been reserved for extensio= ns > developed by this WG.=A0=A0=A0 For example RSV1 will effectively become t= he > compression bit once the per-frame-compession draft is accepted and RSV1 > will only be able to be used by other extensions that are obviously mutua= lly > exclusive to per-frame-compression (such as stream compression) > > I'm not saying this is a bad thing... it's probably good to have these bi= ts > available for standard extensions without the need for the complexity of > dynamic bit allocations.=A0=A0=A0=A0 It just means that 3rd party extensi= on should > really avoid using these bits and put their own flags in the payload.... > unless somebody wants to define the unlimited-reserved-bit extension to b= e > used with other extension :) > > cheers > > > > On 21 May 2012 09:46, Takeshi Yoshino wrote: >> >> On Sat, May 12, 2012 at 2:24 AM, Peter Thorson >> wrote: >>> >>> Is the intention of the RSV registration to prevent the reuse of RSV bi= ts >>> or simply to catalog their use and help determine potential conflicts? >> >> >> My understanding is >> - it's to get the allocation widely known to prevent unexpected >> confliction, complication. >> -=A0it doesn't=A0disallow use of the same bit by multiple extensions >> completely. >> >>> >>> In the case that an endpoint gets a handshake request for two extension= s >>> with incompatible RSV bit registrations what is the expected behavior? = Just >>> pick one? Return an incompatible extension code? Return protocol error? >>> Something else? >> >> >> I think >> - it's ok to request two or more mutually incompatible extensions >> - it's ok that the server accept the client by picking one of them. >> - if the client requested two or more mutually incompatible extensions a= nd >> the server acked two or more of them, the client must fail. >> >> Takeshi >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From toyoshim@google.com Mon May 21 23:18: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 D50559E8013 for ; Mon, 21 May 2012 23:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wa2a3RgHx1xj for ; Mon, 21 May 2012 23:18: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 0D4DF9E800A for ; Mon, 21 May 2012 23:18:01 -0700 (PDT) Received: by lagv3 with SMTP id v3so4640792lag.31 for ; Mon, 21 May 2012 23:18:00 -0700 (PDT) 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 :x-system-of-record; bh=AS3yyEN4ocxap0pj3VmbPZpqd2T4/DijNNZfqh69A5s=; b=eTBt1UW6PDE4moDl4eibtb5zCALfvQu6DAc9duL2QI13+c81VPrp0mZagcJyjK7S3r CSOcYX80x+r2G6KwaE4WmwHbXF6dNtG8WUeYMTDTMWPDVg9FrwV5eTwz/Dp94T0FWFUk NkbG1DTkfutkUngONvO2q209ZIr/jxewKhLvsudSGK5K416Xs9OLaOP4ocDLBbK0Y0n5 U14OPAG31NqeoUXp+0gimWNfpcTLaU/ru4kVktZeVmTtR1tLXtvE53HZKni4ws3aOcxL ZGcLhSnUFD/8ZVLk5NCnfWm1a0lbbBjaPckIUACaWbI7IaRO02P58Y1pZ9DS3BkH27pu SpBA== 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 :x-system-of-record:x-gm-message-state; bh=AS3yyEN4ocxap0pj3VmbPZpqd2T4/DijNNZfqh69A5s=; b=V4Zt5xX3bWECHP76CoCbZ18QY8IGl10JtJXB4PggFSfPRn3Q86ZD0I2Ijh+gmsOYZE fWpC/CEPWqVCI8jH87nB2D3KGN361F1zlgOJqd5QKi0xSGxKVm4I/yseFd94jywPIYzg xIidc26vTauQD9TmKif3iQyxni6ycl1d8D/qgPk7InPlQ8+3YAIF13VKxY1Ii/vs1iBX 1OOqTS4WvgIxzMqWO9j9ZWuC+Aav1cLZhupPb0EumAH21/ox6FcTX6tngdgpT48QlLOt jbJsRcSRmqlppY60GIC/G2CsS1F9RYOn1eHhU70n+L3lV4+wliFgPhhdnd0ghzG9WepD xgPg== Received: by 10.152.132.40 with SMTP id or8mr11151209lab.24.1337667480822; Mon, 21 May 2012 23:18:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.132.40 with SMTP id or8mr11151194lab.24.1337667480685; Mon, 21 May 2012 23:18:00 -0700 (PDT) Sender: toyoshim@google.com Received: by 10.112.113.130 with HTTP; Mon, 21 May 2012 23:18:00 -0700 (PDT) In-Reply-To: References: <4FAACC40.6040308@isode.com> Date: Tue, 22 May 2012 15:18:00 +0900 X-Google-Sender-Auth: nkvh7ah6hIxz5CX0ix0tZe2r_H8 Message-ID: From: Takashi Toyoshima To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn1KbHrGvUiBQ/+KV7BXG0Y91o5sD2OTtCwLKPEQJZpr1Mq75+rOgy0e4ST5wQvBtVg+MpdZoUgGnvWfoUpvWZ8TOdTxNhGWKrMRD/bs8iqK0d0R3srVmIVdMJEg+O5ZLVB0Xgy Cc: hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 22 May 2012 06:18:02 -0000 Hi Takeshi, I agreed your suggestion and also think receiving close frames of payload length=1 is the same as your cases. If payload length was zero, it can be handled as 1005 safely. But length=1 is clearly broken. I'll fix WebKit implementation of receiving 1005, 1006, 1015, and length=1 of close frames. These frames will fire CloseEvent with code=1006 and wasClean=false. Thanks, On Thu, May 10, 2012 at 11:51 AM, Takeshi Yoshino wrote: > Hi Alexey, > > On Thu, May 10, 2012 at 4:57 AM, Alexey Melnikov > wrote: >>> >>> I think this should be taken as protocol error. The endpoint received >>> such a bad close frame should _Fail the WebSocket Connection_ and invoke >>> onclose() with code=1006 and wasClean=false. >> >> 1006 seems as good of a code for this as any. Does "wasClean=false" matter >> in this case? > > > As the received close frame is considered to be broken, we should not take > this as successful completion of closing handshake. I think it should be > taken as "_The WebSocket Connection is Closed_ but not _cleanly_" which > results in wasClean=false for the WebSocket API's case. > >> >> Alternatively, we can reserve a new "you lied to me about your reason" >> close code. > > > We can. But as Arman suggested, we can also just use the existing code 1002 > to tell the remote endpoint that it's broken when the closing handshake > initiator is the remote endpoint. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Tue May 22 02:11:41 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4913521F853D for ; Tue, 22 May 2012 02:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.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_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4buJErlSFm+u for ; Tue, 22 May 2012 02:11:40 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4F21F8450 for ; Tue, 22 May 2012 02:11:40 -0700 (PDT) Received: by qadz3 with SMTP id z3so2207099qad.10 for ; Tue, 22 May 2012 02:11:39 -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=VxcW/YNc/58ueHB3kMcTuSTIiiALayKHA4H6HInk/KY=; b=dmTw5/tb52rNMdOtfAiX6z3Tk4rhdL/nPqwLK3I27roj9yqW44XjVPR6G8DJJ2hcTH V6NMvTWRYNajZagKvk32oiX3zXqIF7cEqwelMzc0giLXXI6QN3OV33lVCMJrzsdcmoOB oWnrkPBQ/0idFcVl7fy9FjKd0ZrPlAy5Hrd71J7TnO49bhprYrqCoUUu3LnQ+2TwiPsL CGXitYwaDJcHdyj4el8hh0lasg7r1+q14cC+N+Mzb8c1gbl5OaJIH60qyDmdvi/ewk1f 9VI84TcO+u0knfRvJ1iZsaf8+yP8OjdpHPcd9VtaRxcgxtDeKVJ+u8VkKvKtPbfHyOZ5 23zQ== MIME-Version: 1.0 Received: by 10.224.190.68 with SMTP id dh4mr43430998qab.5.1337677899829; Tue, 22 May 2012 02:11:39 -0700 (PDT) Received: by 10.229.72.97 with HTTP; Tue, 22 May 2012 02:11:39 -0700 (PDT) In-Reply-To: References: <20120420050004.2740.14810.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 11:11:39 +0200 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf300fad190b133c04c09c68db X-Gm-Message-State: ALoCoQlHYgK8NgckvBmmkuWNeuD9tI73xGJCAWcRWNaiEnV7Fn53deCXLBDxlwGtD98cqnobFxCi Cc: hybi@ietf.org 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: Tue, 22 May 2012 09:11:41 -0000 --20cf300fad190b133c04c09c68db Content-Type: text/plain; charset=ISO-8859-1 I think we should note the discussion happening over in SPDY-dev about their flow control and concerns about it https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/JB_aQPNI7rw Our mux proposal with it's send quotas has effectively the same problem - namely that a fixed quota per channel can cause a significant under utilisation of a fast link, but can also represent a significant over allocation of capacity if many channels are present. I think we need to closely follow that discussion to see what solutions may be developed before we commit to a per channel window flow control. cheers On 20 April 2012 08:08, Takeshi Yoshino wrote: > 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 > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --20cf300fad190b133c04c09c68db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think we should note the discussion happening over in SPDY-dev about = their flow control and concerns about it

=A0 https://groups= .google.com/forum/?fromgroups#!topic/spdy-dev/JB_aQPNI7rw

Our mux proposal with it's send quotas has effectively the same pro= blem - namely that a fixed quota per channel can cause a significant under = utilisation of a fast link, but can also represent a significant over alloc= ation of capacity if many channels are present.=A0 I think we need to close= ly follow that discussion to see what solutions may be developed before we = commit to a per channel window flow control.

cheers



On 20 April 2012 08:08= , Takeshi Yoshino <tyoshino@google.com> wrote:
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


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


--20cf300fad190b133c04c09c68db-- From internet-drafts@ietf.org Tue May 22 03:20: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 27BEC21F8585; Tue, 22 May 2012 03:20: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 wlD0Qz87QeZb; Tue, 22 May 2012 03:20:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3564D21F8435; Tue, 22 May 2012 03:20: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.02 Message-ID: <20120522102010.13128.70070.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 03:20:10 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-04.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 10:20: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-04.txt Pages : 17 Date : 2012-05-22 This specification defines a WebSocket extension that adds per-frame compression functionality to the WebSocket Protocol. It compresses the "Application data" portion of WebSocket data frames using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each frame. This specification provides one compression method available for the extension using DEFLATE. 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-04.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-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-perframe-compres= sion/ From tyoshino@google.com Tue May 22 03:26: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 C48EC21F85F2 for ; Tue, 22 May 2012 03:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IfL52TlhBee for ; Tue, 22 May 2012 03:26:39 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD421F84BF for ; Tue, 22 May 2012 03:26:39 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6142094ggn.31 for ; Tue, 22 May 2012 03:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record; bh=7tfdyFcE4uKc40eEbhitMFvPJsh1eyRwQfnttlnUnWM=; b=OuQChKxmkKGB2PZ8+tqFQ7VWctzYPT2oZo7ALkSDzSn6pz7gMrYM80kHPXOnoWoJNf 8D8SLtfdxms4PF78leCHlk+QVlEd1gP6TZqs3zylPlcxqOn0hQju7fOFWRjj8DooBtXI 9anQBZ69DfdeGisuYBuA36l9v6yBXd/Poqub3TMRrELZ/VhWbUbNvucNS0oRDO56rn2g HJr6WHAe2+3fa6dZ+MwRQu2YW4EYKUkkH2Mtymx6IY9iPRAcEBdFn4wKq+1BQP8ZN2IS 8qIwkn5tPYGPdGqx7kIVS3524ATnoH7YNyba2a6R3PgGbQT2+W+wEqgp/FN5yAgzfENg oxLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record:x-gm-message-state; bh=7tfdyFcE4uKc40eEbhitMFvPJsh1eyRwQfnttlnUnWM=; b=jWO6ISyXquUGqyr4d//GYCQ1Yn5rXah1wkE9xit/a8iCdqorMl68PrP/aQi8porYGo v0/UrrayPWGwFhgb6PaiKww8jsik/ivwalOwT5wPqWw+Fy13goN8lvtnVg0fkJKSHnqg oE8ZhGkpeS7mK6JepBzoFEuUnIGKAUsOQzEKyWNsl80DhIwCEhuXnewE6VfAHH9x+Z6u mMuEZ9x0e1O8kDQWIOX8AydxCKNONoocp2dBn1vfMEQVma766srzlkd/kyXIiBKeQhsA uaXf7gGUMhlTvi3BnRM0Rmjy96GsRcPmZBgseF0JU96gKUP/RQGQhLyjIq71ic0Oj0Ee /hOg== Received: by 10.50.11.225 with SMTP id t1mr9029958igb.64.1337682398477; Tue, 22 May 2012 03:26:38 -0700 (PDT) Received: by 10.50.11.225 with SMTP id t1mt12446680igb.64.1337682398346; Tue, 22 May 2012 03:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.112.130 with HTTP; Tue, 22 May 2012 03:26:18 -0700 (PDT) In-Reply-To: <20120522102010.13128.70070.idtracker@ietfa.amsl.com> References: <20120522102010.13128.70070.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Tue, 22 May 2012 19:26:18 +0900 Message-ID: Cc: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f646c172d57fd04c09d7466 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkXUReX9SnUZ12u+1o5ucHbm1vRcDORxzf/ryB5WS7Z3y0UgXIKTaNvu9qH0BmZEwkzKRf+QIBpwRu6tPvTJ7ifSWHiG8kn3ODuPgqqTFfkl71kFLt9MSvtfaENZT50j83E7IUy Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-compression-04.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 10:26:39 -0000 --e89a8f646c172d57fd04c09d7466 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've published a new draft -04 of compression spec. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-perframe-compression-04.txt Changes - clarified that listing multiple descriptions with the same name is allowed - now the server echoes back the requested parameters - max_window_size and no_context _takeover are renamed to ones with prefixes s2c_ and c2s_ to clarify which direction they are applied --e89a8f646c172d57fd04c09d7466 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I've published a new draft -04 of com= pression spec.


Changes
- clarified that listing multiple des= criptions with the same name is allowed
- now the server echoes b= ack the requested parameters
- max_window_size and no_context _ta= keover are renamed to ones with prefixes s2c_ and c2s_ to clarify which dir= ection they are applied

--e89a8f646c172d57fd04c09d7466-- From arman@noemax.com Tue May 22 04:40:36 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5A021F853D for ; Tue, 22 May 2012 04:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6] 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 TkrCutRiL+fJ for ; Tue, 22 May 2012 04:40:35 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF0721F853C for ; Tue, 22 May 2012 04:40:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1337686828; x=1338291628; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=4rWUPBa+Gr9Hv3m2mIjs7HC02HE=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=SLydmRNG8+pCODRLh+JOnR7KlY3A3TxQidIr++IjuYPXvR4qN7605rq1yLRUW667HVuTnh7MjnBGvzJHndehyZmFJWou027m4rTxnJ0X8zhbARFejmtd5+tT/vjPtTi4QqBc0a/I1Y2Yp1FaDBdcgdVLYoGXWd+t2ECgw09RW/s= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id GQK73426; Tue, 22 May 2012 14:40:26 +0300 From: "Arman Djusupov" To: "'Greg Wilkins'" , "'Takeshi Yoshino'" References: <20120420050004.2740.14810.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 22 May 2012 14:40:21 +0300 Message-ID: <002701cd380f$af9ae000$0ed0a000$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01CD3828.D4E90260" X-Mailer: Microsoft Outlook 14.0 thread-index: AQJn75cJ8lUw0ksMyaNp2LI8wkJEbwHVGKzrAZ9SYVmVhJuoAA== Content-language: en-us Cc: hybi@ietf.org 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: Tue, 22 May 2012 11:40:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01CD3828.D4E90260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The mux specification does not define an algorithm for calculating the subsequent FC quota to be sent to the remote side. This means that the quota is not required to be a fixed value, it can have a dynamic value taking into account various criteria including the share of the per-connection window space available. If we have to resolve the overallocation and underutilization issue on the protocol level, we would need a more complex flow control protocol that would be able use an optimistic window size and discard/retransmit the frames that would be overbuffered. This would definitely be much more complex and I doubt that it would resolve performance problems. Note that the issues being discussed in the SPDY list are not only SPDY problems, they are present even with TCP/IP intermediaries (with the difference that TCP/IP packets can be discarded and retransmitted later if the link is overloaded). With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg Wilkins Sent: Tuesday, May 22, 2012 12:12 PM To: Takeshi Yoshino Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-01.txt I think we should note the discussion happening over in SPDY-dev about their flow control and concerns about it https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/JB_aQPNI7rw Our mux proposal with it's send quotas has effectively the same problem - namely that a fixed quota per channel can cause a significant under utilisation of a fast link, but can also represent a significant over allocation of capacity if many channels are present. I think we need to closely follow that discussion to see what solutions may be developed before we commit to a per channel window flow control. cheers On 20 April 2012 08:08, Takeshi Yoshino wrote: 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 _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi ------=_NextPart_000_0028_01CD3828.D4E90260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The mux specification does not define an algorithm = for calculating the subsequent FC quota to be sent to the remote = side. This means that the quota is not required to be a fixed value, it = can have a dynamic value taking into account various criteria = including the share of the per-connection window space available. =

 

If we have to resolve the overallocation and underutilization issue = on the protocol level, we would need a more complex flow control = protocol that would be able use an optimistic window size and = discard/retransmit the frames that would be overbuffered. This would = definitely be much more complex and I doubt that it would resolve = performance problems.

 

Note that the issues being discussed in the SPDY list are not only = SPDY problems, they are present even with TCP/IP intermediaries (with = the difference that TCP/IP packets can be discarded and retransmitted = later if the link is overloaded).

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Greg Wilkins
Sent: Tuesday, May 22, 2012 12:12 = PM
To: Takeshi Yoshino
Cc: = hybi@ietf.org
Subject: Re: [hybi] I-D Action: = draft-ietf-hybi-websocket-multiplexing-01.txt

 


I think we should note the discussion = happening over in SPDY-dev about their flow control and concerns about = it

  https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/JB_aQ= PNI7rw

Our mux proposal with it's send quotas has effectively = the same problem - namely that a fixed quota per channel can cause a = significant under utilisation of a fast link, but can also represent a = significant over allocation of capacity if many channels are = present.  I think we need to closely follow that discussion to see = what solutions may be developed before we commit to a per channel window = flow control.

cheers

On 20 April 2012 08:08, Takeshi Yoshino <tyoshino@google.com> = wrote:

Hi = all,

 

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

 

 

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

 


______________________________________= _________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi

 

------=_NextPart_000_0028_01CD3828.D4E90260-- From jduell.mcbugs@gmail.com Tue May 22 21:38: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 6CD8021F85FF for ; Tue, 22 May 2012 21:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJS6q3D6QE+s for ; Tue, 22 May 2012 21:38:43 -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 B4A2F21F85F4 for ; Tue, 22 May 2012 21:38:43 -0700 (PDT) Received: by qcsq13 with SMTP id q13so5438321qcs.31 for ; Tue, 22 May 2012 21:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/YkNzPWL5aLiL4aZAekEM05sY/GRaZsODEJI3GWca58=; b=PL/rb3SPku6h7vtMLSeRIpq65ePZ15CAh8mF+5SDYa41FxuctxpVJnzq27llRTiD7K jlOJ7SLO7V+y8poueD0oq/3yo0YcZz0MIF/rjws2U0aad2jBQDVDuq2fOJtN79eV/MYW cGaCdvhRQCkf31i768YSVNKC0vKhY2GMN3fhVNB5irbtGJQZfjJgGFJrw6bGNxjc5X7f aoNsCKjGWtKrrzPmFO0UAR3xJ8Zfwec02ZmKNVTK7eHQHlgQ2XRxI1gmwcrhOQosv9HF ZaBYqGwO1yPkInG/RURI+Y/s9uyVbEq7xJ2hEm6rkB+uegmn8IoI10hPgY6g5+rzGpn1 jKeQ== Received: by 10.229.135.193 with SMTP id o1mr4615869qct.34.1337747922912; Tue, 22 May 2012 21:38:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.198.26 with HTTP; Tue, 22 May 2012 21:38:22 -0700 (PDT) In-Reply-To: References: <4FAACC40.6040308@isode.com> From: Jason Duell Date: Tue, 22 May 2012 21:38:22 -0700 Message-ID: To: Takashi Toyoshima , hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 23 May 2012 04:38:44 -0000 On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima wrote: > I'll fix WebKit implementation of receiving 1005, 1006, 1015, and > length=1 of close frames. > These frames will fire CloseEvent with code=1006 and wasClean=false. What, if anything, do you plan to reply to the endpoint with, if the 1005/1006/1015 is received before your client has sent its own close frame? Will you be replying with 1002, but delivering 1006 to onclose? I can see the logic there, though it's a little confusing. The only other choice would seem to be to simply shut down the TCP connection with no close frame, but that seems harsh. Or we could both send 1002 to the remote server and deliver it to onclose (though I agree that 1006 seems closer in meaning). Jason Duell Mozilla >> We can. But as Arman suggested, we can also just use the existing code 1002 >> to tell the remote endpoint that it's broken when the closing handshake >> initiator is the remote endpoint. From bruce@callenish.com Wed May 23 11:47:22 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 1868A21F8764 for ; Wed, 23 May 2012 11:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Q+Xdc3QmuxLe for ; Wed, 23 May 2012 11:47:21 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.217.142]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6F21F8763 for ; Wed, 23 May 2012 11:47:21 -0700 (PDT) Received: from [24.108.214.86] (port=49551 helo=[192.168.145.103]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SXGab-00055i-JP; Wed, 23 May 2012 11:47:17 -0700 Message-ID: <4FBD30C7.8090206@callenish.com> Date: Wed, 23 May 2012 11:47:35 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" Subject: Re: [hybi] RSV bits in extensions 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, 23 May 2012 18:47:22 -0000 On 5/21/2012 3:35 AM, Greg Wilkins wrote: > In practise, I believe this means that the RSV bits are of very very > limited use to 3rd party extensions and really have been reserved for > extensions developed by this WG. For example RSV1 will effectively > become the compression bit once the per-frame-compession draft is > accepted and RSV1 will only be able to be used by other extensions > that are obviously mutually exclusive to per-frame-compression (such > as stream compression) > > I'm not saying this is a bad thing... it's probably good to have these > bits available for standard extensions without the need for the > complexity of dynamic bit allocations. It just means that 3rd > party extension should really avoid using these bits and put their own > flags in the payload.... unless somebody wants to define the > unlimited-reserved-bit extension to be used with other extension :) > I think this is a little pessimistic. People writing extensions only have to accept that if they use a particular RSV bit, they are automatically incompatible with any other extension that uses it. So long as everyone is really clear in their documentation about what RSV bits they use, users can decide how to deploy them so that no conflicts occur. Admittedly, though, if this WG defines any other RSV bits, that will effectively make them off-limits to others. I wouldn't recommend to any extension writer that they use the RSV1 bit for their extension, for example, unless it was an extension for compression. So although users manually managing extensions for RSV bit conflicts is complicated, and although extension writers run a risk of being booted off their chosen RSV bit by the WG, I still think using them is doable for a couple of reasons. First, I don't see that there will be a flood of extensions that require an RSV bit, and second I don't see the WG rushing to create standard uses for them either. Of course, I could be wrong. If there is a sudden rush for RSV bits then that might be a reason for the WG to define one of the RSV bits as an RSV bit extender, or to have an extension for reserve bits as you suggest. Let's see what happens. From jat@google.com Wed May 23 18:20:18 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 5D03D11E80AB for ; Wed, 23 May 2012 18:20:18 -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 ibZdLoMJf2th for ; Wed, 23 May 2012 18:20:17 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0693011E8072 for ; Wed, 23 May 2012 18:20:15 -0700 (PDT) Received: by qadz3 with SMTP id z3so3861242qad.10 for ; Wed, 23 May 2012 18:20: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=A1Qy7ologfVa8FoBAlle1OsQWKrwessSlR4Q63qHApM=; b=TdAIHfc/aKh7kNFyiBakiqrIOdLQQjyoyzJrx3JGBv41kQyG0QRWRFQRndXPSaDE7y jWIjeZfIbEEnOPxMoWKafsBBnbap5ZG8e7p1kavI5AR2tfjbVrTe+OUErLaeVfwwpcu1 TwoqwiUMp/x2dBXG7IEyH/M3xoSKiKvG0zAnkNIgIhoUqLSMBe/mnffwLudbc8d79Fdi k7zL3qjDYbjOoR3naRfrqAANTUjYZ62F2a+RAKaEhARQFJsnzdKoxSCBezN02kjyfoW6 T5TgTp1NUXth5wvXKTjZLTbVvLcM6nLMbm4pY/hZuUfp6bGbtmp5Mts7P9Ijc4Rod/Kd PMGQ== 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=A1Qy7ologfVa8FoBAlle1OsQWKrwessSlR4Q63qHApM=; b=pd7XPsKyLItZMtgCk18B1msU1n+gMLJoRI/8d99J9YZupJqAtkvpv6Z+bpoMwjbL1P rkLGEH4jzFpZxw/Pjiqzw5OtctsDoiw0yXoKu6o+mmcEo8IhYiJwR7MEJ8eG8KgOJsdZ 3IaE0rw1428YrteKgX0NfFR7+Xt+Ob5Wiy2+m3nKxNtgGtl/EmeAA5O/y1oxhOzxYZ8W wl+V5K5y+TEc6F5khPsXN2/BL2NLUxnHpTm7nXXjKMlgw7IjSENUWkTvhaTss+n7e8E1 4GHI1zj7xYKaUnedDb6p3VcNF3OgtyYwVAFUfOWVColVCdkHqejjSituSi+sRgCVjs+1 v3WQ== Received: by 10.224.44.136 with SMTP id a8mr8721568qaf.34.1337822414824; Wed, 23 May 2012 18:20:14 -0700 (PDT) Received: by 10.224.44.136 with SMTP id a8mr8721554qaf.34.1337822414631; Wed, 23 May 2012 18:20:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.77.195 with HTTP; Wed, 23 May 2012 18:19:54 -0700 (PDT) In-Reply-To: <4FBD30C7.8090206@callenish.com> References: <4FBD30C7.8090206@callenish.com> From: John Tamplin Date: Wed, 23 May 2012 21:19:54 -0400 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=20cf306f7724cbf34304c0be0d4e X-System-Of-Record: true X-Gm-Message-State: ALoCoQmqN3ApFzlIzFWys875YP07IhSE/lrHzqbWDOBZmUqUn3aHshxZYI0751xPrZkj+SUFa2n1p0NHdgIQxV3OIpsYyUB9F47rZ8qXsjr0XgDyDPeO3nCWc1geXV4d8f/cYHvgOUfB Cc: "hybi@ietf.org" Subject: Re: [hybi] RSV bits in extensions 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, 24 May 2012 01:20:18 -0000 --20cf306f7724cbf34304c0be0d4e Content-Type: text/plain; charset=UTF-8 On Wed, May 23, 2012 at 2:47 PM, Bruce Atherton wrote: > I think this is a little pessimistic. People writing extensions only have > to accept that if they use a particular RSV bit, they are automatically > incompatible with any other extension that uses it. So long as everyone is > really clear in their documentation about what RSV bits they use, users can > decide how to deploy them so that no conflicts occur. > > Admittedly, though, if this WG defines any other RSV bits, that will > effectively make them off-limits to others. I wouldn't recommend to any > extension writer that they use the RSV1 bit for their extension, for > example, unless it was an extension for compression. > > So although users manually managing extensions for RSV bit conflicts is > complicated, and although extension writers run a risk of being booted off > their chosen RSV bit by the WG, I still think using them is doable for a > couple of reasons. First, I don't see that there will be a flood of > extensions that require an RSV bit, and second I don't see the WG rushing > to create standard uses for them either. > > Of course, I could be wrong. If there is a sudden rush for RSV bits then > that might be a reason for the WG to define one of the RSV bits as an RSV > bit extender, or to have an extension for reserve bits as you suggest. > Let's see what happens. I suspect that if we came up with a bunch of extensions that needed reserved bits, we would come up with a way of dynamically allocating them. So, I don't think it is really a problem. -- John A. Tamplin Software Engineer (GWT), Google --20cf306f7724cbf34304c0be0d4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 23, 2012 at 2:47 PM, Bruce Atherton = <bruce@callenish.com> wrote:
I think this is a little pessimistic. People writing exte= nsions only have to accept that if they use a particular RSV bit, they are = automatically incompatible with any other extension that uses it. So long a= s everyone is really clear in their documentation about what RSV bits they = use, users can decide how to deploy them so that no conflicts occur.

Admittedly, though, if this WG defines any other RSV bits, that will effect= ively make them off-limits to others. I wouldn't recommend to any exten= sion writer that they use the RSV1 bit for their extension, for example, un= less it was an extension for compression.

So although users manually managing extensions for RSV bit conflicts is com= plicated, and although extension writers run a risk of being booted off the= ir chosen RSV bit by the WG, I still think using them is doable for a coupl= e of reasons. First, I don't see that there will be a flood of extensio= ns that require an RSV bit, and second I don't see the WG rushing to cr= eate standard uses for them either.

Of course, I could be wrong. If there is a sudden rush for RSV bits then th= at might be a reason for the WG to define one of the RSV bits as an RSV bit= extender, or to have an extension for reserve bits as you suggest. Let'= ;s see what happens.

I suspect that if we came up with a bunch of extensions= that needed reserved bits, we would come up with a way of dynamically allo= cating them. =C2=A0So, I don't think it is really a problem.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google --20cf306f7724cbf34304c0be0d4e-- From tyoshino@google.com Wed May 23 21:12: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 ED70721F8567 for ; Wed, 23 May 2012 21:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=0.323, 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 Xx2rweWtAvOb for ; Wed, 23 May 2012 21:12:49 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1CF21F855B for ; Wed, 23 May 2012 21:12:37 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8572341ggn.31 for ; Wed, 23 May 2012 21:12:37 -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=v43dV95BkzR5d7gdpzNeNvMfVFsDK0/dSKSY4IzGL2U=; b=a02feOlrSm1tMcsMcimDAOTfAJeC4phMQsCO0jSz1a3nDFcguFC73gCO03U09/9xnN p97+jZZZqTYAN+heSWts1d8WRbpsMTuWeR2HeZZKxq3xzDJH1KpvXdr3/65XIOl8VEWk 1gywP/VNZcSqoh/3USvEVVEvQLjTm+BpWFyit51enOSsbBHK81r39hiJ2PEfxDAka/SR grz9KoF16coJnt8DX2+Q0LMSheZ1xxI7LrIixWHDscAPgFQulcaDdAl49xFY6DKeyfmw N08e3CrNAlNjlYj34VQEnUwUrvyGIlHSv7erqwj7zYOXpF5PXyTPqOQDB0JxcWm3xIS0 bzmg== 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=v43dV95BkzR5d7gdpzNeNvMfVFsDK0/dSKSY4IzGL2U=; b=Wtz8XjBBlVQpuXYb6mUttK3WsOtciNj/oZYGsmHumq8H0vkk9BSIe9t+YSCdLGEjOm VjwZMFDAXHpE4fxlWwsbOizJuWSd6TQxGGQA8ZGLm82yJ2Ztcjita2+0eI5GgBchzl6q rRTk72NlDY6/yC81g5sZ2vpGoW8hDsiEZK+PvneN0CHGgt0cUjZNBmC1iVOwpeq5CeLQ H21vrJTINwPBDY+2g3zm/5Z8NtU/jBAKDU4r+bjPif5tPYMnkMmUhqG3+HpWyi0x7AD+ qnuBjyGS3JqOTLHe1xKUkFiwIyTT2l/NP7GONmiRGEzcqi7AwWt3k6kKzUxUMif5GbQw MdTA== Received: by 10.42.63.80 with SMTP id b16mr19905700ici.29.1337832756739; Wed, 23 May 2012 21:12:36 -0700 (PDT) Received: by 10.42.63.80 with SMTP id b16mr19905693ici.29.1337832756652; Wed, 23 May 2012 21:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Wed, 23 May 2012 21:12:15 -0700 (PDT) In-Reply-To: References: <4FAACC40.6040308@isode.com> From: Takeshi Yoshino Date: Thu, 24 May 2012 13:12:15 +0900 Message-ID: To: Jason Duell Content-Type: multipart/alternative; boundary=90e6ba5bb94f3aac3704c0c076c9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn9lkSbYCntz5Yn61Ohm2AMgyn6l3xOnHw27vmLa5ebtfIZ7tuo0zwyJq1WgRnra4/n8ZcE5v811rxba0jwJOcbKZxFz3YNiBX+1YrFegYrEXINRoH7KzjxfEkd228/ql3XNw12 Cc: Takashi Toyoshima , hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 24 May 2012 04:12:50 -0000 --90e6ba5bb94f3aac3704c0c076c9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 23, 2012 at 1:38 PM, Jason Duell wrote: > On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima > wrote: > > I'll fix WebKit implementation of receiving 1005, 1006, 1015, and > > length=1 of close frames. > > These frames will fire CloseEvent with code=1006 and wasClean=false. > > What, if anything, do you plan to reply to the endpoint with, if the > 1005/1006/1015 is received before your client has sent its own close > frame? Will you be replying with 1002, but delivering 1006 to > onclose? I can see the logic there, though it's a little confusing. > Yes. It's a bit confusing but well defined behavior. For any other protocol violation, the endpoint received a broken frame SHOULD send 1002 and MUST invoke onclose with 1006. http://tools.ietf.org/html/rfc6455#section-7.1.7 > The only other choice would seem to be to simply shut down the TCP > connection with no close frame, but that seems harsh. Or we could > both send 1002 to the remote server and deliver it to onclose (though > I agree that 1006 seems closer in meaning). It's SHOULD. Shutting down TCP without sending 1002 is also fine as per spec. http://tools.ietf.org/html/rfc6455#section-7.1.7 There has been discussion about the meaning of the code argument of the onclose handler. As 7.1.5 of the spec http://tools.ietf.org/html/rfc6455#section-7.1.5 explains, now it's meaning is finalized as "the status code contained in the first Close control frame received". That's my understanding. So, the code for onclose must be 1006. --90e6ba5bb94f3aac3704c0c076c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 23, 2012 at 1:38 PM, Jason Duell <jduell.mcbugs@gmail.com> wrote:
On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima
<toyoshim@chromium.org> = wrote:
> I'll fix WebKit implementation of receiving 1005, 1006, 1015, and<= br> > length=3D1 of close frames.
> These frames will fire CloseEvent with code=3D1006 and wasClean=3Dfals= e.

What, if anything, do you plan to reply to the endpoint with, if the<= br> 1005/1006/1015 is received before your client has sent its own close
frame? =A0Will you be replying with 1002, but delivering 1006 to
onclose? =A0I can see the logic there, though it's a little confusing.<= br>

Yes. It's a bit confusing but well = defined behavior. For any other protocol violation, the endpoint received a= broken frame SHOULD send 1002 and MUST invoke onclose with 1006.

=A0
The only other choice would seem to be to simply shut down the TCP
connection with no close frame, but that seems harsh. =A0Or we could
both send 1002 to the remote server and deliver it to onclose (though
I agree that 1006 seems closer in meaning).

It's SHOULD. Shutting down TCP without sending 1002 is also fine = as per spec.=A0http://tools.ietf.org/html/rfc6455#section-7.1.7

There has been discussio= n about the meaning of the code argument of the onclose handler. As 7.1.5 o= f the spec=A0h= ttp://tools.ietf.org/html/rfc6455#section-7.1.5=A0explains, now it'= s meaning is finalized as "the status code contained in the first Clos= e=A0control frame received". That's my understanding. So, the code= for onclose must be 1006.

--90e6ba5bb94f3aac3704c0c076c9-- From toyoshim@google.com Thu May 24 00:43:52 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 A95F121F8565 for ; Thu, 24 May 2012 00:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AXZhKlF7a5S1 for ; Thu, 24 May 2012 00:43:52 -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 CFBA421F8559 for ; Thu, 24 May 2012 00:43:51 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so6608133lbb.31 for ; Thu, 24 May 2012 00:43:50 -0700 (PDT) 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-system-of-record; bh=nDOsJIUew3L6H3Ge2XIV/QNAEY+rzzwhW5VTWE0gewU=; b=OCP8pz9+4Kae9nwHIsSxRgXSjK+7uw/LOghrQIYwWso1bSAXIKWP3RCx0xMGb6CggR Bh+SwYgmL/1cndy8SFBKyJIvi/LymMCxBTgoTO4myVHLtyiONiCLZ0cP9I/3xUBgt3Gp yUfB3tZAdre2cypnOX+0LSQKYe2OIkp+MM89MgJ9kkeAXHqz9PCsDdjUFBgzZfm69KvC NXDx7flJYI6g0MLbDmvf51asQOIEftuwgNEM/I1IGPWRzK27BNFcTq5ntgEB/rcS+AFv J7ub4Lob1M/wM4rMAWoAG+//VhHScgPRiGHTyQoAbac4oBuHkXw1P6QsnmSQin1xBgxU jCJA== 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-system-of-record:x-gm-message-state; bh=nDOsJIUew3L6H3Ge2XIV/QNAEY+rzzwhW5VTWE0gewU=; b=L6pwLOGsU7RHG4J6rxToXIK3XZBDq6Fpi9itEKYCThRWX2y8iFmMysUDy17/xbHHx1 1UA4PpFFZLS8QoJBLh2hGuiJpkNT/srIov/y5V2SMDWJPMMX9USGNVrV049FQJ9UxkBc wNPtLmfy9wmttlQT4djLAmoQY+xmxtbRekihLWwmELws1RKcH7fa/2OptHqRs3t5J1Ig YntiFQCCCTzk3HRGQn5zxJ0ouRPz9UHdIHliZbKf2qdm8RsydHueZ1tQzVm+/cmTBiCf MeeNPL9OZ8ZzzFWXv2RiyE3gyol3pYKzw+zDIqdej9mWqa71Tqa+xxvLBNAo13r45u34 +taQ== Received: by 10.152.125.116 with SMTP id mp20mr29559731lab.19.1337845430740; Thu, 24 May 2012 00:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr29559717lab.19.1337845430489; Thu, 24 May 2012 00:43:50 -0700 (PDT) Sender: toyoshim@google.com Received: by 10.112.113.130 with HTTP; Thu, 24 May 2012 00:43:50 -0700 (PDT) In-Reply-To: References: <4FAACC40.6040308@isode.com> Date: Thu, 24 May 2012 16:43:50 +0900 X-Google-Sender-Auth: 1CEK-Nw2fGgZZcW8lvhREBhLtSc Message-ID: From: Takashi Toyoshima To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk/sk51t/hKL2HxJ9UPPR9q02bqaOovos/v1zzJY32GD+AaVpCO4eCUU2ORtaM+q2xfL78v1rLqkdALhAaO5BWbZbAYc18kp01kzUQjyzTAEz/17dMAGaQaF11H5amP+eLlEOX4 Cc: hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 24 May 2012 07:43:52 -0000 I'm planing to deliver 1006 and fall back to the _Fail the WebSocket Connection_ process. Currently it doesn't send an appropriate status code. But I also think 1002 is the best if I sent. On Thu, May 24, 2012 at 1:12 PM, Takeshi Yoshino wrot= e: > On Wed, May 23, 2012 at 1:38 PM, Jason Duell > wrote: >> >> On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima >> wrote: >> > I'll fix WebKit implementation of receiving 1005, 1006, 1015, and >> > length=3D1 of close frames. >> > These frames will fire CloseEvent with code=3D1006 and wasClean=3Dfals= e. >> >> What, if anything, do you plan to reply to the endpoint with, if the >> 1005/1006/1015 is received before your client has sent its own close >> frame? =A0Will you be replying with 1002, but delivering 1006 to >> onclose? =A0I can see the logic there, though it's a little confusing. > > > Yes. It's a bit confusing but well defined behavior. For any other protoc= ol > violation, the endpoint received a broken frame SHOULD send 1002 and MUST > invoke onclose with 1006. > > http://tools.ietf.org/html/rfc6455#section-7.1.7 > >> >> The only other choice would seem to be to simply shut down the TCP >> connection with no close frame, but that seems harsh. =A0Or we could >> both send 1002 to the remote server and deliver it to onclose (though >> I agree that 1006 seems closer in meaning). > > > It's SHOULD. Shutting down TCP without sending 1002 is also fine as per > spec.=A0http://tools.ietf.org/html/rfc6455#section-7.1.7 > > There has been discussion about the meaning of the code argument of the > onclose handler. As 7.1.5 of the > spec=A0http://tools.ietf.org/html/rfc6455#section-7.1.5=A0explains, now i= t's > meaning is finalized as "the status code contained in the first > Close=A0control frame received". That's my understanding. So, the code fo= r > onclose must be 1006. > From alexey.melnikov@isode.com Thu May 24 05:52:26 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 339CC21F85D1 for ; Thu, 24 May 2012 05:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0Pqu+QaR6IjQ for ; Thu, 24 May 2012 05:52:25 -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 E4B5D21F8512 for ; Thu, 24 May 2012 05:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337863944; d=isode.com; s=selector; i=@isode.com; bh=rf35vjdSAQr1ccbOnHT/MK89X3K8lKUDJoSHRLd5rFg=; 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=wQlTowbE3q4TsGMugTWfgv7tKKEqDWEyD1xbNWxSw+LdfZDVqe92v+qSRIw/bJK5JhqM1R 7jGeS28TzitvL9n7VC8RbpQBrKmJwA6LiCitXcwCIVLlTKBxTZ3bfWH3rBPKavUDfLEth5 PmhU2/b9UHDN0tr+EDCtW3OMBrqmym4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 24 May 2012 13:52:24 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FBE2F1E.1030307@isode.com> Date: Thu, 24 May 2012 13:52:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Hybi References: <4FB3765D.5060308@isode.com> <001401cd340c$446034e0$cd209ea0$@noemax.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060206050902070401060506" Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 24 May 2012 12:52:26 -0000 This is a multi-part message in MIME format. --------------060206050902070401060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 21/05/2012 11:45, Greg Wilkins wrote: > > They both look reasonable. Ok, I will register these, but I will call the second one "Try Again Later" instead of "Service Overload". "Try Again Later" is used by other protocols and the meaning is more generic. > On 17 May 2012 11:05, Arman Djusupov > wrote: > > Yes. These status codes do make sense and it is preferable to have > them > standardized. > > With best regards, > Arman > > -----Original Message----- > From: hybi-bounces@ietf.org > [mailto:hybi-bounces@ietf.org ] On > Behalf Of > Alexey Melnikov > Sent: Wednesday, May 16, 2012 12:42 PM > To: Hybi > Subject: [hybi] Additional WebSocket Close Error Codes > > Hi WG, > I am sorry I didn't followup on this when the following 2 codes were > suggested (See > ): > > 1012/Service Restart > 1012 indicates that the service is restarted. a client may reconnect, > and if it choses to do, should reconnect using a randomized delay > of 5 - > 30s. > > Use case: > restart a service with 100k clients connected > clients present an informative user notification ("service > restarting .. > reconnecting in N secs) > clients should not reconnect all at exactly the same time .. thus the > randomized delay > > > 1013/Service Overload > 1013 indicates that the service is experiencing overload. a client > should only connect to a different IP (when there are multiple for the > target) or reconnect to the same IP upon user action. > > Use case: > clients present an informative user notification ("service overload .. > try later or try different IP) > > ----- > > Do people use these and is there still some interest in > registering them? > > Best Regards, > Alexey > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --------------060206050902070401060506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 21/05/2012 11:45, Greg Wilkins wrote:

They both look reasonable.

Ok, I will register these, but I will call the second one "Try Again Later" instead of "Service Overload". "Try Again Later" is used by other protocols and the meaning is more generic.

On 17 May 2012 11:05, Arman Djusupov <arman@noemax.com> wrote:
Yes. These status codes do make sense and it is preferable to have them
standardized.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
Alexey Melnikov
Sent: Wednesday, May 16, 2012 12:42 PM
To: Hybi
Subject: [hybi] Additional WebSocket Close Error Codes

Hi WG,
I am sorry I didn't followup on this when the following 2 codes were
suggested (See
<http://www.ietf.org/mail-archive/web/hybi/current/msg09284.html>):

1012/Service Restart
1012 indicates that the service is restarted. a client may reconnect,
and if it choses to do, should reconnect using a randomized delay of 5 -
30s.

Use case:
restart a service with 100k clients connected
clients present an informative user notification ("service restarting ..
reconnecting in N secs)
clients should not reconnect all at exactly the same time .. thus the
randomized delay


1013/Service Overload
1013 indicates that the service is experiencing overload. a client
should only connect to a different IP (when there are multiple for the
target) or reconnect to the same IP upon user action.

Use case:
clients present an informative user notification ("service overload ..
try later or try different IP)

-----

Do people use these and is there still some interest in registering them?

Best Regards,
Alexey

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

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


--------------060206050902070401060506-- From julian.reschke@gmx.de Thu May 24 12:13: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 4BEC611E80E6 for ; Thu, 24 May 2012 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx0HcsGw5w4f for ; Thu, 24 May 2012 12:13: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 4EDEF11E80E2 for ; Thu, 24 May 2012 12:13:55 -0700 (PDT) Received: (qmail invoked by alias); 24 May 2012 19:13:53 -0000 Received: from p5DD9682C.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.104.44] by mail.gmx.net (mp033) with SMTP; 24 May 2012 21:13:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18aYIIhxJsaFEmfM+0hHN4WdGo9t6Xmy9iA/YY8HB Kk51uUngYQb4o+ Message-ID: <4FBE886F.8050502@gmx.de> Date: Thu, 24 May 2012 21:13:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Arthur Barstow References: <4FBE6DF2.8050705@nokia.com> In-Reply-To: <4FBE6DF2.8050705@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: public-webapps , "hybi@ietf.org" Subject: Re: [hybi] RfC: LCWD of WebSocket API; deadline June 14 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, 24 May 2012 19:13:56 -0000 On 2012-05-24 19:20, Arthur Barstow wrote: > This is a Request for Comments re the 24-May-2012 LCWD version of the > WebSocket API: > > http://www.w3.org/TR/2012/WD-websockets-20120524/ > > The comment deadline is June 14 and all comments should be sent to the > public-webapps@w3.org list. The Bugzilla component for the API is [Bugz]. > ... I note that many keywords that reference parts of other specs are not hyperlinked, so it's extremely hard for a reader to understand what they are supposed to mean (phrasing it politely). For instance, in Section 7: "If the url string is not an absolute URL, then fail this algorithm." "absolute URL" is not defined anywhere in this document. "Resolve the url string, with the URL character encoding set to UTF-8. [RFC3629]" "Resolve" is not defined anywhere in this document. etc. Best regards, Julian From jduell.mcbugs@gmail.com Thu May 24 13:19: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 1600611E809D for ; Thu, 24 May 2012 13:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 daz5+wMwItr3 for ; Thu, 24 May 2012 13:19:09 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C46C11E8097 for ; Thu, 24 May 2012 13:19:09 -0700 (PDT) Received: from [10.0.0.174] (108-224-128-249.uvs.rlghnc.sbcglobal.net [108.224.128.249]) (Authenticated sender: jduell@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 854F2F2454; Thu, 24 May 2012 13:19:08 -0700 (PDT) Message-ID: <4FBE97BB.4090609@gmail.com> Date: Thu, 24 May 2012 16:19:07 -0400 From: Jason Duell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Takashi Toyoshima References: <4FAACC40.6040308@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 24 May 2012 20:19:10 -0000 > >>> On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima >>> wrote: >>>> I'll fix WebKit implementation of receiving 1005, 1006, 1015, and >>>> length=1 of close frames. >>>> These frames will fire CloseEvent with code=1006 and wasClean=false. >>> What, if anything, do you plan to reply to the endpoint with, if the >>> 1005/1006/1015 is received before your client has sent its own close >>> frame? Will you be replying with 1002, but delivering 1006 to >>> onclose? I can see the logic there, though it's a little confusing. >> Yes. It's a bit confusing but well defined behavior. For any other protocol >> violation, the endpoint received a broken frame SHOULD send 1002 and MUST >> invoke onclose with 1006. >> >> http://tools.ietf.org/html/rfc6455#section-7.1.7 > On Wed, May 23, 2012 at 1:38 PM, Jason Duell > wrote: So all protocol errors must deliver 1006 to JS instead of 1002? This is counter-intuitive to me, and I think it will confuse both users and developers. > As 7.1.5 of the spechttp://tools.ietf.org/html/rfc6455#section-7.1.5 explains, > now it's meaning is finalized as "the status code contained in the first > Close control frame received". OK--so if I follow you, the justification here to deliver 1006 to the application when the client encounters a protocol error is because we always set the close code to the error the *server* sends us, or 1006, (i.e a protocol error means no close frame, so 1006). I can see this reading of the spec. But the exact language for 1002 is "1002 indicates that an endpoint is terminating the connection due to a protocol error." Note that it says "an" endpoint, not "the remote endpoint." This makes me think we can deliver 1002 to JS for a protocol error we detect from the server. I suggest that we handle malformed close frames (with close code 1005/1006/1015) as a protocol error, and deliver 1002 to both the remote end and JS, and reserve 1006 for the case where the connection is simply closed, w/o any protocol error (i.e. no malformed frames received). I agree that in either case we should Fail the WS connection, so deliver onerror. Thoughts? Jason Duell Mozilla From tyoshino@google.com Fri May 25 00:16:12 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 5D6F821F848B for ; Fri, 25 May 2012 00:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=0.215, 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 Xk2SEDWaErWb for ; Fri, 25 May 2012 00:16:11 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01721F8484 for ; Fri, 25 May 2012 00:16:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so669082ggn.31 for ; Fri, 25 May 2012 00:16:10 -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=JEStCL55IO98GvoCaVO1juci/5KEL6w9Yw4FpT1ZDH8=; b=TV7ZMVLPlx4xOHY3kTDVz4yZUTC0s32ZztTsjEv2tKyayYrAdqVMQ3smTvqFnw4fmT FlwK1/Dw6VsC3zGjvtRHrNgDUhT0mjdo0nd35g3s5b3o23cKWZ/G6+unJuMPHZT6yp2h 8xAYI6aBcEW3FlqAImE32f4JI0Si82q55sLlS/WZaLZ2AAd0VvVqE3aYHA3dUD87rHt0 XdLM2jyPK0y19sqXNZVFCDlxuLyaJKM4b6V3fA0JqDihCYeq3GFM+D4awZP3900qphxL rRpee0jQvdy8oLEDAVNC8B/0rnCHHwlso9AIwI1zZFwLzn3580qM3g9MziiIyVNtVsmH AymA== 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=JEStCL55IO98GvoCaVO1juci/5KEL6w9Yw4FpT1ZDH8=; b=KWOsr5TWlu/LwtqC3KOeciy/ItSWhH5vuHtgBGPo7YF+2F4Ji6zc8COKTR+zjGDpdo EkfIa29Fnz7DNPAm/lRnUVZ02oiM0zeHZ/3hAhtppGvtG88zohfXFHUr4H5iyVXr16+N EKQ0clx4HLnQ6jBs+v5bB3g2UXlrXV3pp4wEI+EXeIGsL3b4fHEF2dU+2EjzzlMec0db iHo/4vwT+rUZwiI8g1jvRT6qfqeezeErjVaFuPUBMd++KciN8nKXFNEihhUampunU5Pv Q+kHwbzD8wNB0Sfx8VlC2A4yqVgXlTIfZncUHVrr+KtCRXYKNOevdDtDEKCAWU2ms0BH g21w== Received: by 10.50.168.34 with SMTP id zt2mr1172908igb.10.1337930170348; Fri, 25 May 2012 00:16:10 -0700 (PDT) Received: by 10.50.168.34 with SMTP id zt2mr1172895igb.10.1337930170109; Fri, 25 May 2012 00:16:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Fri, 25 May 2012 00:15:49 -0700 (PDT) In-Reply-To: <4FBE97BB.4090609@gmail.com> References: <4FAACC40.6040308@isode.com> <4FBE97BB.4090609@gmail.com> From: Takeshi Yoshino Date: Fri, 25 May 2012 16:15:49 +0900 Message-ID: To: Jason Duell Content-Type: multipart/alternative; boundary=e89a8f64289a860fd604c0d72489 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmTyp1Hqz9dU9PNhhk1OpP9e+RI3SmuPwQQAhkH9poa+GTKdFvOSGtenbrG9SzFgrrm0tuyw2+w6um1RxEyEKNmFCMWLjalWWASMclgkdv1bJgWZYByysrwlEKgNYsL9TgTByDc Cc: Takashi Toyoshima , hybi@ietf.org Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015 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, 25 May 2012 07:16:12 -0000 --e89a8f64289a860fd604c0d72489 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 25, 2012 at 5:19 AM, Jason Duell wrote: > On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima >>>> wrote: >>>> >>>>> I'll fix WebKit implementation of receiving 1005, 1006, 1015, and >>>>> length=1 of close frames. >>>>> These frames will fire CloseEvent with code=1006 and wasClean=false. >>>>> >>>> What, if anything, do you plan to reply to the endpoint with, if the >>>> 1005/1006/1015 is received before your client has sent its own close >>>> frame? Will you be replying with 1002, but delivering 1006 to >>>> onclose? I can see the logic there, though it's a little confusing. >>>> >>> Yes. It's a bit confusing but well defined behavior. For any other >>> protocol >>> violation, the endpoint received a broken frame SHOULD send 1002 and MUST >>> invoke onclose with 1006. >>> >>> http://tools.ietf.org/html/**rfc6455#section-7.1.7 >>> >> On Wed, May 23, 2012 at 1:38 PM, Jason Duell >> wrote: >> > > So all protocol errors must deliver 1006 to JS instead of 1002? This is > counter-intuitive to me, and I think it will confuse both users and > developers. > If we do so, the meaning of 1002 delivery to JS will be ambiguous. We need a way to determine whether the remote server is misbehaving or the client is. Otherwise, it makes healthy clients worry about bugs in themselves. Solutions I can come up with are: - check wasClean to distinguish it's remote error or local error - check if onerror was invoked or not to distinguish it's remote error or local error - add new status codes for local errors (e.g. 1022 "protocol error in the frame from the remote endpoint") Whichever we choose, we need to make change on 7.1.5. > As 7.1.5 of the spechttp://tools.ietf.org/**html/rfc6455#section-7.1.5 explains, >> >> now it's meaning is finalized as "the status code contained in the first >> Close control frame received". >> > > OK--so if I follow you, the justification here to deliver 1006 to the > application when the client encounters a protocol error is because we > always set the close code to the error the *server* sends us, or 1006, (i.e > a protocol error means no close frame, so 1006). > Yes. > I can see this reading of the spec. But the exact language for 1002 is > "1002 indicates that an endpoint is terminating the connection due to a > protocol error." Note that it says "an" endpoint, not "the remote > endpoint." This makes me think we can deliver 1002 to JS for a protocol > error we detect from the server. Yes, but I don't think the text has such implication. It's overridden by 7.1.5. --e89a8f64289a860fd604c0d72489 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 25, 2012 at 5:19 AM, Jason Duell <jduell.mcbugs@gmail.com> wrote:
On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima
<toyoshim@chr= omium.org> =A0wrote:
I'll fix WebKit implementation of receiving 1005, 1006, 1015, and
length=3D1 of close frames.
These frames will fire CloseEvent with code=3D1006 and wasClean=3Dfalse.
What, if anything, do you plan to reply to the endpoint with, if the
1005/1006/1015 is received before your client has sent its own close
frame? =A0Will you be replying with 1002, but delivering 1006 to
onclose? =A0I can see the logic there, though it's a little confusing.<= br>
Yes. It's a bit confusing but well defined behavior. For any other prot= ocol
violation, the endpoint received a broken frame SHOULD send 1002 and MUST invoke onclose with 1006.

http://tools.ietf.org/html/rfc6455#section-7.1.7
On Wed, May 23, 2012 at 1:38 PM, Jason Duell <jduell.mcbugs@gmail.com> wrote: <= br>

So all protocol errors must deliver 1006 to JS instead of 1002? =A0 This is= counter-intuitive to me, and I think it will confuse both users and develo= pers.

If we do so, the meaning of 1002 = delivery to JS will be ambiguous.=A0We need a way to determine whether the = remote server is misbehaving or the client is. Otherwise, it makes healthy = clients worry about bugs in themselves.

Solutions I can come up with are:

- check wasClean to distinguish it's remote error or local err= or
- check if onerror was invoked or not to distinguish it's = remote error or local error
- add new status codes for local errors (e.g. 1022 "protocol erro= r in the frame from the remote endpoint")

Whichever we choose, we need to make change on 7.1.5.
=A0
=A0As 7.1.5 o= f the spechttp://tools.ietf.org/html/rfc6455#section-7.1.5 = =A0explains,

=A0now it's meaning is finalized as "the status code contained in = the first
=A0Close control frame received".

OK--so if I follow you, the justification here to deliver 1006 to the appli= cation when the client encounters a protocol error is because we always set= the close code to the error the *server* sends us, or 1006, (i.e a protoco= l error means no close frame, so 1006).

Yes.
=A0
I can see this reading of the spec. =A0But the exact language= for 1002 is "1002 indicates that an endpoint is terminating the conne= ction due to a protocol error." =A0Note that it says "an" en= dpoint, not "the remote endpoint." =A0This makes me think we can = deliver 1002 to JS for a protocol error we detect from the server.

Yes, but I don't think the text has such implicatio= n. It's overridden by 7.1.5.

--e89a8f64289a860fd604c0d72489-- From jduell.mcbugs@gmail.com Fri May 25 16:11: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 59E6E21F8851 for ; Fri, 25 May 2012 16:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 DN9fcThHPAuC for ; Fri, 25 May 2012 16:11:51 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 473A621F884D for ; Fri, 25 May 2012 16:11:51 -0700 (PDT) Received: from [192.168.2.8] (cpe-066-057-019-007.nc.res.rr.com [66.57.19.7]) (Authenticated sender: jduell@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 97E57F232D for ; Fri, 25 May 2012 16:11:49 -0700 (PDT) Message-ID: <4FC011B4.1080508@gmail.com> Date: Fri, 25 May 2012 19:11:48 -0400 From: Jason Duell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: hybi@ietf.org References: <4FB3765D.5060308@isode.com> <001401cd340c$446034e0$cd209ea0$@noemax.com> <4FBE2F1E.1030307@isode.com> In-Reply-To: <4FBE2F1E.1030307@isode.com> Content-Type: multipart/alternative; boundary="------------080105020503050801060007" Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 25 May 2012 23:11:53 -0000 This is a multi-part message in MIME format. --------------080105020503050801060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/24/2012 08:52 AM, Alexey Melnikov wrote: > On 21/05/2012 11:45, Greg Wilkins wrote: >> >> They both look reasonable. > > Ok, I will register these, but I will call the second one "Try Again > Later" instead of "Service Overload". "Try Again Later" is used by > other protocols and the meaning is more generic. > I never got much of an answer about adding a new code for "client has too many websockets open", but let me ask it again. We could conceivably have your proposed 1013 code ("try again later") cover this case. But one downside of this is that it doesn't distinguish between the case where the application could open a connection to another server (a particular server is overloaded), and the case where no websockets are going to work unless/until some existing ones go away (Client websocket limit reached). So I suggest we want different codes for these. This could look like 1013 "Server busy" 1014 "Too many websockets open in client" assuming 1014 isn't taken yet--where's the list of proposed codes? Thoughts? Jason Duell Mozilla >> On 17 May 2012 11:05, Arman Djusupov > > wrote: >> >> Yes. These status codes do make sense and it is preferable to >> have them >> standardized. >> >> With best regards, >> Arman >> >> -----Original Message----- >> From: hybi-bounces@ietf.org >> [mailto:hybi-bounces@ietf.org ] On >> Behalf Of >> Alexey Melnikov >> Sent: Wednesday, May 16, 2012 12:42 PM >> To: Hybi >> Subject: [hybi] Additional WebSocket Close Error Codes >> >> Hi WG, >> I am sorry I didn't followup on this when the following 2 codes were >> suggested (See >> ): >> >> 1012/Service Restart >> 1012 indicates that the service is restarted. a client may reconnect, >> and if it choses to do, should reconnect using a randomized delay >> of 5 - >> 30s. >> >> Use case: >> restart a service with 100k clients connected >> clients present an informative user notification ("service >> restarting .. >> reconnecting in N secs) >> clients should not reconnect all at exactly the same time .. thus the >> randomized delay >> >> >> 1013/Service Overload >> 1013 indicates that the service is experiencing overload. a client >> should only connect to a different IP (when there are multiple >> for the >> target) or reconnect to the same IP upon user action. >> >> Use case: >> clients present an informative user notification ("service >> overload .. >> try later or try different IP) >> >> ----- >> >> Do people use these and is there still some interest in >> registering them? >> >> Best Regards, >> Alexey >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------080105020503050801060007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/24/2012 08:52 AM, Alexey Melnikov wrote:
On 21/05/2012 11:45, Greg Wilkins wrote:

They both look reasonable.

Ok, I will register these, but I will call the second one "Try Again Later" instead of "Service Overload". "Try Again Later" is used by other protocols and the meaning is more generic.


I never got much of an answer about adding a new code for "client has too many websockets open", but let me ask it again.   We could conceivably have your proposed 1013 code  ("try again later") cover this case.   But one downside of this is that it doesn't distinguish between the case where the application could open a connection to another server (a particular server is overloaded), and the case where no websockets are going to work unless/until some existing ones go away (Client websocket limit reached).  So I suggest we want different codes for these.

This could look like

   1013    "Server busy"
   1014     "Too many websockets open in client"   

assuming 1014 isn't taken yet--where's the list of proposed codes?

Thoughts?

Jason Duell
Mozilla


On 17 May 2012 11:05, Arman Djusupov <arman@noemax.com> wrote:
Yes. These status codes do make sense and it is preferable to have them
standardized.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
Alexey Melnikov
Sent: Wednesday, May 16, 2012 12:42 PM
To: Hybi
Subject: [hybi] Additional WebSocket Close Error Codes

Hi WG,
I am sorry I didn't followup on this when the following 2 codes were
suggested (See
<http://www.ietf.org/mail-archive/web/hybi/current/msg09284.html>):

1012/Service Restart
1012 indicates that the service is restarted. a client may reconnect,
and if it choses to do, should reconnect using a randomized delay of 5 -
30s.

Use case:
restart a service with 100k clients connected
clients present an informative user notification ("service restarting ..
reconnecting in N secs)
clients should not reconnect all at exactly the same time .. thus the
randomized delay


1013/Service Overload
1013 indicates that the service is experiencing overload. a client
should only connect to a different IP (when there are multiple for the
target) or reconnect to the same IP upon user action.

Use case:
clients present an informative user notification ("service overload ..
try later or try different IP)

-----

Do people use these and is there still some interest in registering them?

Best Regards,
Alexey

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

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




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

--------------080105020503050801060007-- From salvatore.loreto@ericsson.com Sun May 27 02:34:26 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 3887D21F8499 for ; Sun, 27 May 2012 02:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3jNm+ZGHn0P for ; Sun, 27 May 2012 02:34:25 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7C67321F8480 for ; Sun, 27 May 2012 02:34:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-53-4fc1f51ee201 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AA.92.00702.E15F1CF4; Sun, 27 May 2012 11:34:22 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Sun, 27 May 2012 11:34:22 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C827C2325 for ; Sun, 27 May 2012 12:34:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F65B52FC4 for ; Sun, 27 May 2012 12:34:21 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0E5F95296F for ; Sun, 27 May 2012 12:34:20 +0300 (EEST) Message-ID: <4FC1F51C.7070906@ericsson.com> Date: Sun, 27 May 2012 12:34:20 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: hybi@ietf.org References: <4FB3765D.5060308@isode.com> <001401cd340c$446034e0$cd209ea0$@noemax.com> <4FBE2F1E.1030307@isode.com> <4FC011B4.1080508@gmail.com> In-Reply-To: <4FC011B4.1080508@gmail.com> Content-Type: multipart/alternative; boundary="------------070004030808040604080707" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvra7c14P+Boua5C3ev9zG5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBV9LAXvoiua+rYxNjA+s+9i5OCQEDCReLFBqouRE8gUk7hw bz1bFyMXh5DAKUaJVy1vWCCcDYwSnUsOs0M45xkl7pxewgjhHGKUmH14JwtIv5DAaUaJMzeT QMbyCmhL7D4WAxJmEVCVWLXxLDuIzSZgJvH84RZmEFtUIFmi93wDmM0rIChxcuYTsDEiQHb3 1jVgcWEBK4nnC+5BLb7CKHFw7iImkASngKbE3xW9bCA2s0CYxPqVp9ghflCTuHpuEzPEPVoS vWc7mSYwCs9CsmMWkhYI21biwpzrUHF5ie1v5zBD2LoSF/5PQRFfwMi2ilE4NzEzJ73cXC+1 KDO5uDg/T684dRMjMCIObvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTCWbTy06+e6fy7vjgamzomddPpN1qLgL+ulcrQf/2nNn31Mb2qJoJNCcdNXUwMh c1YD7mvRBy+Gd9wLLpOZPd30lKvq0z+beqsSS3ae27/4SNWj15/+cPw0+HjP8YKEm9m2IvvS R9cNsmO/H6qLOfEhZnfAG4EzzzO61zyT8XPwklGUErh45Ym1EktxRqKhFnNRcSIABEGpuFYC AAA= Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 27 May 2012 09:34:26 -0000 --------------070004030808040604080707 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi, here you can find the list of registered codes http://www.iana.org/assignments/websocket/websocket.xml /Sal On 5/26/12 2:11 AM, Jason Duell wrote: > On 05/24/2012 08:52 AM, Alexey Melnikov wrote: >> On 21/05/2012 11:45, Greg Wilkins wrote: >>> >>> They both look reasonable. >> >> Ok, I will register these, but I will call the second one "Try Again >> Later" instead of "Service Overload". "Try Again Later" is used by >> other protocols and the meaning is more generic. >> > > I never got much of an answer about adding a new code for "client has > too many websockets open", but let me ask it again. We could > conceivably have your proposed 1013 code ("try again later") cover > this case. But one downside of this is that it doesn't distinguish > between the case where the application could open a connection to > another server (a particular server is overloaded), and the case where > no websockets are going to work unless/until some existing ones go > away (Client websocket limit reached). So I suggest we want different > codes for these. > > This could look like > > 1013 "Server busy" > 1014 "Too many websockets open in client" > > assuming 1014 isn't taken yet--where's the list of proposed codes? > > Thoughts? > > Jason Duell > Mozilla > > >>> On 17 May 2012 11:05, Arman Djusupov >> > wrote: >>> >>> Yes. These status codes do make sense and it is preferable to >>> have them >>> standardized. >>> >>> With best regards, >>> Arman >>> >>> -----Original Message----- >>> From: hybi-bounces@ietf.org >>> [mailto:hybi-bounces@ietf.org ] On >>> Behalf Of >>> Alexey Melnikov >>> Sent: Wednesday, May 16, 2012 12:42 PM >>> To: Hybi >>> Subject: [hybi] Additional WebSocket Close Error Codes >>> >>> Hi WG, >>> I am sorry I didn't followup on this when the following 2 codes were >>> suggested (See >>> ): >>> >>> 1012/Service Restart >>> 1012 indicates that the service is restarted. a client may >>> reconnect, >>> and if it choses to do, should reconnect using a randomized >>> delay of 5 - >>> 30s. >>> >>> Use case: >>> restart a service with 100k clients connected >>> clients present an informative user notification ("service >>> restarting .. >>> reconnecting in N secs) >>> clients should not reconnect all at exactly the same time .. >>> thus the >>> randomized delay >>> >>> >>> 1013/Service Overload >>> 1013 indicates that the service is experiencing overload. a client >>> should only connect to a different IP (when there are multiple >>> for the >>> target) or reconnect to the same IP upon user action. >>> >>> Use case: >>> clients present an informative user notification ("service >>> overload .. >>> try later or try different IP) >>> >>> ----- >>> >>> Do people use these and is there still some interest in >>> registering them? >>> >>> Best Regards, >>> Alexey >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >>> >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > --------------070004030808040604080707 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi,

here you can find the list of registered codes
http://www.iana.org/assignments/websocket/websocket.xml

/Sal


On 5/26/12 2:11 AM, Jason Duell wrote:
On 05/24/2012 08:52 AM, Alexey Melnikov wrote:
On 21/05/2012 11:45, Greg Wilkins wrote:

They both look reasonable.

Ok, I will register these, but I will call the second one "Try Again Later" instead of "Service Overload". "Try Again Later" is used by other protocols and the meaning is more generic.


I never got much of an answer about adding a new code for "client has too many websockets open", but let me ask it again.   We could conceivably have your proposed 1013 code  ("try again later") cover this case.   But one downside of this is that it doesn't distinguish between the case where the application could open a connection to another server (a particular server is overloaded), and the case where no websockets are going to work unless/until some existing ones go away (Client websocket limit reached).  So I suggest we want different codes for these.

This could look like

   1013    "Server busy"
   1014     "Too many websockets open in client"   

assuming 1014 isn't taken yet--where's the list of proposed codes?

Thoughts?

Jason Duell
Mozilla


On 17 May 2012 11:05, Arman Djusupov <arman@noemax.com> wrote:
Yes. These status codes do make sense and it is preferable to have them
standardized.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
Alexey Melnikov
Sent: Wednesday, May 16, 2012 12:42 PM
To: Hybi
Subject: [hybi] Additional WebSocket Close Error Codes

Hi WG,
I am sorry I didn't followup on this when the following 2 codes were
suggested (See
<http://www.ietf.org/mail-archive/web/hybi/current/msg09284.html>):

1012/Service Restart
1012 indicates that the service is restarted. a client may reconnect,
and if it choses to do, should reconnect using a randomized delay of 5 -
30s.

Use case:
restart a service with 100k clients connected
clients present an informative user notification ("service restarting ..
reconnecting in N secs)
clients should not reconnect all at exactly the same time .. thus the
randomized delay


1013/Service Overload
1013 indicates that the service is experiencing overload. a client
should only connect to a different IP (when there are multiple for the
target) or reconnect to the same IP upon user action.

Use case:
clients present an informative user notification ("service overload ..
try later or try different IP)

-----

Do people use these and is there still some interest in registering them?

Best Regards,
Alexey

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

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




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



  


--------------070004030808040604080707--

From tyoshino@google.com  Mon May 28 01:29: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 3EE3D21F8454 for ; Mon, 28 May 2012 01:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.814
X-Spam-Level: 
X-Spam-Status: No, score=-102.814 tagged_above=-999 required=5 tests=[AWL=0.161, 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 6uG6x4JWGSCF for ; Mon, 28 May 2012 01:29:14 -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 8280921F8456 for ; Mon, 28 May 2012 01:29:14 -0700 (PDT)
Received: by yenq13 with SMTP id q13so1442082yen.31 for ; Mon, 28 May 2012 01:29:14 -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=CLjnMLa+qe+6Oai5856YeEdQbxXRwLWzSPoYMkaJDTw=; b=SaawrQEDhhUfF/bdDtJ8wfCACiar3chY8hv+7/thdVCffA+lF0X3ye9sPiLH5lOk5M Jd/FWwP5wuRgqvNHVVTlaj0lSeGok+0zjYvdj2nQWn43yY76GGIn/kOHurq0/BIJkl9X fO6/UEKwrkN9hbgkWw61Y9oSKhTDalBbBj8330FCuxy4jWUCjtdDqwU7qsYavwWcb6ut 07zHbKWN1UFjQj/yVLJZgiO3vgKrgnaWtISWIksMZtWuivtgI2KevqB3G5+/cADQmovi W3QzbIv6IluHFpXqnjBaDOfOYzErRjmwen1vZQx1+bTAMStdcOdNQqQiGwAaXtpzYtho 1jMw==
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=CLjnMLa+qe+6Oai5856YeEdQbxXRwLWzSPoYMkaJDTw=; b=d/8JoTLnBoAYPJRc+yLBxOx4OiJU2EA+N/0OmTWEWmm1Rmytb4iNKk+gylTUgqk+pi df69mptdiaLb0I37eRVAm5LEbNgZubh4qVV76e14nIa7RfPEGZG3JeyF1I7a62UfvXHX 0MP8NPgml9au+LobqoiR7QCrfJXjnWx59RMUuA5p6TJUWEb/vZyVXsEC5uFW4OcFxbq0 pTRDQExoHJIAzKoJpDf239b9aqGyusyx5RuvmcpGdmgVofZHG6xpDrw2wbBSKUyp9tsb TaXzWKPsbpDqoCh6IGMSYd4K7owx0Cy/CYfDqhYZ4m67bARgh+cJaynHHgPNBJxwfehp kSCA==
Received: by 10.50.46.228 with SMTP id y4mr3921658igm.10.1338193753558; Mon, 28 May 2012 01:29:13 -0700 (PDT)
Received: by 10.50.46.228 with SMTP id y4mr3921650igm.10.1338193753437; Mon, 28 May 2012 01:29:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.66.7 with HTTP; Mon, 28 May 2012 01:28:53 -0700 (PDT)
From: Takeshi Yoshino 
Date: Mon, 28 May 2012 17:28:53 +0900
Message-ID: 
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=14dae93410415076d804c11483b8
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn8+3kZxoxzLGPKkqc5FKOtXffxJIuJgZCdNfYu1iOn4M72aWNmFaf+A/pda2nSw9jl7MNba2/AkuyGLsLfkXZcUKjtjCzK2X7CB9LXzESOxSFt1islyDAqBOux8xF4WS/xBkCJ
Subject: [hybi] Multiplexing: Pre-AddChannelResponse quota
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, 28 May 2012 08:29:15 -0000

--14dae93410415076d804c11483b8
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

Sorry for delay on the decision making on the pre-response quota feature of
the multiplexing extension. Based on input on the list, I'm going to add
two extension parameters for use in the server's opening handshake of the
physical channel.

One is pre_handshake_quota. It indicates the number of bytes allowed to be
sent by the client before receiving an AddChannelResponse for each logical
channel.

The second one I want to introduce is max_simultaneous_handshakes that
limits the number of in-flight AddChannelRequests the client may issue not
to run out the server's buffer for pre-handshake data.

Servers may send these extension parameter based on their buffering
capacity.

I also considered limiting total pre-handshake bytes summed for all
channels. This doesn't increase complexity so much as it introduces only
one extension parameter. But not to run out buffer for each channel, this
would be practically limited up to the minimum value of quota for all
logical channel. So, the pre-handshake quota won't be utilized well if many
AddChannelRequests are issued simultaneously.

As John said in the thread, if we allow the WebSocket API to send data
before receiving AddChannelResponse, the JS application should be
responsible for re-sending. Otherwise, the WebSocket stack would need to
buffer much data in case re-sending is necessary.

That said, in the first place, we haven't discussed for what case
re-sending would happen. We need to clarify this and have a way to allow JS
to know what to do.

Takeshi

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

Hi all,

Sorry for delay on the decision makin= g on the pre-response quota feature of the multiplexing extension.=A0Based = on input on the list, I'm going to add two extension parameters=A0for u= se in the server's opening handshake of the physical channel.

One is pre_handshake_quota. It indicates the number of = bytes allowed to be sent by the client before receiving an AddChannelRespon= se for each logical channel.

The second one I want= to introduce is max_simultaneous_handshakes that limits the number of in-f= light AddChannelRequests the client may issue not to run out the server'= ;s buffer for pre-handshake data.

Servers may send these extension parameter based o= n their buffering capacity.

I also considered limiting total pre-handshake bytes summed for al= l channels. This doesn't increase complexity so much as it introduces o= nly one extension parameter. But not to run out buffer for each channel, th= is would be practically limited up to the minimum value of quota for all lo= gical channel. So, the pre-handshake quota won't be utilized well if ma= ny AddChannelRequests are issued simultaneously.

As John said in the thread, if we allow the WebSocket A= PI to send data before receiving AddChannelResponse, the JS application sho= uld be responsible for re-sending. Otherwise, the WebSocket stack would nee= d to buffer much data in case re-sending is necessary.

That said, in the first place, we haven't discussed= for what case re-sending would happen. We need to clarify this and have a = way to allow JS to know what to do.

Takeshi
--14dae93410415076d804c11483b8-- From arman@noemax.com Mon May 28 04: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 5132421F853D for ; Mon, 28 May 2012 04:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.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 rSRM0VMcrMOg for ; Mon, 28 May 2012 04:23:23 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id D31AC21F84B6 for ; Mon, 28 May 2012 04:23:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1338204198; x=1338808998; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=zHwbbSUXTqIcCZb5ePq9fy5vlAY=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=uUYKodZGIh9TN/QFUqpsgizW9pMChv56/23Izh0FCCpIkjlcJcMmykdxEb3Ok6Y6YahxokcgxEYhf11bAWOQ6C1QVMM6qr7fDbtsOax+3DmwDiEr35hR8h914IPfy5+OI01DtittwaflPL4c1EUpBbbPupZqt0xBGeiUb/EYry4= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id MQZ10115; Mon, 28 May 2012 14:23:15 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Mon, 28 May 2012 14:23:06 +0300 Message-ID: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CD3CDD.6CDEEB80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MJbDZw9g Content-Language: en-us Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 28 May 2012 11:23:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0030_01CD3CDD.6CDEEB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resending would be required when the allocation of a logical channel has failed on the server or the intermediary due to any kind of mux related error. For example: "Maximum number of logical channels per physical connection has been reached " or "Intermediary cannot reach the destination endpoint". The current draft requires that if an AddChannelResponse is received with a failed flag, the client attempts to open a new physical connection. Since the browser must keep the mux extension transparent it cannot let the JS application handle the recovery from mux related errors. I like the idea of using the total pre-handshake quota for all logical channels. This would allow high throughput channels to utilize a common pre-handshake quota when other channels do not require to send any data prior to receiving an AddChannelResponse. I believe that this solution would be more optimal than having a pre-handshake quota per logical channel. However, this solution would require the client to subtract the required value from the common quota and specify this value in the AddChannelRequest header, so that the server knows from which initial value to start counting the remote side quota. There should also be a way to restore the common quota, e.g. in AddChannelResponse the server can send a header which would specify the value that should be added to the common pre-handshake quota. With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Monday, May 28, 2012 11:29 AM To: hybi@ietf.org Subject: [hybi] Multiplexing: Pre-AddChannelResponse quota Hi all, Sorry for delay on the decision making on the pre-response quota feature of the multiplexing extension. Based on input on the list, I'm going to add two extension parameters for use in the server's opening handshake of the physical channel. One is pre_handshake_quota. It indicates the number of bytes allowed to be sent by the client before receiving an AddChannelResponse for each logical channel. The second one I want to introduce is max_simultaneous_handshakes that limits the number of in-flight AddChannelRequests the client may issue not to run out the server's buffer for pre-handshake data. Servers may send these extension parameter based on their buffering capacity. I also considered limiting total pre-handshake bytes summed for all channels. This doesn't increase complexity so much as it introduces only one extension parameter. But not to run out buffer for each channel, this would be practically limited up to the minimum value of quota for all logical channel. So, the pre-handshake quota won't be utilized well if many AddChannelRequests are issued simultaneously. As John said in the thread, if we allow the WebSocket API to send data before receiving AddChannelResponse, the JS application should be responsible for re-sending. Otherwise, the WebSocket stack would need to buffer much data in case re-sending is necessary. That said, in the first place, we haven't discussed for what case re-sending would happen. We need to clarify this and have a way to allow JS to know what to do. Takeshi ------=_NextPart_000_0030_01CD3CDD.6CDEEB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Resending would be required when the allocation of a logical channel = has failed on the server or the intermediary due to any kind of mux = related error. For example: “Maximum number of logical channels = per physical connection has been reached “ or “Intermediary = cannot reach the destination endpoint”. The current draft requires = that if an AddChannelResponse is received with a failed flag, the client = attempts to open a new physical connection. Since the browser must keep = the mux extension transparent it cannot let the JS application handle = the recovery from mux related errors.

 

I like the idea of using the total pre-handshake quota for all = logical channels. This would allow high throughput channels to utilize a = common pre-handshake quota when other channels do not require to send = any data prior to receiving an AddChannelResponse. I believe that this = solution would be more optimal than having a pre-handshake quota per = logical channel. However,  this solution would require the client = to subtract the required value from the common quota and specify this = value in the AddChannelRequest header, so that the server knows from = which initial value to start counting the remote side quota. There = should also be a way to restore the common quota, e.g. in = AddChannelResponse the server can send a header which would specify the = value that should be added to the common pre-handshake = quota.

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Monday, May 28, 2012 11:29 = AM
To: hybi@ietf.org
Subject: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

Hi = all,

 

Sorry for delay on the decision making on the = pre-response quota feature of the multiplexing extension. Based on = input on the list, I'm going to add two extension parameters for = use in the server's opening handshake of the physical = channel.

 

One is pre_handshake_quota. It indicates the number of = bytes allowed to be sent by the client before receiving an = AddChannelResponse for each logical channel.

 

The second one I want to introduce is = max_simultaneous_handshakes that limits the number of in-flight = AddChannelRequests the client may issue not to run out the server's = buffer for pre-handshake data.

 

Servers may send these extension parameter based on = their buffering capacity.

 

I = also considered limiting total pre-handshake bytes summed for all = channels. This doesn't increase complexity so much as it introduces only = one extension parameter. But not to run out buffer for each channel, = this would be practically limited up to the minimum value of quota for = all logical channel. So, the pre-handshake quota won't be utilized well = if many AddChannelRequests are issued = simultaneously.

 

As John said in the thread, if we allow the WebSocket = API to send data before receiving AddChannelResponse, the JS application = should be responsible for re-sending. Otherwise, the WebSocket stack = would need to buffer much data in case re-sending is = necessary.

 

That said, in the first place, we haven't discussed = for what case re-sending would happen. We need to clarify this and have = a way to allow JS to know what to do.

 

Takeshi

------=_NextPart_000_0030_01CD3CDD.6CDEEB80-- From alexey.melnikov@isode.com Tue May 29 04:15:36 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA021F8634 for ; Tue, 29 May 2012 04:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TntqBvryY92s for ; Tue, 29 May 2012 04:15:34 -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 E079121F8630 for ; Tue, 29 May 2012 04:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338290132; d=isode.com; s=selector; i=@isode.com; bh=vGspw2d57+pDh5m+NbO6AxaOd3cnPgJfLbHBXoJY8ZE=; 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=aADB9xWYoHpx4tMg5os+KFd26PCxD340Gmfw5d9/geTDWT1JZou62w94x54475xpqAfulB A52/ElrbsP1V1vHSW4p+mnZ1z9/tmrWhQQVi2zPAbX30tSIJc35TOs3uJ6/eWp7EGJ5xx3 ZHV506FQSuhHh2JYFdVm9pfvJsV4j50=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 29 May 2012 12:15:31 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FC4AFD1.8080100@isode.com> Date: Tue, 29 May 2012 12:15:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Jason Duell References: <4FB3765D.5060308@isode.com> <001401cd340c$446034e0$cd209ea0$@noemax.com> <4FBE2F1E.1030307@isode.com> <4FC011B4.1080508@gmail.com> In-Reply-To: <4FC011B4.1080508@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030605080307010507010800" Cc: hybi@ietf.org Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 29 May 2012 11:15:36 -0000 This is a multi-part message in MIME format. --------------030605080307010507010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jason, On 26/05/2012 00:11, Jason Duell wrote: > On 05/24/2012 08:52 AM, Alexey Melnikov wrote: >> On 21/05/2012 11:45, Greg Wilkins wrote: >>> >>> They both look reasonable. >> >> Ok, I will register these, but I will call the second one "Try Again >> Later" instead of "Service Overload". "Try Again Later" is used by >> other protocols and the meaning is more generic. >> > > I never got much of an answer about adding a new code for "client has > too many websockets open", but let me ask it again. We could > conceivably have your proposed 1013 code ("try again later") cover > this case. But one downside of this is that it doesn't distinguish > between the case where the application could open a connection to > another server (a particular server is overloaded), I think having a new code for "try another server" would be better, as it is more explicit that an immediate action can be attempted (where "server overload" or "try again later" imply that an action in a future can be attempted). Would such split work for you? > and the case where no websockets are going to work unless/until some > existing ones go away (Client websocket limit reached). So I suggest > we want different codes for these. > > This could look like > > 1013 "Server busy" > 1014 "Too many websockets open in client" > > assuming 1014 isn't taken yet--where's the list of proposed codes? As Salvatore already pointed out, the list of currently allocated codes is here: This doesn't yet list a couple of extra code I approved recently, but the web page should be updated soon. > Thoughts? > > Jason Duell > Mozilla > > >>> On 17 May 2012 11:05, Arman Djusupov >> > wrote: >>> >>> Yes. These status codes do make sense and it is preferable to >>> have them >>> standardized. >>> >>> With best regards, >>> Arman >>> >>> -----Original Message----- >>> From: hybi-bounces@ietf.org >>> [mailto:hybi-bounces@ietf.org ] On >>> Behalf Of >>> Alexey Melnikov >>> Sent: Wednesday, May 16, 2012 12:42 PM >>> To: Hybi >>> Subject: [hybi] Additional WebSocket Close Error Codes >>> >>> Hi WG, >>> I am sorry I didn't followup on this when the following 2 codes were >>> suggested (See >>> ): >>> >>> 1012/Service Restart >>> 1012 indicates that the service is restarted. a client may >>> reconnect, >>> and if it choses to do, should reconnect using a randomized >>> delay of 5 - >>> 30s. >>> >>> Use case: >>> restart a service with 100k clients connected >>> clients present an informative user notification ("service >>> restarting .. >>> reconnecting in N secs) >>> clients should not reconnect all at exactly the same time .. >>> thus the >>> randomized delay >>> >>> >>> 1013/Service Overload >>> 1013 indicates that the service is experiencing overload. a client >>> should only connect to a different IP (when there are multiple >>> for the >>> target) or reconnect to the same IP upon user action. >>> >>> Use case: >>> clients present an informative user notification ("service >>> overload .. >>> try later or try different IP) >>> >>> ----- >>> >>> Do people use these and is there still some interest in >>> registering them? >>> >>> Best Regards, >>> Alexey >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >>> >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------030605080307010507010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jason,

On 26/05/2012 00:11, Jason Duell wrote:
On 05/24/2012 08:52 AM, Alexey Melnikov wrote:
On 21/05/2012 11:45, Greg Wilkins wrote:

They both look reasonable.

Ok, I will register these, but I will call the second one "Try Again Later" instead of "Service Overload". "Try Again Later" is used by other protocols and the meaning is more generic.


I never got much of an answer about adding a new code for "client has too many websockets open", but let me ask it again.   We could conceivably have your proposed 1013 code  ("try again later") cover this case.   But one downside of this is that it doesn't distinguish between the case where the application could open a connection to another server (a particular server is overloaded),

I think having a new code for "try another server" would be better, as it is more explicit that an immediate action can be attempted (where "server overload" or "try again later" imply that an action in a future can be attempted). Would such split work for you?

and the case where no websockets are going to work unless/until some existing ones go away (Client websocket limit reached).  So I suggest we want different codes for these.

This could look like

   1013    "Server busy"
   1014     "Too many websockets open in client"   

assuming 1014 isn't taken yet--where's the list of proposed codes?
As Salvatore already pointed out, the list of currently allocated codes is here:
 <http://www.iana.org/assignments/websocket/websocket.xml#close-code-number-rules>

This doesn't yet list a couple of extra code I approved recently, but the web page should be updated soon.
Thoughts?

Jason Duell
Mozilla


On 17 May 2012 11:05, Arman Djusupov <arman@noemax.com> wrote:
Yes. These status codes do make sense and it is preferable to have them
standardized.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
Alexey Melnikov
Sent: Wednesday, May 16, 2012 12:42 PM
To: Hybi
Subject: [hybi] Additional WebSocket Close Error Codes

Hi WG,
I am sorry I didn't followup on this when the following 2 codes were
suggested (See
<http://www.ietf.org/mail-archive/web/hybi/current/msg09284.html>):

1012/Service Restart
1012 indicates that the service is restarted. a client may reconnect,
and if it choses to do, should reconnect using a randomized delay of 5 -
30s.

Use case:
restart a service with 100k clients connected
clients present an informative user notification ("service restarting ..
reconnecting in N secs)
clients should not reconnect all at exactly the same time .. thus the
randomized delay


1013/Service Overload
1013 indicates that the service is experiencing overload. a client
should only connect to a different IP (when there are multiple for the
target) or reconnect to the same IP upon user action.

Use case:
clients present an informative user notification ("service overload ..
try later or try different IP)

-----

Do people use these and is there still some interest in registering them?

Best Regards,
Alexey

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

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




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



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

--------------030605080307010507010800-- From arman@noemax.com Wed May 30 06:37:04 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 1BD0D21F8736 for ; Wed, 30 May 2012 06:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-1.150, 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 5ReGjEG06zA5 for ; Wed, 30 May 2012 06:37:02 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 719E921F8737 for ; Wed, 30 May 2012 06:37:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1338385021; x=1338989821; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=1lwtlLVRxm1htJj6/cFiHrZQQrU=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type; b=mFI3pBY/SFIXgH6MnjLAEkQDndg3Crud7ebkl/phGP/aNt9An/dLKEfQ1tU6nIdYD/KUAJ1Ppe+L/k80BJ1BLUHNkmSITAtbOoVguHBNnGmwBZVn0mEfXvl4mvP66UsM+WT2rqZyXnZl8Yk7EAWwExh65vd+fT0E3kkPyWOyvKk= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id OSP24900; Wed, 30 May 2012 16:37:00 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , Date: Wed, 30 May 2012 16:36:52 +0300 Message-ID: <001a01cd3e69$4a221c10$de665430$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CD3E82.6F703E70" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac0+aHlV710MsnfRTMiu0LvIyQHr3Q== Content-Language: en-us Subject: [hybi] Flow control quota 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, 30 May 2012 13:37:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001B_01CD3E82.6F703E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Takeshi, =20 Sometimes the sending side cannot fully utilize the remaining quota available (a typical example is when the remaining quota is too small) = and has to wait for the receiving side to send a flow control frame (even = though the remaining quota is not yet equal to 0). If the receiving side=92s = mux implementation sends flow control frames only when all the quota has = been fully consumed (remaining quota =3D 0), this can lead to a deadlock = situation in which the sending side waits for a FC frame before sending the next = frame while the receiving side waits for more bytes to be received before = sending a FC frame. =20 It would be good if the specification includes some general guidelines = on sending flow control quotas, e.g. =93receiver MUST NOT wait for sending = side to use its full quota before sending a FC frame=94. The specification = could even require that a FC frame is sent when half of the remaining quota is used by the sending side. Otherwise one implementation may prefer to = wait for a FC frame when the frame size exceeds the remaining quota, while = the other may prefer to send a FC frame only when more than, say, =BE of = the quota is used. =20 There are a variety of flow control strategies that can be used and each implementation can have its own, what we need is to define some rules so that all implementations are interoperable. =20 With best regards, Arman =20 ------=_NextPart_000_001B_01CD3E82.6F703E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Takeshi,

 

Sometimes the sending side cannot fully utilize the remaining quota = available (a typical example is when the remaining quota is too small) = and has to wait for the receiving side to send a flow control frame = (even though the remaining quota is not yet equal to 0). If the = receiving side’s mux implementation sends flow control frames only = when all the quota has been fully consumed (remaining quota =3D 0), this = can lead to a deadlock situation in which the sending side waits for a = FC frame before sending the next frame while the receiving side waits = for more bytes to be received before sending a FC = frame.

 

It would be good if the specification includes some general = guidelines on sending flow control quotas, e.g. “receiver MUST NOT = wait for sending side to use its full quota before sending a FC = frame”. The specification could even require that a FC frame is = sent when half of the remaining quota is used by the sending side. = Otherwise one implementation may prefer to wait for a FC frame when the = frame size exceeds the remaining quota, while the other may prefer to = send a FC frame only when more than, say, =BE  of the quota is = used.

 

There are a variety of flow control strategies that can be used and = each implementation can have its own, what we need is to define some = rules so that all implementations are = interoperable.

 

With best regards,

Arman

 

------=_NextPart_000_001B_01CD3E82.6F703E70-- From sustrik@250bpm.com Thu May 31 01:59:16 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2E21F869E for ; Thu, 31 May 2012 01:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7R2K-etNZKa for ; Thu, 31 May 2012 01:59:15 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id A718121F8694 for ; Thu, 31 May 2012 01:59:13 -0700 (PDT) Received: from [192.168.0.11] (unknown [188.11.92.239]) by mail.moloch.sk (Postfix) with ESMTPSA id 7DB93180AF42; Thu, 31 May 2012 10:59:10 +0200 (CEST) Message-ID: <4FC732DC.3000308@250bpm.com> Date: Thu, 31 May 2012 10:59:08 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Arman Djusupov References: <001a01cd3e69$4a221c10$de665430$@noemax.com> In-Reply-To: <001a01cd3e69$4a221c10$de665430$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 31 May 2012 08:59:16 -0000 On 30/05/12 15:36, Arman Djusupov wrote: > Sometimes the sending side cannot fully utilize the remaining quota > available (a typical example is when the remaining quota is too small) That's interesting. Can you provide a concrete example? It seems to me that even if the quota is 1 byte, you can send a frame with 1 byte. Martin From arman@noemax.com Thu May 31 04:01: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 BABFA21F8592 for ; Thu, 31 May 2012 04:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 uKngP5jRt6ew for ; Thu, 31 May 2012 04:01:20 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id E868E21F858E for ; Thu, 31 May 2012 04:01:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1338462077; x=1339066877; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=Klnjml2W7u/deIfiAoTAl+zcA0A=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=hvZ1oth4WRIM4lxwCbglqUdqRyfBufvQ3yJtlZK2TBqtrVPZmZgHELFBaEw+LYZxAyiIlRMy0JmsFMZ7vi9mpjeHRyyMannihIUIVXCTYu1/yz2x1jArmP+17vu2Ii1LYxhWjMzt2Tgm2LvgXfEN36HMPcLL49Yz93d2eVps1Y0= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id PQG27916; Thu, 31 May 2012 14:01:16 +0300 From: "Arman Djusupov" To: "'Martin Sustrik'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> In-Reply-To: <4FC732DC.3000308@250bpm.com> Date: Thu, 31 May 2012 14:01:01 +0300 Message-ID: <000e01cd3f1c$af15ad40$0d4107c0$@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: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRmKSpWoA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 31 May 2012 11:01:20 -0000 When the per-frame compression extension is being used on a logical channel, it is impossible to create a frame of exactly the desired size. A few bytes of quota will always be unutilized unless some padding is used. The mux specification prohibits sending frames bigger than the available quota. When per-frame compression is applied on the payload before mux, this payload cannot be fragmented any more. Even if we make compression extension mux aware, it cannot produce a 1 byte compressed frame, it can only flag a frame as uncompressed and simply send 1 byte. In general, sending 1 byte in a separate frame is not desirable. Extensions that set RSV bits prohibit frame fragmentation. This causes a general incompatibility issue with mux FC when an extension is applied before the mux. We need to consider whether there is a solution to this. With best regards, Arman -----Original Message----- From: Martin Sustrik [mailto:sustrik@250bpm.com] Sent: Thursday, May 31, 2012 11:59 AM To: Arman Djusupov Cc: 'Takeshi Yoshino'; hybi@ietf.org Subject: Re: [hybi] Flow control quota On 30/05/12 15:36, Arman Djusupov wrote: > Sometimes the sending side cannot fully utilize the remaining quota > available (a typical example is when the remaining quota is too small) That's interesting. Can you provide a concrete example? It seems to me that even if the quota is 1 byte, you can send a frame with 1 byte. Martin