Zoltan,
On 4/12/16 9:17 AM, Zoltan Szabadka wrote:
Thank you for reviewing this internet draft.
We do share your concern that it is very difficult to fully specify a
compressed data format of this complexity using natural language text alone.
To address this concern, the language and style of this internet draft
follows that of RFC 1951, which specifies a compression format closely
related to this one, to the extent that some common parts were taken
over verbatim. Moreover, we worked with three independent software
implementers, who agreed to use only the text of this draft to implement
a brotli decoder and provide feedback on where the text was ambiguous or
unclear.
These independent implementations are the following:
1) C language implementation of Mark Adler:
https://github.com/madler/brotli
2) Rust language implementation of Thomas Pickert:
https://github.com/ende76/brotli-rs
3) Go language implementation of Joe Tsai:
https://github.com/dsnet/compress/tree/brotli
I will grant that these serve as existence proofs that the spec "works",
given sufficient effort.
I'm still concerned, but you can just consider me to be one data point
out of four.
The current -08 version of this internet draft addresses the findings of
these reviews, and we believe that it is possible to decide based on
this draft whether or not an arbitrary sequence of bytes is a valid
brotli stream; and what is the uncompressed sequence of bytes that a
valid brotli stream represents.
As the next step, we plan to update the draft with a section about
considerations for compressor implementations. In this, we will address:
1) Jean-Loup Gailly’s review comment about how it is possible, if
desired, to make a sequence of blocks self-contained in a way that they
can be decompressed independently of previous blocks.
2) The secdir review comments about CRIME and DoS attacks.
We expect to be ready with the next version of the draft in one week.
One thing I realized later is that your draft is *informative*, not
normative. Is that the intent? If so, what *is* normative?
If the *code* is normative, then there is no need to make the text
unambiguous without the code. It might be better to simply rewrite the
text as an explanation of the code.
OTOH, if this is intended to be normative, then it needs to be written
with that in mind, using RFC2119 language, and with "Intended Status:
Standards Track".
Thanks,
Paul
Kind Regards,
Zoltan
On Fri, Apr 1, 2016 at 9:02 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
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
