[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TO COMPRESS OR NOT TO CMPRS (please reply)
It was (is?) my impression the question was whether
compression is optional or not at all, though at times I was
confused because the discussion appeared to boarder
mandatory inclusion. Thanks for clarifying.
I am not in a position to say where compression does and does not
belong. I find all of the points for and against compression
interesting, enlightening (for me), and with merit. However,
I believe a facility should be provided within the spec so the
value of compression can be evaluated and empirical data
gathered for future analysis and protocol development. My
vote, for what it is worth, is inclusion.
If you folks will indulge me, perhaps off-line, many on this
list spoke of wasting CPU cycles compressing the
uncompressible. I have seen only a brief discussion on wasting
CPU cycles encrypting the encrypted. An example is encrypting
SSL traffic that may or may not be strongly encrypted, or not
encrypted at all. Certainly there is reason to insure via IPsec
that traffic as well as other secured application traffic
(e.g., snews, klogin) is strongly encrypted; however,
encrypting the encrypted, I believe, not only wastes CPU
cycles but (if I understand things correctly) can weaken
overall data confidentiality. Comments? How is compressing
the uncompressible a worse waste of time?
-dpg
References: