Skip to main content

Compressed Data within an Internet Electronic Data Interchange (EDI) Message
RFC 5402

Revision differences

Document history

Date Rev. By Action
2021-04-06
12 (System) Received changes through RFC Editor sync (added Errata tag, added Verified Errata tag)
2015-10-14
12 (System) Notify list changed from ediint-chairs@ietf.org, harald@alvestrand.no, draft-ietf-ediint-compression@ietf.org to ediint-chairs@ietf.org, harald@alvestrand.no
2010-02-08
12 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-02-08
12 Cindy Morgan [Note]: 'RFC 5402' added by Cindy Morgan
2010-02-08
12 (System) RFC published
2008-10-29
12 (System) IANA Action state changed to No IC from In Progress
2008-10-29
12 (System) IANA Action state changed to In Progress
2008-08-27
12 (System) New version available: draft-ietf-ediint-compression-12.txt
2008-07-01
12 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-06-27
12 Amy Vezza IESG state changed to Approved-announcement sent
2008-06-27
12 Amy Vezza IESG has approved the document
2008-06-27
12 Amy Vezza Closed "Approve" ballot
2008-06-19
12 Cindy Morgan State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan
2008-06-19
12 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-06-19
12 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-06-19
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-06-18
12 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-06-16
12 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-06-16
12 Chris Newman
[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 …
[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.
2008-06-13
12 Pasi Eronen
[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 …
[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.
2008-06-13
12 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-06-03
12 (System) Ballot has been issued
2008-06-03
12 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded by Lisa Dusseault
2008-06-03
12 Lisa Dusseault Created "Approve" ballot
2008-06-03
12 (System) Ballot writeup text was added
2008-06-03
12 (System) Last call text was added
2008-06-03
12 (System) Ballot approval text was added
2008-06-03
12 Lisa Dusseault State Changes to IESG Evaluation from AD Evaluation by Lisa Dusseault
2008-06-03
12 Lisa Dusseault [Note]: 'RFC3932 section 4 item 1 is the appropriate IESG note for this document' added by Lisa Dusseault
2008-06-03
12 Lisa Dusseault
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 …
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.
2008-06-03
12 Lisa Dusseault State Change Notice email list have been change to ediint-chairs@tools.ietf.org, harald@alvestrand.no, draft-ietf-ediint-compression@tools.ietf.org from ediint-chairs@tools.ietf.org, draft-ietf-ediint-compression@tools.ietf.org
2008-06-03
12 Lisa Dusseault State Changes to AD Evaluation from Publication Requested by Lisa Dusseault
2008-06-03
12 Lisa Dusseault Responsible AD has been changed to Lisa Dusseault from Russ Housley
2008-06-03
12 Cindy Morgan
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 …
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.
2008-06-03
12 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-05-05
11 (System) New version available: draft-ietf-ediint-compression-11.txt
2008-03-25
10 (System) New version available: draft-ietf-ediint-compression-10.txt
2007-07-23
09 (System) New version available: draft-ietf-ediint-compression-09.txt
2007-06-11
08 (System) New version available: draft-ietf-ediint-compression-08.txt
2007-05-31
07 (System) New version available: draft-ietf-ediint-compression-07.txt
2007-01-17
06 (System) New version available: draft-ietf-ediint-compression-06.txt
2005-08-16
05 (System) New version available: draft-ietf-ediint-compression-05.txt
2005-01-31
04 (System) New version available: draft-ietf-ediint-compression-04.txt
2004-02-03
03 (System) New version available: draft-ietf-ediint-compression-03.txt
2003-03-28
02 (System) New version available: draft-ietf-ediint-compression-02.txt
2003-01-29
01 (System) New version available: draft-ietf-ediint-compression-01.txt
2001-09-25
00 (System) New version available: draft-ietf-ediint-compression-00.txt