Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt

Takeshi Yoshino <tyoshino@google.com> Tue, 04 June 2013 12:44 UTC

Return-Path: <tyoshino@google.com>
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 EB05621F9A12 for <hybi@ietfa.amsl.com>; Tue, 4 Jun 2013 05:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level:
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaj5yyUqdUGY for <hybi@ietfa.amsl.com>; Tue, 4 Jun 2013 05:44:32 -0700 (PDT)
Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B421421F9BF7 for <hybi@ietf.org>; Tue, 4 Jun 2013 04:17:58 -0700 (PDT)
Received: by mail-ea0-f171.google.com with SMTP id m14so70119eaj.30 for <hybi@ietf.org>; Tue, 04 Jun 2013 04:17:57 -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; bh=5nXab+P1bL2jHRpYkN7atZiaYAJWBJwczZdMTnUiRdM=; b=Xa9PmRiZOG/BKStCsZBsZ0DzBU92aV0qDA0zs5KmfZT2S7PohAjiZ2a1xQgc68OtG+ c8Vu9ajefTnpF6wSZB/PFxYW87EjKIx+Mw8STO3vIXaExkSxCpeLuWW5FIqybtY/kaaw jdFX1ceXEHKfuwWWLoG2CRD3yVcQLpciVoTUTMKnuseAOLUXUHJWkLYVQ0iXZaTBM5ik Gy+dvWzxmKiSGakAjB7s9KVw6sTa0fGwCz8whzkoe7wqriXPriT5ygbjpsMkMsgIwBdL qKM8JTZ4yker+b0Gywwt1u9KxMoAEqGBiZNXHFHFzArdqRZ6sVwMmLc5+fFHBsDv1lrb ZL7w==
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=5nXab+P1bL2jHRpYkN7atZiaYAJWBJwczZdMTnUiRdM=; b=H2QljZA+TBRlmBj49/Quf/Bx3rckJoBZzJ4cmVutjxuBEPDzYVRf+6VE4NNS4UDMxo B40ryl+vdraf9vH48ukqHCKfzAD+ZZM62tAuQaydXTCT45evE+K3P+s1F8jeq+S/ApNl aahEnLdMwlOqbfxClgkoAI2v5Uy2hrkdAgtz37CZpP0MhjnQMM9LYmLhGUlinuOJwBqX fHGgmsVvofWcsdgl0r1R5M5RehNeIQGDn0abeAIGmOIVrFUAPK9+2A7cnx23lsblnoei +9ZiG8Q7Fl4D3SUyTsR8p6TG+2wTv4iHlLpHwbFMrFgKpTNHlaeq+4i6y3ZI5i5aA5dC Dngg==
X-Received: by 10.14.2.7 with SMTP id 7mr9279930eee.99.1370344677699; Tue, 04 Jun 2013 04:17:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 04:17:36 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D4422DC20D62@EXVMBX020-12.exch020.serverdata.net>
References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <CAH9hSJYDH47Ya1FNp80xjeD=pwYJAqcx=XDr=SnBbNDD+f-r4Q@mail.gmail.com> <CAH9hSJYa8QA9VkOwS6GEr0+8iJcnQcpMy3X_fKwGQOuJRr=sEw@mail.gmail.com> <634914A010D0B943A035D226786325D4422DC20D62@EXVMBX020-12.exch020.serverdata.net>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 04 Jun 2013 20:17:36 +0900
Message-ID: <CAH9hSJbbFYL3TTo3YH2stF78qnxDd1EQe8HYOiV9rz3b+6fpvw@mail.gmail.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary="047d7b66f6cbbc345304de523b85"
X-Gm-Message-State: ALoCoQl3fRG0dzw/8KxDU+jl8zHnwdDqlzq1J8irNdTNQ+l3CaSQZ2Vn7FZmqa9pMf+iRy6quT7jhyJgok9/FC4nbdKSl54e1clki5bN6FXIaGfNGdyLCs5rYslg4hNsUkKBGHOWc6S0mdWA3P/4JxZi2J9NHDCXx6HSLvOPXIv5wgPm7j0rqyQrc1Z8ksbVVylnUjw2WJ0r
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 12:44:45 -0000

On Sat, Jun 1, 2013 at 5:54 AM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> > Please post your opinions and experience (implemented, faced any
> difficulties, found issues, etc.).
>
> 1) Some first testing ..
>
> http://code.google.com/p/chromium/issues/detail?id=245732
> http://code.google.com/p/chromium/issues/detail?id=245719
>
>
Thanks so much.


> 2)
> If client offers multiple PMCE choices to the server by including multiple
> elements in the "Sec-WebSocket-Extensions" header and the server supports
> more than one of the PMCEs offered, is there any preference which PMCE the
> server SHOULD choose? E.g. the first PMCE in the header that is supported
> by the server?
>
> The description of the examples in "5.1. Negotiation Examples" seem to
> suggest that the _ordering_ of alternative PMCE offered designates
> _preference_.
>
>
Yes. Order means preference. The server may choose any even if it supports
all of them.

Do you think we need any text to make it clear?


> 3)
> """
>    A server MUST decline a "permessage-deflate" offer if any of the
>    following conditions is met:
>
>    o  The offer has any extension parameter not defined for use in an
>       offer.
>
>    o  The offer has any extension parameter with an invalid value.
>
>    o  The offer has multiple extension parameters with the same name.
>
>    o  The server doesn't support the offered configuration.
> """
>
> So if multiple permessage-deflate PMCEs are offered by the client, the
> server silently skips any invalid until the first valid or none if there is
> no single valid one?
>
> The server does NOT fail the WS connection upon encountering the first
> invalid PMCE in the list of offers?
>

Yes. As far as there's no WebSocket-core-protocol-level grammar error
(extension-param ABNF in RFC 6455), the server doesn't have to fail the
connection.


>
> 4)
> """
>   A client MUST _Fail the WebSocket Connection_ if the server accepted
>    a "permessage-deflate" offer with a response meeting any of the
>    following condition:
>
>    o  The response has any extension parameter not defined for use in a
>       response.
>
>    o  The response has any extension parameter with an invalid value.
>
>    o  The response has multiple extension parameters with the same name.
>
>    o  The client doesn't support the configuration the response
>       represents.
> """
>
> This list does not include: "The response corresponds to a PMCE
> configuration not offered by the client originally".
> Is this on purpose?
> (A client may support a configuration which it did not offer .. for
> whatever reasons)
>
>
Yes. To allow multiple offers but make it unnecessary to identify accepted
request (e.g. we need to attach request ID or something to each extension
entry to do that), I made permessage-deflate responses self-contained (both
client side parameters and server side parameters are listed in a response).

Each extension has sole discretion to consider what response to be
invalid/unsupported.