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

Eric Burger <eburger@standardstrack.com> Fri, 08 October 2010 01:09 UTC

Return-Path: <eburger@standardstrack.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 BEFCA3A63D3 for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 18:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.435
X-Spam-Level:
X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, 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 NUv96S9oloVC for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 18:09:39 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.249.249]) by core3.amsl.com (Postfix) with ESMTP id 084E13A65A5 for <mediactrl@ietf.org>; Thu, 7 Oct 2010 18:09:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=nZrxyC4rM5SVrhzZu4RZc1foEuplzcRy6EAGpT+3Q0TKzElkUZ1+ZnDZj6Iemze+GYnqImGl+OwFYTnCkqOI1/1p68JzMR9XkkZxjgGGPHp5yt14MkEHWO40YhMCg5Uk;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.134]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1P41TJ-0003mt-N7 for mediactrl@ietf.org; Thu, 07 Oct 2010 18:10:06 -0700
From: Eric Burger <eburger@standardstrack.com>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-46--1053814986; protocol="application/pkcs7-signature"; micalg=sha1
Date: Thu, 7 Oct 2010 18:37:10 -0400
In-Reply-To: <C8D354FC.9350%Scott.McGlashan@hp.com>
To: mediactrl@ietf.org
References: <C8D354FC.9350%Scott.McGlashan@hp.com>
Message-Id: <0C1C621D-3038-405D-97EB-5BC95E1BB7F1@standardstrack.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
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: Fri, 08 Oct 2010 01:09:43 -0000

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