Re: urn:oid: (Dale R. Worley) Wed, 19 March 2014 21:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C69A1A07E2 for <>; Wed, 19 Mar 2014 14:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cEoxuBwC3iL0 for <>; Wed, 19 Mar 2014 14:40:12 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:24]) by (Postfix) with ESMTP id 364E51A07FF for <>; Wed, 19 Mar 2014 14:40:11 -0700 (PDT)
Received: from ([]) by with comcast id fQd91n0030vyq2s51Zg2ZR; Wed, 19 Mar 2014 21:40:02 +0000
Received: from ([]) by with comcast id fZg11n00q1KKtkw3RZg10p; Wed, 19 Mar 2014 21:40:02 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s2JLe1EI012694; Wed, 19 Mar 2014 17:40:01 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id s2JLe0fu012691; Wed, 19 Mar 2014 17:40:00 -0400
Date: Wed, 19 Mar 2014 17:40:00 -0400
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Phillip Maness <>
In-reply-to: <520A56052CF01E42B1C128F990FBE681A4715F92@LAX-EXMB02.dts.local> (
Subject: Re: urn:oid:
References: <520A56052CF01E42B1C128F990FBE681A4715F92@LAX-EXMB02.dts.local>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1395265202; bh=QNedqWPlATk2xglGYYarjWWlr8kE0cAw/8avnMVQNuI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Oy8mj+FH0gJKKv1fAlgvr+Y2qPLHnfJXxGBhXYfLR6eIpx34XnNEI1DFJq+6vPGFT +D7AZzp4R16zpAtfZ/sifzsDL6lLCnJfZB/JsZi/3ZI43hWESvdoxx53HRJOLa4+2R StXx6KY21VRwjJ7NYp8oOvKp35uWf0JUOoEQHhKKhuxFczKM+dy98MhtOiVFksd1Wv +QtNqkh/QfPkkKwek0nM7ceNMJQ9ufyQkVrkZuVeLu3l7Z3rXzAqcFdyAJ+2KTZb4K 5QBxC8NyehWICEW8uwo04bcPaavpGlfBlKGHZAfIm6MYCeberz2NtfrufmLiJ/MJgY TLjbVTmr7UcXg==
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, 19 Mar 2014 21:40:15 -0000

> From: Phillip Maness <>

> 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,
but it wasn't there.

It looks like the way to update a private enterprise number is to go
to the application page
and then click on "Modify Private Enterprise Number (PEN)" near the

> So it seems that we can create a urn as
> urn:oid:{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

> 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
> 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
(  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 <>
> To: Joel Kalvesmaki <>
> Subject: Re: URN UUID question
> Archived-At:
> Cc:
> It sounds to me as if you might want to use the 'tag' URI scheme:

Essentially, the idea is that you pick some date on which DTS,
Inc. owned "", for example 2014-01-01.  Then DTS can create
URIs that look like this:,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

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.