Blake:
I wonder if we could not close off the "CompressedData" discussion
simply by adding a few word (e.g. "...and compression, see RFC3274" )
reference to RFC3274, Peter's compression rfc, to Section 2.5.2 of MSG
(and adding RFC3274 to the list of references)?
If 2.5.2 is updated to address the preferBinaryInside issue maybe now is
the time to do both (especially since both are aimed at reducing
messaging overhead).
CompressedData use is listed as an outstanding issue for MSG in the
recent IETF WG meeting minutes:
http://www.imc.org/ietf-smime/mail-archive/msg01339.html
It has also been raised in three threads on this list:
http://www.imc.org/ietf-smime/mail-archive/msg01295.html
http://www.imc.org/ietf-smime/mail-archive/msg01172.html
http://www.imc.org/ietf-smime/mail-archive/msg01241.html
With respect to the order of compression and signing: For receivers it
has been pointed out that the encoding unambiguously indicates the order
upon receipt. Thus it would appear that no new mechanism is required to
ensure interoperability (providing the receiver can process the entities
in either order, and I THINK this what is implied by the current text).
With respect to whether the sender should sign or compress first: Some
applications will prefer signing first (sign-what-you-say, e.g. to meet
EU or other "directives" interpreted to require signing before
compression) and others will prefer compression first (signing the
compressed version, e.g. for processing efficiency or as would be
required if lossy compression were to be used). I suggest we dodge this
bullet by arguing that this is an application issue best left to
mechanisms (if needed) outside s/mime.
Adding a reference to RFC3274 would emphasize RFC3274's use of
corresponding compression algorithm OID(s) as an sMIMECapability to
specify receiver compression capabilities. Hopefully this will promote
the implementation of compression which will reduce message overheads
benefiting mail system operators and users accessing e-mail over low
bandwidth channels.
tony
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Tony Capel
Sent: July 9, 2002 10:24 AM
To: 'Peter Gutmann'; Francois(_dot_)Rousseau(_at_)CSE-CST(_dot_)GC(_dot_)CA;
blake(_at_)brutesquadlabs(_dot_)com; ietf-smime(_at_)imc(_dot_)org;
rhousley(_at_)rsasecurity(_dot_)com
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
Peter,
many of us like your compression addition and would like it widely (if
not ubiquitously!) implemented.
One perceived barrier to the adoption of s/mime is the expansion of
message size due to the repeated application of transfer (base64)
encoding at each wrap. Messaging system operators become alarmed when
told message sizes may more than double as a result. (Indeed the NIST
draft profile depreciates such coding of inner wraps to address this
issue.)
The ability to offer compression also addresses overall message
expansion and will be an important capability to offer in compensation
when "marketing" the adoption of s/mime by large organizations.
Tony Capel
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Peter
Gutmann
Sent: July 9, 2002 4:49 AM
To: Francois(_dot_)Rousseau(_at_)CSE-CST(_dot_)GC(_dot_)CA;
blake(_at_)brutesquadlabs(_dot_)com;
ietf-smime(_at_)imc(_dot_)org; rhousley(_at_)rsasecurity(_dot_)com
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
"Blake Ramsdell" <blake(_at_)brutesquadlabs(_dot_)com> writes:
I didn't see much uptake on this besides Russ saying "MAY", and I'm
worried
about compatibility. I will put a slide in my presentation about
this
for
Yokohama.
AFAIK the major use at the moment is in EDI environments (large,
highly-
compressible messages, and everything is "by prior arrangement"
anyway).
There
are a couple of apps which support it out there though, so having it
mentioned
would be nice just to let implementers know it's there.
Peter.