Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00.txt

From: Andy Newton <[email-masked]>
Date: Tue, 14 Aug 2012 09:59:14 -0400

With co-chair hat removed ( I think I left it somewhere in Paris ):

On Jul 31, 2012, at 12:23 PM, Peter Saint-Andre wrote:

> FYI and as previously mentioned. If approved, this document might enable
> us to remove experimental namespace identifiers from 3406bis.

Larry Masinter made a statement at the APPSWG about URNs that I thought was profound and missing from the URN discussions. Hopefully summarizing his statement correctly: each URN NID should be tied to a naming authority for the purpose of resolving collisions and errors in the future. If true, the UUID NID is a mistake, and I think this would be doing the same.

Given that URNs are suppose to have permanence or persistence or whatever we are calling it today and a resolution mechanism, this desire to shoehorn identifiers that need to qualify as a URI into the URN system might be wrong. An identifier that must be a URI does not necessarily need or have all the properties to be a URN. Just an observation.

-andy

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Aug 2012 09:47:03 -0600

On 8/14/12 7:59 AM, Andy Newton wrote:
>> FYI and as previously mentioned. If approved, this document
>> might enable us to remove experimental namespace identifiers
>> from 3406bis.
> 
> Larry Masinter made a statement at the APPSWG about URNs that I 
> thought was profound and missing from the URN discussions.
> Hopefully summarizing his statement correctly: each URN NID should
> be tied to a naming authority for the purpose of resolving
> collisions and errors in the future. If true, the UUID NID is a
> mistake, and I think this would be doing the same.

The UUID NID is not a mistake. Or, at least, Ted Hardie convinced me
of that last fall in a thread on this very list:

http://www.ietf.org/mail-archive/web/urn/current/msg01612.html
http://www.ietf.org/mail-archive/web/urn/current/msg01613.html
http://www.ietf.org/mail-archive/web/urn/current/msg01614.html
http://www.ietf.org/mail-archive/web/urn/current/msg01615.html
http://www.ietf.org/mail-archive/web/urn/current/msg01616.html

In the case of UUID, the algorithm itself guarantees uniqueness,
effectively providing a managed process for issuance of URNs.

I agree that example URNs are different here.

> Given that URNs are suppose to have permanence or persistence or 
> whatever we are calling it today and a resolution mechanism,

I am not convinced that URNs need to be resolvable.

> this desire to shoehorn identifiers that need to qualify as a URI
> into the URN system might be wrong. An identifier that must be a
> URI does not necessarily need or have all the properties to be a
> URN. Just an observation.

The idea behind the example URN namespace was to provide a way for
people to test URN processing, to use URNs in documentation, and to
remove the need for x-* NIDs. One could argue that such things do not
need to be URNs in the first place, and I'd be open to that argument,
in which case I'd also argue for removing experimental NIDs. At that
point I think we'd also say that example URNs belong under specific
NIDs (e.g., in my world urn:xmpp:example) and could be issued by the
relevant authority for a given NID, thus obviating the need for an
example NID.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Aug 2012 07:50:12 -0400

On 08/14/2012 09:59 AM, Andy Newton wrote:
> whatever we are calling it today and a resolution mechanism, this 
> desire to shoehorn identifiers that need to qualify as a URI into the 
> URN system might be wrong. An identifier that must be a URI does not 
> necessarily need or have all the properties to be a URN. Just an 
> observation.
+1

URNs were intended to be _resource names_, i.e. names of resources 
rather than merely unique identifiers.  The expectation was that such 
resources would generally be at least potentially accessible over the 
network, and that it would be possible to resolve such names to resource 
locations.   Everyone agreed that it should be possible to assign URNs 
to resources that were not resolvable, or at least not resolvable for 
the time being.  But the idea that URNs are appropriate for use whenever 
someone needed a unique non-resolvable identifier that qualifies as a 
URI, always has struck me as bizarre and contrary to the intended 
purpose of URNs.

Keith

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 16 Aug 2012 23:01:32 +0200 (MESZ)

(no hat)

> URI, always has struck me as bizarre and contrary to the intended

+1 (for both statements)

I already have responded similarly to the seminal email wrt this topic
(by Julian) that has motivated the creation this I-D (by PSA).

The above notes seem to be properly backed the following excerpts
from RFC 1737, "Requirements for Uniform Resource Names",
Section 2, "Requirements for functional capabilities":

|      ...
|      It is intended that the lifetime of a URN be permanent.
|      ...
|
|      URNs can be assigned to any resource that might conceivably
|      be available on the network, for hundreds of years.
|      ...

IMO, the concepts of "example URNs" and "testing URNs" seem to be
fundamentally incompatible with these requirements.  For the latter,
rapid software development for testing of namespace management and
resolution systems can be furthered by "early reservation/assignment"
of URN Namespace IDs by IANA (as soon as urn-nid mailing list and
expert review "thumbs up" is obtained for a new URN Namespace proposal.

Best regards,
  Alfred.

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2012 09:27:42 +0200

>> URI, always has struck me as bizarre and contrary to the intended

For the record: -1-

urn:uuid: is used a lot in practice, and I simply don't see a practical 
problem with it.

Are you saying these shouldn't be URIs in the first place, or that a 
separate URI scheme would have been ok (in which case those would be 
URNs as well, just not using the "URN" URI scheme, no?).

> expert review "thumbs up" is obtained for a new URN Namespace proposal.

The use case for reserved example URNs are specifications. It's much 
better if people use one reserved for this purpose than making up 
invalid ones (and that's what started this discussion).

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Aug 2012 07:57:36 -0400

On 08/17/2012 03:27 AM, Julian Reschke wrote:
> urn:uuid: is used a lot in practice, and I simply don't see a 
> practical problem with it.
>

I don't actually have a problem with UUID URNs in principle, so long as 
the mechanisms used to generate UUIDs actually ensure that they're 
unique. (If memory serves, they do, but it's been awhile since I've read 
the spec).   As long as people use UUID URNs to refer to resources, such 
usage is perfectly consistent with the intended purpose of URNs.  And I 
certainly am not suggesting that UUID URNs be deprecated, or any thing 
similarly disruptive.

The problem I have is with the idea that has emerged that if you need an 
ID that happens to be a URI, a URN is the right thing to use.   I've 
seen a lot of things labeled "urn:" that didn't refer to resources, or 
worse, weren't unique at all, apparently because of this idea.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2012 14:09:04 +0200

On 2012-08-17 13:57, Keith Moore wrote:
> ...
> ...

Do you have a definition of "resource" different from:

"the term "resource" is used in a general sense for whatever might be 
identified by a URI" -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.1.1>

?

Other than that, I agree about the uniqueness bit.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Aug 2012 08:17:42 -0400

> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.1.1>

That's not a very useful definition for determining whether a URN is 
appropriate.  But my point is that a URN should name _something_.

In addition, it needs to be clear what is being named by the URN. 
Otherwise there's no way to ensure persistence of the binding between 
the URN and the resource.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2012 15:08:07 +0200

On 2012-08-17 14:17, Keith Moore wrote
> appropriate.  But my point is that a URN should name _something_.

My understanding is that if you can give it a name (URI/URN), it is 
"something".

> the URN and the resource.

Given a UUID, there's no way to know *what* is being named without 
additional information. How is that a problem in practice, if all you 
need is a unique identifier?

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Aug 2012 10:09:04 -0400

> My understanding is that if you can give it a name (URI/URN), it is 

Yes, but you can coin names without binding them to anything, or without 
being clear about what you're naming.
> need is a unique identifier?

URNs aren't merely unique; the binding between the URN and the resource 
named is expected to be persistent.   By declaring something to be a 
URN, you're making both assertions.

UUIDs are unique (by definition), but just because you create a UUID for 
something doesn't mean you're committing to making the binding between 
the UUID and that something persistent.   It follows that not every UUID 
should be considered to be suitable for use in a UUID URN.

(naming is tricky and extremely subtle)

Keith