ned.freed@mrochek.com
Fri, 13 Apr 2001 00:49:34 -0700 (PDT)
> > what was the reason for using audio/basic for g.711 messages
> > rather than audio/wav with the appropriate codec parameter?
Actually, the reason that audio/basic exists is that we needed a simple,
well-defined, and widely implemented audio type to put in the original MIME
specification. G.711 was the obvious choice. It really is just as simple as
that.
> Many if not most MIME type parsers don't do a great job with ';'
> parameters.
Um, not really. Media type parsers have been a basic part of MIME ever since
MIME was created, and I've yet to see an implementation that had a problem
parsing MIME parameters. Think about the boundary parameter of the multipart
top-level media type for a moment and you'll see why such things tend to get
fixed fairly quickly.
The real issue that arises with media type parameters is type discrimination
and dispatch. Specifically, some implementations only allow different handling
to be invoked based on different types, not different parameter values. This
problem originated in the original mailcap format, and is still with us in one
form or another. We've tried not to repeat that mistake when designing new
protocol mechanisms like media feature tags and content negotiation, but of
course we have no control over sloppy implementation work.
Of course this begs the question of whether or not parameter-sensitive dispatch
is actually necessary. In some applications it isn't. But there are cases where
it is quite useful.
There are also places in some non-IETF standards where media types have been
used without allowing for parameters. Unfortunate, but again we have no control
over sloppy standards work outside the IETF.
> Mapping a union of multiple dozens of types (audio/wav)
> in the Content-type header down to an appropriate default subtype
> seems reasonable to me. (Plus, the fact that the values in question
> somehow ended up as unadorned hexadecimal seems like possible trouble.)
> The RIFF header should (SHOULD? MUST?) take precidence over whatever
> audio/wav parameters the MIME type parser comes up with, I hope.
And the potential for the two to disagree leads to silly states. In general we
try to avoid silly states; this is one factor that should be weighed carefully
when adding parameters that duplicate information that's easily derived from
the actual content. In general feature tags are probably a better mechanism for
this sort of information.
Ned
This archive was generated by hypermail 2.0b3 on Fri Apr 13 2001 - 11:09:02 IDT