<ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/vnd.abc>.
Sorry, I thought you had made up an example, I didn't realize this was a
real type.
There's an interesting case, but it's a VERY SPECIAL case. It's audio that
can actually be read by humans directly (well, not *this* particular human,
but... :-)).
In that case, I can understand your interpretation of 2046 (though I think
the registration is wrong and should be audio/vnd.abc and that 2046 should
be clarified). However, I really wouldn't build a theory around such
oddball cases. I would especially worry about using words like "encoding"
when talking about them.
Much data that is textual is not intended to be directly read by users and
does not belong in text/* by virtue of its textual form. May people do not
understand this, and believe that any representation that consists of short
lines of ascii characters means the type belongs in text/*. Not so.
...but that the 'Media' frosting on top can be anything at all:
----------Audio----------
text/vnd.abc
Only in the oddball case where you have a media type that can actually be
directly read in the raw by an ordinary user. I assert that the set of
such types is very small indeed.
...whereas 'audio', 'image' and 'video' types describe the top layer of
frosting:
----------Audio----------
audio/aiff
----------Octets---------
Ah, but here you can have a textual layer, too:
----------Audio----------
audio/hypothetical-thing
----------textual--------
charset
----------Octets---------
You just have to say in the registration of audio/hypothetical-thing that
it takes a charset parameter (and presumably has other textual behaviors
like newline canonicalization). For example, I might register
audio/yes-and-no, where I describe a sound by means of the words yes and
no. I could then say (forgive me on the details):
ct: audio/yes-and-no; charset=us-ascii; language=fr
oui oui oui non non oui
That's textual, but it sure doesn't belong in text/*.