At 9:36 PM 10/17/94, David Goldsmith wrote:
In the context of MIME, why is it necessary to specify the line separator
sequence at all?
Because there is a common (if imprecise) definition of "text" on the
Internet, roughly coinciding to "I can edit it with vi"; perhaps sad, but
definitely true.
I have to say, I really don't understand why people are insisting that all
charsets used in MIME be variants of ASCII.
"charset" is a term that is used with the "text" content-type, which
roughly coincides with the definition of "text" I alluded to above. Things
that use CRLF for other than linebreak or that use NUL's just don't fit.
That does NOT mean that other character sets cannot be used in MIME; it
just means that those other character sets should not be used *with the
"text" content-type*.
So rather than having "text/plain; charset=unicode", we should have
"unicode/plain" or "extended-text/plain; character-set=unicode".
Are we going to have to revise MIME if Unicode
becomes popular?
In terms of adding a new content-type, I firmly believe so. Unicode is
going to be a VERY NEW ANIMAL in many ways, and there's no sense pretending
it fits the old Internet text model. That doesn't mean Unicode is bad; it
just has to be handled differently, and so requires being labelled
differently.
If binary or base64 is good enough to protect images or
sound, why isn't it good enough to protect text? Why not make a little bit
of extra effort now to disentangle the line breaking necessary for SMTP
transport from the MIME content type?
Line breaking isn't necessary only for SMTP. It's also necessary for the
data to actually be used on the destination computer. It's *important* to
know what the linebreak sequence is, so that it can be mapped to local
conventions. Unicode will of course blast those local conventions and the
utilities that rely on them to hell, which is another reason that it should
be clearly labelled as Very Different.
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."