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

[Keith Moore <[e-mail]>]

On 08/17/2012 03: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 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