Graham Klyne wrote:

(1) use application/(something) rather than text/(something) in *all* cases where the content is not primarily for human consumption - i.e. if you expect to do anything other than display as-is on a character display.

I think the last part of that sentence is definitely too far---the only thing that would be displayed "as-is on a character display" is text/plain. Besides plain text, "primarily for human consumption" is one possible criterion, but is that the most useful criterion? RFC 2046 mentions, "The 'text' media type is intended for sending material which is principally textual in form." I don't know what that means exactly, but the RFC goes on to say things in this category are "to some extent readable" and that, "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." I don't have a strong opinion here, but I will point out that RFC 2046 talks about the category being "the highest level" division and that it is "useful". To me, it is useful at a high level to note that the content types discussed here have the following characteristics: * The content bytes are interpreted as text characters (i.e. Unicode code points); ignoring encoding, no bytes are interpreted as anything other than text characters. (These text characters may later be subject to some meta-interpretation---e.g. delimiters---but they are first interpreted as text characters.) * These content types can always be edited in a text editor. * Abstract values, such as numbers, are represented by their text lexical forms, not by some non-text encoding. To me those points are meaningful, and it might be useful to include those criteria when making a high-level distinction. Is the top-level type of RFC 2046 even useful anymore? I think the biggest criteria for me is, "can I edit this thing in a text editor?" Whether the author meant the information to be directly displayed to the user, while interesting, seems less useful from a content-processing point of view. Garret