Subject: RE: urn:oid:

From: Phillip Maness <[email-masked]>
Date: Wed, 12 Mar 2014 13:42:19 +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

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:[email-masked]]
Sent: Monday, February 24, 2014 8:44 PM
To: [email-masked]
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.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 14 Mar 2014 11:31:26 +0900

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

Domain names are being changed and reused all the time. And 
people/organizations who reuse them usually don't know what URNs their 
predecessors have minted, nor would they care.

In Web Architecture discussions, there are people who regularly say that 
there's no need to use URNs, just use something like 
http://dts.com/{string}. The proponents of URNs always said that URNs 
are there to provide more stability than e.g. HTTP URLs. This proposal 
would essentially pollute the overall URN space with the instability 
from other URI/IRI schemes.

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

Just let it expire.

Regards,   Martin.

---

From: Phillip Maness <[email-masked]>
Date: Mon, 17 Mar 2014 18:16:42 +0000

Hi Dale,

Just for clarification, when you say "permanent" are you referring to a persistent instance of "identifier" or a persistent meaning of "identifier".

In all applications where I would use an identifier, the meaning would never change (it couldn't, applications would cease to function correctly). They usually do have a value parameter that changes. The documents they appear in, (often an XML manifest), typically live for anywhere from a few minutes to a few days.

Thanks,
Phil

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Monday, March 17, 2014 5:40 PM
To: Martin J. DC<rst
Cc: Phillip Maness; [email-masked]; Mark R. Johnson
Subject: Re: urn:oid:

> From: "Martin J. DC<rst" <[email-masked]>

> predecessors have minted, nor would they care.

A workable solution is to attach to the domain name the date on which the organization had possession of the domain name.  That solution is used in the "tag" scheme (RFC 4151):

   Examples of tag URIs are:

     tag:[email-masked],2001:web/externalHome
     tag:[email-masked],2004-05:Sandro
     tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19
     tag:blogger.com,1999:blog-555
     tag:yaml.org,2002:int

and in draft-ietf-salud-alert-info-urns "alert" URN extension elements:

    urn:alert:...:[email-masked](1990):...
    urn:alert:...:[email-masked](2013-03):...
    urn:alert:...:[email-masked](2013-03-29):...

But in general, domain names shouldn't be incorporated into permanent identifiers.

Dale

Notice:

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 19 Mar 2014 17:40:00 -0400

> From: Phillip Maness <[email-masked]>

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

Ah!  I looked for "DTS" in
http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers,
but it wasn't there.

It looks like the way to update a private enterprise number is to go
to the application page http://pen.iana.org/pen/PenApplication.page
and then click on "Modify Private Enterprise Number (PEN)" near the
top.

> you educating me on this.

It's not as flexible as that.  See RFC 3001.  The {string} has to be a
"."-separated sequence of nonnegative integers, with no leading "0"s
permitted (except that 0 is represented by "0").  So the syntax is
fairly limited, but of course you can encode anything within that
syntax.  (I'm tempted to say "If you're willing to tolerate
Microsoft-style alphanumeric hashes, you'll tolerate a sequence of
numbers.")

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

If you don't pursue your current application, nothing further will
happen, which is what you would want.  Officially, your internet-draft
would expire, though we're being sensible now and archive I-Ds
indefinitely, which is useful for understanding past proposals.

I've started to sound out the idea of having a generalized URN format
based on enterprise numbers or DNS names on the "main" URN list
([email-masked]).  That hasn't generated a lot of discussion yet, though
there is some interest.

However, I recently stumbled into another alternative which I think
may solve your problem straightforwardly:

> Date: Tue, 11 Mar 2014 14:01:22 -0600
> From: Peter Saint-Andre <[email-masked]>
> To: Joel Kalvesmaki <[email-masked]>
> Subject: Re: URN UUID question
> Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/q9TdGA2GIMP-fCBuxc8-Me1IDYs
> Cc: [email-masked]
> 
> It sounds to me as if you might want to use the 'tag' URI scheme:
> 
> https://tools.ietf.org/html/rfc4151

Essentially, the idea is that you pick some date on which DTS,
Inc. owned "dts.com", for example 2014-01-01.  Then DTS can create
URIs that look like this:

    tag:dts.com,2014:{string}

The reason that a date is needed is that DTS, Inc. does not
*permanently* own the DNS name, so you need to add a date to the DNS
name to get a pointer to the enterprise.  But the "tag" syntax allows
the month and day to be omitted if they are 01.  And for consistency,
you want to use the same date for all the URIs.

Of course, see RFC 4151 for all the details.

As you can see, the URIs point to dts.com.

Officially, these are "universal resource indicators" rather than
"universal resource names" because there isn't a set of rules imposed
by the IETF to ensure that each identifier has exactly one meaning for
all time, etc.  But I don't think that makes any difference in
practice for you.  You can define a resolution mechanism if you'd
like.  And I know of no context where a standard requires a URN and
will not accept a URI.

Conveniently, all of this machinery is already defined and approved,
so you can start using with it without any additional work.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 19 Mar 2014 17:41:05 -0400

> From: "Martin J. Dürst" <[email-masked]>

> predecessors have minted, nor would they care.

A workable solution is to attach to the domain name the date on
which the organization had possession of the domain name.  That
solution is used in the "tag" scheme (RFC 4151):

But in general, domain names shouldn't be incorporated into permanent
identifiers.

Dale