Monday, April 10, 2006
MIME Dilution
I encourage your thoughtful feedback.
Submitted to ATV working group of the IETF
http://www1.ietf.org/mail-archive/web/avt/current/msg06669.html
----
It appears that alternate means are being deployed to differentiate between major media types in part because the original uses of the MIME type are not being strictly followed. Please exuse me: if these issues have been addressed before, I would appreciate a link or two to the appropriate postings.
I have recently been asked about the Media Type being able to distinguish between audio and video. It was stated to me that, for example, application/ogg, application/smil, and application/smil+xml do not distinguish between audio and video.
My response was that the MIME type *should* differentiate between audio, video, and other major types of media. But the top-level MIME types appear to be suffering from dilution.
RSS Media (excerpt from version 1.1.0)
In addition the latest draft of the Media RSS Specification justifies the addition of a "medium" attribute that differentiates between major "mediums" (image audio video document executable) because "it simplifies decision making on the reader side, as well as flushes out any ambiguities between MIME type and object type"
This appears to model EXACTLY the original purpose of the MIME type (section 3 of http://www.isi.edu/in-notes/rfc2046.txt where we see: text image audio video application, as well as composite types: multipart message).
ATOM
While ATOM (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt)Proposes to differentiate between an "entry" (in ATOM format) and all other "media".
It seems like a very useful construct (within ATOM) to be able to differentiate collections based on both top-level MIME type and sub-type. Further dilution of the top-level types seems contradictory to the entire purpose of MIME type.
RSS and Atom Feed Auto-Discovery for Internet TV
http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet_tvMakes use of an attribute: media="tv", to differentiate between what (in my opinion) should be top-level MIME types.
Granted that these examples are not standards (yet), they substantiate the view that top-level MIME types are not sufficient for media differentiation.
Ogg
As a concrete example of the dilution, application/ogg is the MIME type for use of all audio and/or video that is in the Ogg file format. Ogg often contains vorbis-encoded audio or theora-encoded video. It seems appropriate, then, that either audio/ogg and video/ogg, or audio/vorbis and video/theora, be appropriated for use for files using the Ogg format. I found that in Feb 2006, there was an application that included appropriation of audio/vorbis, specifically for RTP transport, and not for Ogg file format. This concerns me only because audio/vorbis seems very appropriate to use for Ogg file format vorbis-encoded audio and its appropriation for use only using RTP "container" format seems premature or somehow misguided.
Over the past year, I've had quite an introduction to video container formats vs. encoding formats. I maintain the "media chart" for Pocket PCs at http://www.feederreader.com/mediachart.html , which attempts to sort out some of the confusion.
Part of the issue is that Media Type, Media Container, and Media Encoding are variously intertwined and mixed. But not essentially addressed by the MIME type specification. And because these issues are at a level above individual MIME types, it seems they would need to be addressed outside any MIME type application.
These issues appear to me to be ripe for "de-confusioning" and it occurred to me that the organization responsible for MIME types would be the place to start.
Thoughts? Comments?
Greg Smith
Submitted to ATV working group of the IETF
http://www1.ietf.org/mail-archive/web/avt/current/msg06669.html
----
It appears that alternate means are being deployed to differentiate between major media types in part because the original uses of the MIME type are not being strictly followed. Please exuse me: if these issues have been addressed before, I would appreciate a link or two to the appropriate postings.
I have recently been asked about the Media Type being able to distinguish between audio and video. It was stated to me that, for example, application/ogg, application/smil, and application/smil+xml do not distinguish between audio and video.
My response was that the MIME type *should* differentiate between audio, video, and other major types of media. But the top-level MIME types appear to be suffering from dilution.
RSS Media (excerpt from version 1.1.0)
In addition the latest draft of the Media RSS Specification justifies the addition of a "medium" attribute that differentiates between major "mediums" (image audio video document executable) because "it simplifies decision making on the reader side, as well as flushes out any ambiguities between MIME type and object type"
This appears to model EXACTLY the original purpose of the MIME type (section 3 of http://www.isi.edu/in-notes/rfc2046.txt where we see: text image audio video application, as well as composite types: multipart message).
ATOM
While ATOM (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt)Proposes to differentiate between an "entry" (in ATOM format) and all other "media".
It seems like a very useful construct (within ATOM) to be able to differentiate collections based on both top-level MIME type and sub-type. Further dilution of the top-level types seems contradictory to the entire purpose of MIME type.
RSS and Atom Feed Auto-Discovery for Internet TV
http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet_tvMakes use of an attribute: media="tv", to differentiate between what (in my opinion) should be top-level MIME types.
Granted that these examples are not standards (yet), they substantiate the view that top-level MIME types are not sufficient for media differentiation.
Ogg
As a concrete example of the dilution, application/ogg is the MIME type for use of all audio and/or video that is in the Ogg file format. Ogg often contains vorbis-encoded audio or theora-encoded video. It seems appropriate, then, that either audio/ogg and video/ogg, or audio/vorbis and video/theora, be appropriated for use for files using the Ogg format. I found that in Feb 2006, there was an application that included appropriation of audio/vorbis, specifically for RTP transport, and not for Ogg file format. This concerns me only because audio/vorbis seems very appropriate to use for Ogg file format vorbis-encoded audio and its appropriation for use only using RTP "container" format seems premature or somehow misguided.
Over the past year, I've had quite an introduction to video container formats vs. encoding formats. I maintain the "media chart" for Pocket PCs at http://www.feederreader.com/mediachart.html , which attempts to sort out some of the confusion.
Part of the issue is that Media Type, Media Container, and Media Encoding are variously intertwined and mixed. But not essentially addressed by the MIME type specification. And because these issues are at a level above individual MIME types, it seems they would need to be addressed outside any MIME type application.
These issues appear to me to be ripe for "de-confusioning" and it occurred to me that the organization responsible for MIME types would be the place to start.
Thoughts? Comments?
Greg Smith
# posted by Greg Smith @ 7:55 AM 
