[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Minimum IP Compression Algorithm for Interoperability



>I'd argue that its the more efficient variation that should *remain*
>the official DEFLATE specification for the long-haul and that
>additional transform IDs could be used for the "deflate with additional
>stuff" as a transition aid.  Or the current transform ID's value could
>even become the transitional one, to save the (re)deployment
>heartbreak.  But even if we decided, due to deployed base, to make the
>inefficient version the official DEFLATE its going to require more
>updating/explanation in the existing IPCOMP specs to guard against
>future implementation errors, let alone to properly describe the
>protocol.  The minimal verbiage/procedures supplied by Slava and myself
>in the archives is all that would be needed to warn future implementers
>to do the right thing for the more efficient variation which the specs
>currently describe.

Yes the suggestion was that the current transform ID would become
historical (the transitional one) and that the new transform ID
would be the official one.  The reason for this suggestion was
that many (most/all?) vendors at the last bakeoff that had shipping
products that supported IPCOMP included the header/checksum and that
few (none?) had shipping products that did it the right way.

-dave