RE: urn:oid:

Phillip Maness <> Wed, 12 March 2014 13:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D1031A09AB for <>; Wed, 12 Mar 2014 06:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 3aPEC6S_3igc for <>; Wed, 12 Mar 2014 06:42:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 945ED1A0728 for <>; Wed, 12 Mar 2014 06:42:30 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.893.10; Wed, 12 Mar 2014 13:42:23 +0000
Received: from (2a01:111:f400:7c10::142) by (2a01:111:e400:16::37) with Microsoft SMTP Server (TLS) id 15.0.893.10 via Frontend Transport; Wed, 12 Mar 2014 13:42:22 +0000
Received: from LAX-EXCA01.dts.local ( by ( with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 12 Mar 2014 13:42:21 +0000
Received: from LAX-EXMB02.dts.local ([fe80::b50e:9af7:de19:4aa9]) by LAX-EXCA01.dts.local ([fe80::5efe:]) with mapi id 14.03.0181.006; Wed, 12 Mar 2014 06:42:21 -0700
From: Phillip Maness <>
To: "Dale R. Worley" <>
Subject: RE: urn:oid:
Thread-Topic: urn:oid:
Thread-Index: Ac899QXbazGiyYDURGqVULMjcCC13g==
Date: Wed, 12 Mar 2014 13:42:19 +0000
Message-ID: <520A56052CF01E42B1C128F990FBE681A4715F92@LAX-EXMB02.dts.local>
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)(438001)(13464003)(377424004)(199002)(189002)(377454003)(50466002)(19580405001)(81816001)(2656002)(49866001)(83322001)(19580395003)(80976001)(94946001)(87936001)(86362001)(92566001)(47976001)(85306002)(15975445006)(69226001)(44976005)(74876001)(87266001)(76796001)(76786001)(4396001)(23726002)(95416001)(76482001)(54356001)(54316002)(74366001)(93136001)(74502001)(76176001)(94316002)(56776001)(46102001)(77096001)(79102001)(92726001)(93516002)(53806001)(81686001)(81342001)(83072002)(51856001)(85852003)(56816005)(90146001)(77982001)(47446002)(97336001)(97186001)(95666003)(20776003)(31966008)(74706001)(59766001)(74662001)(46406003)(47736001)(33656001)(65816001)(55846006)(80022001)(63696002)(6806004)(81542001)(50986001)(47776003)(561944002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR01MB470; H:LAX-EXCA01.dts.local; CLIP:; FPR:CE0CF1E7.AFD2D11A.F9F195B7.44E41141.20553; MLV:sfv; PTR:.; A:1; MX:1; LANG:en;
X-Forefront-PRVS: 01480965DA
Received-SPF: Pass (: domain of designates as permitted sender) receiver=; client-ip=; helo=LAX-EXCA01.dts.local;
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: Wed, 12 Mar 2014 13:42:34 -0000

Hi Dale,

Sorry I let this go quiet for a few weeks.

Thanks for the direction regarding use of OID. We have a registration under Digital Theater Systems, #18239. Our company name has been changed since then to DTS, Inc. and the email listed for the registrant (Brian Berg) is no longer valid, (Brian left), but that's definitely us. Do you know whether it is possible to update this entry?

So it seems that we can create a urn as


Have I got that right? I wasn't aware of this approach, I appreciate you educating me on this.

Your idea to map ':oid:' to ':enterprise', (or 'e') would be a significant improvement from a human readability perspective, but I really like your second idea better, even to perhaps generalize it to:

urn:dn:<domain name>:{string}

For example{string}

In our case this scheme would have the added benefit to inform a developer encountering this urn an easy clue on where to go for more information.

Have you any insight whether this could be an acceptable proposal? I would be willing to write the draft RFC.

In light of this new information, it's apparent there is no merit in pursuing my original namespace RFC. Can I withdraw it, or do I just let it expire?

Thanks and best regards,
Phil Maness

-----Original Message-----
From: Dale R. Worley []
Sent: Monday, February 24, 2014 8:44 PM
Cc: Mark R. Johnson; Phillip Maness

This is an idea that appeared in a previous message to urn-nid.  I want to extract it and present it as a stand-alone message so I can get more feedback on the idea.

The question is, "What do we do if an enterprise (business or other
organization) wants to have a NID of its own?"

("Enterprise" is used as a generic term for organizations in RFC 2578 and the IANA registry of "private enterprise numbers"

I feel that this raises several questions which I have not seen involved in other NID definitions:

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

- There are a *lot* of potential enterprise 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 assign.

- Enterprises will likely desire an NID based on the enterprise's
  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 enterprises.

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 enterprise, these techniques would produce the following examples, assuming that the overall NID was "enterprise", using the different

- urn:enterprise:14490:nss

- urn:enterprise:ariadne:nss

-, or

If we wanted to be terse, we could assign the NID "e", giving these

- urn:e:14490:nss

- urn:e:ariadne:nss

-, or

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



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.