[hybi] Feedback on draft-ietf-hybi-permessage-compression-08.txt

Dario Crivelli <dario.crivelli@lightstreamer.com> Thu, 04 April 2013 16:27 UTC

Return-Path: <dario.crivelli@lightstreamer.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 B3D4B21F8CBE for <hybi@ietfa.amsl.com>; Thu, 4 Apr 2013 09:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.483
X-Spam-Level: *
X-Spam-Status: No, score=1.483 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlSUrqWqxdt5 for <hybi@ietfa.amsl.com>; Thu, 4 Apr 2013 09:27:23 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1E21F8BEA for <hybi@ietf.org>; Thu, 4 Apr 2013 09:27:23 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id ez12so4892382wid.12 for <hybi@ietf.org>; Thu, 04 Apr 2013 09:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightstreamer.com; s=google; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:cc:content-type; bh=Xq/aBIhN8NjR67KwTH0xq3XwoRZWzAGjLz2vRpP3Rz8=; b=HMt8kVJKzONT/axzwLfnLMcLsX14VftCh8im5sWouWCniPY7lmiTqJ9bCbGQy1Sfd5 gPzxvOqyxP63kRxoZmLa47Ux46X4VDqjhkM0r/ipwgITRaJ6IrbH/aNd0gAVp/E4kVAN 9SbYlg2mTK6qBN05XAy0FYrA82CPyCITzB7p0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Xq/aBIhN8NjR67KwTH0xq3XwoRZWzAGjLz2vRpP3Rz8=; b=EmJF6djdDCTusbca+vxr/XPFaoSPb9kUb47kc0ZVQUD7APqJ+YFgBQDjcH9u9gzv44 IvTCQaRuyTNSWeFH5Np6xWPMa53CdqyLM935qIsx7Vr5gN/GPPy3yNJL2Y5umTG6mi3e +06f+1H5pTYXijpQgdMt1ntGD9Hf1A83L+agykUU6fNr9n5z6WiuuHe7LawxXY2mgVZ5 1pLJFDZV2toFnzauq50D+112jBQnfH4io3v8ComH8hj6I+INJ3Czh4bsJocPE/ZY+5yO Wkp9j+IVGohUIQS+C1HoLFYasFdGPt/3DeBM4km9lD7d3To6vjHdr2KmEHs6DcF1hQbT RnXw==
X-Received: by 10.180.97.233 with SMTP id ed9mr30438157wib.32.1365092842243; Thu, 04 Apr 2013 09:27:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.104.199 with HTTP; Thu, 4 Apr 2013 09:27:02 -0700 (PDT)
X-Originating-IP: [2.238.52.66]
From: Dario Crivelli <dario.crivelli@lightstreamer.com>
Date: Thu, 04 Apr 2013 18:27:02 +0200
Message-ID: <CAPwYjpku_sw9FKZWEX3nh7xw1FTPpGP8qEDrTD4zGFGFHOhT3Q@mail.gmail.com>
To: tyoshino@google.com
Content-Type: multipart/alternative; boundary="f46d044306aaf29c6204d98b71a8"
X-Gm-Message-State: ALoCoQlKGhdF3QZOnekJcjsIgX19H5Jiyz1L7M/q8mtoOFag7eBIYAxLenv2ltrIZXkDde6cpN6v
Cc: hybi@ietf.org
Subject: [hybi] Feedback on draft-ietf-hybi-permessage-compression-08.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, 04 Apr 2013 16:27:24 -0000

Hi Takeshi,

Please consider the following feedback.

In your changes in 6.2.3.2, upon the second occurrence of
    If the "agreed parameters"
you should have written: "don't contain".

The general matter of extension chaining also affects paragraph 6.3:
If I understand correctly, you say that an intermediary may add or remove a
DEFLATE extension on the fly.
Do you mean that this is allowed also when other extensions follow the
DEFLATE?
Even if this implies unwinding those extensions first, then applying them
back?

By the way, I see that the note on intermediaries is expressed in terms of
PMCEs, but it lies within the DEFLATE chapter.
Do you confirm that it is not there by mistake?

At the beginning of chapter 5, you say that
    PMCEs operate only on non-control messages
but RFC 6455 only introduces control frames, not control messages.
I see "non-control messages" also written in RFC 6455 on page 34; I suppose
that even that one is a case of improper denomination.

After that, in draft 08 you have added:
    PMCEs operate only on the payload data portion and the "Per-message
Compressed" bit
But the last part seems to me too strong and in contrast with what you
answered me a few weeks ago;
I report the relevant part below:
Q: For instance: can a future extension belonging to this set [i.e. the
PMCEs] also reserve the RSV2 bit?
A: It may though it needs to be discussed and registered with the registry.

Regards
Dario Crivelli





> ------------------------------
>
> Message: 3
> Date: Mon, 01 Apr 2013 07:44:39 -0700
> From: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
> Cc: hybi@ietf.org
> Subject: [hybi] I-D Action:
>         draft-ietf-hybi-permessage-compression-08.txt
> Message-ID: <20130401144439.25672.99712.idtracker@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> 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           : Compression Extensions for WebSocket
>         Author(s)       : Takeshi Yoshino
>         Filename        : draft-ietf-hybi-permessage-compression-08.txt
>         Pages           : 23
>         Date            : 2013-04-01
>
> Abstract:
>    This document specifies a framework for creating WebSocket extensions
>    that add compression functionality to the WebSocket Protocol.  An
>    extension based on this framework compresses the payload data portion
>    of non-control WebSocket messages on per-message basis using
>    parameters negotiated during the opening handshake.  This framework
>    provides a general method to apply a compression algorithm to the
>    contents of WebSocket messages.  For each compression algorithm, an
>    extension is defined by specifying parameter negotiation and
>    compression algorithm in detail.  This document also specifies one
>    specific compression extension using the DEFLATE algorithm.
>
>    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-permessage-compression
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-08
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-08
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>