Slava Kavsan <bkavsan@ire-ma.com> wrote:
> We discovered some Deflate implementation differences that control the
> inclusion of the Deflate
> header and Adler32 checksum. RFC2394 makes no mention of the Deflate
> header or Adler32 checksum . These items are redundant in the case of
> IPCOMP.
Avram Shacham <shacham@cisco.com> wrote:
> In order to keep the advantages of using a well-known algorithm ID,
> I'd suggest (a) modifying RFC2394 to dictate a unified approach,
> or (b) creating multiple DEFLATE IDs in the DOI, one for each option.
>
> avram
Here's some opinions as a recent IPCOMP/DEFLATE implementer who has never
looked at a line of zlib code, to my knowledge....
I found the RFCs 1951, 2393, and 2394 sufficiently detailed enough to
code an IPCOMP/DEFLATE implementation that I expect to have
interoperate. I found few ambiguities, though I won't be surprised to
find I have a few bit-ordering problems to straighten out once I get to
do interop testing with other vendors.
I'd support an "implementation hint" addition to the deflate RFC for
those who are using zlib, if that consists of some instruction on how
to configure/invoke zlib properly so IPCOMP implementations
interoperate. But I don't think in any way that the RFC should imply
that zlib, a particular implementation(?), is a requirement or even an
IETF recommendation. Just an implementation hint.
I sure would rather avoid having multiple flavors of DEFLATE algorithm
ids in the DOI unless someone has a compelling argument for it.
I saw no mention (like Slava) in the above RFCs of the "Adler32
checksum" or "deflate header" mentioned at the start of this thread.
Frankly I'm at a loss as to how we could permit these to be used,
whatever they are, in an interoperable procotocol if the only
"documentation" of them exists in a particular (zlib?) implementation
and not in the compression working group's standards-track documents or
references to other IETF-controlled documents. Have I misunderstood
something or missed a vital RFC??
Based on the above terms, and prior discussions in this thread, it
sounds like the "Adler32 checksum" is something that would be redundant
with IPSec authentication or perhaps even stock ULP checksums. As far
as a "deflate header", RFC 1951 clearly spells out all the "header"
which a set of DEFLATE compressed data needs. And thats only 3 bits
total to convey "final block" and which type (1 of 3) DEFLATE
compression block follows next.
As far as I can tell from RFC 1951, a receiver's DEFLATE decompression
should be totally independent of any "parameters" to a sender's DEFLATE
compression. The only implementation-specific parameters a compressor
should have is how hard it works to achieve its compression, all
symbols emitted should be decompressable. Geesh, DEFLATE even allows
the sender to send the particular Huffman tree it used for its
compression on a particular stretch of data! (Not that I'd expect to
see that much on short packets. :-) )
Is there anyone who sees a need for these extra items to be calculated
and sent in IPCOMP/DEFLATE? Is there some "magic" being conveyed
between compressing/decompressing zlib implementations that needs to be
sent over the wire? I sure hope (not having used zlib, :-) ) that this
isn't the case...
-- Marc --