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

[Keith Moore <[e-mail]>]

On 01/07/2013 01:35 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
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.

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