Brotli Compressed Data Format
draft-alakuijala-brotli-11

Agree with Stephen's point about the IPR declaration.

Has there been an answer to the question in Paul Kyzivat's Gen-ART review about whether this draft is the authoritative specification?

Two valid questions asked by Dan Romascanu in his OPS DIR review:

I believe the document is 'Almost Ready' for publication. I am no expert in compression, but my impression is that the document is clear and precise in defining the algorithm and the flow of operations on compression or decompression. From an operational point of view I have however two reservations:

-          There is no justification of any kind (mathematical proof, measurement results, etc.) that supports the claims that the performance resulting from the application of the algorithms results in ‘with an efficiency comparable to the best currently available general-purpose compression methods’. Even so, if the resulting performance is only ‘comparable’ with existing methods, why define a new one and publish it in an RFC?

-          There is no information or recommendations about the applicability of this format (what type of platforms, or network protocols) or documented results of its deployment – when should a software developer use it? Where should a network operator or IT manager apply it or activate it if available?

For what it is worth, I do believe words in the document to the effect that the specification is intended to be complete and sufficient for implementing the format would be helpful.

dan romascanu performed the opsdir review.

I agree with Stephen's comment requesting more references in the security considerations section to help readers/implementers.

- The IPR declaration confused me a bit. Do we know if it
is saying that any implementation of the RFC for any
purpose is RF or if it only means that RF applies to W3C
stuff? (What's confusing is the last bit where it says
the company "provides a W3C RF commitment" which is just
a bit of an odd thing to see in an IETF IPR declaration.)
Note: I think this is ok, as-is, but it's not entirely
clear to me. If the folks who made the IPR declaration
wanted to clarify that might be good, but I don't think
it's absolutely needed.

- The security considerations could do with some more
references, at least one to a zip bomb and one to the
crime attack. I think those would help some
readers/implementers get the issues better.

- I think it'd have been good to add a section on when
the authors think it's a good and bad idea to use this
algorithm.  For example, would it make sense to ever use
this for arbitrary (but not random) binary data? I don't
mean a full analysis, but just some basic guidance. Not a
big deal, but including that might avoid some repetition
later on, esp if there are places where we know now that
one ought not use this.

- I agree with Alexey's discuss point #1.