Re: [urn] I want URNs for hashes and large random numbers

[John C Klensin <[e-mail]>]

Sean,

Just to help me understand, two questions...

--On Friday, September 12, 2014 00:24 -0700 Sean Leonard
<[e-mail]> wrote:

>...
>>> Here is what I want: I want (unbroken) cryptographic hashes
>>> and large random numbers to be usable as URNs. Specifically,
>>> I want things like: ...
>>> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 **
>>> ...

Ok.  I don't know if this is a proper use of the UUID namespace
defined in RFC 4122.  On skimming, it (and ISO/IEC 9834-8:2004)
seems to require more structure than "a large random number"
because of the requirement for a distinguishable time stamp (see
below).  But, if it is not, then I don't see anything that would
prevent you from creating a new namespace, say, "uuidr", whose
NSS would be a cryptographic hash or large random number.  Do
you see a restriction that prevents such usage (with or without
a separate namespace registration? and, if so, what is it?

>> RFC 6920?
> 
> That's a URI.
> 
> I want a URN.

Why do you see the distinction as important?  For, e.g., the
library community, at least part of the answer is that they have
been using the URN scheme, they have published specs explaining
what they are doing (at least two of them in terms of very
widely used ISO standards), and there are enough millions of
"urn:"-scheme identifiers out there to make "why don't you just
invent a new scheme type with different rules?" more a useful
rhetorical exercise than a practical alternative.

Now, had you said that URIs don't meet your needs but URNs
might, that would reinforce at least the desire to separate
syntax.  But I'm not sure why you would think that was the case
(if you do).

> Specifically I want the definition of URN to be able to
> accommodate these kinds of naming schemes.
> 
> It's not a challenge to the ni: URI. It's just being
> realistic: people are using mathematically deterministic
> processes to uniquely and persistently identify (i.e., name)
> things in real life already. So if URNs uniquely and
> persistently identify things, don't we have a match?

Again, what do you believe bars that use?   Is it in 2141, 3986,
or one of the documents the WG is now working on?  Or are you
just trying to warn against our making some change that would
make such a URN namespace invalid?

Going back to your original note in this thread:

--On Thursday, September 11, 2014 23:27 -0700 Sean Leonard
<[e-mail]> wrote:

> and I want identifiers that are valid in their respective
> namespace, that represent (unbroken) cryptographic hashes or
> large random numbers, to be valid URNs as well, without any
> complaints:
> 
> urn:oid:2.25.324969006592305634633390616021200786553 ***

It is one of several substantive points that have gotten lost in
the 3986 debate, one that probably should have been on my
"decisions to make" list as "do we still believe this?", but one
of the reasons 3406bis is moving toward a registration model
(rather than the IETF Consensus one called for in 3406) is
precisely to allow easy registration and use of NIDs for
externally-defined namespaces.  Your example illustrates, I
think, why some sort of registration procedure is desirable.
While your OID usage above appears to conform to the "oid" NID
definition of RFC 3061, your UUID one does not appear to conform
to the "uuid" definition of RFC 4122 because the latter
requires, at least, an identifiable time-stamp rather than a
full-length-of-NSS random string (or hash).  Reusing an existing
NID with a new namespace definition is probably a bad idea, at
least unless the namespace definition can be updated in a
non-conflicting way.  But, again, nothing should prevent
creating and registering an NID that creates a URN namespace
from some specific established and well-defined namespace.
Indeed, IMO, we should make that as easy and painless as
possible.

> * not an actual URN, yet
> ** actual URN
> ** actual URN -- this one is the aforementioned Version 4
> Random UUID in decimal in the OID arc. It's an OID-y way of
> saying urn:oid:uuid:f47ac10b...

ok.  See above.

> I reviewed some of the e-mails over the past year. Nobody has
> really said anything about this. However, some people tend to
> hem and haw when they see these kinds of things without some
> kind of "registration authority" that makes some sort of
> "promise" not to cause collisions.

I think the discussions may have been longer ago than that.  One
of the disadvantages of a WG that moves this slowly is that
older discussions and therefore sources of conclusions get lost.

> I reviewed draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09:
> Section 3:
> 
>     2.  The "consistent assignment" constraint means that an
> identifier
>         within the namespace is assigned by an organization or
> created in
>         accordance with a process or algorithm that is always
> followed.

> This tells me that an organization is not required; it is
> sufficient to define a process or algorithm (e.g.,
> cryptographic hashing operation, or "pick a random large
> number") that guarantees uniqueness within certain
> constraints, and call it a day.

I believe that was the intent.   It is also an excellent
example, IMO, of why we have to be careful that the needs and
perspectives of one particular cluster of URN namespaces,
definitions, and user community do not define things in ways
that exclude the equally-reasonable requirements of other
communities.

> So are we okay with these kinds of URNs now? If not, what can
> we do to ensure that urnbis says that these types of things
> are okay?

I await a new version of 3406bis but would be surprised and
disappointed if it changed the requirement you quote in a way
that would exclude the sorts of generated strings you are asking
for.   I think they do raise another issue: 3406bis requires
(and, IMO, should require) that there be documentation for a
namespace.  Consistent with moving away from the view that that
the IETF is the center of the universe and is expert on
everything, that documentation could be just a reference to an
external specification, rather than an RFC.  Now, suppose there
is a spec somewhere that describes the "foobar" namespace and
that says "no registration authority needed, no registration or
assignment process needed because these NSS strings will always
be unique".  Should 3406bis be written to simply accept that,
i.e., to allow pointing to an en external specification and, if
what it specifies is not unique, assume it is Someone Else's
Problem.   Or should there be a requirement for an explanation
of why the string is [sufficiently] unique and under what
conditions (e.g., the likelihood of collisions with a
cryptographic hash is not zero but is calculable) and some
serious attempt to review that explanation?

best,
    john