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.
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" octet-stream" .
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/
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.