Re: [Gen-art] Gen-ART review of draft-ietf-hybi-permessage-compression

[Takeshi Yoshino <[e-mail]>]

Thank you for review, Dan.

On Wed, Jun 17, 2015 at 12:08 AM, Barry Leiba <[e-mail]>
wrote:

> Hi, Dan, and thanks for the review.
>
> > I do not know if this is an issue, but I am asking the question. Some
> > implementations are mentioned in the write-up, but they seem to have been
> > written and deployed based on very old versions of the document – 05 and
> > earlier, dating three years back. I am wondering if this is a problem of
> the
> > write-up not being updated. If not – have the changes brought to the
> > document since draft-05 impacted the negotiation and algorithms
> described in
> > the document?
>
> The history here is that the working group sent the document to me at
> version -05, and I reviewed it and sent it back for more editorial
> work -- I found it very hard to read and often unclear.
> Unfortunately, the editorial work took two years and many revisions to
> complete, but I think the result is clear and easy to read, and I'm
> happy with the result.  But that work did not make technical changes
> to the protocol, so implementations of -05 are still implementations
> of -22... unless, of course, they were based on any misunderstandings
> of an unclear document.  I think the likelihood of that last is low,
> because the implementors were involved in the development of the
> document.
>

Here're the non-editorial changes happened since -05:

-10 added hints. This is optional feature. Shouldn't impact
interoperability.

-10 made it mandatory for clients to support client_no_context_takeover (at
this point it was called c2s_no_context_takeover) parameter in an extension
response. This shouldn't introduce any spec issue, I think.

-15 renamed s2c_ to server_ and c2s_ to client_. I think everyone has
followed this change in this 1.5 year.


> On the minor issues:
> I'm ambivalent about changing the "must"s and "must not" to 2119 key
> words.  I think you know that I'm not a fan of overuse of those key
> words.  On the other hand, they do apply fine here as key words, and I
> have no objection to changing them.  I'll leave that up to the author
> and shepherd.
>
> Nits 1 and 2 are correct, and should be fixed; thanks.  For nit 3, I'm
> happy to have the acknowledgments section reflect the author's voice.
>

Changing "must" to "MUST" in Section 5:

>From 2 perspectives, I prefer not to capitalize them:
- (a) These sentences are describing what/how constraints have to be
negotiated for the DEFLATE based compressed communication channel just as
an example.
- (b) These sentences are not explaining requirements that implementors
must follow for interoperability, but just things they have to do to make
DEFLATE based compression/decompression work correctly.

Because of (b), I'd like to keep these "must keep"s uncapitalized. I'm
ambivalent about (a) regarding "MUST" and "may" the following sentences

   In a PMCE negotiation offer, the client MUST inform the server of its
   LZ77 window size so that the server uses an LZ77 window size that is

   LZ77 window size of the client.  In a PMCE negotiation offer, the
   client may inform the maximum LZ77 window size the client can afford

We can consider these to be kind of quotes of conformance requirements.
Actually, we're defining them later in the same doc. So, I'd like to keep
this MUST and change the "may" in the second sentence to "MAY" for
consistency. Does this look good to you?

----

Changing "must not" to "MUST NOT" in Section 8.2.1: Agreed. I'll fix it.

----

Nit 1: Removed the redundant "extension".

Nit 2: Added explanation of the significance of the values 0 and 1 as
follows:

   Meaning
      The message is compressed or not.  RSV1 is set for compressed
      messages and unset for uncompressed messages.

Nit 3: Changed to "Thanks to" as you suggested.