Russ,
I understand from the Final 29 March 2000 S/MIME WG Minutes that you
mentioned about the issue of a MIME compress data type that Jeff Schiller
recommended that the S/MIME WG "just do it" because the issue needs to be
resolved for efficiency purposes.
There are currently two other Internet Draft were this same issue of a MIME
compress data type has been brought up:
a. The Internet Draft "draft-ietf-ediint-as1-11.txt" about MIME-based Secure
EDI from the Electronic Data Interchange Internet Integration (EDIINT) WG
also has a requirement for a MIME compress data type, but mentions the
following in Section 5.4.1:
"Applying compression before encryption strengthens cryptographic security
since repetitious strings are reduced. This sequence of signature,
compression, then encryption, or compression then encryption, is consistent
with the order in which PGP implementations handle compression.
Note: Compression is done automatically when using PGP encryption.
The MIME standards do not define a way in which to convey that a message has
been compressed. However, RFC2045 does allow the definition of additional
MIME header fields to further describe the content of a message.
RFC2068, the HTTP/1.1 specification does define a Content-Encoding field
that is primarily used to convey compression information:
Content-Encoding = "Content-Encoding" ":" content-coding
where content-coding can take on the values of "gzip" or "compress". The
gzip compression standard is further described in RFC 1952, and compress is
the standard UNIX file compression program. Both gzip and compress are
registered with IANA."
b. The Internet Draft "draft-ietf-avt-rtp-mime-02.txt" about MIME Type
Registration of Real-time Transport Protocol (RTP) Payload Formats from the
Audio/Video Transport (AVT) WG on the other hand is using MIME registration
procedure described in RFC2048 to register MIME subtype names for use with
the RTP [RFC1889], including various data compression formats for audio and
video.
Should not the S/MIME WG just do it and create a standard interoperable MIME
compress data type as proposed by Peter, which could be used by both the
S/MIME WG and the EDIINT WG?
Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau(_at_)chrysalis-its(_dot_)com Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078
-----Original Message-----
From: FRousseau(_at_)chrysalis-its(_dot_)com
[mailto:FRousseau(_at_)chrysalis-its(_dot_)com]
Sent: Tuesday, June 20, 2000 11:04 AM
To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: CMS Compressed Data Content Type
Peter,
Do you plan to update your Internet Draft on the S/MIME compressed data
content type, which expired on April 2000?
I would much prefer having a standard and interoperable way of compressing
data before performing encryption than having a different proprietary
approach from each vendor.
Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau(_at_)chrysalis-its(_dot_)com Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078