[whatwg] Give guidance about RFC 4281 codecs parameter

[Maciej Stachowiak]

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.

> 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.

>
> 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.

Regards,
Maciej