On Thu, May 10, 2012 at 3:05 PM, Stephen J. Turnbull <address@hidden>
René Kyllingstad writes:The MIME approach is to *define* "text" as "content that is perfectly
> What is the MIME approach to handling text that is perfectly fine to
> display plainly, but can be optionally enhanced with for example syntax
fine to display plainly"!
>From RFC 2046:
Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful, then, to
distinguish them, at the highest level, from such unreadable data as
images, audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, it is reasonable to
show subtypes of "text" to the user, while it is not reasonable to do
so with most nontextual data.
Later it defines text/plain, and imposes the requirement that if the
MUA encounters a text/whatever it doesn't understand, it should treat
it as text/plain (unless it can't determine the character set).
This is exactly what you said, translated to RFC-ese. Unusually sane
for an RFC. ;-)
IMHO there is a crucial difference between "perfectly fine" and "to some extent readable". It seems the MIME authors disagree.
> Are MUAs supposed to have a list of all of them?Yes! In the sense that if the MUA wants to do something special with
the subtypes of text, then it needs to know what they all are. If it
doesn't care, it should treat them all as text/plain.
The "plain" is redundant, because all subtypes of text fall back to
> Wouldn't it be better with "Content-type: text/plain/elisp" or some such?
Redundant seems a bit harsh to me.
I would prefer Gmail to treat text/rtf different from text/elisp: text/rtf should by default either be displayed with the markup interpreted or as a download, whereas text/elisp should be displayed as text/plain.
This changes the implementation from a simple catch-all to a white-list or black-list, a far less slam-dunk proposal for an esoteric MUA feature. Sigh.