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 MIME 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_tv
Makes 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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt