Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

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. ;-)

 > 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.