At 6:28 PM 10/17/94, John Gardiner Myers wrote:
Masataka Ohta <mohta(_at_)necom830(_dot_)cc(_dot_)titech(_dot_)ac(_dot_)jp>
writes:
What's your "plain text"?
My definition of "plain text" in the Internet domain (which I think
should be included in the definition of the "text" top-level MIME
type) is:
Line-oriented data, with lines separated by the octet
sequence 0D 0A.
Thus, data encoded in EBCDIC or UNICODE-1-1 should not qualify.
Without a definition as strict as above, the term "text" becomes
effectively meaningless. One could legitimately register "GIF" as a
MIME character set.
I could see the potential need for a new top-level type for textual,
line oriented data separated by the 16-bit-quantity sequence 000D 000A.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
In the context of MIME, why is it necessary to specify the line separator
sequence at all?
I have to say, I really don't understand why people are insisting that all
charsets used in MIME be variants of ASCII. For a brand-new standard, this
seems to be very limiting. Are we going to have to revise MIME if Unicode
becomes popular? 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?
Of course, this is all hypothetical in the case of Unicode, but do you
really want to tell people who use EBCDIC based computers that they can't
write
content-type: text/plain; charset=EBCDIC
even if they use a cte of binary or base64? What are they supposed to do
instead? "Sell your mainframe and buy a system that uses ASCII?"
I really think this part of MIME could bear a little bit more work to make
it more friendly to non-ASCII character sets. If it needs to be done
through a new content type because of compatibility issues with existing
MIME implementations, well, that's not ideal but it's better than leaving
users of such character sets high and dry.
----------------------------
David Goldsmith
david_goldsmith(_at_)taligent(_dot_)com
Taligent, Inc.
10201 N. DeAnza Blvd.
Cupertino, CA 95014-2233