Re: draft RFC to describe a URN for DTS audio (Dale R. Worley) Sat, 22 February 2014 03:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B2CEF1A0381 for <>; Fri, 21 Feb 2014 19:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8WsN8-6kFegh for <>; Fri, 21 Feb 2014 19:33:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 025B41A02BD for <>; Fri, 21 Feb 2014 19:33:08 -0800 (PST)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1M3WU3d001971; Fri, 21 Feb 2014 22:32:32 -0500
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id s1M3WNTZ5488615; Fri, 21 Feb 2014 22:32:23 -0500 (EST)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id s1M3WKC35420938; Fri, 21 Feb 2014 22:32:20 -0500 (EST)
Date: Fri, 21 Feb 2014 22:32:20 -0500 (EST)
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Phillip Maness <>
In-reply-to: <520A56052CF01E42B1C128F990FBE681A46B8845@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> <> <520A56052CF01E42B1C128F990FBE681A46B8845@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: Sat, 22 Feb 2014 03:33:11 -0000

Thanks for your recent thoughts.  Here are some more of my thoughts.
They are not organized into a particular proposal, but I think may
provide a guide to obtaining useful results.

I am having some difficulty orienting myself as to how to look at your
proposal.  One issue is that your proposal is (or at least appears to
be) completely commercial.  I don't think that is intrinsically bad,
but it is *different* from other namespace proposals.  And I think
that other people will see your proposal as *different* for the same

Backing up, I see that you would like a "formal" URN namespace, one
with a nice name, and not a "urn-<number>" name.  (RFC 3406)  That
makes sense to me.  But that does mean that the IESG will have to
approve the proposal as an RFC.  So there's a question of whether the
IESG will raise the questions that I am discussing.

I see a number of issues deriving from DTS's purely commercial status:

- There is an intention of commercial benefit, and less of a position
  of public benefit.

I don't see this as important, since many namespace assignments are
delegations to industry consortia.  The consortia are usually
non-profit, but their members are definitely businesses.

- Because the registrant is a business, it would be desirable if the
  delegation was done under a policy that was explicitly even-handed
  toward all businesses that might want a delegation.

- There are a *lot* of potential business registrants, leading to the
  possibility of "NID pollution", filling the registry with names to
  the point that new names that are meaningful would be difficult to

- Businesses will likely desire an NID based on the business' name,
  making it harder to resolve conflicts regarding desired NIDs.

It seems to me that a good way to address these issues is to create a
single NID whose sub-NIDs are delegated to businesses.

At this point, let me use the term "enterprise" instead of "business".
"Enterprise" is used as a generic term for organizations in RFC 2578
and the IANA registry of "private enterprise numbers"

I can see at least three ways to handle all enterprises in a
systematic way:

- urn:enterprise:<enterprise-number>:<NSS>

This technique uses the existing private enterprise numbers to
identify the enterprise.

- urn:enterprise:<identifier>:<NSS>

This technique would create a new registry, from which enterprises
would allocate identifiers on a first-come basis.  The syntax of
<identifier> would probably be the same as <NID> in RFC 2141.

- urn:enterprise:<domain-name>:<NSS>

This technique uses the enterprise's domain name.  (There are a bunch
of details that are needed to make domain names permanent.  See
draft-ietf-salud-alert-info-urns-11 for how to do it.)

Using my consulting company (Ariadne Internet Services) as an example,
these techniques would produce:

- urn:enterprise:14490:nss

- urn:enterprise:ariadne:nss

-, or

Perhaps this concept has been discussed in the URN working group and
they have already come to a decision.