On 4/11/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
On Apr 10, 2007, at 11:58 AM, Ralph Giles wrote: > On Tue, Apr 10, 2007 at 11:21:10AM -0700, Dave Singer wrote: > >>> # application/ogg; disposition=moving-image; codecs="theora, vorbis" >>> # application/ogg; disposition=sound; codecs="speex" >> >> what is the 'disposition' parameter? > > The idea of a 'disposition-type' is to mark content with > presentational > information. See the Content-Disposition Header for MIME described in > RFC 1806 for an early example. 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. Ogg is more pragmatic in this respect: application/ogg is for the bucket type video/x-theora for the video codec stream (no audio) audio/x-vorbis for the audio codec stream Neither video/x-theora nor audio/x-vorbis actually tell you in what container (bucket) your stream comes.
> The specific proposal Silvia mentioned is to add the content- > disposition to the media-type to inform parsers of the general > nature of the content, even if they don't recognize the specific > codecs. The allowed values for the 'disposition' label come from > the Dublin Core set. This is not part of RFC 4281, and as far as > I know hasn't been formally documented with the IETF, but we do > think it's a good idea. It seems redundant with the "video/" and "audio/" base types, and adding such a feature just to make the point that the Ogg container is universal seems like a stretch. > > This arose out of the need to discover or record "audio" vs > "audiovisual" status for media files in the context of routing > to the proper playback application, which has been particularly > contentious with the Ogg container since we have insisted that > such distinctions be made via metadata or file inspection instead > of defining distinguishing filename extensions has has been done > with other containers. (MooV is perhaps another example.) File inspection is not really workable for content coming from the web that might be sent to an external app, so I think the Ogg community should reconsider this stance on distinguishing file types by primary use.
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.
> > In terms of user presentation, "audio" vs "video" vs "text" vs > "still image" is the important distinction, while the 'codecs' > parameter answers the more technical question of what playback > capabilities are necessary. And indeed, MIME already has "audio/", "video/", "text/" and "image/" base types to make this very distinction. It seems unhelpful to invent a second way to say the same thing.
rfc4281 and many other digital media bucket formats show that this is not an Ogg-only problem. Since multimedia comes in containers (buckets) in order to serialise what is essentially time-parallel data, there will always be a problem to describe both the container and the containing type of data. Since neither theora nor vorbis can stand on their own without a container format (such as rtsp or ogg), video/x-theora or audio/x-vorbis cannot indicate anything. They only make sense in context. And the same applies, btw, to streaming text or images that are part of a multimedia application. It's not as simple as dividing the world into files of type application (sw), audio, video, text and images. This simplistic world view has been overtaken by reality a long time ago. Best Regards, Silvia.
