[Top] [All Lists]

Re: Massive Content-Type definition ideas & Gopher

1993-06-10 04:17:40
I have seen several suggestions:

Content-T-E: base64; compressor=compress
Content-T-E: compressed-base64
Content-T-E: base64-compressed
Content-T-E: base64/compressed; compressor=compress

There were/are probably others.

IMHO adding compression is an issue that should be dealt with separately
or independently from the Content-Type or Content-Transfer-Encoding,
since it doesn't really have anything to do with MIME data-types or
MIME transfer-encodings.  It is something that we want to do to the
data before encoding it for the wire (for bandwidth/filespace savings)
and needs to be recorded so that the process can be reversed.  So maybe
I missed it; but, what is the problem with adding a Content-Compression:
header with what-ever semantics are necessary to do/undo compression?
If the message has a Content-Compression: header, the message is
DEcompressed after it is transfer-DEcoded.

For example:

  MUA    message_body -> compression -> transfer_encoding -> wire

  1.  The user wants us to compress some content-type using xyz compression
        algorithm (xyz is a registered for Content-Compression use algorithm)
        or using x-xyz because the receiver knows x-xyz compression and can
        deal with it.
  2.  The content-type data is compressed by xyz algorithm compressor.
  3.  We label the Content-Transfer-Encoding as binary if using 8-bit capable
        mail or we base64 the compressed data and label it as base64.
  4.  We send it.
  5.  The reciever gets the message with the
  6.  If the cte is base64, the body is un-base64'ed.
  7.  We examine the Content-Compression header and undo the compression.
        If we don't know how, at least we can allow the user to save it to a
  8.  We display the content-type data as best we can.  If decompression was

Since adding compression is going to break existing applications anyway,  why
don't we do it correctly?

My suggestion is to either add a new message header "Content-Compression:"
or at worst(?) add a "compression=" parameter to the Content-Type header.
Lets leave the Content-Transfer-Encoding meaning what we did to the data
so we could send it, intact.

We also need to consider what happens at gateways when a compressed message
arrives.  Having n! Content-Transfer-Encodings as going to make it less
likely and much more difficult for a gateway to "get it right".


Mark A Keasling                 Twin Sun Inc                        AIR Co. LTD
                        360 N. Sepulveda Suite #2055    Software Development 7F
                            El Segundo, CA 90245        1-3-14 Kitahama Chuo-ku
Email:                         (310) 524-1800                   Osaka 541 Japan
makr(_at_)twinsun(_dot_)com : in the United States                           
(06) 201-4307
makr(_at_)airco(_dot_)co(_dot_)jp : in Japan