Re: [urn] URN NIDs for private enterprises

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

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 <[e-mail]>
> 
> For reasons that should be clear if you review the archives (or
> 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
> institutionalize sub-NIDs, especially sub-NID trees that are
> 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
> 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:".

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

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

> IANA's URN workload for
> [informal] 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).

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.

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

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.

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

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.

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

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