Re: [MEDIACTRL] Issue with mixer package <codec> element

[Eric Burger <[e-mail]>]

Works for me. Anyone else?

On Oct 7, 2010, at 4:49 AM, McGlashan, Scott wrote:

> Hi Jonathan,
> 
> Thanks for the comment and apologies for the delay.
> 
> Reviewing the XCON's definition, I see that they have a name attribute
> which we have mistakenly not put in our definition of <codec>.
> 
> Unless anyone on the mailing list objects, I'll add a mandatory name
> attribute to the <codec> element which specifies the top-level media type
> of the codec. I'll also fix up the definitions of name and <subtype> to
> map to the type-name and subtype-name of RFC 4288 as well as the examples.
> 
> Thanks 
> 
> Scott
> 
> 
> 
> 
> On 25/03/2010 21:58, "Jonathan Lennox" <[e-mail]> wrote:
> 
>> I'm sorry this is being raised so late, but I was looking over the mixer
>> package's definition of <codec> (to recommend that MRB copy its
>> definition for its <rtp-codec>), and realized there was a problem.
>> 
>> The problem is that mixer package's definition of <codec> includes only
>> the media subtype (e.g. pcmu or h264), not its top-level media type
>> (audio or video).  In most cases subtypes are unique, but there are a few
>> "container" subtypes (e.g. rtx, fec, or red) that are registered as
>> multiple top-level types.  I believe this is only by convention and good
>> practice, however; RFC 4288 requires only that the type/subtype pair be
>> unique. 
>> 
>> My recommendation would be to add a <type> element under <codec>, whose
>> definition is the top-level content type, leaving <subtype> as the
>> subtype.  (An alternative would be to change to only using <type> as
>> type/subtype, e.g. audio/pcmu, which would probably be equally good, but
>> this might make life unnecessarily harder for implementations that want
>> to try to maintain backward compatibility with the draft as-is.)
>> 
>> It is probably also worth pointing out that both type and subtype names
>> are not case-sensitive.
>> 
>> The other (minor) problem is that I'm not sure the defining the values of
>> <subtype> by reference to a column IANA's RTP Payload Format media types
>> table is the best choice, among other reasons being that that table is
>> very incomplete, missing, for instance, video/h264.  (This has been
>> raised with IANA.)  I would instead define the value simply as "the name
>> of the subtype of the codec's media format".  The reference to RFC 4855
>> can remain.
>> 
>> -- 
>> Jonathan Lennox
>> Vidyo, Inc
>> [e-mail]
>> 
>> 
>> _______________________________________________
>> MEDIACTRL mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mediactrl
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/mediactrl
> 
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl