Congratulations. We've reinvented the OSI Presentation layer. :-|
Kidding aside. This requirement (?) has also been discussed in the context
of X.400, but it has never motivated anybody enough to make it happen. My
feeling is that RFC 2616 took basically the right approach, though.
What we are sorely in need of are some standardized IETF middleware
applications that do things like compression, digital signature, etc. for
any client application. There are a number of good models for this that
could be drawn on. However, I don't think that this will happen until a
critical mass of people get fed up with solving every problem n times (for n
| International Electronic |
| Communication Analysts, Inc. |
| Christopher D. Bonatti |
| Principal Engineer |
| bonattic(_at_)ieca(_dot_)com |
| Tel: 301-208-2349 |
Larry Masinter wrote:
Is there an RFC (or movement toward one) for a compressed encoding
There seems to be a lot of interest lately in compressing attachments.
End users are encouraged to zip Office files before mailing them,
and at least one product (MaxCompression) does this automatically
(in a proprietary way.) Even with modem compression, there seems to
be some gain from this, and the disk storage implications on the mail
server are also interesting.
It seems that a new MIME standard for content-transfer-encoding that
would indicate a compressed base64 type ala gzip could be nice.
Creative minds might even improve the efficiency of base64 at the
same time, if we don't have to worry about translation into EBCDIC
HTTP (RFC 2616) added a different transformational layer
(Content-Encoding) to avoid combinatorial explosion with different
transfer-encodings (transfer-encodings were also kept distinct
from content-transfer-encodings). Valid content-coding tokens
include "gzip", "compress" and "deflate".
It might be possible to extend Content-Encoding to work with mail.
And if you want to avoid Base64 in mail, well, there's BINARYMIME