I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please treat these comments just like any other
last call comments. For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-alakuijala-brotli-08
Reviewer: Paul Kyzivat
Review Date: 2016-02-23
IETF LC End Date: 2016-04-08
IESG Telechat date: 2016-04-21
Summary:
This draft has serious issues, described in the review, and needs to be
rethought.
Major: 1
Minor: 0
Nits: 0
==========
(1) Major:
In my opinion this document does not satisfy the purpose given in
section 1.1 for the type of reader identified in section 1.2.
I spent many hours trying to decipher the document, but ultimately
failed. (I have no experience in implementing compression/decompression
algorithms, but I have many decades of programming experience including
that involving detailed bit manipulation and data representation.)
If two expert programmers were asked to independently build
encoder/decoders in accord with this document, IMO it would be
incredibly unlikely (impossible) that the resulting programs would be
interoperable. And given the complexity of the encoding it would also be
extremely difficult to figure out *why* they didn't interoperate.
My sense from reading this document is that the format is operationally
defined by an existing program (https://github.com/google/brotli) and
that this document is an attempt to re-render the source code in
English. However the algorithms being described are so complex that
English (at least *this* English) is inadequate for the job.
I started out making notes about particular places where I found the
language confusing or ambiguous. But there were so many that I
ultimately gave up.
I have serious doubts that the goal of this document achievable using
natural language text. I don't have much of an idea of what to try to
achieve this. It will take much more than just patching the current
document. If possible at all it will require a vastly different approach.
To achieve the goal of having a specification independent of a
particular implementation it may be necessary to abandon backward
compatibility with *this* implementation. (I recognize that doing so may
be unacceptable.)
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
