[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] The storage format of EVRC/SMV vocoder (resent)

At 2:04 PM -0400 4/22/03, Colin Perkins wrote:



>  Are there minutes of this meeting available? I'd like to understand the
>  rationale behind the choice (especially the choice of changing the MIME
>  type, since "audio/qcp" seems appropriate).





Regarding the MIME type, "audio/qcp" was the initial suggested MIME
type, but there was pushback based on the principle that MIME types
should describe the content, not the format.  In general, neglect of
this principle reduces interoperability, since it then means that an
implementation that supports a certain MIME type may not be able to
handle content received in that MIME type.



Yes, although there's sometimes a fine line between content differences and the
use of different content options. The standard example is PostScript, which has
numerous optional facilities, so many that describing them all in  either
parameters or in subtype names is clearly impractical.




So, in accordance with
the principle, it makes sense to use "audio/qcelp" for QCELP 13K data
in this format, "audio/evrc-qcp" for EVRC data stored in the QCP
format, and "audio/smv-qcp" for SMV data in the QCP format.





I suppose "audio/qcelp" plus "audio/qcp" with a mandatory parameter
for the codec included, which could only be SMV or EVRC, not QCELP,
could also work.  I've added Ned Freed to the distribution list to
get his views, as the IANA-designated MIME expert.



(FYI, I'm on the AVT list already...)

I tend to lean towards separate types myself, but either way will work.

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