Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

[Nico Williams <[e-mail]>]

On Sat, Apr 19, 2014 at 4:18 PM, Scott Brim <[e-mail]> wrote:
> On Apr 18, 2014 11:20 AM, "Mark Baker" <[e-mail]> wrote:
>> Whether it's a name or a locator is not an intrinsic property of the
>> string, but depends solely upon the presence or absence of a local
>> resolution mechanism for that string.
>>
>> A string that *you* might *today* call a "name", might already be a
>> "locator" to somebody who's rigged a private resolution service. Ten years
>> from now, that "name" might be a "locator" to all of us.

Yes.  Consider a use of URNs as opaque identifiers of optional
behaviors.  Add a registry of such URNs listing their specifications.
But now they are both names and locators, since they can be used to
locate specifications in the corresponding registries.  Now, if
there's no way to automate this location, and/or if it's only useful
to implementors, then such URNs remain names.  Names for what?  For
behaviors.

> The inverse way of looking this is that identity-related functions can use
> anything they want since they can treat it opaquely ... and do ... while
> location-related functions are limited to tokens they understand the
> semantics of.

Yes.  We could construct a URN namespace where location of
specifications via [IANA, say] registry lookups turns them into
locators.  Just not locators useful to most people.  In the end URNs
are really just opaque identifiers.  Some of them name real resources
(e.g., there's a way to name RFCs using URNs); some will not.  We
should not demand that every URN name a "resource" in that sense!

Nico
--