RE: draft RFC to describe a URN for DTS audio

Phillip Maness <> Fri, 21 February 2014 02:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD83E1A03BD for <>; Thu, 20 Feb 2014 18:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gmXulhsPK4ZY for <>; Thu, 20 Feb 2014 18:12:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1CF941A03C4 for <>; Thu, 20 Feb 2014 18:12:56 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 21 Feb 2014 02:12:51 +0000
Received: from (2a01:111:f400:7c10::100) by (2a01:111:e400:2c16::32) with Microsoft SMTP Server (TLS) id 15.0.883.10 via Frontend Transport; Fri, 21 Feb 2014 02:12:51 +0000
Received: from LAX-EXCA02.dts.local ( by ( with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Fri, 21 Feb 2014 02:12:51 +0000
Received: from LAX-EXMB02.dts.local ([fe80::b50e:9af7:de19:4aa9]) by LAX-EXCA02.dts.local ([fe80::5efe:]) with mapi id 14.03.0174.001; Thu, 20 Feb 2014 18:12:50 -0800
From: Phillip Maness <>
To: "Dale R. Worley" <>
Subject: RE: draft RFC to describe a URN for DTS audio
Thread-Topic: draft RFC to describe a URN for DTS audio
Thread-Index: AQHPLDLBHwS6EV29SE6B2sonNGQO6Jq+gVnCgAAAptA=
Date: Fri, 21 Feb 2014 02:12:48 +0000
Message-ID: <520A56052CF01E42B1C128F990FBE681A46B8845@LAX-EXMB02.dts.local>
References: <520A56052CF01E42B1C128F990FBE681A46AFD52@LAX-EXMB02.dts.local> <> <520A56052CF01E42B1C128F990FBE681A46B5587@LAX-EXMB02.dts.local> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(377454003)(85714005)(13464003)(51914003)(189002)(199002)(51704005)(87266001)(69226001)(54316002)(44976005)(56776001)(83322001)(19580405001)(76482001)(19580395003)(561944002)(86362001)(94316002)(85306002)(95416001)(92566001)(94946001)(50466002)(81342001)(87936001)(33656001)(47736001)(50986001)(47976001)(4396001)(2656002)(95666003)(49866001)(81542001)(47446002)(74502001)(31966008)(55846006)(51856001)(74662001)(93136001)(93516002)(46102001)(80976001)(53806001)(54356001)(77096001)(74366001)(77982001)(59766001)(79102001)(81816001)(47776003)(63696002)(81686001)(20776003)(76796001)(76786001)(6806004)(92726001)(65816001)(46406003)(90146001)(56816005)(80022001)(74706001)(85852003)(74876001)(83072002)(23726002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR01MB121; H:LAX-EXCA02.dts.local; CLIP:; FPR:CE2FF3E5.AEFAD3E1.F2D39BBB.46EDF94C.20609; PTR:.; MX:1; A:1; LANG:en;
X-Forefront-PRVS: 01294F875B
Cc: "" <>, "Mark R. Johnson" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2014 02:13:02 -0000

Hi Dale,

Thanks for the additional insight, this is some very helpful dialog.

The primary use of this urn would by those providing services to devices that contain our technologies (products made by many different CE manufacturers), or devices connected to devices that contain our technology.

We don't derive revenue from service providers. Our revenues come from the device manufacturers who license our technologies. We also permit (in the case of audio codecs), devices to "pass-through" to downstream decoder at no cost. In this case, a device (such as a streaming service box or dongle) can advertise "inherited" features of a device downstream (e.g. an A/V receiver attached via. HDMI).

Our objective is to enable our customers, (or rather the consumers who purchase their products), the ability to derive greater benefit from the availability of our technology. This benefits us by making our technology more useful, but it also benefits our customers by expanding the use of features already available in their products, and benefits the consumer (their customer) by providing them a better entertainment experience.

So DTS' benefit is indirectly related to the use of the URN. I wouldn't go so far as to say that we will never directly benefit (financially) from the use of an assigned namespace, but I can't envision such a use case at this time.

I think this is consistent with how the industry consortia you cited use their namespace to benefit their members (for profit companies) to directly deriving benefit by selling services.

I'm sure my explanation above could be better worded, but is this usage better in line with the philosophy of ietf? Does this explanation help you? Would it be beneficial to add this usage explanation in section 5?

Thanks and best regards,
Phil Maness

-----Original Message-----
From: Dale R. Worley []
Sent: Thursday, February 20, 2014 10:41 AM
To: Phillip Maness
Cc:; Mark R. Johnson
Subject: Re: draft RFC to describe a URN for DTS audio

> From: Phillip Maness <>
> Sorry, I have to be intentionally vague from this point on. We have a
> number of business activities in process so we have to consider
> customers, partners and competitors (and, of course, the financial
> community, as we are a publicly traded company). The nature of these
> disclosures in publications such as an RFC can be (intentionally or
> unintentionally) indicative, (or perceived as being indicative), of
> future business.

My first impulse was to say, "I doubt you're going to get much traction with a proposal for a system of names if you're not going to admit *what* they are naming."  But that is incorrect, as lots of organizations have obtained URN NIDs for such generic use.

You may have some difficulty in that DTS is a business, and has no purported public benefit purpose.  In my quick look at the NID registrations that are essentially delegations to organizations, all of the organizations are governments or industry consortia which have public benefit purposes.  Granting a delegation to DTS would be setting a precedent for delegation to a business (a straightforward for-profit entity).  Certainly the question will be raised, "Will it be possible to use one of these URNs in a context that does not cause money to flow to DTS Inc."?

(I will note that there are several mechanisms by which DTS could obtain an Object ID delegation, and there is no question that businesses may do so.  Since all Object IDs correspond to URNs (urn:oid:...), DTS can immediately obtain a URN delegation in that

Comparing draft-pmaness-dts-urn-00 and the NID registrations for "3gpp" (RFC 5279), "cablelabs" (RFC 6289), and "cgi" (RFC 5138), the organizational delegation registrations seem to favor declarations like "The registration tables and information will be published and maintained by 3GPP on its web site."  I don't know if such a promise of public information is critical to getting the NID approved, but it would certainly help.

The whole of section 1 seems to be true but not actually relevant to the namespace, as the proposed namespace doesn't seem to be intrinsically tied to DTS audio formats (that just happens to be everything that DTS Inc. is involved in right now).  I don't know what would be a good replacement, but the truth seems to be "DTS has a lot of irons in the fire, and we think that it would be useful if we could assign URNs.  Though we have a lot of good ideas, we aren't entirely certain what we would use them for yet."

In regard to the syntax, you need to specify that "category" may not contain ":"; otherwise a URN can't be unambiguously parsed into "category" and "string" components.



This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.