Date: Thu, 29 Aug 1991 10:14:34 -0700 (PDT)
From: Mark Crispin <MRC(_at_)panda(_dot_)com>
Subject: Re: Character-set header (was Re: Minutes of the Atlanta 822ext
meeting
I agree with Nathaniel that I don't like the idea of a separate character set
header. To be honest, I don't like the idea of a separate encoding header
either, because it creates silly states. I've gone along with it solely in
the interests of compromise (I'm still not sure I know what QUOTED-PRINTABLE
in IMAGE/FAX means, although I have a vague idea).
Suggestion: write down a matrix of all the variables and the states created.
You'll find that a two-dimensional matrix is bad enough; multi-dimensional
matrices get really ugly. When you find that the n-dimensional matrix is
heavily populated with silly states with a few sparse useful ones, you'll
wonder whether it won't be a good idea to reduce the rank of the matrix and
coerce the useful states so they fit in the resulting simpler matrix.
<stuff deleted>
Here's the current type/encoding matrix. Note that it could rather easily be
coerced into a vector:
7bit 8bit Binary BASE64 Quoted-Printable
Text OK OK? silly OK OK
Text-Plus OK OK? silly OK OK
Message OK NO? NO NO NO?
Multipart OK NO NO NO NO
Application NO NO NO NO NO
Binary silly silly OK? OK silly
Image silly silly OK? OK silly
Audio silly silly OK? OK silly
Video silly silly OK? OK silly
Alas, this matrix doesn't stand up to close scrutiny, and many of
Mark's "silly states" (good term, by the way!) are really needed.
For example, Text-Plus/FrameMaker format is a binary format,
is not human readable, and would most reasonably be encoded in
Binary.
Another example would be several draw packages, that save a more/draw
metafile format in ascii, and therefore would be of type image but
transport encoding 7 bit.
As I understand it, "binary" is the catchall for types that don't
fit anywhere else, and are not readable. If you had a machine
readable type that was coded to fit within the definition of 7bit
or 8 bit then those silly states go back to OK. An example of this
would be the compression algorithm that was proposed earlier to
this list.
Anyway, my point is that each of us has a model for how we expect
email to work, and with things make sense. However, we have seen
that our models are not all the same. This leads to lots of discussion
and dissention. The end goal should not be to construct a system that
is so tight that you cannot do anything that the architect didn't
believe was reasonable. Instead, we should be providing a structure
to build email systems within, and make the rules clear enough to
ensure that equivalent systems can interoperate.
(I had a strident mini-flame here, but thought better of it.)
Neil