RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt

["Hollenbeck, Scott" <[e-mail]>]

>       If an implementation chooses to support compression, then
>       the implementation MUST support the ZLIB compression
>       algorithm.
> 
> Russ

Something to consider: ZLIB (RFC 1950) and DEFLATE (RFC 1951) are NOT the
same thing.  I ran into a small bit of specification confusion (thankfully
caught by Ned Freed) when my TLS compression draft went through IESG review.
It might be worth noting Ned's comments so that rfc2633bis specifies the
algorithm you intend:

"First of all, it is important to realize that RFC 1950 and RFC 1951 specify
two things: (1) A compression scheme and corresponding format called DEFLATE
(1951) and (2) A general wrapper format for compressed data called ZLIB
(1950).
I believe most compression applications simply use the DEFLATE format and
don't
bother with the extra wrapper and most of our specifications that do this
refer to deflate and RFC 1951 rather than zlib and RFC 1950.

This document doesn't follow this approach. Rather, it repeatedly calls
the compression scheme ZLIB and refers to both of the RFCs. Does this mean
this specification actually uses the zlib wrapper? I suspect the answer
is no, and if that's indeed the case, the document needs to be clarified
in this regard. I suggest referring to the scheme as DEFLATE and removing
the reference to RFC 1950 entirely.

If, on the other hand, the intent really is to use the zlib wrapper, then
the specification is incomplete in that ZLIB allows for multiple compression
algorithms, checksumming, and so forth. These various settings would need to
be specified in order to have interoperable ZLIB implementations."

-Scott-