At 1998-10-30 16:18, Steve Dorner wrote:
<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... :-)).
...but even to you it's 'to some extent readable', in the words of RFC
2046.
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).
That would be a change, not a clarification.
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.
Um. By 'encode', I just mean 'represent'.
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.
Again, that's not what RFC 2046 says. Any type that is 'to some extent
readable' as plain text should be in text/*.
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.
No, if the data is formatted textually, it belongs in text/*:
# Such formatted textual data should be
# represented using subtypes of "text".
...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.
I maintain that you're holding a far higher standard of readability than
that implied by RFC 2046.
...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/*.
Your example is tendentious, since it's not a reasonable representation
of audio. But if it were, then it should be in text/*.
A better example would be a hypothetical 'ascii-art' type. ASCII art
obviously represents images, but since it is readable as text, it should
(according to RFC 2046) be registered as 'text/ascii-art', not
'image/ascii-art'.
--
Ashley Yakeley, Seattle WA