Comment 35 for bug 25830

I don't know what "specs" James is talking about. I was alluding to RFC2046.
Specifically, section 4.1. of that says:

   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. Such formatted textual data should be
   represented using subtypes of "text".

Later, in 4.1.4:

   Unrecognized subtypes of "text" should be treated as subtype "plain"
   as long as the MIME implementation knows how to handle the charset.
   Unrecognized subtypes which also specify an unrecognized charset
   should be treated as "application/octet-stream".

My take is that, when encountering "text/my-doc-format; charset=us-ascii", to be
compliant, Mozilla must allow display of this as if it were text/plain. It
should (IMHO) treat text/xyz with a missing charset as if charset were UTF-8
(this makes most cases work), and it should allow MIME types other than text/*
to be displayed raw, if that isn't much work.