At 1998-10-30 15:08, Steve Dorner wrote:
At 2:22 PM -0800 10/30/98, Ashley Yakeley wrote:
My understanding of top-level types is that image, audio & video indicate
what the stream encodes, whereas text (and perhaps message) indicate how
the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is
encoded in text.
This is a very common MISunderstanding.
One encouraged by RFC 2046, sec. 4.1:
# 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".
Any MIME content type can have textual semantics, simply by specifying
textual semantics in the document that defines the type. Doesn't matter if
it's application/whatever, image/whatever, etc. You can specify that it be
slung around as a textual thing, with newline canonicalization, charset,
...which makes such things 'formatted textual data', which according to
RFC 2046 'should be represented using subtypes of "text"'.
Text subtypes, on the other hand are assumed to have textual semantics, but
it doesn't end there. For a subtype to belong in text, it must have a
further property, that of being appropriate for normal users to read
without any special software.
RFC 2046 merely claims that it needs to be 'to some extent readable'.
So, your textual encoding of audio is not "text/vnd.abc", it's
"audio/vnd.abc". But it's still allowed to be textual.
No, it's (correctly) 'text/vnd.abc'. See
Ashley Yakeley, Seattle WA