[Top] [All Lists]

Re: Massive Content-Type definition ideas & Gopher

1993-06-11 07:04:55
Excerpts from mail: 10-Jun-93 Re: Massive Content-Type de.. Jim
Conklin(_at_)educom(_dot_)edu (626)

  I can't speak with the authority of an implementer, but I'm convinced
that we can't forsee the varieties of compression that will prove useful
and how they'll be used among the various types of MIME content-types.  I'm
particularly unconvinced only that a single compression algorithm will be
needed for MIME use.

Let me try one more time to clarify a point on which there is a LOT of

We don't NEED to foresee the varieties of compression that will prove
useful for specific content-types.  This is, in general, the province of
domain experts.  For example, the MIME spec says nothing at all about
image or video compression, because that was handled quite well by the
experts who created JPEG and MPEG.  Similar considerations should apply
to future content-types.  Audio is a current problem because we didn't
find a similarly-agreeable standard for compressed audio, but that's a
completely separate problem that should lead to a new MIME audio subtype

When you consider JPEG and MPEG, you realize that MIME already supports
several compression mechanisms, but does so IMPLICITLY.  The question is
whether MIME should support any general compression mechanisms
explicitly.  Such mechansism will always be best considered "fallback"
compression, for use when the specific content-type is itself poorly

The current state of compression algorithms appears to be such that a
single algorithm will suffice for that purpose.  Perhaps some day there
will be an algorithm so much better that we want a second, but there's
just NO WAY we're going to want a whole lot of these, and I oppose any
mechanism that will make it too easy to end up with lots of different
incompatible compression schemes.  We just don't need 'em.  I think
there's a better case to be made for no general compresion mechanism at
all than for a proliferation of them!  -- Nathaniel