Comment 77 for bug 25830

Someone has quoted RFC2046. There is also a suggestion in RFC1341 about what to
do with text/strange-unknown-format and similar MIME types:

>In general, the top-level Content-Type is used to declare
>the general type of data, while the subtype specifies a
>specific format for that type of data. Thus, a Content-Type
>of "image/xyz" is enough to tell a user agent that the data
>is an image, even if the user agent has no knowledge of the
>specific image format "xyz". Such information can be used,
>for example, to decide whether or not to show a user the raw
>data from an unrecognized subtype -- such an action might be
>reasonable for unrecognized subtypes of text, but not for
>unrecognized subtypes of image or audio.

I think there is a third 'strand' to this bug that is separate from the two
issues mentioned by Boris Zbarsky. He mentioned user preferences to handle a
particular type as plain text, and an extra 'view as text' option for a helper
dialogue box. But for a MIME type that is text/something, shouldn't the browser
just display the document immediately as it does for text/plain? This should
not require any UI spec - no extra dialogue boxes or prompts are needed, all
that happens is for text/* to be treated the same way as text/plain unless some
more specific handler is set up.

Having a preferences box to treat a particular type as plain text (and not
limited to just text/* MIME types) would be nice; an extra 'view as text' option
in the helper app dialogue box would also be nice. But neither of these is a
prerequisite for fixing the current default behaviour, so that a text/* document
displays as text rather than being treated as a wholly unknown type.