I certainly understand that an independent wrapping mechanism would provide
more generality, but I am a little concerned that CMS may not be as widely
adopted as some might hope, whereas implementing it within a crypto algorithm
would allow SSL, TLS, PSEC, etc., etc., to implement it within their suite of
supported algorithms.
I think this one's already been addressed in a previous message.
Also, don't some/most compression algorithms make use of previously
calculated symbol tables? Couldn't those tables be transferred and referred
to independently, rather than being sent with the text, assuming they are
reasonably constant?
This might argue that some parameters to the compression algorithm wold be
nice to have.
zlib uses semi-adaptive Huffman coding for statistical compression and LZ77
for dictionary compression, the codeword tables[0] are stored in a compressed
format[1] at the start of the data. They're built by scanning the data and
building a fixed tree for each data block with more or less fixed statistics,
so there are no pre-calculated tables. zlib does contain provisions for pre-
computed dictionaries (you can seed the model used by the compressor with data
you know will appear in the data to be compressed), but it's complex to manage
and doesn't have much effect unless you're sending very small messages. I
don't know of anything which uses it, it isn't worth the effort and
complexity.
Peter.
[0] Strictly speaking the Huffman tree.
[1] Actually the tables aren't stored in any kind of form, what's stored is
the information required to reconstruct a canonical Huffman tree by the
decoder.