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

[Julian Reschke <[e-mail]>]

On 2013-01-09 05:27, Keith Moore wrote:
> 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.
> ...

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