[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deflate issue
At 12:10 14.1.2000 -0800, Avram Shacham wrote:
>Slava,
>
>Am I reading correctly that the DEFLATE decompression is dependent
>on the parameters to the compression process, i.e. an extra attribute
>needs to be negotiated in order to enable the decompression process?
>For comparison, afaik, LZS has the capability to decompress a packet
>regardless of the compression parameters.
>
>Your suggestion to negotiate a DEFLATE-specific attribute,
>while doable and supported by the protocol, will have the side-effect
>of excluding that compression algorithm from the list of well-known
>algorithms, as RFC2393 defines:
>
> Compression Parameter Index (CPI)
>
> 16-bit index. The CPI is stored in network order. The values
> 0-63 define well-known compression algorithms, which require no <==
> additional information, and are used for manual setup. The
<==
> values themselves are identical to IPCOMP Transform identifiers
> as defined in [SECDOI]. [...]
The values
> 256-61439 are negotiated between the two nodes in definition of
> an IPComp Association, as defined in section 4. Note: When
> negotiating one of the well-known algorithms, the nodes MAY
> select a CPI in the pre-defined range 0-63.
>
>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
>
We interoperated with several vendor at the San Diego bakeoffs, they
used Deflate header and Adler32. IRE didn't include header and adler32,
so they had loads of problems.
They way I see it, we were all (except IRE) wrong. But changing the
behaviour now
would break interoperability.
I'd request a new ID in the DOI, for "DEFLATE without the rubbish".
Jörn
References: