ietf-smtp
[Top] [All Lists]

RE: compressed content-transfer-encoding?

1999-07-29 02:34:55
At 11.57 -0700 99-07-27, Larry Masinter wrote:
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".

After thinking more about this, I have come to the conclusion
that compression should be automatic and supported by the
standards. The reason for this is that this will make things
easier for the users. The users need not ever see that information
is compressed during transmission.

The issue is whether compression should be done in the application
layer, with special compression headers, etc., or in lower layers.

For example, and e-mail message is usually forwarded through
at least two store-and-forward MTAs:

Original  ->  Local MTA   ->  Local MTA      -> Final
sender        for sender      for recipient     recipient

With compression in the application layer, an attachment will
be compressed by the original sender, and not uncompressed
again until by the final recipient.

With compression in the transport layer, the attachment
will be compressed and uncompressed for each store-and-forward
step.
------------------------------------------------------------------------
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme