RE: urn:oid:

[Phillip Maness <[e-mail]>]

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

urn:oid:1.3.6.1.4.1.18239:{string}

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

Your idea to map ':oid:1.3.6.1.4.1' 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

urn:dn:dts.com:{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 [mailto:[e-mail]]
Sent: Monday, February 24, 2014 8:44 PM
To: [e-mail]
Cc: Mark R. Johnson; Phillip Maness
Subject:

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"
(https://www.iana.org/assignments/enterprise-numbers/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
formats:

- urn:enterprise:14490:nss

- urn:enterprise:ariadne:nss

- urn:enterprise:ariadne.com:nss, or
  urn:enterprise:ariadne.com(2012-01-01):nss

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

- urn:e:14490:nss

- urn:e:ariadne:nss

- urn:e:ariadne.com:nss, or
  urn:e:ariadne.com(2012-01-01):nss

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

Dale

________________________________

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