Subject: [urn] URN NIDs for private enterprises

From: [email-masked] (Dale R. Worley)
Date: Mon, 3 Mar 2014 15:36:43 -0500 (EST)

This is an idea that I floated in a previous message to urn-nid while
we were discussing a NID request from a business.  I want to extract
it and present it as a stand-alone message so I can get more feedback
on the idea.  I've just joined the URN mailing list, so I'm not up on
the discussions of the revisions of the URN RFCs.  Perhaps this issue
has been dealt with already.

The question is, "What do we do if an enterprise (business or other
private 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

Comments?

Dale

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Mar 2014 04:06:47 -0500

--On Monday, 03 March, 2014 15:36 -0500 "Dale R. Worley"
<[email-masked]> wrote:

> This is an idea that I floated in a previous message to
> urn-nid while we were discussing a NID request from a
> business.  I want to extract it and present it as a
> stand-alone message so I can get more feedback on the idea.
> I've just joined the URN mailing list, so I'm not up on the
> discussions of the revisions of the URN RFCs.  Perhaps this
> issue has been dealt with already.
> 
> The question is, "What do we do if an enterprise (business or
> other private 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"

Dale,

For reasons that should be clear if you review the archives (or
that I'm happy to review f2f), I'm a little reluctant to
institutionalize sub-NIDs, especially sub-NID trees that are
managed by IANA rather than the registrant.  To summarize the
non-technical part, I think it would lead us down the same path
that the DNS has gone since ICANN took over, e.g., demands to
use "example." rather than "example.foo." and "example:" rather
than "
"enterprise:example:".

I'm not sure what you intend from your examples but, if there is
any hint of claiming equivalence between "enterprise:ariadne:"
and "enterprise:14490:", that is a whole different can of worms.
Use of the first would embroil IANA in the whole trademark mess
about which ICANN has given us a lot of education.  The day
someone on that side of the gap decided that enterprise names
could be profitably monetized or used in an extortion scheme..
well, we just don't want to go there.

Counter-suggestion, which keeps the process lightweight: we
break the "informal" (urn-NNNN:) URN space into blocks so that,
for example, the range from 1 - 9999 (or 1-999999 if we are
really nervous and want to be cautious) dedicated to
sequentially-assigned "informal" spaces as specified in the
current versions of 3407bis.  Values above that may be obtained
by:

(i) Obtaining an enterprise number from that IANA registry.
(ii) Requesting an informal namespace with NID
    urn: <10000 + enterprise-number>: 
or
    urn: <1000000 + enterprise-number>:
from IANA. 

That is consistent with the general informal namespace model
(and would require only a few extra sentences in 3406bis and no
change to URN-handling applications).  It just uses a second
assignment model for a different range.  IANA's URN workload for
such namespaces doesn't take it into trademark or name-ownership
territory (whatever the risks are in that area are in the
existing enterprise number registry).

An alternative with the same general theme would be to use the
entire ISO-IANA-arc private enterprise number (see either RFC
2578 or the IANA registry at
http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers),
giving you an NID of
   urn-1.3.6.1.4.1.14490 
We'd have to sort out whether that syntax made sense and whether
it would be disruptive elsewhere, but, with a few lines of
additional specification, it would have the additional advantage
of allowing anyone who was offended by needing to register in a
tree associated with a US Government entity [1] could register
in another tree of their choice and, at most, notify IANA that
the URN form was going to be in use.  That eliminates the need
to split the informal space by ranges and eliminates the need
for IANA to arbitrate uniqueness in anything but its own arc.

Would that help?
    john

[1] Incorporate the entire "Internet Governance" mess, and
especially the "globalization of IANA" part (see Thursday
"Internet Governance Update" session for some pieces) by
reference.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 7 Mar 2014 13:14:22 -0500 (EST)

I'll prepend this note that this discussion is not purely theoretical,
it was triggered by the request by DTS, Inc. for a URN namespace with
NID "dts" (naturally enough).  Oddly, neither the specific proposal or
my message summarizing the more general questions elicited any
discussion (other than from myself and the registrant).  I think that
some feedback from the URN WG is in order, because otherwise the DTS
URN proposal as it stands now is likely to pass by default.

Dealing with a number of issues in no particular order:

> From: John C Klensin <[email-masked]>
> 
> that I'm happy to review f2f),

The threads that I have found that are relevant are
"[URN] WG last call: URN Namespace Definition Mechanisms"
https://www.ietf.org/mail-archive/web/urn/current/msg01355.html
"[URN] focus the question"
https://www.ietf.org/mail-archive/web/urn/current/msg01334.html

If you know of others, it might be worth pointing to them on this
list.

> I'm a little reluctant to
> managed by IANA rather than the registrant.  

I see that there has been considerable opposition to making URNs
hierarchical.  For example:

| From: "Larry Masinter" <masinter at parc.xerox.com>
| Date: Sat, 10 Oct 1998 22:21:31 PDT
| 
| > The draft even clearly mentions the possibility of subdividing  
| > (partitioning) namespaces.
| 
| draft-ietf-urn-nid-req-06.txt clearly mentions the possibility
| of subdividing the name space in order to delegate the assignment
| of uniqueness, as happens, for example, with ISBN numbers, where
| each publisher is delegated the authority of keeping their part
| of the name space unique.
| 
| However, in the case of urn:us:ssn:001-101-4452 and
| urn:us:ca:license:7URN123, this is not merely a delegation
| for the purpose of uniqueness, but a separation of the namespace
| into subspaces which will differ for every attribute in the
| template given in draft-ietf-urn-nid-req-06.txt.
| 
| If you go through the fields in the draft:
|    Registration Information
| [...]
| 
| It would seem that these can't be easily handled by  having a 
| country-code URN namespace then having the country parcel it out
| for country-unique spaces. I could imagine reserving the names
| "xx-<blah>" for country xx, so that "us-ssn" would be recommended
| over "ssn" to distinguish it from "dk-ssn", but I'd think that
| each of these should be registered separately.

On the other hand,

| From: urn-list at faerber.muc.de (Claus AndrC) FC$rber)
| Date: 10 Oct 1998 14:36:00 +0200
| 
| I don't think so. The propsed Mechanisms are so open that you could  
| certainly register a namespace that -- as a consistent set of features  
| -- is subdividable into several namespaces by the same rules.
| 
| The draft even clearly mentions the possibility of subdividing  
| (partitioning) namespaces.

And it's true that RFC 3406 "URN Namespace Definition Mechanisms"
mentions partitioning:

      Possible answers include, but are not limited to:

      -  exposition of the structure of the identifiers, and
         partitioning of the space of identifiers amongst assignment
         authorities which are individually responsible for respecting
         uniqueness rules

> To summarize the

> IANA's URN workload for
> [informal] namespaces doesn't take it into trademark or name-ownership

Yes, I can see the maze of problems that could arise if NIDs were
assigned that were intended to match the names of ordinary commercial
enterprises.

> and "enterprise:14490:", that is a whole different can of worms.

In regard to equivalence per se, I have no intention to create
"alternative spellings" when that can be avoided.  It's true that
there is no rule that one object/resource may not be named by multiple
URNs, it's generally good to avoid that, excepting for "lexical
equivalence" that can be specified by a closed algorithm (that is, one
that does not need to reference a time-varying database, as the
equivalence of "enterprise:ariadne" and "enterprise:14490" would).

The various examples I gave were indended to be *exclusive*
alternatives for how we might allocate URNs.

> assignment model for a different range.  

Thanks for pointing me toward the informal NID group, as that largely
has the semantics I'm looking for.  I don't like the idea of "1000000
+ enterprise-number", because people are likely to get it wrong, as
well as using more characters than is necessary.

Perhaps we could define a new group of informal NIDs,
"ent-<enterprise-number>"?  This would avoid the "add 10,000" problem
without otherwise disturbing the semantics and registration procedures
for informal NIDs.

> for IANA to arbitrate uniqueness in anything but its own arc.

If we're going to use OIDs, I would suggest we tell registrants that
they should register an enterprise number and then they would be able
to use OID-based URNs for their resources:
    urn:oid:1.3.6.1.4.1.14490.xxx.yyy.zzz 
That is already specified; essentially their enterprise number
registration gets them an OID delegation, which allocates to them a
URN sub-space.

One question which I see is that there has generally been some
opposition to registrations which say "I want to have a namespace, but
I'm not going to tell you anything specific about its use."  This
tends to happen automatically if a NID is going to be partitioned into
sub-NIDs, because the different sub-NIDs have different answers for
the various registration questions:

| From: "Larry Masinter" <masinter at parc.xerox.com>
| Date: Tue, 13 Oct 1998 15:20:37 PDT
| 
| [The NID registration] document asks the registrar of a namespace a
| lengthy and detailed set of questions, which include questions about
| the syntax, semantics, matching rules, uniqueness considerations, etc
| etc.
| 
| If the namespace owner actually intends to set up a bunch of delegated
| namespaces that each individually have their own different answers to
| each of those questions, and so answers each of the questions "it
| depends on the sub-namespace I'll delegate", then what is the purpose
| and use of having the form at all?

But it turns out that a lot of NID registrations already have
minimally-informative registrations.  Of the first 10 registrations
listed at
http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
today, only one ("epc") provides any syntax (although a number only
provide links to external documents, all of which 404).

So in a sense, there's not much information that we genuinely require
in a NID registration, and I think that it would be reasonable to have
an automatic NID registration, derived from enterprise number
assignment.

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 08 Mar 2014 12:01:51 -0700

On 3/7/14, 11:14 AM, Dale R. Worley wrote:
> discussion (other than from myself and the registrant).

I think folks were busy with the IETF meeting and preparations for that. 
At least, I know I was!

> I think that

Side topic: I think it's confusing to have two lists for URN-related 
discussion.

<snip/>

> registration gets them an OID delegation, which allocates to them a

If we already have something that will work, I suggest we use it.

> an automatic NID registration, derived from enterprise number

There are two topics here:

(1) What we require for registration of a formal NID. Historically, 
registrants have needed to specify some public benefit, if you will, and 
to document their processes to some extent. That still seems beneficial 
to me.

(2) What we require for (automatic?) registration of an enterprise NID. 
If these are truly private and not intended to be public in any way 
(although such things often leak out into the public space, see RFC 6648 
for related considerations) then a less onerous registration process 
might be sensible.

FWIW, then I worked at Cisco I had to actively stamp out usage of 
(private, internal) XML namespaces like urn:cisco:* - naive developers 
though they could create such things out of thin air. Discouraging such 
behavior would be a good thing. If "automatic" registration via the OID 
namespace identifier (RFC 3061) moves us in that direction, that might 
be helpful (but one reason people try to use URNs like "urn:cisco:*" 
even when the NID doesn't exist is that it seems so straightforward and 
developer-friendly).

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Mar 2014 14:05:53 -0600

On 3/12/14, 1:50 PM, Dale R. Worley wrote:
> In regard to providing a method for private enterprises to
> automatically have a space of URNs:
>
>> From: Peter Saint-Andre <[email-masked]>
>> Date: Sat, 08 Mar 2014 12:01:51 -0700
>
>>> [...]
> That is sensible.  It seems to me that you may have solved the problem
> in another message:
>
>> 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
>
> The "tag" scheme lets DTS, Inc. use URIs with the format (among others):
>
>      tag:dts.com,2014:{pchar-string}
>
> which seems to me to solve all their practical problems.  Formally,
> they're URIs not URNs, but that seems (1) to have no practical
> consequences, and (2) to avoid any philosophical problems regarding
> uniqueness/persistence, public documentation, public syntax, public
> benefit, etc.
>
> I've proposed this to the DTS people on urn-nid.  Let's see what they
> have to say.

Thanks.

The 'tag' scheme seems to fit the bill for a lot of folks, but folks 
don't know about it. Perhaps it needs a better marketing department.

Peter

---

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

> If we already have something that will work, I suggest we use it.

I will suggest that as a possibility to the DTS people.

> to document their processes to some extent. That still seems beneficial 

I agree with the sentiment.  But looking at the registration for
urn:3gpp (which I choose only because it is the first namespace listed
in the registry), it contains essentially no information about any of
those issues.  And yet, I see no reason not to approve 3GPP's
registration.

> for related considerations) then a less onerous registration process 

I think that there is a complication:  while a set of URNs may be
"proprietary", in that they're defined and used in a way specified by
a private enterprise, the "ecosystem community" around the enterprise
that uses those URNs may be quite large, possibly open-ended, and the
URNs themselves may be flying around the greater Internet, and appear
in contexts that are to some degree visible to parties/systems outside
of the ecosystem.  So the difference between "public usage" and
"private usage" is not clear-cut.

Referring to your paragraph I quote below, if Google wants to name an
XML namespace and publish its DTD, it needs a piece of namespace that
it can be sure doesn't overlap with anyone else's namespace.

> even when the NID doesn't exist is that it seems so straightforward and 

I was at a company that needed to name XML namespaces, and we used
HTTP URLs, since we already had the registration for the "host" DNS
name.

In a sense, the public benefit of this proposal is that it easily
allows enterprises to create URNs that won't collide with URNs created
by any other enterprise.

Dale

---

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

Dale