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

[Takeshi Yoshino <[e-mail]>]

Thanks. Addressed in -23

Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-23
Summary:
https://mailarchive.ietf.org/arch/msg/hybi/7NxhaWKJaU-qSULQXQ3hnw8peM4

Takeshi

On Tue, Jun 23, 2015 at 3:58 PM, Romascanu, Dan (Dan) <[e-mail]>
wrote:

>  Hi,
>
>
>
> Thank you for addressing my comments and clarifying the issues.
>
>
>
> I am fine with the proposed resolutions.
>
>
>
> Regards,
>
>
>
> Dan
>
>
>
>
>
> *From:* Takeshi Yoshino [mailto:[e-mail]]
> *Sent:* Tuesday, June 23, 2015 9:52 AM
> *To:* Barry Leiba
> *Cc:* Romascanu, Dan (Dan); General Area Review Team;
> [e-mail]
> *Subject:* Re: Gen-ART review of draft-ietf-hybi-permessage-compression
>
>
>
> 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.
>
>
>