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

Re: Clarification proposal for Deflate RFC

Slava wrote:

 > Roy, all,
 > 
 > Here are recommended changes to rfc1951 "DEFLATE Compressed Data Format
 > Specification":

I support what Slava has suggested but rather than track down all other
usage of rfc 1951 that changing it might effect I'd assume it would be
more appropriate to make his changes to the IP Compression working
group's own document, RFC 2394.  So here's my suggestion.

It would appear to me that his changes would fit into section 2,
DEFLATE Algorithm Implementation, of RFC 2394 just fine.  The current
second paragraph in section 2 of RFC 2394:

   Compression and decompression algorithm details should be followed as
   outlined in [Deutsch96] or the use of a software library may be
   preferable.  Since IPComp is a stateless protocol, history MUST be
   cleared between packets when either compressing or decompressing.

could be modified to read:

   Compression and decompression algorithm details should be followed
   as outlined in [Deutsch96].  Specifically, the compression data
   elements transmitted MUST be confined to those defined in Section 3
   of [Deutsch96].  The use of a software library, such as ZLIB which
   supports a superset of [Deutsch96], may be an appropriate
   implementation mechanism.  See Appendix A for implementation
   suggestions for ZLIB.

   Since IPComp is a stateless protocol, history MUST be cleared
   between packets when either compressing or decompressing.

Slava's Zlib recommendations would go into the new Appendix A.                        
                         
   -- Marc --


 > 
 > Add the following statement at the very end of section 2,
 > Compressed representation overview.
 > 
 > "There must be no additional data sent beyond that described in section
 > 3,
 > Detailed specification. Specifically. neither the library header nor the
 > 
 > Adler32 checksum generated by Zlib must be sent."
 > 
 > Add a new section "Zlib interface recommendations"
 > between the existing section 4. Compression algorithm details, and
 > section
 > 5. References, as follows:
 > 
 > 5. Zlib interface recommendations
 > 
 > The default initialization call to the Zlib implementation of Deflate
 > produces an unnecessary wrapper consisting of a Zlib specific header and
 > 
 > checksum.  If this publicly available implementation of Deflate is used,
 > 
 > then it should be initialized in a manner similar to the following:
 > 
 >   returnCode = deflateInit2_(
 >                 &stream,
 >                 Z_DEFAULT_COMPRESSION,
 >                 Z_DEFLATED,
 >                 -WINDOW_SIZE,
 >                 DEF_MEM_LEVEL,
 >                 Z_DEFAULT_STRATEGY,
 >                 ZLIB_VERSION,
 >                 sizeof(z_stream));
 > 
 > The absolute value of the WINDOW_SIZE argument controls the size of the
 > history buffer used by deflate, in powers of 2 bytes (i.e. WINDOW_SIZE =
 > 11
 > configures a 2048 byte history buffer).  Negating this argument will
 > prevent Zlib from adding the Zlib header or Adler32 checksum.
 > 
 > Likewise, the initialization of the Zlib decompression implementation
 > Inflate should be invoked in a manner to the following:
 > 
 >   returnCode = inflateInit2_(
 >                 &stream,
 >                 -WINDOW_SIZE,
 >                 ZLIB_VERSION,
 >                 sizeof(z_stream));
 > 
 > In this case, WINDOW_SIZE should be 15, permitting the maximum history
 > buffer of 32768.  By setting the argument to -WINDOW_SIZE, or -32768,
 > Zlib
 > will be configured not to expect a Zlib header or Adler32 checksum.
 > 
 > 
 > 
 > --
 > Bronislav Kavsan
 > IRE Secure Solutions, Inc.
 > 100 Conifer Hill Drive  Suite 513
 > Danvers, MA  01923
 > voice: 978-539-4816
 > http://www.ire.com
 > 
 > 
 > 
 >
Follow-Ups: