Thanks for the HTTP reference; that's quite helpful. Any view on
whether it makes more sense to mandate gzip versus deflate combined with
a Content-MD5?
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>
-----Original Message-----
From: Adam M. Costello
[mailto:ietf-822(_dot_)amc+0(_at_)nicemice(_dot_)net(_dot_)RemoveThisWord]
Sent: Wednesday, February 26, 2003 17:38
To: ietf-822(_at_)imc(_dot_)org
Subject: Re: gzip-8bit
Lawrence Greenfield <leg+(_at_)andrew(_dot_)cmu(_dot_)edu> wrote:
There's absolutely no reason to bet on probabilities here when
counting the output octets is so easy and guarantees correct behavior
even when faced with a smart adversary.
I agree. Furthermore, I see no need to require any particular algorithm
for choosing the line breaks. Simply require that lines not exceed
998 octets (plus the CRLF). One implementation might count the output
octets in order to wait as long as possible before inserting a line
break. Another implementation might break the input into lines of 499
octets, then escape the octets that need it, which can at worst double
the length to 998. The simpler implementation will have 0.4% overhead
for line breaks instead of 0.2%. Is that enough to warrant disallowing
the simpler implementation? Should we require gzip -9 rather than the
default gzip -6? No, any compression algorithm that produces a valid
stream should be allowed, and likewise any line breaking algorithm that
produces valid lines should be allowed.
By the way, HTTP defines both "gzip" and "deflate" content codings,
where "gzip" is deflate with a gzip header/trailer (RFC-1952), and
"deflate" is deflate with a zlib header/checksum (RFC-1951). The
gzip header contains various meta-info that is not useful in a
transfer-encoding, while the zlib header contains just the minimal
compression parameters needed to interpret the compressed data. You
might consider whether you prefer to define gzip-8bit or deflate-8bit.
AMC