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

From: Dario Crivelli <[email-masked]>
Date: Thu, 4 Apr 2013 18:27:02 +0200

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: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Subject: [hybi] I-D Action:
>         draft-ietf-hybi-permessage-compression-08.txt
> Message-ID: <[email-masked]>
> 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 [email-masked] 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/
>
>
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 25 Apr 2013 19:03:17 +0900

> you should have written: "don't contain".

Oh, right. Fixed.

> If I understand correctly, you say that an intermediary may add or remove
> a DEFLATE extension on the fly.
>

Yes. Not per message but per connection.

> Even if this implies unwinding those extensions first, then applying them

Yes.

> Do you confirm that it is not there by mistake?

Good catch. Yes, that's just my mistake. Left some note specific to
permessage-deflate and added a higher level section with more general note.

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

Right. Replaced with non-control frames.

> A: It may though it needs to be discussed and registered with the registry.

I see. Removed the sentence and added "If the extension expects frames as
input, build a frame for the message and pass it." to the paragraphs
talking about connection to the subsequent extension instead.