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

"McGlashan, Scott" <scott.mcglashan@hp.com> Thu, 07 October 2010 08:48 UTC

Return-Path: <scott.mcglashan@hp.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA153A6E7E for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 01:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level:
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKFWI8oLKO0c for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 01:48:27 -0700 (PDT)
Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id D75163A6ECA for <mediactrl@ietf.org>; Thu, 7 Oct 2010 01:48:27 -0700 (PDT)
Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id A9B0F384D8; Thu, 7 Oct 2010 08:49:29 +0000 (UTC)
Received: from G5W0323.americas.hpqcorp.net (16.228.8.68) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Oct 2010 08:49:12 +0000
Received: from GVW1124EXC.americas.hpqcorp.net ([16.228.24.184]) by G5W0323.americas.hpqcorp.net ([16.228.8.68]) with mapi; Thu, 7 Oct 2010 08:49:12 +0000
From: "McGlashan, Scott" <scott.mcglashan@hp.com>
To: Jonathan Lennox <jonathan@vidyo.com>, "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Thu, 7 Oct 2010 08:49:09 +0000
Thread-Topic: [MEDIACTRL] Issue with mixer package <codec> element
Thread-Index: Actl/INUJhm3G1UwQNKvpuaMh2fAnQ==
Message-ID: <C8D354FC.9350%Scott.McGlashan@hp.com>
In-Reply-To: <C3759687E4991243A1A0BD44EAC82303053842DE@BE235.mail.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.0.0.100802
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MEDIACTRL] Issue with mixer package <codec> element
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2010 08:48:29 -0000

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" <jonathan@vidyo.com> 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
>jonathan@vidyo.com
>
>
>_______________________________________________
>MEDIACTRL mailing list
>MEDIACTRL@ietf.org
>https://www.ietf.org/mailman/listinfo/mediactrl
>Supplemental Web Site:
>http://www.standardstrack.com/ietf/mediactrl