[Top] [All Lists]

Re: CTE: Compressed-Base64 (Was: Massive Content-Type definition)

1993-06-10 19:06:26

Summary and Strawman Proposal

 Define a single new content-transfer-encoding, compressed-base64.

 This will provide compression for existing 7 bit transport.  Should
 binary transport be widely available in the future, and the need for
 compression be demonstrated in this environment, a compressed-binary
 may be defined later.

Greg, you are really making two proposals (relative to the email
on the list).

1. we should use the CTE field for compression.  I'm on record
   as not favoring this technique because it assumes a single
   (or very small number) of compression values.  Architecturally
   I think this is the wrong answer -- I think one would want
   to use compression (or the generalization of compression --
   a general "filter" field) for any content type, especially
   video, image, or audio.

   Basically, I view the content type field as picking the
   "viewer" of the data, and would like to be able to add
   compression of this data between consenting UA's without
   having to come up with new viewers.

   But I have to admit that Keith has made a good argument
   as to why this is "too late", and we would run into
   compatibility problems with existing UAs

2. However, I really object to only having a compressed-base64
   CTE.  While SMTP is only 7 bit, and will probably be that way
   for the forseeable future, MIME is larger than that.  In particular,
   we've seen other internet protocols like Gopher and Netnews, both
   of which have binary transports, want to adopt MIME.  Why should
   we set up extra, arbitrary barriers for them.  In addition, a
   compressed binary CTE is very useful in the purely local case
   (which is outside our design charter, but still a valid
   target for some of us...).


<Prev in Thread] Current Thread [Next in Thread>