[Ballot comment]
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.

[Ballot comment]
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.

I looked at the history of this document, and it was once a product of the EDIINT WG.  It still appears to be a WG document although EDIINT closed about three years ago. 

The first IESG Note in RFC3932 section 4 applies here, because it says this was at one time considered by the IETF. 

I see no reason to recommend against publication of this document.

IESG,

This RFC-to-be was submitted to the RFC Editor to be published as
Informational: draft-ietf-ediint-compression-11.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Four week timeout expires on 30 June 2008.

Compressed Data within an Internet EDI Message

This document explains the rules and procedures for utilizing
compression (RFC 3274) within an Internet EDI (Electronic
Data Interchange) 'AS' message, as defined in RFCs 3335, 4130,
and 4823.

This document was reviewed by the RFC Editor and by Jim Schaad,
with additional input from Harald Alvestrand, and the document
was updated to meet all reviewer recommendations.