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

[Sean Leonard <[e-mail]>]

On 9/12/2014 2:18 AM, John C Klensin wrote:
> Sean,
>
> Just to help me understand, two questions...
>
I think there were more than two questions. :)

[SNIP]
>
>> 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?

Over the years I have made a couple of URN proposals. One source of 
pushback has been that when the URN uses some large random number or 
cryptographic hash, the assignment process does not "guarantee" enough 
uniqueness. Some respondents said that you need to have an organization 
or an IANA registry doling out identifiers. (There were/are other 
issues, but they are out-of-scope for this discussion.)

If you compare RFC 3406 and and 
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09, it seems clear that 
non-human processes are permitted, so long as they provide "consistent 
assignment"--organizations are no longer required. Compare, in 
particular, Page 5 of RFC 3406 with Page 4 of the urnbis draft.


>
> 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.
[SNIP]
(some of the premise of the text was incorrect--hopefully my description 
of UUIDs clarifies that issue)

All I'll say is that we need some standards. URNs shouldn't be a 
free-for-all.

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

Yup. And this is a reasonable requirement, based on engineering 
discipline and experience.

[SNIP]
>> 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?

Per the above, the metric that I advocate for is "engineering 
reasonableness". Persistence and location-independence (specifically, 
independent of Internet topology) are clear and desirable goals for 
URNs, that URLs like http, ldap, gopher, ws, snmp, dns, file, and others 
lack. (The commonality with the URLs mentioned is that they use // 
syntax with an authority part; thus, they are intended to identify 
resources accessible via the Internet using IP or DNS.)

Anyway though, to get that persistence, you have to delegate the 
allocation of names using a process. All I'm saying is that processes 
based on natural phenomena, i.e., bounded and describable by physics, 
mathematics, or other sciences, are just as reliable as commitments by 
human organizations. Organizations (being made up of humans) fail; 
organizations make mistakes; organizations change their minds. Natural 
phenomena don't change like that--they have other problems. Sometimes 
natural phenomena (i.e., MD5) fail spectacularly. But the commonality 
between organizations and natural processes is that for engineering 
purposes, they're good enough.

In the case of large random numbers, as long as the address space is 
large enough, the probability of collision is small enough, that it's 
good enough for all practical intents and purposes. The same can be said 
of cryptographic hash operations (in fact that is the engineered purpose 
of a cryptographic hash operation, and what distinguishes a 
cryptographic hash from a non-cryptographic one).

Honestly, engineering reasonableness is achievable by using the 
Specification Required standard, as long as the people ratifying the 
standard are reasonable engineers. :-) I don't think that 
rfc3406bis-urn-ns-reg needs to lower the bar. We just need to accept 
that there is more than one way to generate identifiers that are unique 
within the bounds that matter for engineered systems.

Sean