[whatwg] Give guidance about RFC 4281 codecs parameter

[Dave Singer]

At 12:12  +1000 11/04/07, Silvia Pfeiffer wrote:
>On 4/11/07, Maciej Stachowiak <mjs at apple.com> wrote:
>>Wouldn't it be simpler to use "video/ogg" and "audio/ogg" as the base
>>types here? That would already tell you the intended disposition.
>
>
>Please note that rfc4281 also mentions the problem that video/* bucket
>types could have audio only included in them:
>
>"With each "bucket" type, a receiving agent only knows that it has a
>   container format.  It doesn't even know whether content labeled
>   video/3gpp or video/3gpp2 contains video; it might be audio only,
>   audio and video, or video only."
>
>Therefore, the video/* type does not clearly indicate which
>application would be most suitable to be used with such a contant
>type.

But it does at least indicate that we have a time-based multimedia 
container on our hands, and that it might contain visual 
presentation.  "application/" suffers that it does not say even that, 
and it raises the concern that this might be arbitrary, possibly 
executable, data.  We discussed whether application/ was appropriate 
for MP4 and decided that it masked important characteristics of the 
format -- that it really is a time-based multimedia presentation -- 
and raised unwarranted concerns.

We had to settle on one type that was valid for all files, to deal 
with the (common) case where the server was not willing to do 
introspection to find the correct type.  We decided that "audio/" 
promises that there isn't video, whereas "video/" indicates that 
there may be.  It's not optimal, agreed.

>Neither video/x-theora nor audio/x-vorbis actually tell you in what
>container (bucket) your stream comes.

These seem to be unregistered (x-) types that attempt to identify a 
codec in a container-independent way (a problem that the 'bucket' RFC 
struggled with), right?

>
>
>I totally agree - file inspection is not workable in many cases and
>therefore the MIME type has to indicate all of this information: the
>bucket type, the contained codecs, and the suggested type of
>application to use.

Unfortunately, those parameters in the mime type relayed from the 
server are derived by ... file inspection.  Yes, types embedded in 
the page can be more accurate.

I'm with my colleague here;  I think application/ is needlessly 
vague, raises unwarranted concerns, and avoids using acceptable, more 
specific types.  Maybe I should have said so on the IETF list when 
the I-D was becoming an RFC...

I'm not sure how pertinent this is to whatwg, though...
-- 
David Singer
Apple Computer/QuickTime