[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Minimum IP Compression Algorithm for Interoperability
>>>>> "Mason," == Mason, David <David_Mason@nai.com> writes:
Mason,> Bronislav also brought up the following point found at the
Mason,> last bakeoff that most implementations were using the less
Mason,> efficient Deflate (header and Alder checksum) method and not
Mason,> using the undocumented feature of the Zlib that avoids that
Mason,> overhead. I don't believe this mailing list ever resolved
Mason,> this Deflate issue.
Mason,> If I recall it was suggested that the header and Alder
Mason,> checksum would be included if the IPCOMP_DEFLATE transform ID
Mason,> was used as it is currently specified in the DOI (rfc2407)
Mason,> and that a new transform ID would be allocated to specify
Mason,> Deflate without the header and Alder checksum.
Hm, I don't remember a specific conclusion but Slava commented that
the extra stuff is redundant and/or not relevant to IPcomp.
So why retain it? It seems more straightforward to clarify the
description to say that the existing ID means "Deflate without that
overhead".
Unless there's a good reason why it's useful to have a variant with
those headers, let's not create a new ID and not define a variant that
comes with that overhead.
paul
PS. Shouldn't the Deflate RFC be standards track? It seems odd to
have the IPcomp spec be standards track but no compression algorithm
that it needs be on that track.
References: