Compressed Data within an Internet Electronic Data Interchange (EDI) Message
draft-ietf-ediint-compression-12

This inherits some fairly serious security considerations.
Specifically, it uses RFC 3274, a standards track document that
creates another back-channel to transport phishing and virus messages
past common-use spam and virus filter technology.

Section 7, the sentence "is free of any intellectual property
restrictions" seems to be taking a position regarding the validity 
and scope of IPRs -- please remove.

The MIME entity example in Section 2 isn't actually a well-formed
XML document (a well-formed XML document contains at least one
element).

Is the base64-encoded example in Section 2 actually valid?  (I tried
base64-decoding and parsing the DER, but the DER parsing failed around
byte 50 -- I might be doing something wrong, though.).

Section 7, "The worst case scenerio is an expansion of 5 bytes per 32K
byte block." This expansion is for the DEFLATE algorithm; it doesn't
include the overhead from ZLIB header or RFC 3274 structures (which
for small documents, could be much more).

Section 8: 
>  [..] except for the fact that compressing data before encryption
>  can enhance the security by reducing redundancy of the file. The
>  lower the redundancy of the plaintext being encrypted, the more
>  difficult the cryptanalysis, see reference[CRYPTANALYSIS].

I'm not sure if all security experts would agree on this (if the
encryption algorithm is good, compression won't enhance it -- and if
it's horribly broken, it's not clear that compression would enhance
anything, either), and the cited reference [CRYPTANALYSIS] doesn't
seem to claim anything like this. I'd suggest just removing this text.