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

From: Sean Leonard <[email-masked]>
Date: Thu, 11 Sep 2014 23:27:47 -0700

IETF 90 was my first URNBIS meeting. It was an...interesting experience, 
so I decided to join this list.

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:sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 *
urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 **

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

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

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

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?

Thanks,

Sean

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Sep 2014 08:33:41 +0200

On 2014-09-12 08:27, Sean Leonard wrote:
> ...
> ...

RFC 6920?

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Fri, 12 Sep 2014 00:24:00 -0700

>> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 **

That's a URI.

I want a URN.

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?

Sean

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Sep 2014 09:54:10 +0200

>>> urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479 **

Yes.

> I want a URN.

Why?

> these kinds of naming schemes.

Which I agree with.

> URNs uniquely and persistently identify things, don't we have a match?

+1; I never got why people were upset about urn:uuid.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Sep 2014 05:18:17 -0400

Sean,

Just to help me understand, two questions...

--On Friday, September 12, 2014 00:24 -0700 Sean Leonard
<[email-masked]> 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: ...

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?

> 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
<[email-masked]> 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:
> 

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.

> 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

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

---

From: Sean Leonard <[email-masked]>
Date: Fri, 12 Sep 2014 08:35:02 -0700

Thanks John. Let me try to respond to a subset of your

> a separate namespace registration? and, if so, what is it?

The full repertoire of UUIDs [RFC 4122] is 128-bits. When I say the 
"full namespace", I mean the full range of values that a UUID can take 
on. The versions spelled out in RFC 4122 require that the bits Msb0=1 
and Msb1=0 be fixed; however, nothing stops Microsoft Corporation (for 
example) from using Msb0=1, Msb1=1, Msb2=0 from creating UUIDs for its 
own purposes.

UUIDs of the RFC 4122 variant have five versions:
1 = time-based [including a MAC address]
2 = DCE Security version, with embedded POSIX UIDs
   the structure is not specified
3 = MD5 hashing
4 = random
5 = SHA-1 hashing

The result is that UUIDs can easily contain:
- a top-down, hierarchically assigned and registered set of identifiers 
(based on V1 MAC address)
- a set of identifiers that are based on a universal, monotonically 
increasing counter (V1 and V2 timestamps)
   http://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm
http://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01
- a set of identifiers that have local uniqueness and are extremely 
efficient (V2):
    clock_seq_low and time_low fields in V2 embed the POSIX UID or GID.

Chapter 5:
By this embedding of local host IDs in (security-version) UUIDs, local 
host identity information (privilege attributes) can be derived from 
UUIDs in an especially straightforward and efficient manner (as opposed 
to, say, going through an auxiliary ID mapping table, maintained either 
on the local host or elsewhere). (The embedding of local host IDs is 
specified above in the particular case of POSIX hosts; the embedding in 
the case of non-POSIX systems is not currently specified in DCE.)

Further:
Concerning the/uniqueness/of security-version UUIDs, see the discussion 
inPrivilege (Authorisation) Service 
(PS)<http://pubs.opengroup.org/onlinepubs/9696989899/chap1.htm#tagcjh_03_06>of 
the double-UUID identification scheme. The point of that discussion is 
that the security architecture of DCE depends upon the uniqueness of 
security-version UUIDs/only within the context of a cell/; that is, only 
within the context of the local RS's (persistent) datastore, and that 
degree of uniqueness can be guaranteed by the RS itself (namely, the RS 
maintains state in its datastore, in the sense that it can always check 
that every UUID it maintains is different from all other UUIDs it 
maintains). In other words, while security-version UUIDs are (like all 
UUIDs) specified to be "globally unique in space and time", security is 
not compromised if they are merely "locally unique per cell". This 
statement does not relax the requirements on implementations of 
security-version UUIDs, it is only a comment about the trust structure 
of DCE, namely, entities (security subjects and objects) need 
not/trust/that foreign RSs maintain globally unique UUIDs, only that 
their own local RS maintains locally unique UUIDs.

- a set of identifiers that are based on a deterministic mathematical 
process (V3 and V5 cryptographic hashing)
RFC 4122 leaves this extremely broad. Specifically, "names" are drawn 
from some "name space"; both terms are "broadly construed". The 
algorithm is:
1. figure out a way to generate a canonical sequence of octets in some 
common way for all named items in the name space
2. pick algorithm (MD5 or SHA-1)
3. hash octets
4. extract and fiddle with bits

- a set of identifiers that are based on large random numbers (V4)

All of these amazing things are possible! All in a UUID!

***
Regarding ISO/IEC 9834-8:2008:
All UUIDs are valid. They are not limited to Version 1 or any other such 
thing.

Clause 10:
10 Validation
Apart from determining if the variant bits are set correctly, and that 
the Time value used in a time-based UUID is in the
future (and therefore not yet assignable), there is no mechanism for 
determining if a UUID is valid in any real sense, as
all possible values can otherwise occur.

Clause 15 specifically states how to generate V4 random UUIDs. it also says:
– Set all the other bits of the UUID to randomly (or pseudo-randomly) 
generated values.
NOTE – Pseudo-random numbers may produce the same value multiple times. 
The use of cryptographic-quality
random numbers is strongly recommended in order to reduce the 
probability of repeated values.

ISO/IEC 9834-8:2008 provides for a Registration Authority to register 
UUIDs. 16.1.5: "The RA for UUIDs is responsible for a collision between 
registered UUIDs, but it is not responsible for a collision between a 
registered UUID and an unregistered UUID because it does not manage 
unregistered UUIDs. If such a collision occurs, the semantics associated 
with the registered UUID should have precedence; the semantics 
associated with the unregistered UUID value should not be used. Thus, 
the registration of an OID with a UUID does not ensure that the OID has 
more uniqueness than its UUID's uniqueness. The objective of the 
registration should be seen mainly as a means of publishing the UUID and 
its contents."

16.2.2: The RA's liability is disclaimed.
16.4 and 16.5: The RA operates a registration website.

ISO/IEC 9834-8:2012 changes stuff up. In the 2012 edition, "registered 
UUID" is removed, along with Clause 16 in its entirety. Apparently 
www.oid-info.com used to be the RA, but no longer. As of 2012, there is 
no distinction between registered and unregistered UUIDs. They are all 
the same. Uniqueness is guaranteed by the UUID's definition, not by the 
act of registration.

See <http://www.oid-info.com/get/2.25>.

In conclusion: UUIDs already have crypto hash and random number 
identifiers. (It also has locally-unique identifiers, see V2.) And 
because it does, so do URNs. And so do OIDs. And so do URIs. There is no 
need for a "uuidr" namespace because "uuid" does it already.

Perhaps this gets to a broader point: when you delegate authority over 
part of a namespace to a subsidiary authority, the subsidiary authority 
*can do whatever it wants*. You are basically trusting the subsidiary 
authority to follow the rules, both the rules that you made and made 
them agree to on condition of delegating the namespace, and the rules 
that the subsidiary authority declares itself to follow for its own 
purposes.

But the subsidiary authority can change its mind. And many times, the 
reasons why it changes its mind are not malicious, but in response to 
genuine technical or business needs that can be syntactically 
accommodated by the naming scheme and will be compatible with the vast 
majority of implementations that matter.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Fri, 12 Sep 2014 09:04:14 -0700

> <[email-masked]> wrote:
[SNIP]
> syntax.  But I'm not sure why you would think that was the case

Overall, the broader question for the group is not "what do or should 
the stanadards documents say?" but rather:
"why would someone make and use identifiers out of URNs, and why would 
someone make and use identifiers out of URIs?"

We're engineers...let's get right to the purpose, i.e., the utility of 
the things.

I am guided by a vague sense that URNs are for "uniquely naming things, 
so that computer systems (connected to the Internet) can identify the 
things, using a text-based string with no line breaks", while URIs are 
for "naming things in a uniform way, so that computer systems (connected 
to the Internet) can retrieve representations of those resources 
(dereferencing) or perform operations on those resources, using a 
text-based string with no line breaks".

It's a pointless exercise in an SDO that has "Internet Engineering" in 
its title to ask "what is this [made-up thing]?" as if they have some 
utility simply because some people thought of them. The whole point is 
to make computer systems connected to the Internet more useful.

Whether we say URNs are URIs, or URNs are not URIs, or whatever, it 
doesn't really matter. They need to have utility.

So overall the point is that, as a user of URI-based implementations, 
sometimes I want a URI's semantics, and sometimes I don't.

Let's say I want to identify a discussion about a Blue Screen after 
applying update KB2982791 to Windows 7 Home Premium 64 bit.

I can say:
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/blue-screen-stop-0x50-after-applying-update/6da4d264-02d8-458e-89e2-a78fe68766fd

Or I could also say:
{6da4d264-02d8-458e-89e2-a78fe68766fd}

Or I could also say:
urn:uuid:6da4d264-02d8-458e-89e2-a78fe68766fd

So what am I saying (and more specifically, what are computer systems 
connected to the Internet going to do), when I recite these magical spells?

A web browser knows how to deal with the http one. That's because it 
means "the web resource identified by this URI, which you can retrieve 
using HTTP". A UUID parser...not so much.

A UUID parser knows how to deal with the {} one. That is not an Internet 
standard; it's just the way that UUIDs are formatted. You know one when 
you see one. Its meaning is contextual...generally it means "the object 
associated with this UUID", or, it means "associate this UUID with the 
following object" (e.g., in COM interface declarations). A web 
browser...not so much.

But both UUID-aware systems and web browsers (URI implementations) know 
how to deal with the third one. That's because it means "the /thing/ 
that is named in the UUID namespace". The flexibility here is that you 
can use this form for Microsoft forum posts; you can use it for ABI 
interfaces; you can use it for DCE authorization identities (aka, 
security principals); you can use it even to identify XML namespaces. 
And generally speaking, you can use it anywhere where you can use a URI, 
including "unexpected" places like XML namespaces or parts of X.509/PKIX 
certificates. It is a significant efficiency advantage that you can 
reuse URI parsers to validate the syntax of the thing.

If you give a web browser urn:uuid:6da4d264-02d8-458e-89e2-a78fe68766fd 
and say "retrieve this" (implicitly, "retrieve this in such a way that 
the web browser can present it nicely"), perhaps the web browser knows 
how to resolve it...or perhaps not. But, the web browser has a *uniform 
way* to look up the resolution mechanism (perhaps via a web browser 
extension or via a web service) and pass that resolution mechanism a 
well-formed thing.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Fri, 12 Sep 2014 11:19:05 -0700

> Just to help me understand, two questions...
I think there were more than two questions. :)

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

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

> that exclude the equally-reasonable requirements of other

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

[SNIP]
>> Should 3406bis be written to simply accept that,

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

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 12 Sep 2014 14:55:56 -0400

> From: Sean Leonard <[email-masked]>
> 

I'm not perfectly clear what you want here.

If you want names for cryptographic hash functions, you can use the
urn:oid:... identifiers for the hash functions that are given in RFC
4055 section 3.1.

For the hashes of things themselves, the ni: scheme seems suitable.
Of course, they aren't in the urn: scheme, but that's a technicality,
they have the properties of a name.  I suppose it's an interesting
question whether the ni: identifiers are truly unique, because they're
only unique in practice, to a high probability.  "Are you willing to
bet your life on it?"

As for "unbroken", something isn't a "name" if it can be deallocated.
And since any algorithm might be broken in the future, you can't
require only "unbroken" algorithms be used, as that condition could
change.

As for large random numbers, what exactly do you want?  You can denote
them with data: URIs of course, or you could assign them names using
any of the existing mechanisms.  But I don't think either of those is
what you intend.

Perhaps if you wrote a draft about this it would make your intention
clearer.

Dale

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Sep 2014 15:33:47 -0400

--On Friday, September 12, 2014 11:19 -0700 Sean Leonard
<[email-masked]> wrote:

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

Speaking personally, this, in combination with 

	-- your earlier observation that, if one delegates a
	namespace to a particular organization or process, one
	effectively loses the ability to second-guess particular
	entries in that namespace and 
	
	-- the more general realization that registration to
	prevent the same label (in this case NID) from being
	accidentally used for two different things is a good
	thing even if the definitions are not of the quality one
	might like

are the reasons some of us have been pushing for a registration
process in which the IETF community could offer advice on
documentation and encouragement to do things in other ways but
would not have a "approve" a particular namespace, its
management, or its definitions or restrictions.

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

It does clarify the issue.  As to free-for-alls, I agree, but
setting up the IETF community as arbiters of taste, especially
when the community may have a shortage of knowledge about the
particular issues associated wit the namespace but surplus of
opinions on the subject, is not a solution either.  My own hope,
which I think is more or less consistent with 3406bis, is that
we will move toward to review committee procedure that can
supply advice and some persuasion about better and worse ways to
handle things, but that cannot block a registration.   Of
course, blocking some community from inventing an NID and using
it in a URN is close to impossible (and the reason I make cracks
about the powerful protocol police).

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

Agreed, modulo my being concerned about setting up a "URN tsar",
aka a single appointed expert whose authority goes to his head,
rather than an advisory and consultative process.

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

I hope we have learned enough by now that no one disagrees with
you.  Because people forget, it clearly needs to be made clear
in the document.  My notion of a consultative process during
namespace registration would include some "are you sure you
really want to do that?" questions if someone came along today
with a plan about a namespace based on MD5, but, until someone
discovers perfect foresight, it probably shouldn't go much
future than that, e.g. to reject a contemporary hash on the
grounds that it might not be good enough to guarantee uniqueness
for all eternity.

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

First of all, we aren't at "Specification Required" today, we
are at "IETF Consensus".  IMO, _that_ bar needs to be lowered
for all sorts of reasons.  The difficulty with a "reasonable
engineers" standard is that many reasonable engineers (and
reasonable other people) tend to get narrowly focused on the
particular problems they are trying to solve and lose sight of
other issues.   That is precisely the reason the IETF tries to
insist on cross-area review for standards-track documents.

My preference would be that we have two procedures:

(1) For something that is merely a URN encapsulation of a
standard from some body whose review and approval procedures the
IETF considers competent (we use the term "recognized standards
developer" or something like it for Media Types), there should
be a _really_ fast track.   If what they want from a URN is
anything beyond "embed our established identifier as the NSS"
(i.e., "fragments", "queries", or "path segments"), then they
have responsibility for defining those in a stable way, but I
don't think we need to care what they pick, whether it is part
of their base standard that establishes the name space, part of
a technical report or supplemental standard, or something
published somewhere else, i.e., in the RFC Series.  I'd strongly
prefer that such encapsulated namespace URNs conform to the
syntax restrictions of 3986 and 4121bis and think we should be
willing to offer advice to help that happen, but we need to
recognize that we have no power to stop such a body from doing
anything it decides is needed.

(2) For anything else, we establish an "expert review committee"
that consists of volunteer experts from the URN-experience
community, ideally representing multiple perspectives.  Their
role would be to review applications for registration and to
work with applicants to improve the quality of those
registration applications and, where appropriate, to raise
questions and offer advice about how that particular URN
namespace might be defined and used.  Part of that is close to
"Specification Required", but the focus should be on getting the
to best specs and best way of defining the URN that is possible
under the circumstances rather than on "approval".  The
committee might try to talk someone out of doing something in a
particular way, but should not have (or exercise except under
the most unusual and egregious of circumstances) the ability to
say "no, registration rejected".

I think that model would meet your needs.  Plus or minus fine
tuning, I think it is consistent with 3406bis.  It does go a
little further than we have been going because it recognizes
that, should some namespace-owner be determined to do something
stupid (e.g., in sufficient violation of 3996 syntax to cause
generic parsers problems), we can't stop them -- our only choice
is ultimately whether to register what they are doing (perhaps
prevent inadvertent conflicts in NID strings) or refuse to do
that on the theory that our lack of implicit endorsement might
accomplish something.

    john