Hi, Thank you for addressing my comments and clarifying the issues.
I am fine with the proposed resolutions. Regards, Dan From: Takeshi Yoshino [mailto:[email protected]] Sent: Tuesday, June 23, 2015 9:52 AM To: Barry Leiba Cc: Romascanu, Dan (Dan); General Area Review Team; [email protected] 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 <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
