Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt

[Julian Reschke <[e-mail]>]

On 2011-12-23 09:14, Juha Hakala wrote:
> ...
> Is there a way to estimate how widely the UUID community is using
> urn:uuids, and for what purposes?
> ...

I think it's safe to say that it's used a lot if you need a globally 
unique URI that doesn't need to be resolvable.

And no, I don't think there's something like an "UUID community"...

>> Do you want to force identifiers like these into different URI
>> schemes? Why?
>
> To be honest, I would rather not see another URN namespace like uuid,
> since most users of persistent identifier systems have service
> expectations based on resolvability. And URN:UUIDs a priori will not
> fulfill any of these expectations. But based on what Peter said earlier,
> I suppose URN:UUID is and will be different from (all/most) other URN
> namespaces in this respect.

We should keep that the important point in UR*N* * *naming*.

URNs *can* be (made) resolvable, and URLs *can* be (stable) names.

If this WG believes that urn:uuid is something that is kind of wrong 
then I think we have a problem :-)

>> Also, once you start to focus too much on resolution then you'll
>> inevitably get people asking why you don't start with a scheme that
>> already is resolvable in the first place. In the end, stability of
>> URIs depends mainly on those who mint them, not on the actual notation.
>
> Yes, there is a broad agreement among the people who deal with long term
> preservation of digital content that preservation is primarily an
> organizational issue.
>
> The reason why resolution is important is that URN and other persistent
> identifiers will only become popular if they can provide added value;
> services which cool URIs etc. cannot support at all, or could only
> support with difficulty. These services are often based on resolution.

I don't follow. Any kind of organization that can make name-based 
identifiers stable and resolvable *could* do that with HTTP URIs as 
well. It's not a technical problem but only one of organization.

> There are good reasons for keeping services and identification apart
> (for instance, services are technology driven and will change over
> time), which is why the URN community has tried to avoid conflicts here,
> both in the existing URN RFCs and in the documents currently under
> development.

Is this the "HTTP" may go way argument? Even if it does, you will still 
be able to write resolvers, just like what you're trying to do right now 
with URNs.

Best regards, Julian