- From: Dave Singer <singer@apple.com>
- Date: Wed, 11 Apr 2007 17:45:34 -0700
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
Received on Wednesday, 11 April 2007 17:45:34 UTC