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

[Julian Reschke <[e-mail]>]

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

Best regards, Julian