From tyoshino@google.com Thu Nov 1 00:08: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 6AB2721F8553 for ; Thu, 1 Nov 2012 00:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.788 X-Spam-Level: X-Spam-Status: No, score=-101.788 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5EOUS5qSvjt for ; Thu, 1 Nov 2012 00:08:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3421F8458 for ; Thu, 1 Nov 2012 00:08:24 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2648953vbb.31 for ; Thu, 01 Nov 2012 00:08: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=9ibAC1qboTDCVXPWfU2K0dp9lzhmmYVxwi5L+vFvsJ4=; b=jqRDHotrApGQ1ELmrzHPBQo+4yix9PWqKsoi3+eSWG6FTpx2yv1i6M1UhV6nbIp+pQ pXat3PYYvZcOAkIrv6Fx+DnuDOWEkf0OUCRP7cIlVWOECe9/3jvUyRkyy8OEfcSXTjOO sC/ri2Neh4tniG9YVkS2suYfRTTWjUB5aHIsBAZ7OsCgY0yq1mXFTc3sABQsBTTXydCa orlNxHz1FjHP0f/SUxjeB8YrxMsIIBatgAIkSs3A3L4qcotpNmAkGRrUfttfbnSOHCsL TBWoSn/M/oArvVHrpDPLjydpX2E0yxpe2Y2rQWj4Sot2b4RZwit2ZA5Ct0cckXbdicf5 AKWA== 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=9ibAC1qboTDCVXPWfU2K0dp9lzhmmYVxwi5L+vFvsJ4=; b=aFLBLhQI5RH7nTJZQVzdDB8emubk6zea7od996gEZ7kKWj/VZ2N1g7IelbuoTH8VIT DWFlwX7re0lnY+Ge/c+S1h4WZOHxyy1EgbAZcwreqpq/Qq6AetcrEKByWKC02pBJWdbN /3Q4fYyLTmCBOEra/lP5dFbqHBNpV3Wpb+66uxXK6X+kwO4ko0TRDi8X6QN0M7PnzXHn zDJvKtt6ALQONSdap9cXFzEsT/Zup2ZYoIThhhTRN/De1FgHwJy7jv36w8E0h/KPkuxD g/kusLpUzil6qzi7Q0xZC9wHbbC2SvrYnSvAd+5uqbaeFhAfSoRTo9KvHwXFe66kSJjm ATcg== Received: by 10.59.13.135 with SMTP id ey7mr48092338ved.37.1351753703910; Thu, 01 Nov 2012 00:08:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.106 with HTTP; Thu, 1 Nov 2012 00:08:03 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 1 Nov 2012 16:08:03 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=089e011767dd586d9204cd69af89 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmrS17HIDOJTs4HAKvG/M41rsMtgjlQ6vnky3LNrigRQQnUBgZiSJEvENQsr3ngaXlXczByuKDyvuUj7I0BjTLsdPsFvLnmHQsCRdjTX/ogC2uR2oQwQQsl/hKwIET0JYGbkmnIYIfNFlhVfAvA1BHWBPowUu6YF4OjTXHP1MQBixKtm5ARGtcoLcwnB0YOS80VB/to Cc: hybi@ietf.org Subject: Re: [hybi] Mux / Delta encoded AddChannel Request/Response 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, 01 Nov 2012 07:08:26 -0000 --089e011767dd586d9204cd69af89 Content-Type: text/plain; charset=ISO-8859-1 I rethought if multiple headers with the same value are really problematic. It seems to be fine to allow multiple headers with the same name sent in the handshake field instead of merging. The receiver MUST - when received identity encoded handshake -- remember values and the order in which they were in the handshake field - when received delta-encoded handshake -- if there's a header with name=X value=empty, remove all of the entries -- if there're header(s) with name=X value=non-empty, forget all the remembered values and remember new value(s) and their order -- if there're no headers with name=X, decode the memorized values in the memorized order We cannot drop part of them (all or nothing). But that's all. What do you think? What about multiple Set-Cookie response headers? > https://tools.ietf.org/html/rfc6265#section-4.1 says SHOULD NOT for > servers. > Might need some language in the mux spec to say this becomes MUST NOT for > mux. > Thanks. Yes, we need to support multiple entries with the same name because of this. > However, https://tools.ietf.org/html/rfc2616#section-4.2 says that > multiple message headers of the same name is allowed. > > Multiple message-header fields with the same field-name MAY be > present in a message if and only if the entire field-value for that > header field is defined as a comma-separated list [i.e., #(values)]. > It MUST be possible to combine the multiple header fields into one > "field-name: field-value" pair, without changing the semantics of the > message, by appending each subsequent field-value to the first, each > separated by a comma. The order in which header fields with the same > field-name are received is therefore significant to the > interpretation of the combined field value, and thus a proxy MUST NOT > change the order of these field values when a message is forwarded. > > > httpbis is also disallowing multiple headers with the same name unless it's 1#X in the main text as well as RFC 2616 but has a short note about this problem. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2 --089e011767dd586d9204cd69af89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I rethought if multiple headers with the same value ar= e really problematic.

It seems to be fine to allow multiple headers with the same name sent in th= e handshake field instead of merging.

<= /div>
The receiver MUST
- when received identity encoded handshake
= -- remember values and the order in which they were in the handshake field<= /div>
- when received delta-encoded handshake
-- if there's a header with name=3DX value= =3Dempty, remove all of the entries
-- if t= here're header(s) with name=3DX value=3Dnon-empty, forget all the remem= bered values and remember new value(s) and their order
-- if there're no headers with name=3DX, dec= ode the memorized values in the memorized order

We cannot drop part of them (all = or nothing). But that's all.

What do you= think?

What about multiple Set-Cookie response headers?
https://= tools.ietf.org/html/rfc6265#section-4.1=A0says SHOULD NOT for servers.<= /div>
Might need some language in the mux spec to say this becomes MUST NOT = for mux.

Thanks. Yes, we need to supp= ort multiple entries with the same name because of this.
=A0
However,=A0https://tools.= ietf.org/html/rfc2616#section-4.2=A0says that multiple message headers = of the same name is allowed.

   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics=
 of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.


httpbis is also disa= llowing multiple headers with the same name unless it's 1#X in the main= text as well as RFC 2616 but=A0has a short note about this problem.=A0http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#sectio= n-3.2
=A0
--089e011767dd586d9204cd69af89-- From tyoshino@google.com Thu Nov 1 22:17: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 D32AC21F98CB for ; Thu, 1 Nov 2012 22:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N02Psn9x7hJF for ; Thu, 1 Nov 2012 22:17:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10CF121F98CD for ; Thu, 1 Nov 2012 22:17:29 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3853088vbb.31 for ; Thu, 01 Nov 2012 22:17:29 -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=bQva1LlS1XOuQaoWxqUniIuuctl48tI7OLCtr1ayqow=; b=jmVfgr/aCZA/jMUiC+QsAY76+GwEKr/r7Fz9JY4VKPfg5c5wxOzgbbJlVeiThDfrd+ M8MBk2tPvJ+n9E2AhBWny0Q4oRnf81+eleidU8gx63elvB5mKHo9/9ra/ba52HGSFL1x A6jqEJ6M1/Ig3LlhA6J3QgEXVouJSEarv9m0FtQRdbbpinOwCkOft97LeqaRR0T433Ih yWzqdLoX9N2qI6xDqnXbK36REanPOAVVLhrb1VreUiv0RrU8ZKPBawNxqE5BAII2ghcS XR6VyhUsxHNiYsxceFlsGI+zF93y9tcSKf2i4f5ZFkrKcNvb85zIuIydBsjQc4sg/vlW BESw== 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=bQva1LlS1XOuQaoWxqUniIuuctl48tI7OLCtr1ayqow=; b=GcxtmvTXkR04lvejFZrl5f/i16fI2Mkm6ECY6LDs8Fo9LbFMBwrSmnPmgXKVjoZDVY J2Xi43SFL126mwM8miHZ+wMmbj7d5TLozFFrsTJFv6x5aAOV4NtQEWVKkrLU4GbY+RMU f4FoBF5uD5Ey3tcG5Bk6pYYrUdscwYNN7+GDi4tZD7IiS8gEiYkSQ3NgednXlx/ZNev5 nKT4uckC7S6l3uCbcFyo6aTFD+VzTw7F5E/P+8zm2KhwxMUTqeX5RyNWa7nb54SEyFRg OVpF1qCveO1jE1zy/IgeDi++m95N4N4b9w/RqUHBxVcNB+nOrEgYif032xBEkdnyFJ2j rNKg== Received: by 10.52.28.144 with SMTP id b16mr793833vdh.4.1351833449119; Thu, 01 Nov 2012 22:17:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Thu, 1 Nov 2012 22:17:08 -0700 (PDT) From: Takeshi Yoshino Date: Fri, 2 Nov 2012 14:17:08 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf307f39c887c09c04cd7c40b0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJqbPWSiSgdDGjRIRLtkgflMhC8T3GdsXo41dIf46uDRMwxmB5QXzP9Sl6EELi0dy26T+JQDMm5Mn6QImzMCOCgXSLUL3eOksQJ+tMcP+qFH4AXNQKQ1r8u8KSBOvBsg112qoPdld1AoshKOe/7qPszJekR2xecFihDE8rmvNGc9K3nReq0zEq2Ug4umaQaVUd6ocm Subject: [hybi] ABNF for the method parameter's value of permessage-compression-04 conflicts with Sec-WebSocket-Extensions's ABNF 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, 02 Nov 2012 05:17:30 -0000 --20cf307f39c887c09c04cd7c40b0 Content-Type: text/plain; charset=ISO-8859-1 In http://tools.ietf.org/html/rfc6455#section-9.1 extension-param = token [ "=" (token | quoted-string) ] ;When using the quoted-string syntax variant, the value ;after quoted-string unescaping MUST conform to the ;'token' ABNF. but I just noticed the value of the method extension parameter of the permessage-compression doesn't always conform token ABNF after unescaping. Please see history below. AFAIK, there was no reason to limit the contents in quoted-string even to token. It's overkilling (sorry that I didn't try to discuss this enough when the first change was made and I drafted permessage-compress forgetting this text). So, ... I'd like to relax the constraint in RFC 6455 and keep current design of premessage-compression. ---- History Until http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07, value ABNF was quoted-string. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08 to -13, it was token. Since http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14, it's quoted-string with the constraint. I remember that I recommended that characters to be used in extension parameter value should be restricted to U+0020 - U+007E. That resulted in quoted-string -> token change. token -> quoted-string change was made IIRC so that existing library for normal HTTP that always quotes any value can be used without fix. See this thread for detail http://www.ietf.org/mail-archive/web/hybi/current/msg08013.html. --20cf307f39c887c09c04cd7c40b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In=A0<= a href=3D"http://tools.ietf.org/html/rfc6455#section-9.1">http://tools.ietf= .org/html/rfc6455#section-9.1

=A0 =A0 =A0 =A0 = =A0extension-param =3D token [ "=3D" (token | quoted-string) ]
=A0 =A0 =A0 =A0 =A0 =A0 =A0;When using the quoted-string syntax varian= t, the value
=A0 =A0 =A0 =A0 =A0 =A0 =A0;after quoted-string unes= caping MUST conform to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0;'token= ' ABNF.

but I just noticed the value of the method extension parameter of the = permessage-compression doesn't always conform token ABNF after unescapi= ng.

Please see history below. AFAIK, there wa= s no reason to limit the contents in quoted-string even to token. It's = overkilling (sorry that I didn't try to discuss this enough when the fi= rst change was made and I drafted permessage-compress forgetting this text)= .

So, ... I'd like to relax the constraint in RFC 645= 5 and keep current design of premessage-compression.

----

History

Since=A0http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketpro= tocol-14, it's quoted-string with the constraint.

I remember that I recommended that characters to be used in extension = parameter value should be restricted to U+0020 - U+007E. That resulted in q= uoted-string -> token change.

token -> quote= d-string change was made IIRC so that existing library for normal HTTP that= always quotes any value can be used without fix.


--20cf307f39c887c09c04cd7c40b0-- From tyoshino@google.com Thu Nov 1 22:32: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 9B5B021F9974 for ; Thu, 1 Nov 2012 22:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI3gQ-nGNZHk for ; Thu, 1 Nov 2012 22:32:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE98021F9970 for ; Thu, 1 Nov 2012 22:32:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3825475vcb.31 for ; Thu, 01 Nov 2012 22:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=v4mCTWM7WBwrLTrvdlHeDSUsrDvQ91q4zpEGYHfvmuQ=; b=Bic+mBT7uRDkGkdGu5r12N0c4Ta9H0TGsDOC/V46ZejXSSUq1e63roEY6cYWlCaaiv pnx6AqYBNSnooCOewYZp6bg2C1IWfspZXmpGVFlMxdgaKQrSSEOLhC/DYee43fb3jRO9 dsH2nMnHf1HMOVLR6nl9SxWDv43Xrk9S9ateSJhVQLupe3u0445d7XDtbi+7bpwNTjIy 0wZqKHwdrW1f1G7IaLJjjxrLQNZcXSNu+pVV9ANMu0EKmYDmunFtmEeHcOwgAcCua58R L/qzeZ4GghTdoO66ijx3LtiPsyvbwhHy/NXVfIzHLH2RiBDUlqyOOuh6WKm9PHYRqrCT ND8w== 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=v4mCTWM7WBwrLTrvdlHeDSUsrDvQ91q4zpEGYHfvmuQ=; b=ZrBtDUA4iDYZSXg5XU14REkDcsHnTrDShpe8QwaH5JLhSYPsDmKerqCNRT5wSR1Rsj qyI6waZLJ0nj+9HAdW+5GL0tGmnBAfA81tl64m9Ayuah0qjQLsbSOMBwB8wGLl9U39gQ EUUHpuhv0JoC2LLY8QOnRl69zzyPQxFqkNo1x89S6kxFkcYfXcpQRY1N7KUvh86xzBaY qL/to9m+O3Iwh6XNePZcmcYU9riBtTICvV1gKDLs1oTnwkDXlWqVSTSXMtgmLHwHqiBB G1SBxFAJ9p3HwXd0kCslTAg9jhHKhF8Z1VXfC67dP45uK3rjAvy17Ne9EaJjZQKf6riQ EmAA== Received: by 10.220.152.11 with SMTP id e11mr797874vcw.61.1351834367912; Thu, 01 Nov 2012 22:32:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Thu, 1 Nov 2012 22:32:27 -0700 (PDT) In-Reply-To: <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> From: Takeshi Yoshino Date: Fri, 2 Nov 2012 14:32:27 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=f46d043d64ab4b6cb604cd7c7729 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlghtg/yfAYHcOrRhS6yBXMWZOcmcA4r0PH+cfFLoBu1ydip5Do8agdDBiJoU8cbbRDtCkP36oHSBVU3oeJOvpY7e1Wdd/AMO7Jg/qbhU6++dklG4vh5xR5tptIt5YLl0uRnxNctOnvpGatAMDyHNevg3oTIes/H4Dzrmnm7yGoE+Jv1+E5ZDwJvccZF8fSxojHsbMz Cc: "hybi@ietf.org" Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 02 Nov 2012 05:32:49 -0000 --f46d043d64ab4b6cb604cd7c7729 Content-Type: text/plain; charset=ISO-8859-1 Thank you for review, Peter. On Thu, Nov 1, 2012 at 6:49 AM, Peter Thorson wrote: > First a question: are there any existing implementations of > permessage-compress (either client or server) suitable for me to test > interoperability with? > pywebsocket server supports it. Tell me if you want to check your impl with it. > Regarding Extension Negotiation > Section 3. Extension Negotiation describes the grammar of the list of > compression method descriptions. It references `token` in the ABNF. Is > token universally defined in ABNF? Or does token here refer to the > definition of token from RFC2616(HTTP 1.1)? In RFC6455 (Websocket > Protocol), which also uses RFC2616 tokens explicitly mentions this and > cites RFC2616 for the definition of token. > Yes. They're constructions borrowed from RFC 2616. I'll add a reference and citation mark ups. > Overall, this section is largely similar to section 9.1 (Extension > Negotiation) of RFC6455 except with less detail (specifically: no mention > of the borrowed HTTP 1.1 semantics including critical reminders of things > like the implied *LWS rules). If each extension is going to include the > exact details of extension negotiation I'd suggest that it include all of > this language. > OK. I'll do so (LWS, etc.). > Alternatively, a much simpler description of extension negotiation that > refers the reader to RFC6455 section 9.1 for the details might be > appropriate. > How about this? OLD The grammar of the list is "requested-method-list" defined in the following ABNFs. ... NEW The ABNF for the list is the same as extension-list defined in the Section 9.1 of [RFC6455] to define the grammar of the Sec-WebSocket-Extensions header. OLD Its grammar is "method-agreement" defined in the following ABNF. ... NEW Its ABNF is extension defined in the Section 9.1 of [RFC6455] to define the grammar of the Sec-WebSocket-Extensions header. > Some minor english issues: > Thanks. > *Some observations from my work implementing this extension* > > snip > - Compression breaks a number of optimizations that servers can use to > reduce CPU and memory usage like outgoing message > preparation/de-duplication. > Do you mean that even if some part of frame construction (copying, etc.) can be skipped, whole frame octets must always go through compressor and it consumes CPU and memory? --f46d043d64ab4b6cb604cd7c7729 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for review, Peter.

On Thu, Nov 1, 2012 at 6:49 AM,= Peter Thorson <webmaster@zaphoyd.com> wrote:
Fir= st a question: are there any existing implementations of permessage-compres= s (either client or server) suitable for me to test interoperability with?<= /div>

pywebsocket server supports it. Tell= me if you want to check your impl with it.
=A0
Regarding Extension Negotiation
Section 3. Extension Negotiation describes the grammar of the list = of compression method descriptions. It references `token` in the ABNF. Is t= oken universally defined in ABNF? Or does token here refer to the definitio= n of token from RFC2616(HTTP 1.1)? In RFC6455 (Websocket Protocol), which a= lso uses RFC2616 tokens explicitly mentions this and cites RFC2616 for the = definition of token.

Yes. They're constructions borro= wed from RFC 2616. I'll add a reference and citation mark ups.
=A0
Overall, this section i= s largely similar to section 9.1 (Extension Negotiation) of RFC6455 except = with less detail (specifically: no mention of the borrowed HTTP 1.1 semanti= cs including critical reminders of things like the implied *LWS rules). If = each extension is going to include the exact details of extension negotiati= on I'd suggest that it include all of this language.

OK. I'll do so (LWS, etc.).
=A0
Alternatively, a much simpler description of extension negotiation th= at refers the reader to RFC6455 section 9.1 for the details might be approp= riate.

How about this?

OLD
=A0 =A0The grammar of the list=A0is = "requested-method-list" defined in the following ABNFs.
=A0 =A0...
NEW
=A0 =A0The ABNF for the list= =A0is the same as extension-list defined in the Section 9.1 of [RFC6455] to= define the grammar of the Sec-WebSocket-Extensions header.

OLD
=A0 =A0Its grammar is=A0"method= -agreement" defined in the following ABNF.
=A0 =A0...
<= div>NEW
=A0 =A0Its ABNF is extension defined in the Section 9.1 o= f [RFC6455] to define the grammar of the Sec-WebSocket-Extensions header.
=A0
Some minor english issues:
<= div>
Thanks.
=A0
*Some observations from m= y work implementing this extension*

snip
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
- Co= mpression breaks a number of optimizations that servers can use to reduce C= PU and memory usage like outgoing message preparation/de-duplication.

Do you mean that even if some part o= f frame construction (copying, etc.) can be skipped, whole frame octets mus= t always go through compressor and it consumes CPU and memory?

--f46d043d64ab4b6cb604cd7c7729-- From julian.reschke@gmx.de Fri Nov 2 02:08: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 C3FA021F9230 for ; Fri, 2 Nov 2012 02:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.235 X-Spam-Level: X-Spam-Status: No, score=-103.235 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAldwNB47Efm for ; Fri, 2 Nov 2012 02:08:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D356A21F918E for ; Fri, 2 Nov 2012 02:08:40 -0700 (PDT) Received: (qmail invoked by alias); 02 Nov 2012 09:08:38 -0000 Received: from p5DD97A10.dip.t-dialin.net (EHLO [192.168.2.117]) [93.217.122.16] by mail.gmx.net (mp010) with SMTP; 02 Nov 2012 10:08:38 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+P5bE/7WqPHZFagiegOteKDxhM2jYcFhCx1SC/ff Q2k3FxYb2PHcCP Message-ID: <50938D8A.5020504@gmx.de> Date: Fri, 02 Nov 2012 10:08:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Takeshi Yoshino References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> 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" , Peter Thorson Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 02 Nov 2012 09:08:41 -0000 On 2012-11-02 06:32, Takeshi Yoshino wrote: > ... > Regarding Extension Negotiation > Section 3. Extension Negotiation describes the grammar of the list > of compression method descriptions. It references `token` in the > ABNF. Is token universally defined in ABNF? Or does token here refer > to the definition of token from RFC2616(HTTP 1.1)? In RFC6455 > (Websocket Protocol), which also uses RFC2616 tokens explicitly > mentions this and cites RFC2616 for the definition of token. > > > Yes. They're constructions borrowed from RFC 2616. I'll add a reference > and citation mark ups. > > Overall, this section is largely similar to section 9.1 (Extension > Negotiation) of RFC6455 except with less detail (specifically: no > mention of the borrowed HTTP 1.1 semantics including critical > reminders of things like the implied *LWS rules). If each extension > is going to include the exact details of extension negotiation I'd > suggest that it include all of this language. > > > OK. I'll do so (LWS, etc.). > ... You will also need to include text that explains that you use RFC 2616-style ABNF (instead of RFC 5234) -- or update it. Did you actually check the ABNF with an ABNF parser yet? Best regards, Julian From tyoshino@google.com Sun Nov 4 23:50: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 AC6FC21F8B81 for ; Sun, 4 Nov 2012 23:50:46 -0800 (PST) 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.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EsHAtPJJbQh for ; Sun, 4 Nov 2012 23:50:44 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0092521F8B5D for ; Sun, 4 Nov 2012 23:50:42 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so6184118vcb.31 for ; Sun, 04 Nov 2012 23:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4gUxTdFrnjskMwPheZZWE6lJ/cuD5G8+yfRA4v2vSUc=; b=kOMzQYjsCUtH4RahxUh1Fh1lu40fK0vgCYiqCGyaoL86faT79VRdA/mPjkZFLqADw6 PskU0bEq+o4FcZW5701RYUr/TJwsJzR+z7rjUfbZu2nIntXldShyQ9CEpkrJ0uMVKnHJ Dt93ZEm9WY10YIQHQYXlOfkecLA+0yYKylXamKAX6qydNUCdKTuOQ4iI440MtzNWIYTu 0vc8iav2OfOMyW6c8W6mrsTGb93rY2UcEBU5pd6apbTA0u/CFrezVDSisaY2iSh7fmSF b7EEdPjn+5p+tXDgd5WljH43kQ6Q5RH1DM/W6FVdOtf+idWU5rYzkriR2nkI8/BABWTh qomg== 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=4gUxTdFrnjskMwPheZZWE6lJ/cuD5G8+yfRA4v2vSUc=; b=m6IeV2xecND7P7SdgXlBEoOMpn5y0Vy5KZquD0KZOmwfgCWIrt4cC/ImqTnpRkHmWi RD423PB/UzlEIfVMAkD+mJ7IVNeF3J1UT/0EUzqGkMwM3eenvt/+KFr2rig3/k1a8wep Rofu6KgfGlXXhOG+54H+8VJHSBNsUttDwceIOpIyDoMjIgVVCrKWpD58Brx9paEgsC8g CP+Crvlx0ySLAs3dOBDDgayv2+GZYaxLHwKlOvWlt5HZHr66K8YyJh88u2K83Rli7NWl M2EPJGgj4Slhcu/qUQqRL2qtDWSrz4RZHukncFIe+uwAW8MTJDUDAN2v14zoNB66kwyv eCAA== Received: by 10.220.152.11 with SMTP id e11mr8512558vcw.61.1352101842458; Sun, 04 Nov 2012 23:50:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Sun, 4 Nov 2012 23:50:22 -0800 (PST) In-Reply-To: <50938D8A.5020504@gmx.de> References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> <50938D8A.5020504@gmx.de> From: Takeshi Yoshino Date: Mon, 5 Nov 2012 16:50:22 +0900 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d043d64ab05192404cdbabe57 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlx1+3Z6uiddJJjJ/YRd44QxMuBrFu6cEpvX5oHNPWfbs/DQFl4962xqLECpvRmjbViOdFOpiIsfuTgcNUo5gjfP72SrMqpJf9FkBQ6/pZEqaWAhSYd9qOEf4DlxwrzgTB+ubaSCgywd8GT+RSPQbkV+cjlU19KzcNKH82AeZP/OFNEhSVWkeYPnHvBRjrcZDqiClhJ Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 05 Nov 2012 07:50:46 -0000 --f46d043d64ab05192404cdbabe57 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 2, 2012 at 6:08 PM, Julian Reschke wrote: > > ... > You will also need to include text that explains that you use RFC > 2616-style ABNF (instead of RFC 5234) -- or update it. > > OK. > Did you actually check the ABNF with an ABNF parser yet? > > Not yet. I just did quick check by using http://www.anfdata.cz/bnfparser2/ but with two more grammar line repetition = ([repeat] element) / ([list] element) list = *DIGIT "#" *DIGIT and changing alternation symbol from "/" to "|". Is there any convenient online checker with the ABNF constructions defined in RFC 2616 predefined? Thanks Takeshi --f46d043d64ab05192404cdbabe57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 2, 2012 at 6:08 PM, Julian Reschke <j= ulian.reschke@gmx.de> wrote:
...
You will also need to include text that explains that you use RFC 2616-styl= e ABNF (instead of RFC 5234) -- or update it.


OK.
=A0
Did you actually check the ABNF with an ABNF parser yet?


Not yet. I just did quick check by using=A0http://www.anfdata.cz/bnfparser2/= =A0but with two more grammar line
=A0 repetition =A0 =A0 =3D =A0([repeat] element) / ([list] elemen= t)
=A0 list =A0 =A0 =A0 =A0 =3D =A0*DIGIT "#"= ; *DIGIT
and changing alternation symbol from "/"= to "|".

Is there any convenient online checker with = the ABNF constructions defined in RFC 2616 predefined?

=
Thanks
Takeshi
--f46d043d64ab05192404cdbabe57-- From julian.reschke@gmx.de Mon Nov 5 00: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 57B7421F84A7 for ; Mon, 5 Nov 2012 00:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.844 X-Spam-Level: X-Spam-Status: No, score=-103.844 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiEMAs+eZqLE for ; Mon, 5 Nov 2012 00:37:03 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1518921F849D for ; Mon, 5 Nov 2012 00:37:02 -0800 (PST) Received: (qmail invoked by alias); 05 Nov 2012 08:37:01 -0000 Received: from p5DD958E6.dip.t-dialin.net (EHLO [192.168.2.117]) [93.217.88.230] by mail.gmx.net (mp016) with SMTP; 05 Nov 2012 09:37:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+tDuVqMPCtRvow+OBm5o7pBKUBaI5sE3CLBuWg0B cxLQ4ga+/892ZQ Message-ID: <50977AAA.6030509@gmx.de> Date: Mon, 05 Nov 2012 09:36:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Takeshi Yoshino References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> <50938D8A.5020504@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" , Peter Thorson Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 05 Nov 2012 08:37:04 -0000 On 2012-11-05 08:50, Takeshi Yoshino wrote: > On Fri, Nov 2, 2012 at 6:08 PM, Julian Reschke > wrote: > > ... > You will also need to include text that explains that you use RFC > 2616-style ABNF (instead of RFC 5234) -- or update it. > > > OK. > > Did you actually check the ABNF with an ABNF parser yet? > > > Not yet. I just did quick check by using > http://www.anfdata.cz/bnfparser2/ but with two more grammar line > repetition = ([repeat] element) / ([list] element) > list = *DIGIT "#" *DIGIT > and changing alternation symbol from "/" to "|". Hu? What's that supposed to do? > Is there any convenient online checker with the ABNF constructions > defined in RFC 2616 predefined? Online I don't think. But there's source in Best regards, Julian From tyoshino@google.com Mon Nov 5 01:08:58 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D911B21F8495 for ; Mon, 5 Nov 2012 01:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.745 X-Spam-Level: X-Spam-Status: No, score=-102.745 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W2NTM7buZuS for ; Mon, 5 Nov 2012 01:08:58 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB521F8491 for ; Mon, 5 Nov 2012 01:08:57 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6307005vbb.31 for ; Mon, 05 Nov 2012 01:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=d/jNtou7Rm/NTB9G2Ze5g5atcaCptoiJ+xtAF3O28D0=; b=GBXwq6e4V3NXGskVJgxcXBhm5AiXeEj0w4zP4cl+ipgcDW1mGMMhz4+rrNRAzx8WwD llGIb4e3wxtdhgxdBqTfJuI0CwCjEQFe84volUcX5HjuWv4GkIwkSaLrBS0oXZCgfFz+ +HRW9NXTJXBCFxXijL9TqjM3I+RyEfGd7qho5RDmLZR5jT9obwy5bh9mKs0dkSzhrFlD EOX/ATulwXTb1VDY+lDnMz7ndPTFNB4pJkBkLybXWvFIRXUsz5b0Q4hF0S+VFqZAdPCF xefvKO5D9/UJGSIsxkZBvncENDKSr0lc62vaLhw7qoAottaV7QHM4pUiM4w450E9qf3/ PtVw== 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=d/jNtou7Rm/NTB9G2Ze5g5atcaCptoiJ+xtAF3O28D0=; b=IKdHBRz2KV/oHnwMMrLfL6i7q8lG7HU8u3yZGjyPLdaR7IYS/duR1Ku1mse89d+wQ2 7tai5BJluLTX7hJLeHTLIJK7fthVKLEM0AGmCTzR+qMHdpuNZc+H0oQI1RiiHlVqf9hN BWhjtH/CKf2FtvMh/L6nZRNvBfp+blUzO/JdVxgmqF5pUizgunju5OmlcXiaT2u/k/Ol VqPTdZtSU7z2ESeA9LJtT+apu0imtTgc+1SY6z2VADJEjRfvBCopEKCQHQON8M2glQxN EUQ9MPigucx271ORcEwmh4RhKeBfIxDMonZOTn5qUPsKl+ZmbF6DdC7coYPoshEt++wo YbEg== Received: by 10.220.226.200 with SMTP id ix8mr8616057vcb.67.1352106537078; Mon, 05 Nov 2012 01:08:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Mon, 5 Nov 2012 01:08:36 -0800 (PST) In-Reply-To: <50977AAA.6030509@gmx.de> References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> <50938D8A.5020504@gmx.de> <50977AAA.6030509@gmx.de> From: Takeshi Yoshino Date: Mon, 5 Nov 2012 18:08:36 +0900 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=14dae9cdca8fd74ebb04cdbbd5ff X-System-Of-Record: true X-Gm-Message-State: ALoCoQn787TaHWW0r3ea1kdYLBUEZ99ypWhlec36Uw4Ct/asmXiXaBpVsuLVD71ynrXYPqFdt62ERo7lJ7sXtJcr0B3qgK+yJtN5znfHlhUf0Bdu2uM1r2112vDLR5vVLPyeyuctjkO1CGpf1sTfLcSJILnS/05Hjes/fB6EXELUTJTQEt1EYB0OR1Pf9rjtpT2Jh3rVECpz Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 05 Nov 2012 09:08:59 -0000 --14dae9cdca8fd74ebb04cdbbd5ff Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 5, 2012 at 5:36 PM, Julian Reschke wrote: > On 2012-11-05 08:50, Takeshi Yoshino wrote: > >> On Fri, Nov 2, 2012 at 6:08 PM, Julian Reschke > **> wrote: >> >> >> Not yet. I just did quick check by using >> http://www.anfdata.cz/**bnfparser2/ but with two more grammar line >> repetition = ([repeat] element) / ([list] element) >> list = *DIGIT "#" *DIGIT >> and changing alternation symbol from "/" to "|". >> > > Hu? What's that supposed to do? > > To add RFC 2616 specific rules. #rule and (rule1 | rule2). I didn't mean it's enough. Never mind. > > Is there any convenient online checker with the ABNF constructions >> defined in RFC 2616 predefined? >> > > Online I don't think. But there's source in *wg/httpbis/trac/browser/**abnfparser/bap > > > > Thanks. --14dae9cdca8fd74ebb04cdbbd5ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2012 at 5:36 PM, Julian Reschke <j= ulian.reschke@gmx.de> wrote:
On 2012-11-05 08:50, Takes= hi Yoshino wrote:
On Fri, Nov 2, 2012 at 6:08 PM, Julian Reschke <julian.reschke@gmx.de
<mailto:julia= n.reschke@gmx.de>> wrote:


Not yet. I just did quick check by using
http://www.= anfdata.cz/bnfparser2/ but with two more grammar line
=A0 =A0repetition =A0 =A0 =3D =A0([repeat] element) / ([list] element)
=A0 =A0list =A0 =A0 =A0 =A0 =3D =A0*DIGIT "#" *DIGIT
and changing alternation symbol from "/" to "|".

Hu? What's that supposed to do?


To add RFC 2616 specific rules. #rule and (rule1 | rul= e2).

I didn't mean it's enough. Never mind= .
=A0

Is there any convenient online checker with the ABNF constructions
defined in RFC 2616 predefined?

Online I don't think. =A0But there's source in <http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfp= arser/bap>


Thanks.
=A0
--14dae9cdca8fd74ebb04cdbbd5ff-- From julian.reschke@gmx.de Mon Nov 5 01:14: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 9F19421F868E for ; Mon, 5 Nov 2012 01:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.731 X-Spam-Level: X-Spam-Status: No, score=-103.731 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZD+zV3ireMz for ; Mon, 5 Nov 2012 01:14:17 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5D0AF21F84DA for ; Mon, 5 Nov 2012 01:14:16 -0800 (PST) Received: (qmail invoked by alias); 05 Nov 2012 09:14:13 -0000 Received: from p5DD958E6.dip.t-dialin.net (EHLO [192.168.2.117]) [93.217.88.230] by mail.gmx.net (mp071) with SMTP; 05 Nov 2012 10:14:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/z1pt6SDrzjsYkcWhiB4DSGvhIIBjh+/5j7VsN5p IrjS03+htN3ch2 Message-ID: <50978362.3060304@gmx.de> Date: Mon, 05 Nov 2012 10:14:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Takeshi Yoshino References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> <50938D8A.5020504@gmx.de> <50977AAA.6030509@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" , Peter Thorson Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 05 Nov 2012 09:14:20 -0000 On 2012-11-05 10:08, Takeshi Yoshino wrote: > On Mon, Nov 5, 2012 at 5:36 PM, Julian Reschke > wrote: > > On 2012-11-05 08:50, Takeshi Yoshino wrote: > > On Fri, Nov 2, 2012 at 6:08 PM, Julian Reschke > > >__> > wrote: > > > Not yet. I just did quick check by using > http://www.anfdata.cz/__bnfparser2/ > but with two more grammar line > repetition = ([repeat] element) / ([list] element) > list = *DIGIT "#" *DIGIT > and changing alternation symbol from "/" to "|". > > > Hu? What's that supposed to do? > > > To add RFC 2616 specific rules. #rule and (rule1 | rule2). > > I didn't mean it's enough. Never mind. Oh - that would add the rules to the grammar of ABNF, not the grammar of the field definition (as least it looks like that). > > Is there any convenient online checker with the ABNF constructions > defined in RFC 2616 predefined? > > > Online I don't think. But there's source in > > > > > Thanks. I would recommend to either copy the language from the base spec (and use the same ABNF variant), or alternatively normatively reference HTTPbis, Part1. Best regards, Julian From tyoshino@google.com Tue Nov 6 19:15: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 BC00421F87AB for ; Tue, 6 Nov 2012 19:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmeswvmnYAWi for ; Tue, 6 Nov 2012 19:15:53 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0021F878B for ; Tue, 6 Nov 2012 19:15:53 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1224047vbb.31 for ; Tue, 06 Nov 2012 19:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fuH/a+LeyNVg/RzN9vkm7dOTM18ttfsTHNsE1EGZYA0=; b=nW++HcDqOmX52jfxBJy8ZSU0gKdn/THRPXP/m3XAHh6qtJk1/jzP2BaWtYZkWmYb1S xrIm4mSR2ELrVp5phPhwBoTFz01j9ZIchxF/Ir+nmGSi8fS++NBha+nqyLe8zs3JYwno fq6cLNBRkoukETdUXzqOnQO/GdVpWXSv+1Bn7Lx6UVeC38BQteMmP5GEQ/YkYpJZ/6Pu 47UDVyFwHo3RSYtEJ4ka+MpHuSCb+z3wIrTP3ZD0XRcXztimEjPYJEOqedsi3Q3AswOY o8rSY4IL29WwzkRhtL6rAvTz2tI2/TINU53tAyuaF7Fhi/Fc9HpbQGSzsmTm1P6MRcAp T/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=fuH/a+LeyNVg/RzN9vkm7dOTM18ttfsTHNsE1EGZYA0=; b=GcY9KZyI7f2SHGGE7D6w2OrKRw23l2tH8S7BmPBXq6mcI77dQEBmg0QVpZ5c1jCiI9 NJ8RY0bHS8EIfP0RGsTMsE6pGs7Gr/QeFQeqAui+RZrz3qjR3WqOvkHPMl3l100NS++7 1Fd+vYaEmbQyBDT2kK702H9s5b84IFn/Xw0aZ313teSlbbEf+2rgpLoJhebK7/ttZzZ/ TsYLI+9fMO0YrW//x7kucE85DKvDmd5svWxjFpr7XYLsJMX80727GyTF4qFowkzW9Ijs KN/7vud1PGgyCcahGSVbJZLNufdPF+NUJriAVnZxfJA2kXBF3bWkpOqqlFIjktL+MZPL IoOA== Received: by 10.52.28.144 with SMTP id b16mr2594064vdh.4.1352258152779; Tue, 06 Nov 2012 19:15:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Tue, 6 Nov 2012 19:15:32 -0800 (PST) In-Reply-To: <50978362.3060304@gmx.de> References: <508686AB.4000409@ericsson.com> <509173D7.2020402@ericsson.com> <9F33F43E-CA1D-4B58-B460-A5C1DD297510@zaphoyd.com> <50938D8A.5020504@gmx.de> <50977AAA.6030509@gmx.de> <50978362.3060304@gmx.de> From: Takeshi Yoshino Date: Wed, 7 Nov 2012 12:15:32 +0900 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=20cf307f39c8d74f2d04cddf2205 X-Gm-Message-State: ALoCoQkQTVH+HtOyiDo+mDH0RbEleOo8s86+naYevjQ6zMUYpT2TwseRCNIs1cu3h5cYFrcYOSpDKj70rtU6E75a3mgsup9o1HJAchbud0+jjD4d2HuXtMfzMGeFoSe/wMPcq1IyAt7qK/ns08GFj1FJK2kz1YT1N4T8FR7r0NIghlTRtKYv9Wa0dznQP1qjOWFKiW90V9As Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th) 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, 07 Nov 2012 03:15:54 -0000 --20cf307f39c8d74f2d04cddf2205 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 5, 2012 at 6:14 PM, Julian Reschke wrote: > On 2012-11-05 10:08, Takeshi Yoshino wrote: > >> To add RFC 2616 specific rules. #rule and (rule1 | rule2). >> >> I didn't mean it's enough. Never mind. >> > > Oh - that would add the rules to the grammar of ABNF, not the grammar of > the field definition (as least it looks like that). > Yes. What I did is - add them to the left box of the "Grammar" section of http://www.anfdata.cz/bnfparser2/ - pasted the permessage-compression ABNF to "Input string" - clicked "PARSE" to check the validity of the ABNF. > > >> Is there any convenient online checker with the ABNF constructions >> defined in RFC 2616 predefined? >> >> >> Online I don't think. But there's source in >> > abnfparser/bap >> > abnfparser/bap >> >> >> >> >> Thanks. >> > > Checked the ABNF using bap @ httpbis. >From http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21, copied these rules to core.abnf. tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA ; any VCHAR, except special token = 1*tchar quoted-string = DQUOTE *(qdtext / quoted-pair) DQUOTE OWS = *( SP / HTAB ) qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text obs-text = %x80-FF quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) and parsed these ABNFs in the permessage-compress I-D successfully. requested-method-list = 1#method-desc method-desc = method-name *( OWS ";" OWS method-param) method-name = token method-param = token ["=" (token / quoted-string)] the result is: requested-method-list = *( "," OWS ) method-desc *( OWS "," [ OWS method-desc ] ) method-desc = method-name *( OWS ";" OWS method-param ) method-name = token method-param = token [ "=" ( token / quoted-string ) ] using this result (together with the rules copied to core.abnf), checked examples in the permessage-compress I-D at http://www.anfdata.cz/bnfparser2/ All passed. > I would recommend to either copy the language from the base spec (and use > the same ABNF variant), or alternatively normatively reference HTTPbis, > Part1. > > OK. --20cf307f39c8d74f2d04cddf2205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2012 at 6:14 PM, Julian Reschke <j= ulian.reschke@gmx.de> wrote:
On 2012-11-05 10:08, Takes= hi Yoshino wrote:
To add RFC 2616 spec= ific rules. #rule and (rule1 | rule2).

I didn't mean it's enough. Never mind.

Oh - that would add the rules to the grammar of ABNF, not the grammar of th= e field definition (as least it looks like that).

=
Yes. What I did is
- add them to the left box of the &= quot;Grammar" section of=A0http://www.anfdata.cz/bnfparser2/
- pasted the permessage-compression ABNF to "Input string"
- clicked "PARSE" to check the validity of the ABNF.
=A0


=A0 =A0 =A0 =A0 Is there any convenient online checker with the ABNF constr= uctions
=A0 =A0 =A0 =A0 defined in RFC 2616 predefined?


=A0 =A0 Online I don't think. =A0But there's source in
=A0 =A0 <http://trac.tools.ietf.org/__wg= /httpbis/trac/browser/__abnfparser/bap
=A0 =A0 <http://trac.tools.ietf.org/wg/httpb= is/trac/browser/abnfparser/bap>>


Thanks.


Checked the ABNF using bap @ httpbis.<= /div>


tchar =A0 =A0 =A0 =A0 =A0=3D "!" / "#&qu= ot; / "$" / "%" / "&" / "'"= / "*"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ "+" /= "-" / "." / "^" / "_" / "`&qu= ot; / "|" / "~"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ DIGIT / ALPHA
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0; any VCHAR, except special
token =A0 =A0 =A0 = =A0 =A0=3D =A01*tchar
quoted-string =A0=3D =A0DQUOTE *(qdtext / q= uoted-pair) DQUOTE
OWS =A0 =A0 =A0 =A0 =A0 =A0=3D =A0*( SP / HTAB= )
qdtext =A0 =A0 =A0 =A0 =3D =A0OWS / %x21 / %x23-5B / %x5D-7E / obs-tex= t
obs-text =A0 =A0 =A0 =3D =A0%x80-FF
quoted-pair =A0 = =A0=3D =A0"\" ( HTAB / SP / VCHAR / obs-text )

and parsed these ABNFs in the permessage-compress I-D successfully.

requested-method-list =3D 1#method-desc
method-desc =3D method-name *( OWS ";" OWS method-param)
method-name =3D token
method-param =3D token ["=3D"= ; (token / quoted-string)]

the result is:

requested-method-list =3D =A0*( "," OWS ) method= -desc *( OWS "," [ OWS method-desc ] )
method-desc =3D method-name *( OWS ";" OWS method-param )
method-name =3D token
method-param =3D token [ "=3D&= quot; ( token / quoted-string ) ]

using this resul= t (together with the rules copied to core.abnf), checked examples in the pe= rmessage-compress I-D at=A0ht= tp://www.anfdata.cz/bnfparser2/

All passed.
=A0
I would recommend to either copy the language from the base spec (and use t= he same ABNF variant), or alternatively normatively reference HTTPbis, Part= 1.


OK.=A0
--20cf307f39c8d74f2d04cddf2205-- From webmaster@zaphoyd.com Wed Nov 7 07:11: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 9B80821F8C07 for ; Wed, 7 Nov 2012 07:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mhbtWRWlbV5 for ; Wed, 7 Nov 2012 07:11:03 -0800 (PST) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD4C21F8BBE for ; Wed, 7 Nov 2012 07:11:03 -0800 (PST) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:44937 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TW7HR-0001Sb-EF; Wed, 07 Nov 2012 10:11:01 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC269A0E-267D-46B9-921D-EA887AF90D71" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Peter Thorson In-Reply-To: Date: Wed, 7 Nov 2012 09:11:00 -0600 Message-Id: References: To: Takeshi Yoshino X-Mailer: Apple Mail (2.1499) 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] ABNF for the method parameter's value of permessage-compression-04 conflicts with Sec-WebSocket-Extensions's ABNF 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, 07 Nov 2012 15:11:04 -0000 --Apple-Mail=_FC269A0E-267D-46B9-921D-EA887AF90D71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 2, 2012, at 24:17 , Takeshi Yoshino wrote: > In http://tools.ietf.org/html/rfc6455#section-9.1 >=20 > extension-param =3D token [ "=3D" (token | quoted-string) ] > ;When using the quoted-string syntax variant, the value > ;after quoted-string unescaping MUST conform to the > ;'token' ABNF. >=20 > but I just noticed the value of the method extension parameter of the = permessage-compression doesn't always conform token ABNF after = unescaping. >=20 > Please see history below. AFAIK, there was no reason to limit the = contents in quoted-string even to token. It's overkilling (sorry that I = didn't try to discuss this enough when the first change was made and I = drafted permessage-compress forgetting this text). >=20 > So, ... I'd like to relax the constraint in RFC 6455 and keep current = design of premessage-compression. >=20 > ---- >=20 > History >=20 > Until = http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07, = value ABNF was quoted-string. > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08 to = -13, it was token. > Since = http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14, it's = quoted-string with the constraint. >=20 > I remember that I recommended that characters to be used in extension = parameter value should be restricted to U+0020 - U+007E. That resulted = in quoted-string -> token change. >=20 > token -> quoted-string change was made IIRC so that existing library = for normal HTTP that always quotes any value can be used without fix. >=20 > See this thread for detail = http://www.ietf.org/mail-archive/web/hybi/current/msg08013.html. It seems that relaxing this constraint is required in order to allow = extension parameters to have their own sub-parameters or to provide = multiple parameter values for the server to choose between. Neither of = these capabilities are easily doable given the constraints of the = RFC6455 extension negotiation syntax. Are header fields this complex = typically used in HTTP? Is this sort of complex negotiation likely to be = needed for other extensions? Does mux required it also? If it is needed, = I think allowing arbitrary quoted extension parameter values is a sane = way to do it that is consistent with RFC2616 style parsing. I'd also like to clarify cases where a server is intended to = ignore/reject the extension negotiation vs fail the connection. Should a = parse error in the request-method-list ABNF defined by = permessage-compress or a syntactically valid header that violates one of = the MUSTs in section 3 (i.e. a permessage-compress extension with zero = or two parameters or a value >15 for window bits) result in a failure of = the entire handshake or just a failure to negotiate the extension? What about cases where the header is syntactically valid by the proposed = relaxed RFC6455 rules but not by the request-method-list syntax? Example (trailing empty method param): Sec-WebSocket-Extensions: = permessage-compress; method=3D"deflate; s2c_max_window_bits=3D10, = deflate;" In the case that there is a failure to negotiate an extension that is = required by the client (and implimented by both endpoints) due to not = agreeing on parameters (see example) what close code should the client = fail the connection with? Still 1010? or something else? If 1010, what = exactly would be appropriate to return in the text reason? The entire = value with the required parameters? Example: Sec-WebSocket-Extensions: permessage-compress; method=3D"deflate;= s2c_max_window_bits=3D10" with a server that doesn't support custom = window sizes. > - Compression breaks a number of optimizations that servers can use to = reduce CPU and memory usage like outgoing message = preparation/de-duplication. >=20 > Do you mean that even if some part of frame construction (copying, = etc.) can be skipped, whole frame octets must always go through = compressor and it consumes CPU and memory? These optimizations allow an endpoint can send an identical message to n = clients with constant rather than linear marginal memory usage and = processing time (for frame construction, utf8 validation, masking, etc). = For pubsub/broadcast with many clients this is significant. By default, = permessage-compress creates a stream out of the otherwise independent = compressed messages in one connection. The sliding window state becomes = unique to each connection and required to build subsequent compressed = frames. This prevents message preparation as identical messages may be = compressed differently for each connection (depending on past messages) = and must necessarily be sent through processing once for each connection = rather than once for all. In general this behavior is a good default, as I think in most cases = sliding window takeover will be beneficial and at low concurrency levels = the memory requirements are worth it. High concurrency services may need = to think carefully about whether permessage-compress is worth it. Disabling sliding window takeover from server to client can also be used = to mitigate this behavior in those cases (at obvious compression = effectiveness cost). However, presently it seems only the client can = request that the server not reuse previous state? I haven't had a chance = to test exactly what happens when a server unilaterally decides to reset = the sliding window for every message it sends. Is this likely to cause = problems? Does the negotiation need a way to signal that this is = happening? Peter= --Apple-Mail=_FC269A0E-267D-46B9-921D-EA887AF90D71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 tyoshino@google.com> = wrote:

In http://tools.ietf.= org/html/rfc6455#section-9.1

    =      extension-param =3D token [ "=3D" (token | = quoted-string) ]
             ;When using the = quoted-string syntax variant, the value
      =        ;after quoted-string unescaping MUST conform = to the
            =  ;'token' ABNF.

but I just noticed the value of the method extension parameter of = the permessage-compression doesn't always conform token ABNF after = unescaping.

Please see history below. = AFAIK, there was no reason to limit the contents in quoted-string even = to token. It's overkilling (sorry that I didn't try to discuss this = enough when the first change was made and I drafted permessage-compress = forgetting this text).

So, ... I'd like to relax the constraint in RFC 6455 = and keep current design of premessage-compression.

----

History

Since http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14, = it's quoted-string with the constraint.

I remember that I recommended that characters to be used in = extension parameter value should be restricted to U+0020 - U+007E. That = resulted in quoted-string -> token = change.

token -> quoted-string change was = made IIRC so that existing library for normal HTTP that always quotes = any value can be used without fix.

<= /div>

It seems that relaxing this constraint = is required in order to allow extension parameters to have their own = sub-parameters or to provide multiple parameter values for the server to = choose between. Neither of these capabilities are easily doable given = the constraints of the RFC6455 extension negotiation syntax. Are header = fields this complex typically used in HTTP? Is this sort of complex = negotiation likely to be needed for other extensions? Does mux required = it also? If it is needed, I think allowing arbitrary quoted extension = parameter values is a sane way to do it that is consistent with RFC2616 = style parsing.

I'd also like to clarify cases = where a server is intended to ignore/reject the extension negotiation vs = fail the connection. Should a parse error in the request-method-list = ABNF defined by permessage-compress or a syntactically valid header that = violates one of the MUSTs in section 3 (i.e. a permessage-compress = extension with zero or two parameters or a value >15 for window bits) = result in a failure of the entire handshake or just a failure to = negotiate the extension?

What about cases where = the header is syntactically valid by the proposed relaxed RFC6455 rules = but not by the request-method-list syntax?
Example = (trailing empty method param): Sec-WebSocket-Extensions: = permessage-compress; method=3D"deflate; s2c_max_window_bits=3D10, = deflate;"

In the case that there is a = failure to negotiate an extension that is required by the client (and = implimented by both endpoints) due to not agreeing on parameters (see = example) what close code should the client fail the connection with? = Still 1010? or something else? If 1010, what exactly would be = appropriate to return in the text reason? The entire value with the = required parameters?

Example: = Sec-WebSocket-Extensions: permessage-compress; method=3D"deflate; = s2c_max_window_bits=3D10" with a server that doesn't support custom = window sizes.

- Compression breaks a number of optimizations that = servers can use to reduce CPU and memory usage like outgoing message = preparation/de-duplication.

These optimizations allow an endpoint can send an = identical message to n clients with constant rather than linear marginal = memory usage and processing time (for frame construction, utf8 = validation, masking, etc). For pubsub/broadcast with many clients this = is significant. By default, permessage-compress creates a stream out of = the otherwise independent compressed messages in one connection. The = sliding window state becomes unique to each connection and required to = build subsequent compressed frames. This prevents message preparation as = identical messages may be compressed differently for each connection = (depending on past messages) and must necessarily be sent through = processing once for each connection rather than once for all.
In general this behavior is a good default, as I = think in most cases sliding window takeover will be beneficial and at = low concurrency levels the memory requirements are worth it. High = concurrency services may need to think carefully about whether = permessage-compress is worth it.

Subject: Re: [hybi] ABNF for the method parameter's value of permessage-compression-04 conflicts with Sec-WebSocket-Extensions's ABNF 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, 08 Nov 2012 08:15:00 -0000 --20cf3071ca044b9e4504cdf76e08 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 8, 2012 at 12:11 AM, Peter Thorson wrote: > > On Nov 2, 2012, at 24:17 , Takeshi Yoshino wrote: > > In http://tools.ietf.org/html/rfc6455#section-9.1 > > extension-param = token [ "=" (token | quoted-string) ] > ;When using the quoted-string syntax variant, the value > ;after quoted-string unescaping MUST conform to the > ;'token' ABNF. > > but I just noticed the value of the method extension parameter of the > permessage-compression doesn't always conform token ABNF after unescaping. > > Please see history below. AFAIK, there was no reason to limit the contents > in quoted-string even to token. It's overkilling (sorry that I didn't try > to discuss this enough when the first change was made and I drafted > permessage-compress forgetting this text). > > So, ... I'd like to relax the constraint in RFC 6455 and keep current > design of premessage-compression. > > ---- > > History > > Until http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07, > value ABNF was quoted-string. > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08 to > -13, it was token. > Since http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14, > it's quoted-string with the constraint. > > I remember that I recommended that characters to be used in extension > parameter value should be restricted to U+0020 - U+007E. That resulted in > quoted-string -> token change. > > token -> quoted-string change was made IIRC so that existing library for > normal HTTP that always quotes any value can be used without fix. > > See this thread for detail > http://www.ietf.org/mail-archive/web/hybi/current/msg08013.html. > > > It seems that relaxing this constraint is required in order to allow > extension parameters to have their own sub-parameters or to provide > multiple parameter values for the server to choose between. Neither of > these capabilities are easily doable given the constraints of the RFC6455 > extension negotiation syntax. Are header fields this complex typically used > in HTTP? > AFAIK, no. > Is this sort of complex negotiation likely to be needed for other > extensions? Does mux required it also? > There was some discussion how we should pass extensions for logical channels. Currently they're listed linearly together with mux and extensions for physical connection but there was an idea of nesting extension list (e.g. mux; logical_ext="compress; deflate, baz", foo, bar). > If it is needed, I think allowing arbitrary quoted extension parameter > values is a sane way to do it that is consistent with RFC2616 style parsing. > > I'd also like to clarify cases where a server is intended to ignore/reject > the extension negotiation vs fail the connection. Should a parse error in > the request-method-list ABNF defined by permessage-compress or a > syntactically valid header that violates one of the MUSTs in section 3 > (i.e. a permessage-compress extension with zero or two parameters or a > value >15 for window bits) result in a failure of the entire handshake or > just a failure to negotiate the extension? > I think it's safe to reject only permessage-compress but keep handshake going as far as core protocol level Sec-WebSocket-Extensions parser doesn't fail. permessage-compress: - with zero parameter - with two or more parameters - with unknown parameter(s) can be safely ignored. Of course, we can also fail them aggressively to let implementors know their bugs. ---- http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04#section-5.1 A server MUST ignore "deflate" method descriptions that: o have any method parameter unknown to the server o have any method parameter with an invalid value o is not supported by the server http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04#section-3 If the server doesn't support any of the descriptions listed by the client, the server MUST reject use of the Per-message Compression Extension. So, - deflate method description with win > 15 will be ignored - if there's no description available, reject the permessage-compress extension > > What about cases where the header is syntactically valid by the proposed > relaxed RFC6455 rules but not by the request-method-list syntax? > Example (trailing empty method param): Sec-WebSocket-Extensions: > permessage-compress; method="deflate; s2c_max_window_bits=10, deflate;" > > permessage-compress - with method parameter value that doesn't conform the request-method-list ABNF Is also safe to be ignored, I think. As long as the server doesn't send back permessage-compress, there should be no problem (assuming core WebSocket stack on the client has no problem). > In the case that there is a failure to negotiate an extension that is > required by the client (and implimented by both endpoints) due to not > agreeing on parameters (see example) what close code should the client fail > the connection with? Still 1010? or something else? If 1010, what exactly > would be appropriate to return in the text reason? The entire value with > the required parameters? > > How the reason for 1010 should be like is not well specified for now. If we're going to let UAs react to 1010 automatically, we need to define something structured (1010 from server may be used as hint for client's retrial), but IMO, it's sufficient if it contains some text reading that developers can know what parameter should be supported. > Example: Sec-WebSocket-Extensions: permessage-compress; method="deflate; > s2c_max_window_bits=10" with a server that doesn't support custom window > sizes. > My idea is that if the client can live without s2c_max_window_bits, it should send Sec-WebSocket-Extensions: permessage-compress: method="deflate; s2c_max_window_bits=10; deflate". Otherwise, it should send value like your Example. If the server rejected the permessage-compress (as specified in http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04#section-5.1.2, if the server choose "deflate; s2c_max_window_bits=10" as accepted request, it must include s2c_max_window_bits=10 in its method agreement. since the server doesn't support s2c_max_window_bits, the only way the server can take is rejecting whole permessage-compress request), for example, the client would send a 1010 with reason phrase in natural language like "permessage-compress with s2c_max_window_bits=10 is mandatory". This approach requires clients to list combinatorial number of offers (method descriptions), but the number of parameters looks reasonably small for deflate's case. This is necessary to allow clients to declare mandatoriness. There're alternatives such as "mandatory" annotation, but they should be also as complicated as this approach, maybe. > > - Compression breaks a number of optimizations that servers can use to >> reduce CPU and memory usage like outgoing message >> preparation/de-duplication. >> > > Do you mean that even if some part of frame construction (copying, etc.) > can be skipped, whole frame octets must always go through compressor and it > consumes CPU and memory? > > > These optimizations allow an endpoint ... > Thanks for explanation. > > Disabling sliding window takeover from server to client can also be used > to mitigate this behavior in those cases (at obvious compression > effectiveness cost). However, presently it seems only the client can > request that the server not reuse previous state? I haven't had a chance to > test exactly what happens when a server unilaterally decides to reset the > sliding window for every message it sends. Is this likely to cause > problems? Does the negotiation need a way to signal that this is happening? > > It should be no problem that the server resets compression context for new message without client's request to do so. Backward reference symbols coming from server refers only data inside the message that are also known by the client (dynamic huffman code used are always introduced in the message since a deflate block never straddles message boundary). The compression context of the client which didn't request s2c_no_context_takeover just remembers data of previous messages that will never be referred by symbols coming from the server. Thanks Takeshi --20cf3071ca044b9e4504cdf76e08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 8, 2012 at 12:11 AM, Peter Thorson <w= ebmaster@zaphoyd.com> wrote:

On Nov 2, 2012, at 24:17 , Takeshi Yoshino <= ;tyoshino@google.c= om> wrote:

In=A0http://tools.ietf.org/html/rfc6455#section-9= .1

=A0 =A0 =A0 =A0 =A0extension-param =3D token [ "= =3D" (token | quoted-string) ]
=A0 =A0 =A0 =A0 =A0 =A0 =A0;When using the quoted-string syntax varian= t, the value
=A0 =A0 =A0 =A0 =A0 =A0 =A0;after quoted-string unes= caping MUST conform to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0;'token= ' ABNF.

but I just noticed the value of the method extension parameter of the = permessage-compression doesn't always conform token ABNF after unescapi= ng.

Please see history below. AFAIK, there wa= s no reason to limit the contents in quoted-string even to token. It's = overkilling (sorry that I didn't try to discuss this enough when the fi= rst change was made and I drafted permessage-compress forgetting this text)= .

So, ... I'd like to relax the constraint in RFC 645= 5 and keep current design of premessage-compression.

--= --

History

Until http://tools.ietf.org/html/= draft-ietf-hybi-thewebsocketprotocol-07, value ABNF was quoted-string.<= /div>
Since=A0http://tools.ietf.org/html/draft-ietf-hy= bi-thewebsocketprotocol-14, it's quoted-string with the constraint.=

I remember that I recommended that characters to be used in extension = parameter value should be restricted to U+0020 - U+007E. That resulted in q= uoted-string -> token change.

token -> quote= d-string change was made IIRC so that existing library for normal HTTP that= always quotes any value can be used without fix.


It seems that relaxing this constraint is requir= ed in order to allow extension parameters to have their own sub-parameters = or to provide multiple parameter values for the server to choose between. N= either of these capabilities are easily doable given the constraints of the= RFC6455 extension negotiation syntax. Are header fields this complex typic= ally used in HTTP?

AFAIK, no.
=A0
Is this = sort of complex negotiation likely to be needed for other extensions? Does = mux required it also?

There was some discussion how we sho= uld pass extensions for logical channels. Currently they're listed line= arly together with mux and extensions for physical connection but there was= an idea of nesting extension list (e.g. mux; logical_ext=3D"compress;= deflate, baz", foo, bar).
=A0
If it is needed, I think allowing arbitrary quoted extension pa= rameter values is a sane way to do it that is consistent with RFC2616 style= parsing.

I'd also like to clarify cases where a server is in= tended to ignore/reject the extension negotiation vs fail the connection. S= hould a parse error in the request-method-list ABNF defined by permessage-c= ompress or a syntactically valid header that violates one of the MUSTs in s= ection 3 (i.e. a permessage-compress extension with zero or two parameters = or a value >15 for window bits) result in a failure of the entire handsh= ake or just a failure to negotiate the extension?

I think it's safe to reject only= permessage-compress but keep handshake going as far as=A0core protocol lev= el Sec-WebSocket-Extensions parser doesn't fail. permessage-compress:
- with zero parameter
- with two or more parameters
- with unknown parameter(s)
can be safely ignored.

Of course, we can also fail them aggressively to let impl= ementors know their bugs.

----

=A0 =A0A server MUST ignore "deflate" method descriptio= ns that:
=A0 =A0o =A0have any method parameter unknown to the ser= ver
=A0 =A0o =A0have any method parameter with an invalid value
=A0 =A0o =A0is not supported by the server

=A0 =A0If = the server doesn't support=A0any of the descriptions listed by the clie= nt, the server MUST reject=A0use of the Per-message Compression Extension.= =A0

So,
- deflate method description with w= in > 15 will be ignored
- if there's no description availa= ble, reject the permessage-compress extension
=A0

What about cases wh= ere the header is syntactically valid by the proposed relaxed RFC6455 rules= but not by the=A0request-method-list=A0syntax?
Example (trailing= empty method param):=A0Sec-WebSocket-Extensions: permessage-compress;=A0me= thod=3D"deflate;=A0s2c_max_window_bits= =3D10, deflate;"


permessage-compress
- with method parameter value that doesn't conform the re= quest-method-list ABNF
Is also safe to be ignored, I think.

As long as the server doesn't send back permessage-compr= ess, there should be no problem (assuming core WebSocket stack on the clien= t has no problem).
=A0
In the case that there = is a failure to negotiate an extension that is required by the client (and = implimented by both endpoints) due to not agreeing on parameters (see examp= le) what close code should the client fail the connection with? Still 1010?= or something else? If 1010, what exactly would be appropriate to return in= the text reason? The entire value with the required parameters?


How the reason for 10= 10 should be like is not well specified for now. If we're going to let = UAs react to 1010 automatically, we need to define something structured (10= 10 from server may be used as hint for client's retrial), but IMO, it&#= 39;s sufficient if it contains some text reading that developers can know w= hat parameter should be supported.
=A0
Example: Sec-WebSocket-Extensions: permessage-compres= s;=A0method=3D"deflate; s2c_max_window_bits=3D10" with a server t= hat doesn't support custom window sizes.

My idea is that if the client can li= ve without s2c_max_window_bits, it should send
=A0 Sec-WebSocket-= Extensions: permessage-compress: method=3D"deflate; s2c_max_window_bit= s=3D10; deflate".

Otherwise, it should send value like your Example. If t= he server rejected the permessage-compress (as specified in=A0http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04= #section-5.1.2, if the server choose "deflate; s2c_max_window_bits= =3D10" as accepted request, it must include s2c_max_window_bits=3D10 i= n its method agreement. since the server doesn't support s2c_max_window= _bits, the only way the server can take is rejecting whole permessage-compr= ess request),=A0for example, the client would send a 1010 with reason phras= e in natural language like "permessage-compress with s2c_max_window_bi= ts=3D10 is mandatory".

This approach requi= res clients to list combinatorial number of offers (method descriptions), b= ut the number of parameters looks reasonably small for deflate's case.<= /div>

This is necessary to allow clients to declare mandatori= ness. There're alternatives such as "mandatory" annotation, b= ut they should be also as complicated as this approach, maybe.
=A0

- Compression breaks a number of optimi= zations that servers can use to reduce CPU and memory usage like outgoing m= essage preparation/de-duplication.

Do you mean that even if some part of frame construction (copying, etc.= ) can be skipped, whole frame octets must always go through compressor and = it consumes CPU and memory?

These optimizations allow an endpoint ...

Thanks for explanation.
=A0

Disabling sliding window takeover from server to client can also be use= d to mitigate this behavior in those cases (at obvious compression effectiv= eness cost). However, presently it seems only the client can request that t= he server not reuse previous state? I haven't had a chance to test exac= tly what happens when a server unilaterally decides to reset the sliding wi= ndow for every message it sends. Is this likely to cause problems? Does the= negotiation need a way to signal that this is happening?


It should be no problem that the se= rver resets compression context for new message without client's reques= t to do so. Backward reference symbols coming from server refers only data = inside the message that are also known by the client (dynamic huffman code = used are always introduced in the message since a deflate block never strad= dles message boundary). The compression context of the client which didn= 9;t request s2c_no_context_takeover just remembers data of previous message= s that will never be referred by symbols coming from the server.

Thanks
Takeshi
=A0
--20cf3071ca044b9e4504cdf76e08-- From peter.dunkley@crocodile-rcs.com Thu Nov 8 05:57:40 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453F121F85D6 for ; Thu, 8 Nov 2012 05:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kevi+Nvz5b8O for ; Thu, 8 Nov 2012 05:57:39 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id BEC1421F85BA for ; Thu, 8 Nov 2012 05:57:39 -0800 (PST) Received: (qmail 30759 invoked by uid 0); 8 Nov 2012 13:57:18 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy8.bluehost.com with SMTP; 8 Nov 2012 13:57:18 -0000 Received: from [90.152.0.102] (port=57246 helo=[192.168.0.189]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TWSbd-0002g6-IR for hybi@ietf.org; Thu, 08 Nov 2012 06:57:18 -0700 Message-ID: <1352383033.2304.25.camel@pd-notebook-linux.croc.internal> From: Peter Dunkley To: hybi@ietf.org Date: Thu, 08 Nov 2012 13:57:13 +0000 Organization: Crocodile RCS Ltd Content-Type: multipart/alternative; boundary="=-bVQdul/xqiXp0KRrM5/h" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Subject: [hybi] [Fwd: MSRP over WebSocket] X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:57:40 -0000 --=-bVQdul/xqiXp0KRrM5/h Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello, Salvatore Loreto suggested that, as this draft refers to a new WebSocket sub-protocol, I should advertise it on this list. Regards, Peter Dunkley -------- Forwarded Message -------- From: Peter Dunkley To: simple@ietf.org Subject: MSRP over WebSocket Date: Tue, 6 Nov 2012 12:50:40 -0000 Hello, I have been working on this draft (http://tools.ietf.org/html/draft-pd-msrp-websocket-01) to enable MSRP to be used over WebSocket transport. The latest Kamailio code-base in Git contains an MSRP over WebSocket server implementation. Can anyone advise as to whether there is interest in moving this draft forward, and if so, what the correct process for doing so is? Regards, Peter Dunkley -- Peter Dunkley Technical Director Crocodile RCS Ltd -- Peter Dunkley Technical Director Crocodile RCS Ltd --=-bVQdul/xqiXp0KRrM5/h Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hello,

Salvatore Loreto suggested that, as this draft refers to a new WebSocket sub-protocol, I should advertise it on this list.

Regards,

Peter Dunkley

-------- Forwarded Message --------
From: Peter Dunkley <peter.dunkley@crocodile-rcs.com>
To: simple@ietf.org
Subject: MSRP over WebSocket
Date: Tue, 6 Nov 2012 12:50:40 -0000

Hello,

I have been working on this draft
(http://tools.ietf.org/html/draft-pd-msrp-websocket-01) to enable MSRP to
be used over WebSocket transport.  The latest Kamailio code-base in Git
contains an MSRP over WebSocket server implementation.

Can anyone advise as to whether there is interest in moving this draft
forward, and if so, what the correct process for doing so is?

Regards,

Peter Dunkley

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--=-bVQdul/xqiXp0KRrM5/h-- From willchan@google.com Sat Nov 10 18:07:07 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 54CBB21F8875 for ; Sat, 10 Nov 2012 18:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnR9oZSnOV1Y for ; Sat, 10 Nov 2012 18:07:06 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0A9421F8873 for ; Sat, 10 Nov 2012 18:07:05 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so986233qae.10 for ; Sat, 10 Nov 2012 18:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Yb/MnsGMXUIoa6YAJgUHrWzpna/k5HSZ27+GPN5cGQw=; b=KaS323Q/Y3lm8H1s2X3qLX8hlEv1AbHD+dhmDtWHXe/mbBLLtWSz+zz575WHjtZ9Y/ +tWxvHttrrunKqbhO/yJElar1ryaHMKoyvE+mknOiUSVIaP8toqWQINHcQQO+I4N4qCS aLQOalwQ/JRhPqQqHDUYE5y/osCjBI6eJ6ccWvIrBXfHkcGFUJ15wXxoVN5c5fvNQmRy KN5bj4Ua04L6MkNmt0Ogptk5F2a3EEhqUSeWqoCmZZ6EQtx7iRtb95JW8bDQsW/U9QmP 3RidyivyGolSNJq5y/iZRJqtFairDEDylt/0IXvwQ8ax+CCXqYK9rnaJG7I1Zc8ft/IK EszQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=Yb/MnsGMXUIoa6YAJgUHrWzpna/k5HSZ27+GPN5cGQw=; b=D84VOR5DsGGHZfm4pataChmJcCFNFtyeSDDQlH+ijFxzXwrtdfCW0pZwPs0sIyg6IA S/K2jkeVBuzzYy8jpShuW8R6pjqjSKbklqd797AmVTU4ZPepgvWoNeJwgY8ezRYnmSns c50Tt+H3qTn++FJmy/0tdsBMbHXqCOyNckemvc9D6s2oSEC/uhhOPZQsh9aXYuKHlqE/ UBkwK9F9g+GIPS3jAGvkgqjXJudyU/fH/iBInMWyrl+srZAPbwnSEjAQx6lKKdsd/3s/ 5YBOjM38EnN+9ONJdChg27QB0pjovt4g3CiljPe5+4MC14mpaMtqonowMOxMxFh0sHPz nhKQ== MIME-Version: 1.0 Received: by 10.224.33.135 with SMTP id h7mr19609693qad.26.1352599622261; Sat, 10 Nov 2012 18:07:02 -0800 (PST) Sender: willchan@google.com Received: by 10.229.201.36 with HTTP; Sat, 10 Nov 2012 18:07:02 -0800 (PST) Date: Sat, 10 Nov 2012 18:07:02 -0800 X-Google-Sender-Auth: iss1F8mwgJGP_stYK0E1yBiqhng Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf306f7704021c0f04ce2ea4f8 X-Gm-Message-State: ALoCoQktZlqfFyeHWaSMso4dgBHAc5h6NJV719p3sHbFFi9LI2v2Sl75xJ7t7Xp0gMSNKULL/a4SXOu4PaXiEb0tHVa7msQFS0Jj1GyoZax/KBWaBlgOsuIPViIiVezBjDNCTZgLHERRG1e4jlY+yey3dCIx7BGYozDxTVvzurBzC+XrFAI1f6e7+XIPkU4mPrrE0PIhg/wH X-Mailman-Approved-At: Sat, 10 Nov 2012 20:46:48 -0800 Subject: [hybi] Questions about http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-03 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 02:08:19 -0000 --20cf306f7704021c0f04ce2ea4f8 Content-Type: text/plain; charset=ISO-8859-1 There were some updates on https://code.google.com/p/chromium/issues/detail?id=131960, so this I-D recently came to my attention. I have a number of questions about it. Let me know if I should be asking somewhere else. Btw, please keep me cc'd on replies since I'm not subscribed to this mailing list. Just to doublecheck, are the motivations for this header primarily described in Section 1.1? I'm reading: """ Management of idle HTTP connections has an impact on long-lived communications between hosts. Hosts are able to close idle connections in order to reduce resource consumption. Many clients choose not to send non-idempotent requests on idle connections. If the intermediary or server holding the other end of the connection chooses to close the connection while a non-idempotent request is in transit, the client has no way to tell if the request has succeeded. For this reason, many clients establish a new connection for every non-idempotent request. This is inefficient if the existing connection is a usable connection: establishing a new connection adds significantly to the latency of the request. Connection resources can be more efficiently used when an idle connection timeout is known. A client that only periodically sends request can learn about the possibility of a connection timeout and can act to create a new connection for requests or send requests that keep the connection from timing out. Alternatively, a client that knows that more requests on a connection are unlikely within the discovered timeout interval can close the connection immediately after a poll, releasing resources. """ Point of information, to my knowledge, Chromium does *not* "choose not to send non-idempotent requests on idle connections". In my tenure working on Chromium's network stack I have not seen any bugs related to this. Therefore, I do not know that we're particularly interested in making use of this header, but am very curious to hear what motivated it, in case perhaps we should. * Are there existing problems that other clients are seeing that motivate having servers implement this header for better client connection reuse algorithms? * What are clients planning to do for this? This is a hop-by-hop header, so in order to take advantage of this, would clients have to know the roundtrip time to the next hop? How are clients determining this? Based off connect() times? * As I understand it, the Chromium bug reporter is asking for non-compliant behavior here, right? It's not the client's responsibility to close the connection, it's the server's responsibility to send a FIN to close down its send stream. I ask because then doing nothing (as Chromium currently does) is perfectly compliant behavior. I see no reason for Chromium to unnecessarily wake up the network link (especially in the mobile case when that requires powering up the radio) to close down a connection. * Do we believe that existing intermediaries will actually discard the header as described in section 3? Sorry if I've misunderstood anything. I tried to look up discussion about this I-D on the mailing list archives, but was unable to find anything. If there's previous discussion I should read, please link me and I'll be happy to read it prior to sending more ignorant questions regarding this subject. Cheers. --20cf306f7704021c0f04ce2ea4f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
T= here were some updates on https://code.google.com/p/chromium/issues/detail?id= =3D131960, so this I-D recently came to my attention. I have a number o= f questions about it. Let me know if I should be asking somewhere else. Btw= , please keep me cc'd on replies since I'm not subscribed to this m= ailing list.

Just to doublecheck, are the motivations for this header pri= marily described in Section 1.1? I'm reading:
""&qu= ot;
   Management of idle HTTP connections has an impact on long-lived
   communications between hosts.  Hosts are able to close idle
   connections in order to reduce resource consumption.

   Many clients choose not to send non-idempotent requests on idle
   connections.  If the intermediary or server holding the other end of
   the connection chooses to close the connection while a non-idempotent
   request is in transit, the client has no way to tell if the request
   has succeeded.  For this reason, many clients establish a new
   connection for every non-idempotent request.  This is inefficient if
   the existing connection is a usable connection: establishing a new
   connection adds significantly to the latency of the request.

   Connection resources can be more efficiently used when an idle
   connection timeout is known.  A client that only periodically sends
   request can learn about the possibility of a connection timeout and
   can act to create a new connection for requests or send requests that
   keep the connection from timing out.  Alternatively, a client that
   knows that more requests on a connection are unlikely within the
   discovered timeout interval can close the connection immediately
   after a poll, releasing resources.
"""

Point of information, to my knowledge, Chromium does= *not* "choose not to send non-idempotent requests on idle connections= ". In my tenure working on Chromium's network stack I have not see= n any bugs related to this. Therefore, I do not know that we're particu= larly interested in making use of this header, but am very curious to hear = what motivated it, in case perhaps we should.

* Are there existing problems that other clients are se= eing that motivate having servers implement this header for better client c= onnection reuse algorithms?
* What are clients planning to do for= this? This is a hop-by-hop header, so in order to take advantage of this, = would clients have to know the roundtrip time to the next hop? How are clie= nts determining this? Based off connect() times?
* As I understand it, the Chromium bug reporter is asking for non-comp= liant behavior here, right? It's not the client's responsibility to= close the connection, it's the server's responsibility to send a F= IN to close down its send stream. I ask because then doing nothing (as Chro= mium currently does) is perfectly compliant behavior. I see no reason for C= hromium to unnecessarily wake up the network link (especially in the mobile= case when that requires powering up the radio) to close down a connection.=
* Do we believe that existing intermediaries will actually discard the= header as described in section 3?

Sorry if I'= ve misunderstood anything. I tried to look up discussion about this I-D on = the mailing list archives, but was unable to find anything. If there's = previous discussion I should read, please link me and I'll be happy to = read it prior to sending more ignorant questions regarding this subject.

Cheers.
--20cf306f7704021c0f04ce2ea4f8-- From w@1wt.eu Sat Nov 10 23:50:00 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 EEC1221F882E for ; Sat, 10 Nov 2012 23:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6QA4iPDrfdd for ; Sat, 10 Nov 2012 23:50:00 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08021F860F for ; Sat, 10 Nov 2012 23:49:59 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id qAB7nspY004733; Sun, 11 Nov 2012 08:49:54 +0100 Date: Sun, 11 Nov 2012 08:49:54 +0100 From: Willy Tarreau To: "William Chan (?????????)" Message-ID: <20121111074954.GL1019@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] Questions about http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-03 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 07:50:01 -0000 Hi William, On Sat, Nov 10, 2012 at 06:07:02PM -0800, William Chan (?????????) wrote: > There were some updates on > https://code.google.com/p/chromium/issues/detail?id=131960, so this I-D > recently came to my attention. I have a number of questions about it. Let > me know if I should be asking somewhere else. Btw, please keep me cc'd on > replies since I'm not subscribed to this mailing list. > > Just to doublecheck, are the motivations for this header primarily > described in Section 1.1? I'm reading: > """ > > Management of idle HTTP connections has an impact on long-lived > communications between hosts. Hosts are able to close idle > connections in order to reduce resource consumption. > > Many clients choose not to send non-idempotent requests on idle > connections. If the intermediary or server holding the other end of > the connection chooses to close the connection while a non-idempotent > request is in transit, the client has no way to tell if the request > has succeeded. For this reason, many clients establish a new > connection for every non-idempotent request. This is inefficient if > the existing connection is a usable connection: establishing a new > connection adds significantly to the latency of the request. > > Connection resources can be more efficiently used when an idle > connection timeout is known. A client that only periodically sends > request can learn about the possibility of a connection timeout and > can act to create a new connection for requests or send requests that > keep the connection from timing out. Alternatively, a client that > knows that more requests on a connection are unlikely within the > discovered timeout interval can close the connection immediately > after a poll, releasing resources. > > """ > > Point of information, to my knowledge, Chromium does *not* "choose not to > send non-idempotent requests on idle connections". In my tenure working on > Chromium's network stack I have not seen any bugs related to this. > Therefore, I do not know that we're particularly interested in making use > of this header, but am very curious to hear what motivated it, in case > perhaps we should. So that means that Chromium *does* send POST requests over uncertain links for example ? How does it handle one of the various failures : - connection close received after a few hundreds of milliseconds without a status code (you don't know if the request was received and is being processed) ; - no response, possibly meaning a connection hang in the middle, or a long processing time on the server ; In either case, does it automatically retry or does it try to explain to the user what happened ? > * Are there existing problems that other clients are seeing that motivate > having servers implement this header for better client connection reuse > algorithms? Yes, see above :-) HTTP spec explicitly forbids the UA from retrying non-idempotent requests after a failure, which means that if the UA decides to send such a request over a keep-alive connection, it must then let the end user decide what to do with a possible failure. The header intends to inform the whole chain about the expected life time of the connection so that clients and even intermediaries can decide whether or not it appears safe to reuse an existing connection. Of course there is no 100% guarantee, but it's much better than what we all have to deal with at the moment. Cheers, Willy From willchan@google.com Sun Nov 11 00:18: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 A714121F8921 for ; Sun, 11 Nov 2012 00:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.426 X-Spam-Level: X-Spam-Status: No, score=-101.426 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_RD_TO_BAD_TLD=2.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rmarEoCA5en for ; Sun, 11 Nov 2012 00:18:12 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE821F891F for ; Sun, 11 Nov 2012 00:18:12 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so3670290qca.31 for ; Sun, 11 Nov 2012 00:18:12 -0800 (PST) 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; bh=kkSFLaqJvnEtVTX7WCCtM3dGODp8qynCvJW4AQRcr44=; b=MZXUnjqsOCPuYzxqOWKQJTuravIhh9mZruiDhucHFzVfltehenszAzLXhDvOQaHNDZ 45L4JCcB0sPOIj3AhSmSobUaP2Q2zzhukfhILD4ugyCOpfXraQRyCgAxs66YcEwDRQWX TqGaol8wpKdqffaAcTMPJYTZZvsJfD/4Z7mls9CmPU7dTJcCyRMqStUFB4uCNbhmgONf vrEUjhbU3aoEp7Ut5pYZmlnPPTRSIRy3wqfF13425uKTIkyC0oiWetBQeJdO+/H+2DJF CMhBWoxNQo3hpgS6ORJg97J2+Ty3EYFyuOWyquVX0jtDX2HLn5DONZwurbqH/TCUHSnT n/3g== 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-gm-message-state; bh=kkSFLaqJvnEtVTX7WCCtM3dGODp8qynCvJW4AQRcr44=; b=aJ9h2xmtCMyWTFXorsoGyTjUPuiFRrdKSGRu6nEAVzb5B0UzCGq7c2eGl2qwoNXHXa U/iGhjtcCrbUym6AMUjCAj8N+PX3mQmAaoBWMahEygvX4RCgT/VPKRxhYmDBe7cBVQJ9 JTTds0VDjeg9qKIOGvTXhhb0FmbknLlGlWqL/1RxtuGrl5cCkq3WFBjGsYCv1/PyJvSo Qxq9EpWHwBncdD9heYfaYmSjhUSclLJ1l95CNuMqaggkHo0uo9J7WW5kqdMclMFhXR2T gXAkxmtDd3HeuTWKv7byunM9yQqmLkErrn5QQGjX1Jw7LqU6IqAmf1goDM5tY6w7KKcd 5PCw== MIME-Version: 1.0 Received: by 10.224.72.206 with SMTP id n14mr20174018qaj.38.1352621892127; Sun, 11 Nov 2012 00:18:12 -0800 (PST) Sender: willchan@google.com Received: by 10.229.201.36 with HTTP; Sun, 11 Nov 2012 00:18:12 -0800 (PST) In-Reply-To: <20121111074954.GL1019@1wt.eu> References: <20121111074954.GL1019@1wt.eu> Date: Sun, 11 Nov 2012 00:18:12 -0800 X-Google-Sender-Auth: IVQ23WR-16LHLhQjpQkM6MEnURw Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Willy Tarreau Content-Type: multipart/alternative; boundary=20cf3074b800654a8c04ce33d3d6 X-Gm-Message-State: ALoCoQnuM+gBU92Wcf9WjB8CFCwdElz4ONEOcTDappuuqyzkJEYZArOQqB5LuWgD5limNDBLLRQUe98goZwfE86McrFKD8iDdX5i0wXmtSOsxZm4JHCGnp11WdMWtu9Q2o7aDHmNmdu1hIWrQY+nN8Uedg06wXKRb8IXD07Ns+QBaoSWzMECikLv2X8IdrdtU53MM5J58Ar6 X-Mailman-Approved-At: Sun, 11 Nov 2012 00:41:50 -0800 Cc: hybi@ietf.org Subject: Re: [hybi] Questions about http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-03 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 08:18:13 -0000 --20cf3074b800654a8c04ce33d3d6 Content-Type: text/plain; charset=ISO-8859-1 It appears my messages require moderation, so I apologize to the list if they appear delayed. On Sat, Nov 10, 2012 at 11:49 PM, Willy Tarreau wrote: > Hi William, > > On Sat, Nov 10, 2012 at 06:07:02PM -0800, William Chan (?????????) wrote: > > There were some updates on > > https://code.google.com/p/chromium/issues/detail?id=131960, so this I-D > > recently came to my attention. I have a number of questions about it. Let > > me know if I should be asking somewhere else. Btw, please keep me cc'd on > > replies since I'm not subscribed to this mailing list. > > > > Just to doublecheck, are the motivations for this header primarily > > described in Section 1.1? I'm reading: > > """ > > > > Management of idle HTTP connections has an impact on long-lived > > communications between hosts. Hosts are able to close idle > > connections in order to reduce resource consumption. > > > > Many clients choose not to send non-idempotent requests on idle > > connections. If the intermediary or server holding the other end of > > the connection chooses to close the connection while a non-idempotent > > request is in transit, the client has no way to tell if the request > > has succeeded. For this reason, many clients establish a new > > connection for every non-idempotent request. This is inefficient if > > the existing connection is a usable connection: establishing a new > > connection adds significantly to the latency of the request. > > > > Connection resources can be more efficiently used when an idle > > connection timeout is known. A client that only periodically sends > > request can learn about the possibility of a connection timeout and > > can act to create a new connection for requests or send requests that > > keep the connection from timing out. Alternatively, a client that > > knows that more requests on a connection are unlikely within the > > discovered timeout interval can close the connection immediately > > after a poll, releasing resources. > > > > """ > > > > Point of information, to my knowledge, Chromium does *not* "choose not to > > send non-idempotent requests on idle connections". In my tenure working > on > > Chromium's network stack I have not seen any bugs related to this. > > Therefore, I do not know that we're particularly interested in making use > > of this header, but am very curious to hear what motivated it, in case > > perhaps we should. > > So that means that Chromium *does* send POST requests over uncertain links > for example ? How does it handle one of the various failures : > - connection close received after a few hundreds of milliseconds without > a status code (you don't know if the request was received and is being > processed) ; > https://code.google.com/searchframe#OAMlx_jo-ck/src/net/http/http_network_transaction.cc&exact_package=chromium&l=1278 If we reused an idle connection, then we retry with another connection, not necessarily a new one either. > - no response, possibly meaning a connection hang in the middle, or a > long processing time on the server ; > We don't time out requests. It just spins. The user usually does something if it hangs for too long. > > In either case, does it automatically retry or does it try to explain to > the user what happened ? > Yes for the first case, no for the second. > > > * Are there existing problems that other clients are seeing that motivate > > having servers implement this header for better client connection reuse > > algorithms? > > Yes, see above :-) > > HTTP spec explicitly forbids the UA from retrying non-idempotent requests > after a failure, which means that if the UA decides to send such a request > over a keep-alive connection, it must then let the end user decide what to > do with a possible failure. I'm having trouble finding the relevant section in 2616 which says this. Can you link me? > > The header intends to inform the whole chain about the expected life time > of the connection so that clients and even intermediaries can decide > whether > or not it appears safe to reuse an existing connection. Of course there is > no 100% guarantee, but it's much better than what we all have to deal with > at the moment. > Can you answer my other questions, especially the one which is intended to clarify how a client would effectively use the information in the header? > > Cheers, > Willy > > --20cf3074b800654a8c04ce33d3d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I= t appears my messages require moderation, so I apologize to the list if the= y appear delayed.

On Sat, Nov 10, 2012 at 11:49 PM, Willy Tarreau <w@1wt.eu><= /span> wrote:
Hi William,

On Sat, Nov 10, 2012 at 06:07:02PM -0800, William Chan (?????????) wrote: > There were some updates on
> https://code.google.com/p/chromium/is= sues/detail?id=3D131960, so this I-D
> recently came to my attention. I have a number of questions about it. = Let
> me know if I should be asking somewhere else. Btw, please keep me cc&#= 39;d on
> replies since I'm not subscribed to this mailing list.
>
> Just to doublecheck, are the motivations for this header primarily
> described in Section 1.1? I'm reading:
> """
>
> =A0 =A0Management of idle HTTP connections has an impact on long-lived=
> =A0 =A0communications between hosts. =A0Hosts are able to close idle > =A0 =A0connections in order to reduce resource consumption.
>
> =A0 =A0Many clients choose not to send non-idempotent requests on idle=
> =A0 =A0connections. =A0If the intermediary or server holding the other= end of
> =A0 =A0the connection chooses to close the connection while a non-idem= potent
> =A0 =A0request is in transit, the client has no way to tell if the req= uest
> =A0 =A0has succeeded. =A0For this reason, many clients establish a new=
> =A0 =A0connection for every non-idempotent request. =A0This is ineffic= ient if
> =A0 =A0the existing connection is a usable connection: establishing a = new
> =A0 =A0connection adds significantly to the latency of the request. >
> =A0 =A0Connection resources can be more efficiently used when an idle<= br> > =A0 =A0connection timeout is known. =A0A client that only periodically= sends
> =A0 =A0request can learn about the possibility of a connection timeout= and
> =A0 =A0can act to create a new connection for requests or send request= s that
> =A0 =A0keep the connection from timing out. =A0Alternatively, a client= that
> =A0 =A0knows that more requests on a connection are unlikely within th= e
> =A0 =A0discovered timeout interval can close the connection immediatel= y
> =A0 =A0after a poll, releasing resources.
>
> """
>
> Point of information, to my knowledge, Chromium does *not* "choos= e not to
> send non-idempotent requests on idle connections". In my tenure w= orking on
> Chromium's network stack I have not seen any bugs related to this.=
> Therefore, I do not know that we're particularly interested in mak= ing use
> of this header, but am very curious to hear what motivated it, in case=
> perhaps we should.

So that means that Chromium *does* send POST requests over unce= rtain links
for example ? How does it handle one of the various failures :
=A0 - connection close received after a few hundreds of milliseconds withou= t
=A0 =A0 a status code (you don't know if the request was received and i= s being
=A0 =A0 processed) ;



If we reused an idle connection, then we retry with ano= ther connection, not necessarily a new one either.


=A0 - no response, possibly meaning a connection hang in the middle, or a =A0 =A0 long processing time on the server ;

We don't time out requests. It just spins. The user usually does = something if it hangs for too long.
=A0

In either case, does it automatically retry or does it try to explain to the user what happened ?

Yes for the fi= rst case, no for the second.
=A0

> * Are there existing problems that other clients are seeing that motiv= ate
> having servers implement this header for better client connection reus= e
> algorithms?

Yes, see above :-)

HTTP spec explicitly forbids the UA from retrying non-idempotent requests after a failure, which means that if the UA decides to send such a request<= br> over a keep-alive connection, it must then let the end user decide what to<= br> do with a possible failure.=A0

I'm havi= ng trouble finding the relevant section in 2616 which says this. Can you li= nk me?
=A0

The header intends to inform the whole chain about the expected life time of the connection so that clients and even intermediaries can decide whethe= r
or not it appears safe to reuse an existing connection. Of course there is<= br> no 100% guarantee, but it's much better than what we all have to deal w= ith
at the moment.

Can you answer my other = questions, especially the one which is intended to clarify how a client wou= ld effectively use the information in the header?
=A0

Cheers,
Willy


--20cf3074b800654a8c04ce33d3d6-- From w@1wt.eu Sun Nov 11 01:38: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 53ED421F8432 for ; Sun, 11 Nov 2012 01:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, SARE_RD_TO_BAD_TLD=2.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnoYdGQWmmj2 for ; Sun, 11 Nov 2012 01:38:25 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 57F6A21F8431 for ; Sun, 11 Nov 2012 01:38:24 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id qAB9cJZs004932; Sun, 11 Nov 2012 10:38:19 +0100 Date: Sun, 11 Nov 2012 10:38:19 +0100 From: Willy Tarreau To: "William Chan (?????????)" Message-ID: <20121111093819.GM1019@1wt.eu> References: <20121111074954.GL1019@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] Questions about http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-03 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 09:38:26 -0000 Hi William, On Sun, Nov 11, 2012 at 12:18:12AM -0800, William Chan (?????????) wrote: > It appears my messages require moderation, so I apologize to the list if > they appear delayed. OK. You should probably subscribe, hybi has very low traffic these days, you won't be spammed. > On Sat, Nov 10, 2012 at 11:49 PM, Willy Tarreau wrote: > > So that means that Chromium *does* send POST requests over uncertain links > > for example ? How does it handle one of the various failures : > > - connection close received after a few hundreds of milliseconds without > > a status code (you don't know if the request was received and is being > > processed) ; > > https://code.google.com/searchframe#OAMlx_jo-ck/src/net/http/http_network_transaction.cc&exact_package=chromium&l=1278 > > If we reused an idle connection, then we retry with another connection, not > necessarily a new one either. OK so that means you can send multiple non-idempotent requests then ? That's very dangerous, it possibly is one of the reasons why one of my colleagues received two books a few years ago while ordering only one (but he paid twice). > > - no response, possibly meaning a connection hang in the middle, or a > > long processing time on the server ; > > > > We don't time out requests. It just spins. The user usually does something > if it hangs for too long. OK. However some environments this can become tricky : with WiFi it's easy to get reassigned a new IP very often when losing connectivity, and outgoing packets will just be dropped. Similarly in mobile environments, if the PDP context is lost and re-established, you have no way of knowing this and idle connections will easily time out. > > In either case, does it automatically retry or does it try to explain to > > the user what happened ? > > Yes for the first case, no for the second. OK, however as I said this is extremely dangerous and even explicitly forbidden by 2616. > > > * Are there existing problems that other clients are seeing that motivate > > > having servers implement this header for better client connection reuse > > > algorithms? > > > > Yes, see above :-) > > > > HTTP spec explicitly forbids the UA from retrying non-idempotent requests > > after a failure, which means that if the UA decides to send such a request > > over a keep-alive connection, it must then let the end user decide what to > > do with a possible failure. > > > I'm having trouble finding the relevant section in 2616 which says this. > Can you link me? Yes, sorry, it's 8.1.4, practical considerations. > > The header intends to inform the whole chain about the expected life time > > of the connection so that clients and even intermediaries can decide > > whether > > or not it appears safe to reuse an existing connection. Of course there is > > no 100% guarantee, but it's much better than what we all have to deal with > > at the moment. > > > > Can you answer my other questions, especially the one which is intended to > clarify how a client would effectively use the information in the header? The informat would tell the client whether or not there is a risk to reuse an idle connection. By having the whole intermediary chain update the header on the response path, the client knows that reusing a connection that remained idle for close to the advertised time is very likely going to cause issues. It will also allow the client to inform the whole chain about its desired connection duration. This would for example allow intermediaries to increase their timeouts from their default values, to better satisfy the client's needs. Of course the header will not tell you if a NAT box is going to timeout in the chain. However intermediaries that are configured according to their surrounding environments might proxy that information. For example, when you have a firewall with 60s timeouts close to your proxy, you don't set your proxy timeouts to 60s, but rather to 50-55s max. This will naturally be reflected in the keep-alive header. To be clear, I'm quite certain this is not the universal solution to all issues, but I think it may improve the overall connection quality on the net. Cheers, Willy From internet-drafts@ietf.org Mon Nov 12 02:51:58 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CB921F8565; Mon, 12 Nov 2012 02:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2MiP+LdbBvB; Mon, 12 Nov 2012 02:51:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21E821F854B; Mon, 12 Nov 2012 02:51:57 -0800 (PST) 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.36 Message-ID: <20121112105157.26360.95684.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2012 02:51:57 -0800 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:51: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 HTTP Wo= rking Group of the IETF. Title : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-09.txt Pages : 43 Date : 2012-11-12 Abstract: The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-multiplexing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-websocket-multiplexing-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Mon Nov 12 03:01:40 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F019421F849A for ; Mon, 12 Nov 2012 03:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2vbJwPXa-E9 for ; Mon, 12 Nov 2012 03:01:39 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD1D621F8485 for ; Mon, 12 Nov 2012 03:01:38 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6734417vbb.31 for ; Mon, 12 Nov 2012 03:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=J+T2sBxn5hKmIfK8Pnik1ZeadgpINfOcmcwEthTiaRo=; b=bR6cVpKyJsqvy2uanvazot1GIu7QxFos3qbUo0Ty/xxnU8gl2AsJ3ovQgY1+fY0SLb 73azOBwWYt6XZCxsTdup93dsYrROhZgYEO6YiW8RrG5ZChVGju1LV44+PKKb0zGli/X6 Zo7T+yimC27h3A2jpWjf5QHmWR+fogxw3f8nvK/OPrPoqI0cJmtoCdNEpxToM10we1a/ kz9ZKqJJGRvG/Ks2a15A7z34SYZg5k714hXsNbXIPSMG1SCWeBMCi4yJ/I6I9KQc0K7W WqZsOvW7ND4s699zI4ZyBqsY6zj+ZnvUmhwAeSx6LaLFPtKj3RnCpj75VKI0rCQsJCzS aHvA== 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-gm-message-state; bh=J+T2sBxn5hKmIfK8Pnik1ZeadgpINfOcmcwEthTiaRo=; b=UYZ6oo+8oPvgbWvtf6i4ALFd2d3TxJZZBDKKQPSXBfd/bG0zSMreV1ZEs0YMx62QjC qdDBgfH0L3BcaLzOcL5i4q/+JY7qOGP7vhkMnGq1csAAs/S/ybOdYYtXJp0ErZ4UF+8Q tEqO1/KZMmmXz3hxnJ0zwIiIJtFgoeeLm6h120g515GRXwQd0i1+S6D29q1dkkRIXwMk vX3Q24pPCzQE+iA74wJzdixoV/zBBCRuPxE1imjmLitORqO0NPuMAoWNFCeacVcnMvIc 10NChH9ndDXWYuNHa2YWwE8kzPY9zHpdjKpg7s4Z72OjBWB9BOpzRH1IBa/ujUnlYeA8 Rbbw== Received: by 10.58.0.83 with SMTP id 19mr19086715vec.53.1352718097739; Mon, 12 Nov 2012 03:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Mon, 12 Nov 2012 03:01:17 -0800 (PST) In-Reply-To: <20121112105157.26360.95684.idtracker@ietfa.amsl.com> References: <20121112105157.26360.95684.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Mon, 12 Nov 2012 20:01:17 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=047d7b33d302b26e4104ce4a3926 X-Gm-Message-State: ALoCoQlgV770O5wnep/vLjrnOdjb2NQ4WHWKpmijgj1ydXsUW29I2ENrjultjxMbUX9mLLJz4swv3yZEBdsPaQ274jCF4/2HFVABk7cMyimBD7SI/V5Bi9bm4/VqPrbsf9k1znKm0AL+hjK1HpDT3nUMMUNDfiFUfQD5EOrlkTYNq3G0akNvlm7Y9bcvFscuyHLF3KY80ZtL Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 11:01:40 -0000 --047d7b33d302b26e4104ce4a3926 Content-Type: text/plain; charset=ISO-8859-1 Semantic change - new drop reason code 3009 -- since message boundary information is connected to flow control mechanism, I'd like endpoints to fail the logical channel when it sees frame sequence that is invalid in RFC 6455 Clarification - added examples - delta-base is updated after running some modification steps - nothing must be injected between fragments of a control frame on the same logical channel - multiple headers with the same name are allowed in AddChannelRequest/Response - replenished quota field with MSB set MUST be handled as invalid multiplex block, not overflow error Editorial - fixed typos -- http://www.ietf.org/mail-archive/web/hybi/current/msg09887.html - defined "encapsulating message" Takeshi On Mon, Nov 12, 2012 at 7:51 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the BiDirectional or Server-Initiated HTTP > Working Group of the IETF. > > Title : A Multiplexing Extension for WebSockets > Author(s) : John A. Tamplin > Takeshi Yoshino > Filename : draft-ietf-hybi-websocket-multiplexing-09.txt > Pages : 43 > Date : 2012-11-12 > > Abstract: > The WebSocket Protocol [RFC6455] requires a new transport connection > for every WebSocket connection. This presents a scalability problem > when many clients connect to the same server, and is made worse by > having multiple clients running in different tabs of the same user > agent. This extension provides a way for separate logical WebSocket > connections to share an underlying transport connection. > > Please send feedback to the hybi@ietf.org mailing list. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-multiplexing > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --047d7b33d302b26e4104ce4a3926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
S= emantic change
- new drop reason code 3009
-- since mes= sage boundary information is connected to flow control mechanism, I'd l= ike endpoints to fail the logical channel when it sees frame sequence that = is invalid in RFC 6455

Clarification
- added examples
- de= lta-base is updated after running some modification steps
- nothi= ng must be injected between fragments of a control frame on the same logica= l channel
- multiple headers with the same name are allowed in AddChannelRequest= /Response
- replenished quota field with MSB set MUST be handled = as invalid multiplex block, not overflow error

Editoria= l
- fixed typos
--=A0=A0http://www.ietf.org/mail-archive/web/hybi/curren= t/msg09887.html=A0
- defined "encapsulating message"<= /div>

Takeshi


On Mon, Nov 12, 2012 at 7:51 PM, <internet-drafts@ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A Multiplexing Extension for We= bSockets
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : John A. Tamplin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-websocket-multipl= exing-09.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 43
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-11-12

Abstract:
=A0 =A0The WebSocket Protocol [RFC6455] requires a new transport connection=
=A0 =A0for every WebSocket connection. =A0This presents a scalability probl= em
=A0 =A0when many clients connect to the same server, and is made worse by =A0 =A0having multiple clients running in different tabs of the same user =A0 =A0agent. =A0This extension provides a way for separate logical WebSock= et
=A0 =A0connections to share an underlying transport connection.

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


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hybi-websocke= t-multiplexing-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-hybi-websocket-multiplexing-09


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

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

--047d7b33d302b26e4104ce4a3926-- From salvatore.loreto@ericsson.com Mon Nov 12 12:38:00 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 F279121F875C for ; Mon, 12 Nov 2012 12:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.951 X-Spam-Level: X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+AzVnzqtjkF for ; Mon, 12 Nov 2012 12:37:59 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C87B821F86EC for ; Mon, 12 Nov 2012 12:37:58 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-17-50a15e2541ed Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.DF.26143.52E51A05; Mon, 12 Nov 2012 21:37:57 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 12 Nov 2012 21:37:57 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 23593244F for ; Mon, 12 Nov 2012 22:37:57 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0C9FC53897 for ; Mon, 12 Nov 2012 22:37:56 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B0C6F52F90 for ; Mon, 12 Nov 2012 22:37:55 +0200 (EET) Message-ID: <50A15E24.6080603@ericsson.com> Date: Mon, 12 Nov 2012 22:37:56 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: hybi@ietf.org References: <20121111074954.GL1019@1wt.eu> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvja5q3MIAg7/9ehbvX25jcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqkFnUwF95grts6Zx97A+I+pi5GTQ0LARGLbkWVQtpjEhXvr 2boYuTiEBE4ySky6/4wFwtnAKPF8wQko5xyjRPPrB+wQzkFGiZ6eCVA9pxglZv4/wQoyjFdA W+LY463sIDaLgKrE96tbWEBsNgEziecPtzCD2KICyRJrPz1hh6gXlDg58wlYjQiQ3b11DViN sECixPkvfVALtjBKtN7oA2rg4OAUCJSYPDUepIZZwEJi8ZuD7BC2vETz1tnMEA+pSVw9twnM FhLQkug928k0gVFkFpJ1s5C0z0LSvoCReRUje25iZk56udEmRmA4H9zyW3UH451zIocYpTlY lMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyBScPM/00aqyy69F/uh/kPt8Z83k R9LSZqazWT5WCf07fdiuwSJz9dKFOZcVVLg/9eZGLPgsd91qbqqZ5zsrB/8JN+ON/LIUEg+U bVxeZ583+17+52NLFB58cf8vN2vZs+Sa/IfcW8rmyiUf9jezsyx+ZH/7RG1L3e6M9zaRgrsa fHaZLuu8qcRSnJFoqMVcVJwIANO0A201AgAA Subject: Re: [hybi] Questions about http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-03 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:38:00 -0000 On 11/11/12 10:18 AM, William Chan (陈智昌) wrote: > It appears my messages require moderation, so I apologize to the list > if they appear delayed. Hi William, your messages are moderated because you are not subscribed to the hybi mailing list. If you want to contribute to the discussion you are more then welcome but please subscribe to the ml https://www.ietf.org/mailman/listinfo/hybi thanks Salvatore -- Salvatore Loreto, PhD www.sloreto.com From tyoshino@google.com Tue Nov 13 20:30: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 16E2B21F8531 for ; Tue, 13 Nov 2012 20:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiI7QI3S7CPo for ; Tue, 13 Nov 2012 20:30:36 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B97DD21F8462 for ; Tue, 13 Nov 2012 20:30:35 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so23489vbb.31 for ; Tue, 13 Nov 2012 20:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ic1YebY0ktK8UpYfZGkBOiSV/YoafBSl1KBZQrRSI3I=; b=VZPEBFSA61xPzdM7BzJYJ7CN/Pw+8tza4plO6lF8MTOIdIjENiIJSHKHkKNpipo59s CE/VyOLOv1My3DOrxQTr+wYPSOB4R1IxIh5cfxNOHRPVES3sXd+1Ox6I91tiJFyf+D5R x6CosRL6Qj4aqS2uWSqTcUuRdjBps0hrf87T10+aVignS1LHvW7dXhSvBr1zOL2lG3xA 2FEyVS/0OyqSjx3P2T1VjojkqzXs+jQG+YiL4QS9fmcrOVn7740uOwJjzyWASQZ9y5dl oiGE+9nbjkpWYJCEgCQtdMJ7ae3Oj9RTX7hSmFyhMz5JDKQEIrMN3n8zrGS7tUAfQkZB a1BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=Ic1YebY0ktK8UpYfZGkBOiSV/YoafBSl1KBZQrRSI3I=; b=Ji5L1gRzTesjNIOm8Fhcq4q+v4aUd1opa1u67xuKIe3iQ9yncLTqXAjdDrdbfhNV9c lVRDrSf/WT/Q6Ywp5/t9/W6OH4yK85EcFArCatarB56urRtor0nu59yEMUwH74O+EIzF g5DwrBK89aU0PBupTi7aoTZqhKZl+AQiWIeBTfnjO9ewXH6T9FrBuYScvZyTLXHs3xra hjKvK0qvP+Aq0U4PirzKT7LwPaJsoHHuqXBaK5UZ+xJz79Hki10lvbUiOSIm65DW16qQ 9RrmeAHMluUIYKxcU1W+cP9B15yGfEQmCtvkLAWxtch/PNo8e3H4az32H5jrRNyIuVvn WRwg== Received: by 10.58.252.72 with SMTP id zq8mr30806736vec.20.1352867433610; Tue, 13 Nov 2012 20:30:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Tue, 13 Nov 2012 20:30:13 -0800 (PST) From: Takeshi Yoshino Date: Wed, 14 Nov 2012 13:30:13 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=047d7b6daa70cefd4904ce6cfefd X-Gm-Message-State: ALoCoQkNHRd68v2JndNXFgpb6l0YUMjpGpoOPVj2NA+4AiMunLHkFjMpqRNB9MhdDEWMt9Yn4lsxOYCnzg/Fhw6JTwYxM8FIr0Lx0RrGfrkXbGm9SHa7iEZet/uANitEPGIu5KN1Zz8RAFTSOSrfr79kJqG1TNmFalgD0z4qTqayivoGETr3jm4XqP7eQaQo8wpZ2Um3m1IM Subject: [hybi] [Compression] Parameter to suppress client-side compression 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, 14 Nov 2012 04:30:37 -0000 --047d7b6daa70cefd4904ce6cfefd Content-Type: text/plain; charset=ISO-8859-1 Forwarding an off-list request I got on compression spec. The proposal is adding a server->client parameter to suppress compression on client->server data. It might be useful for applications where client->server data is not worth being compressed. Once we add some interface on WebSocket object to turn on/off compression on outgoing data as planned, it'll be less necessary. Thanks Takeshi --047d7b6daa70cefd4904ce6cfefd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
F= orwarding an off-list request I got on compression spec.

The proposal is adding a server->client parameter to suppress com= pression on client->server data. It might be useful for applications whe= re client->server data is not worth being compressed.

Once we add some interface on WebSocket object to turn = on/off compression on outgoing data as planned, it'll be less necessary= .

Thanks
Takeshi
--047d7b6daa70cefd4904ce6cfefd-- From webmaster@zaphoyd.com Wed Nov 14 08:06: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 5336021F8574 for ; Wed, 14 Nov 2012 08:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9il95jR4+KW for ; Wed, 14 Nov 2012 08:06:20 -0800 (PST) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3E421F85A5 for ; Wed, 14 Nov 2012 08:06:20 -0800 (PST) Received: from ranna.uchicago.edu ([128.135.45.206]:62687) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TYfTn-0002vt-5Z for hybi@ietf.org; Wed, 14 Nov 2012 11:06:19 -0500 From: Peter Thorson Content-Type: multipart/alternative; boundary="Apple-Mail=_B1CF1913-F81C-4853-9C70-AF662449B658" Message-Id: <03C7BEFC-231A-4995-980D-712B2DC755F9@zaphoyd.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Wed, 14 Nov 2012 10:06:11 -0600 References: To: "hybi@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1499) 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: Re: [hybi] [Compression] Parameter to suppress client-side compression 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, 14 Nov 2012 16:06:21 -0000 --Apple-Mail=_B1CF1913-F81C-4853-9C70-AF662449B658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 13, 2012, at 22:30 , Takeshi Yoshino wrote: > Forwarding an off-list request I got on compression spec. >=20 > The proposal is adding a server->client parameter to suppress = compression on client->server data. It might be useful for applications = where client->server data is not worth being compressed. >=20 > Once we add some interface on WebSocket object to turn on/off = compression on outgoing data as planned, it'll be less necessary. >=20 > Thanks > Takeshi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi In the absence of such an application facing interface to switch = compression on or off is the intended default that a browser supporting = permessage-compress would automatically compress all outgoing messages = for a connection where permessage-compress was successfully negotiated? Has there been any discussion of browser side interfaces for compression = anywhere yet? I am particularly interested in whether these APIs will = allow end user applications to switch compression on/off per message or = only per connection. Have any browser vendors announced anything = regarding their plans to implement permessage-compress yet? Is there any = reason to believe that browsers will ship with permessage-compress = without a method for javascript apps to signal whether or not to = compress outgoing messages?= --Apple-Mail=_B1CF1913-F81C-4853-9C70-AF662449B658 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 tyoshino@google.com> = wrote:

Forwa= rding an off-list request I got on compression = spec.

The proposal is adding a = server->client parameter to suppress compression on client->server = data. It might be useful for applications where client->server data = is not worth being compressed.

Once we add some interface on WebSocket object to = turn on/off compression on outgoing data as planned, it'll be less = necessary.

Thanks
Takeshi
_______________________________________________
hybi mailing = list
hybi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/hybi

In the absence of = such an application facing interface to switch compression on or off is = the intended default that a browser supporting permessage-compress would = automatically compress all outgoing messages for a connection where = permessage-compress was successfully = negotiated?

Has there been any discussion of = browser side interfaces for compression anywhere yet? I am particularly = interested in whether these APIs will allow end user applications to = switch compression on/off per message or only per connection. Have = any browser vendors announced anything regarding their plans to = implement permessage-compress yet? Is there any reason to believe that = browsers will ship with permessage-compress without a method for = javascript apps to signal whether or not to compress outgoing = messages?
= --Apple-Mail=_B1CF1913-F81C-4853-9C70-AF662449B658-- From tyoshino@google.com Wed Nov 14 18:40: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 4A1F521F8471 for ; Wed, 14 Nov 2012 18:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpomdt15Il6s for ; Wed, 14 Nov 2012 18:40:28 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9131521F8470 for ; Wed, 14 Nov 2012 18:40:19 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1284545vbb.31 for ; Wed, 14 Nov 2012 18:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7rSz9FvTBJQm6CU5eA6nj6yb2iFJlmxqSr3JeC1NQuw=; b=E2TB+0wpd2V0o8JchWNLtTG+3+1IzG3efWbCrNJHids3gSttAfCITlOFE1IqctVc8d a1yYKJl9cNorp9/CU1P+fPBptVdoZzEWt4JY4maKmjGi8RoRs8EPwp1euEh88fBFdyoE KGnCDbMrRQh9fr3CvZ501fHnv61YoSRPCuY0/FVUSmv+x+6p/W+/gs9clB3lxBLrMJVZ Xtad2LtO17vMniNikbzNKnnjQ9kigfe/5HuSFPbf8itq/xgUx1NAqwLfBBw0hgGXv59s V0mNuij6D6MSAszrt3yaF6KpzcvrJsZ/3afuTnJKdWDT6DBJPmeNdPJbAABAI9SPe/0H fJrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=7rSz9FvTBJQm6CU5eA6nj6yb2iFJlmxqSr3JeC1NQuw=; b=caOY3GeeLrMnZ6I+Fz2Wx6eycYhspnUCi/qNm8n249UhLMTcblL9046zUfbiwW8nQQ 3skhGCtjf9l6jZ/wXer7AVgTvzMzQQidvNn3zs9xsW5GH9P6ImLn0gw8/NPm0mv9P7hZ EcHf+6sPZSnKfG8D/d3IbnmicARy6mTp8yu+rM5+naxDctTWZdE+HDAM0eGFRjTxu1Hl N5oM1cO/UzmRyuEGeM78CSBBJki7FxOXetp9dO0DehQZescJPSr7YHfAr6OfaC7uNu3l GNFLS85KrPzJ75NrCUbB4GQUZ+4h5/XskIytT2Wue85up/95scoCPSjrgnvIEu1W84oY X/bw== Received: by 10.220.231.8 with SMTP id jo8mr14000097vcb.40.1352947218948; Wed, 14 Nov 2012 18:40:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.115 with HTTP; Wed, 14 Nov 2012 18:39:58 -0800 (PST) In-Reply-To: <03C7BEFC-231A-4995-980D-712B2DC755F9@zaphoyd.com> References: <03C7BEFC-231A-4995-980D-712B2DC755F9@zaphoyd.com> From: Takeshi Yoshino Date: Thu, 15 Nov 2012 11:39:58 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=14dae9cdc0fd62a47c04ce7f92cb X-Gm-Message-State: ALoCoQlnIBv6cklUoVgXW8fyVVcLvGqkQ+KuJafem3lOfzzxlzh8JErvMbjYVh1eQKqucC2i5JbsWF0cJnomy4u7ZRPiDiRN9pQ88E1NxkumKQ87oDLVo738IlZKR4hzR6ZV4+Ib832yCttDWkj53qW3oZSgZo7iQS6PDX9LBINV0it1UXP2cO0biPy3yJGvNi/C7PsX4yCN Cc: "hybi@ietf.org" Subject: Re: [hybi] [Compression] Parameter to suppress client-side compression 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, 15 Nov 2012 02:40:30 -0000 --14dae9cdc0fd62a47c04ce7f92cb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 15, 2012 at 1:06 AM, Peter Thorson wrote: > > On Nov 13, 2012, at 22:30 , Takeshi Yoshino wrote: > > Forwarding an off-list request I got on compression spec. > > The proposal is adding a server->client parameter to suppress compression > on client->server data. It might be useful for applications where > client->server data is not worth being compressed. > > Once we add some interface on WebSocket object to turn on/off compression > on outgoing data as planned, it'll be less necessary. > > Thanks > Takeshi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > In the absence of such an application facing interface to switch > compression on or off is the intended default that a browser supporting > permessage-compress would automatically compress all outgoing messages for > a connection where permessage-compress was successfully negotiated? > Yes. Or if there's any good heuristic, UAs can employ it to avoid compressing messages that don't compress well. > > Has there been any discussion of browser side interfaces for compression > anywhere yet? > There was. See http://www.ietf.org/mail-archive/web/hybi/current/msg07923.html > I am particularly interested in whether these APIs will allow end user > applications to switch compression on/off per message or only per > connection. > IIRC, people were discussing enabling per-message on/off. > Have any browser vendors announced anything regarding their plans to > implement permessage-compress yet? > There's no work on API side yet, I think. > Is there any reason to believe that browsers will ship with > permessage-compress without a method for javascript apps to signal whether > or not to compress outgoing messages? > > Such an API can be added later without introducing incompatibility. The protocol layer already has "permessage compressed" bit. Thanks Takeshi --14dae9cdc0fd62a47c04ce7f92cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 15, 2012 at 1:06 AM, Peter Thorson <web= master@zaphoyd.com> wrote:

On Nov 13, 2012, at 22:30 , Takeshi Yoshino <tyoshino@google.com> w= rote:

Forwarding an off-list r= equest I got on compression spec.

The proposal is = adding a server->client parameter to suppress compression on client->= server data. It might be useful for applications where client->server da= ta is not worth being compressed.

Once we add some interface on WebSocket object to turn = on/off compression on outgoing data as planned, it'll be less necessary= .

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

In the absence of such an application facing in= terface to switch compression on or off is the intended default that a brow= ser supporting permessage-compress would automatically compress all outgoin= g messages for a connection where permessage-compress was successfully nego= tiated?

Yes. Or if there's any good heur= istic, UAs can employ it to avoid compressing messages that don't compr= ess well.
=A0

Has there been any = discussion of browser side interfaces for compression anywhere yet?

=A0
I am particularly interested in whether these APIs will allow e= nd user applications to switch compression on/off per message or only per c= onnection.

IIRC, people were discussing enablin= g per-message on/off.
=A0
Have any=A0browser vendors announced anything regarding their plans t= o implement permessage-compress yet?

There's no work on API side yet, I think.
=A0
Is there any reason to believe that browsers will ship wi= th permessage-compress without a method for javascript apps to signal wheth= er or not to compress outgoing messages?


Such an API can be added later w= ithout introducing incompatibility. The protocol layer already has "pe= rmessage compressed" bit.

Thanks
Takeshi
=A0
--14dae9cdc0fd62a47c04ce7f92cb-- From SRS0+bd6b738c9c7cf84b=JR=noemax.com=arman@noemax.com Wed Nov 21 05:50:03 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3621F8983 for ; Wed, 21 Nov 2012 05:50:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAkfSoEmhy9y for ; Wed, 21 Nov 2012 05:50:02 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 44E0A21F88B2 for ; Wed, 21 Nov 2012 05:50:02 -0800 (PST) DKIM-Signature: a=rsa-sha1; t=1353505796; x=1354110596; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=ZrGQwGvnea7Bi1dMdt+bJInoS3Y=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l47J4ymM2t4kE7xATeRX9Ir+41oQNqhbYMLITLXD5p8p2v6teRO3Jfx/xAyP0LnE4lBsHN4EeHuVus4r5P9bYIgUE99uMNmWoCy+Po++J7poaFllSWG9zh/zhIbZwzFOrJrwauCuUVxXrHxRONO6PWPMwpzpnvE7UHcBtG5p7z8= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id FYS71855 for ; Wed, 21 Nov 2012 15:49:55 +0200 From: "Arman Djusupov" To: Date: Wed, 21 Nov 2012 15:49:53 +0200 Message-ID: <001201cdc7ef$18b61630$4a224290$@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: Ac3H7edjZ4f8F5/CTca0CTX9qUZVYw== Content-Language: en-us Subject: [hybi] Status code 1011 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, 21 Nov 2012 13:55:44 -0000 Hi all, Can we change the description of status code 1011 from "1011 indicates that a server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request." to the following so that the term "server" is replaced by "endpoint", same as we did for 1007 and 1008: "1011 indicates that an endpoint is terminating the connection because it encountered an unexpected condition that requires it to close the connection." I also removed the mention of "request" because in duplex event-driven communication this condition (leaving no other option but to drop the connection) might also arise with a one-way message or even a response message. With best regards, Arman From webmaster@zaphoyd.com Wed Nov 21 11:39: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 24E0A21F886C for ; Wed, 21 Nov 2012 11:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDVm4aJD6gpI for ; Wed, 21 Nov 2012 11:39:40 -0800 (PST) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9421F885A for ; Wed, 21 Nov 2012 11:39:40 -0800 (PST) Received: from ranna.uchicago.edu ([128.135.45.206]:59220) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TbG94-0000Mo-9n; Wed, 21 Nov 2012 14:39:38 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Peter Thorson In-Reply-To: <001201cdc7ef$18b61630$4a224290$@noemax.com> Date: Wed, 21 Nov 2012 13:39:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001201cdc7ef$18b61630$4a224290$@noemax.com> To: Arman Djusupov X-Mailer: Apple Mail (2.1499) 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] Status code 1011 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, 21 Nov 2012 19:39:41 -0000 I believe this has been corrected already in the RFC 6455 Errata. At = least the s/server/endpoint/ change is. On Nov 21, 2012, at 07:49 , Arman Djusupov wrote: > Hi all, >=20 > Can we change the description of status code 1011 from >=20 > "1011 indicates that a server is terminating the connection because > it encountered an unexpected condition that prevented it from > fulfilling the request." >=20 > to the following so that the term "server" is replaced by "endpoint", = same > as we did for 1007 and 1008: >=20 > "1011 indicates that an endpoint is terminating the connection because > it encountered an unexpected condition that requires it to close the > connection." >=20 > I also removed the mention of "request" because in duplex event-driven > communication this condition (leaving no other option but to drop the > connection) might also arise with a one-way message or even a response > message. >=20 > With best regards, > Arman >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From Markus.Isomaki@nokia.com Fri Nov 23 02:59: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 6FF9F21F859D for ; Fri, 23 Nov 2012 02:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJWMjF1wB7as for ; Fri, 23 Nov 2012 02:59:29 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5189C21F8596 for ; Fri, 23 Nov 2012 02:59:28 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qANAxRje014964 for ; Fri, 23 Nov 2012 12:59:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Nov 2012 12:59:24 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.131]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0318.003; Fri, 23 Nov 2012 10:59:23 +0000 From: To: Thread-Topic: Websocket over TLS keep-alive overhead Thread-Index: Ac3JZhTrqgN5+FAiRC2vlGrsEjKGjQ== Date: Fri, 23 Nov 2012 10:59:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2012 10:59:24.0629 (UTC) FILETIME=[996B0850:01CDC969] X-Nokia-AV: Clean Subject: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 10:59:33 -0000 Hi, I have been trying to check the size of WebSocket "keep-alive" messages ove= r TLS/TCP. By "keep-alive" I mean messages that are sent just to keep the T= CP connection alive through NATs, firewalls etc. I guess there are two ways= of doing that in WebSocket. Either use the PING - PONG control frames or s= end an actual small data frame over the connection. In either case the plai= ntext payload is small, around 6-7 bytes with the WebSocket header and mask= ing key.=20 The question is how big such messages are when sent over TLS. I've done som= e traces with http://www.websocket.org/echo.html and it seems 74(!) byte pa= yloads get generated by just sending a single character over the WS/TLS/TCP= connection, using Chrome. If I'm reading the Wireshark dissector output co= rrectly, there are two TLS records inside the TCP packet, each with size 5 = + 32 bytes (32 =3D 16 byte minimum block + 16 byte MAC?). That's fine excep= t I don't understand why two TLS records are needed. This might be a single= instance but I've also gotten traces of two XMPP clients that send 2-byte = CRLF as keep-alive, and that also becomes the same 74 bytes over TLS. (In t= he XMPP cases I believe TLS compression is in use, don't know about the Chr= ome - websocket.org connection.) 74 bytes + TCP/IP headers is still a very small packet, but it may become a= n issue in WCDMA/HSPA 3G networks. In those networks very small amounts of = data can be carried on a low power-consuming radio channel (FACH), while an= y larger traffic triggers a more-consuming dedicated channel (DCH) to be ac= tivated. So, there is a significant difference in power consumption which w= ay the keep-alive happens - considering you do it every 5 minutes for sever= al hours, for instance. 74 bytes + TCP/IP happen to be just about on the bo= rder, so depending on the network settings and the phase of the moon it som= etimes triggers DCH. Something like 50 bytes in TCP payload seems to be alr= eady safe in this sense, unless you do it like once a minute or faster. Any insight on this? What is the KA size supposed to be and what might expl= ain these 74 byte messages I'm seeing? Any way to make it "smaller"? Markus =20 From tobias.oberstein@tavendo.de Fri Nov 23 04:00: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 D72C921F84E0 for ; Fri, 23 Nov 2012 04:00:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lsxvPTdSZss for ; Fri, 23 Nov 2012 04:00:52 -0800 (PST) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6706A21F85D4 for ; Fri, 23 Nov 2012 04:00:51 -0800 (PST) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.107]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Fri, 23 Nov 2012 04:00:45 -0800 From: Tobias Oberstein To: "Markus.Isomaki@nokia.com" , "hybi@ietf.org" Date: Fri, 23 Nov 2012 04:00:46 -0800 Thread-Topic: Websocket over TLS keep-alive overhead Thread-Index: Ac3JZhTrqgN5+FAiRC2vlGrsEjKGjQACz0aQ Message-ID: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 12:00:57 -0000 > The question is how big such messages are when sent over TLS. I've done s= ome > traces with http://www.websocket.org/echo.html and it seems 74(!) byte > payloads get generated by just sending a single character over the WS/TLS= /TCP > connection, using Chrome. If I'm reading the Wireshark dissector output > correctly, there are two TLS records inside the TCP packet, each with siz= e 5 + > 32 bytes (32 =3D 16 byte minimum block + 16 byte MAC?). That's fine excep= t I > don't understand why two TLS records are needed. This might be a single Here is a wild guess: sending a single octet from within JS/Chrome might call into the TLS implementation on the Chrome/client side 2 times: a) for the WS frame header, b) for the payload. This might generate 2 TLS records. WS Pings cannot be triggered from JS, but browsers of course respond to server-sent WS Pings with a Pong, you could try the following experiment and do wiretapping: On a WS TLS connection, send WS Pings from server (with no payload, unmasked =3D 2 octets) and see if the Pong responses (no payload, masked =3D 6 octets) get assembled into 1 or 2 TLS records .. -- Tobias From per.strandh@gmail.com Sun Nov 25 11:23:28 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA51321F865C for ; Sun, 25 Nov 2012 11:23:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUZBBD5JeBoD for ; Sun, 25 Nov 2012 11:23:28 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D122021F8628 for ; Sun, 25 Nov 2012 11:23:27 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so8695182lbk.31 for ; Sun, 25 Nov 2012 11:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ML70wA4XYrFY42czQstf7ptIAXFe0cmtVNpfdqMDqpU=; b=tUNjdOLu9lb6UKgTrkp0/HNEDeKVqfPKYOyfk+3546WS7N4UiCEh4/sHVLwaBsYWxf PIoE6HqvvKu/nidKmsttIVdzAs+WwfPWxFkgbPqHMoSkDybp1JiQsI1XrIB9Nn9ENscB vYviRg+4fZKsmaLs28nIibUJDn9UpCpZ/wdawsWPK05rMxDZt1xDj+p/acWthirfbRRz E+yF5JFL0hCoJv40X9oXu5pTRbIigwyvkeGPxX35rA85PBQ7kVkNkS7xC5l7aYYGw0sX wQKB/z6auzZTWa/MNIwex5vGR1s37uWn0Q3Srd5bLkCk1ZiViUM9WCHd8fGmvUIUJuy2 NZkQ== MIME-Version: 1.0 Received: by 10.152.105.33 with SMTP id gj1mr8810411lab.49.1353871406795; Sun, 25 Nov 2012 11:23:26 -0800 (PST) Received: by 10.112.145.199 with HTTP; Sun, 25 Nov 2012 11:23:26 -0800 (PST) Date: Sun, 25 Nov 2012 20:23:26 +0100 Message-ID: From: Per Strandh To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d040716e3460cf304cf56c0df Subject: [hybi] Unsupported websocket subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 19:23:28 -0000 --f46d040716e3460cf304cf56c0df Content-Type: text/plain; charset=ISO-8859-1 Hi, The websocket standard (RFC6455) specifies how a client can specify one or more subprotocols, and then how the server can select one or none(null) of them. If the server selects none of the subprotocols I interpret the standard to allow the server to upgrade the connection to a websocket. It would then be possible for the client to use or terminate the connection. Have I interpret the standard in the correct way on howto a CLIENT can/should handle an unsupported subprotocol situation? I also wonder if the SERVER can choose to end the connection (due to unsupported or required subprotocol)? If the standard allows it, how should it be done? - By NOT upgrading the connection and returning some other HTTP response code than 101? - By upgrading the connection to a websocket, and then immediately closing it by sending a 'Close Frame' with some of the predefined websocket Status codes? - Some other way? Regards /Per/ --f46d040716e3460cf304cf56c0df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The websocket standard (RFC6455) spec= ifies how a client can specify one or more subprotocols, and then how the s= erver can select one or none(null) of them.

If the= server selects none of the subprotocols I interpret the standard to allow = the server to upgrade the connection to a websocket.
It would then be possible for the client to use or terminate the conne= ction.

Have I interpret the standard in the correc= t way on howto a CLIENT can/should handle an unsupported subprotocol situat= ion?


I also wonder if the SERVER can choose t= o end the connection (due to unsupported or required subprotocol)?
If the standard allows it, how should it be done?
- By NOT upgr= ading the connection and returning some other HTTP response code than 101?<= /div>
- By upgrading the connection to a websocket, and then immediately clo= sing it by sending a 'Close Frame' with some of the predefined webs= ocket Status codes?
- Some other way?


Regards
/Per/<= /font>

--f46d040716e3460cf304cf56c0df-- From tyoshino@google.com Wed Nov 28 22:23:09 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 00CF521F8A31 for ; Wed, 28 Nov 2012 22:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4pkmHJwBmx8 for ; Wed, 28 Nov 2012 22:23:08 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0500221F8A19 for ; Wed, 28 Nov 2012 22:23:07 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so13749696vcb.31 for ; Wed, 28 Nov 2012 22:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EXKo9++qgpyh+XRrp4to3WpTLwWSeH5Fxt37xtj8tnQ=; b=Gvccp6t0h3JFXdXhUozPbC1ONdm7booJCK2OsiF8M+5pHoquDPSAMzsLQl9NSsvxOJ rQvKbscJmRYTlX5M/vM4TdWLqo1me6aDSvP0G4bn8hVhTgmx0roY4w7gHI26vQxN+BVO YefiJBfzaIr3AqbnuZ4hQVl/r6GzD6eGrQb/sUdvq+ZC7kZ4UjypjsckY15vyymTv6vf gF9uWJiJCm3v17S5HeQ/xzsW61uvGtBOZzyr8JVyGWShyj0GHcOKKos+PSXHpXjSeL4G FS3TQW2bOZfAk95Yx4CuLAJDWAeCghCvQ3fH0QeOXe5AZvcVK3JortlOm2bPpybiXUhV b9oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=EXKo9++qgpyh+XRrp4to3WpTLwWSeH5Fxt37xtj8tnQ=; b=L/Rv+2yRFpacPyyyuO7iRNyorsUrPsyNFydnRXH4erjJvVSfIiJHn3RS22DS9Zb1/r XvxsMF3BGyUcAhnEF2UMozMfk20s7MRjlzUcfNi8TAt2459h3pzk1nMiv862roijudFz p6NQHRk/CXclsZnQehIfVYMsu/leZyNsppte8nlSxL22TYHmbXZ1eubVv70H2n/5rxtk Pav+RyPJGfdvwQYv1Nf9iu0aWbtjuObsH1xWPUMbMpZsvOYg7FJYObjBkuzQxIbVx/OB lV46w7Wvg8bm179k25LpIaZO771lPz/h4d1E5fnSzWkpmbssyuItHh9hA18L/kmhRsat mO1g== Received: by 10.52.31.197 with SMTP id c5mr8077904vdi.65.1354170186171; Wed, 28 Nov 2012 22:23:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.248.228 with HTTP; Wed, 28 Nov 2012 22:22:45 -0800 (PST) In-Reply-To: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Thu, 29 Nov 2012 15:22:45 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=bcaec517c548e9869904cf9c5024 X-Gm-Message-State: ALoCoQkrf+c2ZCTqeD0RjvvVBJisveCykUEwnU2jqso2+rGUtS2Z9AgHeA1Nbj9DYgsyNq+7MBLhSBrxUIY0Oi8K3pNjMi+CpXH8OTy/fLrGLO92Z9pMNcNXOZzVBAsYTX81QIijnGW/3CuFIdDGN6UMu9beYWCPLuGp9bDwAFf1a1VLUyqN/jxTQOFUU2zzMgbkl9Cla4ju Cc: "hybi@ietf.org" Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 06:23:09 -0000 --bcaec517c548e9869904cf9c5024 Content-Type: text/plain; charset=ISO-8859-1 Hi, Chromium is using 1/n-1 record splitting for TLS 1.0 connection w/ CBC mode cipher to work around BEAST exploit. So, even a WebSocket frame with 1 octet payload (client -> server, 7 octets in total. AES block size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) > 7, so 1 application data record with 32 octets payload is enough) will be packed into two TLS records with big padding. re: TLS compression, it's disabled on Chromium to address another exploit called CRIME. Thanks Takeshi --bcaec517c548e9869904cf9c5024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Chromium is using 1/n-1 record splitting for TLS 1.0 conne= ction w/ CBC mode cipher to work around BEAST exploit. So, even a WebSocket= frame with 1 octet payload (client -> server, 7 octets in total. AES bl= ock size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) >= ; 7, so 1 application data record with 32 octets payload is enough) will be= packed into two TLS records with big padding.

re: TLS compression, it's disabled on Chromium to a= ddress another exploit called CRIME.

Thanks
Takeshi

--bcaec517c548e9869904cf9c5024-- From tyoshino@google.com Wed Nov 28 23:57: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 847C521F89A5 for ; Wed, 28 Nov 2012 23:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5CNvGY0H+di for ; Wed, 28 Nov 2012 23:57:15 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4995C21F89FA for ; Wed, 28 Nov 2012 23:57:15 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7333393vbb.31 for ; Wed, 28 Nov 2012 23:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HSRTxcNngLFGpJEy52u3psyqFPCnWFLDGSH0XzY9A/w=; b=NANnoSCSEj3LlTp3QeDWpIa9AEHi+AhInygi2ZEXj1yZ9rnEUWroPeljpvitL9bkZ+ Wd8+exoD7yzH27kCM9/7d+FPnxAQVhcTJ4VYKVv0xB5gdflpcyTtIm2/r1vW0NIlHRy2 q/YPGBrzjaRDcm707lV7yc1JhsN61xQVGCasvgHNKl1HOyWYbCjNaYLi3i+g+rcJiSyR 2zUAaJ+8Y/aY9A2Z0VLCDQGfKk7Lq1RaZ/HqPQWFFk/+oTIcCKF6HAYsiMpc9bBGbNI+ 04C31dY54mxYk9aKII7GMr04QET665aZAkOTohlZPDDEJ1yIZWKY0X1yRfjXlv4gNzY5 c/CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=HSRTxcNngLFGpJEy52u3psyqFPCnWFLDGSH0XzY9A/w=; b=kYvPCYch3p0xCxKZvvejkRIMRWg0mSO0sru+zluKIpNW8YgOLqeNZqtvf3PvZBcA2t bVZ109vG7Da8dEPmwNeZwP1fp4o+R0GbLFJuuRAQ5FPX0dHQ0ROzeOwcefaftUBu9Dh8 tqbO4aa1JIaICdjG+965OXk2+ar0bDH/HkJQNIIVs349KU0JPSqmtqQ4KoDhfNUmIgfp elWoixElBfac8bcKKT4rqXJw4sB9z0YF7MofOXotXKyWIYdcxTetIyBjJk2jplMkYOwM /8WKBOFAQDXlSZs3oPkEw66txPvBZR/py8Y6rukwwMsXUeZxiYfrR+VFPyeXt+KzHUgx U6tA== Received: by 10.58.186.226 with SMTP id fn2mr32236460vec.33.1354175834452; Wed, 28 Nov 2012 23:57:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.248.228 with HTTP; Wed, 28 Nov 2012 23:56:54 -0800 (PST) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 29 Nov 2012 16:56:54 +0900 Message-ID: To: Per Strandh Content-Type: multipart/alternative; boundary=047d7b677ff093743404cf9da1c9 X-Gm-Message-State: ALoCoQl2Hd42jdlxTV/M5fjKls8fTdf9lF6PSxlUGbPJhdqiBy8RkxfaOh5FwAvYw8EeDxUd/+SMYP3YcL1sLAP+sSIT+gnZN2c7uqo/W9hsMdoQur/59pIUoDJW7WcZ9iVnAwXSBHBIetNnes9oj9A2bLPQROEVPHrQK900lMjgATsd7hOgDLnTdyeHKJ3dWasaKpbkCNfD Cc: hybi@ietf.org Subject: Re: [hybi] Unsupported websocket subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 07:57:16 -0000 --047d7b677ff093743404cf9da1c9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 26, 2012 at 4:23 AM, Per Strandh wrote: > Hi, > > The websocket standard (RFC6455) specifies how a client can specify one or > more subprotocols, and then how the server can select one or none(null) of > them. > > If the server selects none of the subprotocols I interpret the standard to > allow the server to upgrade the connection to a websocket. > It would then be possible for the client to use or terminate the > connection. > > Yes, a browser accepts a client's opening handshake without the "Sec-WebSocket-Protocol" header (meaning subprotocol=null) even if the client's opening handshake had the "Sec-WebSocket-Protocol" header. If the application on the browser doesn't want to keep talking to the server, it has to close the established connection by itself. > Have I interpret the standard in the correct way on howto a CLIENT > can/should handle an unsupported subprotocol situation? > > > I also wonder if the SERVER can choose to end the connection (due to > unsupported or required subprotocol)? > If the standard allows it, how should it be done? > - By NOT upgrading the connection and returning some other HTTP response > code than 101? > It's not specified. But I think it's ok to reject ones with unsupported subprotocol list by 400. I don't come up with any issue in WebSocket protocol layer can be caused by such a rejection. > - By upgrading the connection to a websocket, and then immediately closing > it by sending a 'Close Frame' with some of the predefined websocket Status > codes? > This is also fine. > - Some other way? > > > Regards > /Per/ > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --047d7b677ff093743404cf9da1c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 26, 2012 at 4:23 AM, Per Strandh <per= .strandh@gmail.com> wrote:
Hi,

The we= bsocket standard (RFC6455) specifies how a client can specify one or more s= ubprotocols, and then how the server can select one or none(null) of them.<= /div>

If the server selects none of the subprotocols I interp= ret the standard to allow the server to upgrade the connection to a websock= et.
It would then be possible for the client to use or terminate the conne= ction.


Yes, a browser = accepts a client's opening handshake without the "Sec-WebSocket-Pr= otocol" header (meaning subprotocol=3Dnull) even if the client's o= pening handshake had the "Sec-WebSocket-Protocol" header.

If the application on the browser doesn't want to k= eep talking to the server, it has to close the established connection by it= self.
=A0
Have I interpret the standard in the correct way on howto a= CLIENT can/should handle an unsupported subprotocol situation?


I also wonder if the SERVER can choose t= o end the connection (due to unsupported or required subprotocol)?
If the standard allows it, how should it be done?
- By NOT upgr= ading the connection and returning some other HTTP response code than 101?<= /div>

It's not specified.=A0But I think it&#= 39;s ok to reject ones with unsupported subprotocol list by 400. I don'= t come up with any issue in WebSocket protocol layer can be caused by such = a rejection.
=A0
- By upgrading the connection to a websocket, and then immediately clo= sing it by sending a 'Close Frame' with some of the predefined webs= ocket Status codes?

This is also fine= .=A0
=A0
- Some other way?


Regards
= /Per/


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


--047d7b677ff093743404cf9da1c9-- From jamie@shareable.org Thu Nov 29 02:11:07 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 4394321F8430 for ; Thu, 29 Nov 2012 02:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZcxXfPCZjfy for ; Thu, 29 Nov 2012 02:11:06 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id AC16C21F8826 for ; Thu, 29 Nov 2012 02:11:06 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Te15D-0004fy-2n; Thu, 29 Nov 2012 10:11:03 +0000 Date: Thu, 29 Nov 2012 10:11:02 +0000 From: Jamie Lokier To: Takeshi Yoshino Message-ID: <20121129101102.GA17793@jl-vm1.vm.bytemark.co.uk> References: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hybi@ietf.org" Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:11:07 -0000 Takeshi Yoshino wrote: > Hi, > Chromium is using 1/n-1 record splitting for TLS 1.0 connection w/ CBC > mode cipher to work around BEAST exploit. So, even a WebSocket frame > with 1 octet payload (client -> server, 7 octets in total. AES block > size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) > > 7, so 1 application data record with 32 octets payload is enough) will > be packed into two TLS records with big padding. > re: TLS compression, it's disabled on Chromium to address another > exploit called CRIME. It might make sense if TLS could transmit its own, much shorter, keepalive messages, which are for the sole purpose of keeping the link alive. I would guess, since they have no other effect, that they wouldn't be exploitable in the same way. Is that right? It would be best if they could be invoked from the higher layer rather than generated in TLS itself (because the higher layer will have a better idea of the keepalive patterns that it needs), and if they were one-way keepalives rather than PING/PONG to avoid amplification attacks, and because PING/PONG is not the most efficient keepalive pattern. Is there provision in TLS for that sort of thing now? (Of course over mobile links, it would make much more sense for power efficiency to have a single, aggregated keepalive stream for all sockets rather than one per active websocket, or some other way of taking advantage of the phone's existing mobile link-level keepalives which it already does and are designed for efficiency.) -- Jamie From jamie@shareable.org Thu Nov 29 02:32: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 0BDCD21F8A45 for ; Thu, 29 Nov 2012 02:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=-2.824, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8Ot2xqXjU6w for ; Thu, 29 Nov 2012 02:32:25 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8355D21F89F3 for ; Thu, 29 Nov 2012 02:32:21 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Te1Pn-0004p0-V4; Thu, 29 Nov 2012 10:32:19 +0000 Date: Thu, 29 Nov 2012 10:32:19 +0000 From: Jamie Lokier To: Takeshi Yoshino Message-ID: <20121129103219.GB17793@jl-vm1.vm.bytemark.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] [Compression] Parameter to suppress client-side compression 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, 29 Nov 2012 10:32:26 -0000 Takeshi Yoshino wrote: > Forwarding an off-list request I got on compression spec. > The proposal is adding a server->client parameter to suppress > compression on client->server data. It might be useful for applications > where client->server data is not worth being compressed. > Once we add some interface on WebSocket object to turn on/off > compression on outgoing data as planned, it'll be less necessary. > Thanks > Takeshi Where the server is supporting 100ks or millions of low-throughput mostly-idle connections per server, it seems useful to disable client->server compression for short messages to avoid the memory overhead of having to receive and decompress them at the server. This applies especially to keepalives, which are sometimes the dominant traffic by far. At the same time, when there is something more interesting and longer to transmit, then it may be useful to compress it. (Server can allocate memory as needed, or even offload to another server if there is a burst of activity on too many connections at once.) So I can see an obscure use case for giving the client JS the option to control this per message, or to set a message size threshold, or to leave it set to automatic. But it seems like a niche situation and there are other strategies such as using multiple WebSockets in parallel and/or writing a compressor in Javascript. -- Jamie From fenix@google.com Thu Nov 29 10:42:50 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 917E321F8B53 for ; Thu, 29 Nov 2012 10:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xynOY-VUt7wn for ; Thu, 29 Nov 2012 10:42:46 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11F4721F8B3B for ; Thu, 29 Nov 2012 10:42:45 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so12087985iaf.31 for ; Thu, 29 Nov 2012 10:42:45 -0800 (PST) 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; bh=GDzqeQ28+QgKsiYYw1Ij1owAvyDPwhlBVZRSMmT2s94=; b=HA38HZtHk8KiEdWuXQX8LtOeM/W1ZPX+q5g7X2acDaIWjPJpMNHDHMZI88yQML+N/h xrlshfgktI5baVUQbUBSyMZTeLbRpmxXzF03p+2KA0QwE35oDGWRXCw5RIOJooOv8ukE idx084yTzr1KzYBFRX5lLFe8Trg4uIZCGYJc6v4gJ8HWYNGbPWGWQ7PteOoVsFe6Mozd C0Qh18gR+Cx6R6rwmlL67gKzkp3MkzciQJjyRGKT9sinTMKajGudp+8VRqtPSHLWTSbW AANBm/lLD/FRXE4/7zGsDHkISof7TnwCQdAPOnF+eZHY+AbQE6eTZ/4mUzFGshq+U15i DruQ== 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=GDzqeQ28+QgKsiYYw1Ij1owAvyDPwhlBVZRSMmT2s94=; b=XgeyOCyIDdELJm4sBmXS1jlKbvnNSQDbjOqrqB3Vwu80sMXCZ0oCxev5nAYPCFzae5 06B6aaDhe4AgzQgkwuL4pFfPJZ1BtB05UyJqmNF+s+upUsmKX26FPwrp5fZIOzeUnr+p dCg3Nq8dvKeN6XgTlesTJMKETaN85z5PJmJeEa83DF1PUbOBamScNODptpCXD6vPQASH e7eM9VGT1izpA1chAYOAmrOsOCTU5sFR23ZFYLUUI0Y0jo7UsHcw/jyT7rW1I+oynkyQ ttjdjOEQYamCszT3quFHhbTw5XrOdVUmhr5mCnkKFfjXSVJDreXtNQRSrfC9jj/St76J 8XxA== MIME-Version: 1.0 Received: by 10.50.5.236 with SMTP id v12mr26679503igv.6.1354214565294; Thu, 29 Nov 2012 10:42:45 -0800 (PST) Received: by 10.50.30.169 with HTTP; Thu, 29 Nov 2012 10:42:45 -0800 (PST) Received: by 10.50.30.169 with HTTP; Thu, 29 Nov 2012 10:42:45 -0800 (PST) In-Reply-To: <20121129101102.GA17793@jl-vm1.vm.bytemark.co.uk> References: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> <20121129101102.GA17793@jl-vm1.vm.bytemark.co.uk> Date: Thu, 29 Nov 2012 10:42:45 -0800 Message-ID: From: Roberto Peon To: Jamie Lokier Content-Type: multipart/alternative; boundary=e89a8f646e731d345b04cfa6a686 X-Gm-Message-State: ALoCoQlJd+FY2drvHibLhykrkjeOmuBIXk589qQ+kH1EQm17HmY5yFAuNBdsm1BL+GFN+jlDO1E543wIRLF8NJc4cN+iAODGAoDwE//Kel4n3qb0aQyoS+pPy7uNDLjQaPPxs7EFob15R/Vd6o78RDzaoJANFa5eATnRa67PTu9wIYHVk5eg64hlcpEodLkhvM0MH6pZJwrz Cc: hybi@ietf.org Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 18:42:50 -0000 --e89a8f646e731d345b04cfa6a686 Content-Type: text/plain; charset=ISO-8859-1 ++ On Nov 29, 2012 2:11 AM, "Jamie Lokier" wrote: > Takeshi Yoshino wrote: > > Hi, > > Chromium is using 1/n-1 record splitting for TLS 1.0 connection w/ CBC > > mode cipher to work around BEAST exploit. So, even a WebSocket frame > > with 1 octet payload (client -> server, 7 octets in total. AES block > > size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) > > > 7, so 1 application data record with 32 octets payload is enough) will > > be packed into two TLS records with big padding. > > re: TLS compression, it's disabled on Chromium to address another > > exploit called CRIME. > > It might make sense if TLS could transmit its own, much shorter, > keepalive messages, which are for the sole purpose of keeping the link > alive. I would guess, since they have no other effect, that they > wouldn't be exploitable in the same way. Is that right? > > It would be best if they could be invoked from the higher layer rather > than generated in TLS itself (because the higher layer will have a > better idea of the keepalive patterns that it needs), and if they were > one-way keepalives rather than PING/PONG to avoid amplification > attacks, and because PING/PONG is not the most efficient keepalive > pattern. > > Is there provision in TLS for that sort of thing now? > > (Of course over mobile links, it would make much more sense for power > efficiency to have a single, aggregated keepalive stream for all > sockets rather than one per active websocket, or some other way of > taking advantage of the phone's existing mobile link-level keepalives > which it already does and are designed for efficiency.) > > -- Jamie > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --e89a8f646e731d345b04cfa6a686 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

++

On Nov 29, 2012 2:11 AM, "Jamie Lokier"= ; <jamie@shareable.org> wr= ote:
Takeshi Yoshino wrote:
> =A0 =A0Hi,
> =A0 =A0Chromium is using 1/n-1 record splitting for TLS 1.0 connection= w/ CBC
> =A0 =A0mode cipher to work around BEAST exploit. So, even a WebSocket = frame
> =A0 =A0with 1 octet payload (client -> server, 7 octets in total. A= ES block
> =A0 =A0size (16) * 2 - SHA1 HMAC size (20) - padding length field size= (1) >
> =A0 =A07, so 1 application data record with 32 octets payload is enoug= h) will
> =A0 =A0be packed into two TLS records with big padding.
> =A0 =A0re: TLS compression, it's disabled on Chromium to address a= nother
> =A0 =A0exploit called CRIME.

It might make sense if TLS could transmit its own, much shorter,
keepalive messages, which are for the sole purpose of keeping the link
alive. =A0I would guess, since they have no other effect, that they
wouldn't be exploitable in the same way. =A0Is that right?

It would be best if they could be invoked from the higher layer rather
than generated in TLS itself (because the higher layer will have a
better idea of the keepalive patterns that it needs), and if they were
one-way keepalives rather than PING/PONG to avoid amplification
attacks, and because PING/PONG is not the most efficient keepalive
pattern.

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

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

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