[Top] [All Lists]

Re: text/*

1998-10-30 17:48:20
At 1998-10-30 16:18, Steve Dorner wrote:


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 

In that case, I can understand your interpretation of 2046 (though I think 
the registration is wrong and should be audio/ 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:


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


Ah, but here you can have a textual layer, too:


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 

Ashley Yakeley, Seattle WA

<Prev in Thread] Current Thread [Next in Thread>