On Thu, May 10, 2012 at 3:05 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

> René Kyllingstad writes:
>
>  > What is the MIME approach to handling text that is perfectly fine to
>  > display plainly, but can be optionally enhanced with for example syntax
>  > highlighting?
>
> The MIME approach is to *define* "text" as "content that is perfectly
> 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.


>  > Wouldn't it be better with "Content-type: text/plain/elisp" or some
> such?
>
> The "plain" is redundant, because all subtypes of text fall back to
> text/plain anyway.
>

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.


-- René