At 12:12 +1000 11/04/07, Silvia Pfeiffer wrote:
On 4/11/07, Maciej Stachowiak <[EMAIL PROTECTED]> 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
