[MEDIACTRL] Issue with mixer package <codec> element

Jonathan Lennox <jonathan@vidyo.com> Thu, 25 March 2010 20:57 UTC

Return-Path: <jonathan@vidyo.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 67AB93A67A3 for <mediactrl@core3.amsl.com>; Thu, 25 Mar 2010 13:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.131
X-Spam-Level:
X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1]
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 JaUvDweEm+WQ for <mediactrl@core3.amsl.com>; Thu, 25 Mar 2010 13:57:58 -0700 (PDT)
Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 334743A6C1D for <mediactrl@ietf.org>; Thu, 25 Mar 2010 13:57:57 -0700 (PDT)
Received: from BH003.mail.lan ([10.110.21.103]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 16:57:41 -0400
Received: from HUB023.mail.lan ([10.110.17.23]) by BH003.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 16:57:49 -0400
Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Thu, 25 Mar 2010 16:58:18 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Thu, 25 Mar 2010 16:58:16 -0400
Thread-Topic: Issue with mixer package <codec> element
Thread-Index: AcrMXeP6dPjKilPwSYi3GfX2VjMJcg==
Message-ID: <C3759687E4991243A1A0BD44EAC82303053842DE@BE235.mail.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Mar 2010 20:57:49.0810 (UTC) FILETIME=[D43A5D20:01CACC5D]
Subject: [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, 25 Mar 2010 20:57:59 -0000

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