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

Re: Deflate issue



 > 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
 > 

Given the above comment about "rubbish" and the fact that "Deflate
header" and Adler32 are not mentioned in any current IPCOMP working
group direct document references (except indirectly through the mention
of ZLIB) why would we want to proliferate more choices for no (as of
yet) cited benefit?  Can the vendors who interoperated with these
additional deflate header/Adler32 "artifacts" cite any benefits to
their usage in IPCOMP that they've discovered?

I'd say that we should retain just the single current IPCOMP/DEFLATE
DOI id to define DEFLATE without the above artifacts.  Just as the RFCs
1951, 2393, and 2394 specifically describe, and which are all directly
referenced or products of the IPCOMP working group's output.  Sticking
with these RFCs only would mean no disruption of the IPCOMP standards
progress to full standards, if my understanding of the process is correct.

Admittedly there may be some folks who are interoperating already with
these apparently-zlib artifacts and it would be a shame to needlessly
"break" them.  But an earlier E-mail seemed to suggest it was pretty
trivial to eliminate these zlib features.  The compression stuff is
still at an early stage in the standardization process, as these
interops appear to be showing some non-trivial differences in
interpretations of the required compression features/encodings
themselves.  But if these additional artifacts aren't referenced in any
current IPCOMP working group documents, provide no cited benefits, and
are a protocol or computational burden then I think the choice is clear
to eliminate them now.  And just add a warning about avoiding them as
an implementation hint to the current IPCOMP DEFLATE documents.

I wouldn't object, as an aid to current interoperaters with fielded
product, an eventually-to-be-deprecated IPCOMP/DEFLATE DOI id for the
"with rubbish" version that is clearly documented as an "interim" id.
As long as the official/standard one doesn't have the "rubbish"! 

                        
                         
   -- Marc --