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

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jan 2013 11:35:12 -0700

Old thread alert!

On 8/17/12 1:27 AM, Julian Reschke wrote:
> On 2012-08-16 23:01, Alfred � wrote:
>> (no hat)
>> 
>> On 08/16/2012, Keith Moore wrote:
>>> On 08/14/2012 09:59 AM, Andy Newton wrote:
>>>> 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.
>>> +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
>> 
>> +1 (for both statements)
> 
> 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?).
> 
>> 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.
> 
> 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).

Exactly. Just as we have reserved domain names for specifications (RFC
2606), I think it might be useful to have a reserved URN namespace ID
for specifications. I'd be happy to more carefully scope the
Internet-Draft to reflect that narrow focus.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jan 2013 23:27:56 -0500

On 01/07/2013 01:35 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Old thread alert!
>
Whether something works well in practice, and whether something conforms 
to the intent of a standard, are of course two separate questions.

Again, URNs were designed to identify resources.   If people use them 
for other things, that's not a problem so long as such use doesn't 
degrade the intended utility of URNs.   It's not like the protocol 
police are going to chase down the users of UUID URNs and put them in 
jail if those UUIDs weren't chosen to refer to resources.  And of course 
you can't tell by looking what is named by a URN  - and that is a 
feature, not a bug.

But just because people find uses for URNs that weren't intended, 
doesn't mean that the URN standard should be changed to encompass those 
uses.  This _would_ degrade the utility of URNs.

To be clear, there's nothing in principle wrong with a UUID URN. What's 
wrong is using a UUID URN just because what you need is a unique 
identifier that doesn't refer to a resource, and you want that unique ID 
to be some sort of URI.   Yes, it probably does little harm most of the 
time, but it's still not a good idea to promote the practice.

> be URNs as well, just not using the "URN" URI scheme, no?).
I'm saying that whoever insisted that it was a good idea to use URIs of 
any kind as unique identifiers, just because they happened to contain 
DNS names (which we already knew were not unique over time), was adding 
needless complexity to the network in exchange for marginal, probably 
negative, utility.  UUIDs by themselves would have worked just fine.[*] 
   Misuse of URNs in this way is just a small part of the resulting 
collateral damage.

[*]  Well, almost just fine.  I've seen security holes in web services 
that relied on UUID URNs as transaction IDs and were vulnerable to 
trivial UUID guessing attacks.   But the general problem is with adding 
more layers which aren't well understood. People who don't understand 
security protocols shouldn't be picking what to use as nonces, people 
who don't understand URNs shouldn't be designing protocols around 
them.   etc.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jan 2013 16:48:56 +0100

On 2013-01-09 05:27, Keith Moore wrote:
> ...

"This specification does not limit the scope of what might be a 
resource; rather, 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>

Case closed.

Best regards, Julian (ducks)

---

From: Keith Moore <[email-masked]>
Date: Wed, 09 Jan 2013 10:59:30 -0500

> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.1.1>
yes, but it didn't anticipate that URNs would be widely used to not name 
resources at all.

again, most such uses do little harm.  but that's not an argument for 
perverting URNs to be just
random numbers instead of resource identifiers.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jan 2013 17:00:48 +0100

> random numbers instead of resource identifiers.

My point being: they *are* resource identifiers.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 09 Jan 2013 11:05:00 -0500

> My point being: they *are* resource identifiers.
Only if they actually identify resources.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Wed, 9 Jan 2013 11:19:32 -0500

Is it really 1999 all over again? Maybe I should by come CMGI stock.

With a couple of noted exceptions this is one area where the W3C and the IETF's URN group agreed: That the definition of 'resource'  is the thing identified by a URI. That minting any URI immediately causes its resource to come into being in the abstract. Some URI scheme specifications can restrict that it limits resource to be sequences of bits on a network but that is a limitation of that particular URI. We never set that limit for URNs. In other words, the rough consensus from back then was Julian is right, that ALL URIs identify 'resources' by definition. Merely being identified by a URI _makes_ it a resource.

wow… that made me feel ten years younger! ;-)

-MM

On Jan 9, 2013, at 11:05 AM, Keith Moore <[email-masked]> wrote:

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jan 2013 17:23:20 +0100

> wow… that made me feel ten years younger! ;-)

Me too :-)

---

From: Keith Moore <[email-masked]>
Date: Wed, 09 Jan 2013 11:31:04 -0500

> With a couple of noted exceptions this is one area where the W3C and the IETF's URN group agreed: That the definition of 'resource'  is the thing identified by a URI. That minting any URI immediate…

It's the cases where there is no "it" that concern me.   People seem to 
have gotten the idea that URNs aren't resource identifiers, but rather, 
nonces.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jan 2013 17:42:01 +0100

On 2013-01-09 17:31, Keith Moore wrote:
>> With a couple of noted exceptions this is one area where the W3C and
>> the IETF's URN group agreed: That the definition of 'resource'  is the
>> thing identified by a URI. That minting any URI immediately causes its
>> resource to come into being in the abstract. Some URI scheme
>> specifications can restrict that it limits resource to be sequences of
>> bits on a network but that is a limitation of that particular URI. We
>> never set that limit for URNs. In other words, the rough consensus
>> from back then was Julian is right, that ALL URIs identify 'resources'
>> by definition. Merely being identified by a URI _makes_ it a resource.
>

There is no such case. Somebody mints a UUID for *something*, and at 
that point there is a "it". It's just not resolvable/testable.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 09 Jan 2013 11:51:24 -0500

> that point there is a "it". It's just not resolvable/testable.
Not so.  Just because someone mints a UUID doesn't mean that there is an 
it.

The whole point of URNs is that the relationship between the name, and 
the thing that is named by the name, cannot change.  If this 
relationship between the name and the thing that is named isn't 
explicit, no such assurance can be made, and it's not appropriate to use 
a URN.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jan 2013 18:08:35 +0100

> have gotten the idea that URNs aren't resource identifiers, but rather,

Well.

Your use of the term "resource" is in conflict with the RFC 3986 definition.

I could ask you for your definition but I fear we'll end up with totally 
pointless philosophical discussion :-)

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Jan 2013 00:50:01 +0100

* Michael Mealling wrote:
>Is it really 1999 all over again?

We did warn you about the Y2K bug...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Larry Masinter <[email-masked]>
Date: Sat, 12 Jan 2013 09:04:37 -0800

Old thread fans -- resources are angels:

http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html

---

From: Larry Masinter <[email-masked]>
Date: Sat, 19 Jan 2013 08:27:31 -0800

For my part, the only way I can make peace with URNs is to take the perspective that "persistence" is wishful thinking, that "resource" is a myth, and that the primary use for URNs is a way of importing into the space of URIs those identifiers that are maintained by other organizations (namely, the "naming authority").

Of course, you should only use naming authorities who can offer a credible promise of persistence of the association of the name to the thing named, but each service makes its own guarantees. IETF offers that "STD 66" names something, even if the document changes, and that "RFC 3986" names something which is currently the same document. But that also what it names is somewhat independent of the format it's set in, or the location.

This description of URNs doesn't require anyone to believe in Resources or that URNs Name them, or that they do so Uniformly.  It explains _most_ of the URN namespaces. 

The only problem is the darn urn:uuid: namespace, where "uuid" is not an authority at all, and there's nowhere to turn to figure out who might have known at any point in time what was meant by it. I don't know what to do with urn:uuid except to declare it a mistake.

Larry
--
http://larry.masinter.net

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith
> Moore
> Sent: Wednesday, January 09, 2013 5:51 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00
>

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Jan 2013 23:19:45 -0500

> For my part, the only way I can make peace with URNs is to take the perspective that "persistence" is wishful thinking, that "resource" is a myth, and that the primary use for URNs is a way of impo…

Which of course has nothing to do with the purpose of URNs.
> This description of URNs doesn't require anyone to believe in Resources or that URNs Name them, or that they do so Uniformly.  It explains _most_ of the URN namespaces.
No it doesn't.  it's just a mostly-coincidental characteristic of some URNs.
> The only problem is the darn urn:uuid: namespace, where "uuid" is not an authority at all, and there's nowhere to turn to figure out who might have known at any point in time what was meant by it.…
That might not be a bad idea, but not for the reason you cite.

To attempt to define what URNs are in terms of what you observe about 
URNs is to attempt to destroy their utility.

Keith