Re: urn:oid:

[[e-mail] (Dale R. Worley)]

> From: Phillip Maness <[e-mail]>

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

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

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

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
([e-mail]).  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 <[e-mail]>
> To: Joel Kalvesmaki <[e-mail]>
> Subject: Re: URN UUID question
> Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/q9TdGA2GIMP-fCBuxc8-Me1IDYs
> Cc: [e-mail]
> 
> 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