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

Takeshi Yoshino <tyoshino@google.com> Thu, 13 June 2013 16:22 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 4A86521F9944 for <hybi@ietfa.amsl.com>; Thu, 13 Jun 2013 09:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 atSJGIkIrH8Y for <hybi@ietfa.amsl.com>; Thu, 13 Jun 2013 09:22:57 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7F21F9695 for <hybi@ietf.org>; Thu, 13 Jun 2013 09:22:55 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f11so294742wgh.15 for <hybi@ietf.org>; Thu, 13 Jun 2013 09:22:54 -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=SmS4dxizKtUA164kz1Iz/hkbEYOBaBjMZ0jvKUKjG/c=; b=L6bynUP0dIE2rvs4tFnN8C3ckOjbUdGeXR+/b9IHO2hbzOByMMYjgm9ecxhoE/pSEd wMwxnmBbWYflPNio0puCNOMPwqamOETWyrWXR5B8Oeq4LWErpwRGiNUiJ2Imy2m6gaCf OWfn53iMuVNDZKaNdo8EbGuD+4coIctzT0Xy4Iwe5uAf3JYc+SEmi1TE6HXYIs4TxrBb abqI4pD0kPK/gq6rB8FmhgdYWyainLGPXDWydBamkSnCvLlR13ewpGVuN2lvTCMcMN+x 4gtwwK1UfmCZxCMe8SvUVR68Sy0T19yi9+UVyfiFZmE0AcSjBMq4EOqNTGDY0a/04qYI Diow==
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=SmS4dxizKtUA164kz1Iz/hkbEYOBaBjMZ0jvKUKjG/c=; b=oyYO1rnEyQK1hU3/7dZ/ZzhEQcNODxpjoIJzuSNnCb7Sm8Y4nSClmAEAjhIDdhyq6b kcCTKYudBAD6dyopTHdSuaIUwgVtUTWtKYR42ZeWlJ7ou9dH4ERX4ntgkgrkfQAI/5e6 9YBta1OguW5yw4rOAnTCYJotsD389kuhdpQ05yTQo0k5TiD4KDnc7g6htorRfCH+tEf0 AWpZ+a2dqfpy2A4EL3ZfA788zLGLOBY8qA5XaiNePbWd976uXs5+//lMh8c39t0nCWn9 Vkeq1WGyjM2AtEDm7QszlfdRxxG9qp2EzjeKRHjARTAru0KnWfPWG60nKmCTPMg2kCG9 jTwA==
X-Received: by 10.180.36.12 with SMTP id m12mr1063070wij.10.1371140574754; Thu, 13 Jun 2013 09:22:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.25.230 with HTTP; Thu, 13 Jun 2013 09:22:33 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D4422DC213DF@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> <CAH9hSJbbFYL3TTo3YH2stF78qnxDd1EQe8HYOiV9rz3b+6fpvw@mail.gmail.com> <634914A010D0B943A035D226786325D4422DC213DF@EXVMBX020-12.exch020.serverdata.net>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 14 Jun 2013 01:22:33 +0900
Message-ID: <CAH9hSJaZqa9wJz5S+H0CWwvZBbj243ZfGCKT9zyBArUjimqzFg@mail.gmail.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=e89a8f5030ace5588804df0b8aa4
X-Gm-Message-State: ALoCoQm0e1ezKobzGUMKPOpMfrn/jNfhIb07jPadtSEThjXCi7SjriNM0IIkHmn5bhjEx6ciSQz3whwicPA5bb0iZJaSTskBiZCiJ7EKXiR3vXX6QF+DGpgJ/3Jyt84Ai/xr8YNCGADdnyg42DjGXqWVOPRc/kD9+o4HTAPIeaOgl8k1ubstLoRA0LR4g02aVbPhqmbx09F2
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: Thu, 13 Jun 2013 16:22:58 -0000

On Tue, Jun 4, 2013 at 9:20 PM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> "doesn't have to fail" ..
>
> So a server MAY fail the handshake instead of just skipping bad offers?
> Confused.
>
> At least for me I have troubles with the word "decline" in "A server MUST
> decline .."
>
> a) decline = silently skip
>
> OR
>
> b) decline = fail handshake
>
> ?
>
>
I meant a). As far as the Sec-WebSocket-Extensions header value conforms to
the grammar for it and the server doesn't include a reply for it, there
should be no problem.

But I'm also fine with b).


> I'd prefer b) - why be too liberal here - , but am ok with a) also .. but
> please consider defining "decline" in the text.
>
> Sorry: maybe it's just me, but I was really spending time with above
> question ..
>
>
Sorry about that.


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

Sorry. Let me correct this:
s/Each extension/The client/.


>
> Lets say a client supports all features, but offers
>
> permessage-deflate; s2c_max_window_bits=10
>
> (hence, no fallback)
>
> and the server responds:
>
> permessage-deflate.
>

This is bad response. Servers MUST not generate such a response.

But if the client can and wants to accept the response, we don't have to
stop it.

I remember the rationale based on which we made RFC 6455 to enforce servers
to reject frames w/o masking. Enforcing receiver to ban bad-mannered data
can work as some pressure to server implementors to conform to the server
requirements.

>From this point of view, I agree with you.


>
> Autobahn client will FAIL that, since the PMCE response from the server
> does not match any offer, despite the reponse PMCE is supported.
>
> If it would accept that, why would there be a need to offer explicit
> fallbacks like
>
> permessage-deflate; s2c_max_window_bits=10, permessage-deflate
>
> ?
>
>
A server conforms to the spec (requirements for servers) responds with
"permessage-deflate" to this request, but doesn't for "permessage-deflate;
s2c_max_window_bits=10".

So, the client needs to send this.

Sorry that my last response was unclear and misleading.