Re: draft RFC to describe a URN for DTS audio (Dale R. Worley) Thu, 20 February 2014 18:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF2A51A0256 for <>; Thu, 20 Feb 2014 10:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6YN1Gnoo6Jvm for <>; Thu, 20 Feb 2014 10:51:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8FF771A01DD for <>; Thu, 20 Feb 2014 10:51:08 -0800 (PST)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1KIoDpQ010263; Thu, 20 Feb 2014 13:50:15 -0500
Received: from (localhost []) by (8.13.6/8.12.8) with ESMTP id s1KIefP05390028; Thu, 20 Feb 2014 13:40:41 -0500 (EST)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id s1KIeelE5399376; Thu, 20 Feb 2014 13:40:40 -0500 (EST)
Date: Thu, 20 Feb 2014 13:40:40 -0500 (EST)
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Phillip Maness <>
In-reply-to: <520A56052CF01E42B1C128F990FBE681A46B5587@LAX-EXMB02.dts.local> (
Subject: Re: draft RFC to describe a URN for DTS audio
References: <520A56052CF01E42B1C128F990FBE681A46AFD52@LAX-EXMB02.dts.local> <> <520A56052CF01E42B1C128F990FBE681A46B5587@LAX-EXMB02.dts.local>
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: Thu, 20 Feb 2014 18:51:11 -0000

> 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.