[Top] [All Lists]

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

1993-06-10 22:05:45

From:  Neil(_dot_)Katin(_at_)eng(_dot_)sun(_dot_)com (Neil Katin )
To:  ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu, 

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.


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.

I've been following this conversation and I'm convinced that going for
a minimum number of options and using CTE('s) is best from the point
of view of interoperability as well as consistency with the MIME way
of doing thngs.

  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...).

However, I agree that compressed-binary should be defined from the
beginning.  If it's need is anticipated in mail, that would be enough
reason, but the potential for use of MIME or MIME-like messages within
other protocols seems like the clincher to me.  Who knows, even the
next verion of IRC might use MIME so you could send sounds, etc., as
well as text.



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