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) <[email protected]> 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:[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]> > 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
