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

["Martin J. Dürst" <[e-mail]>]

On 2014/04/19 21:59, John C Klensin wrote:

> --On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker
> <[e-mail]> wrote:
>
>>> 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.
>>
>> Which is exactly what I was saying.
>>
>> For example, UPC code for a can of baked beans is a URN.
>>
>> But if you go to Amazon you can use it as a locator, albeit
>> mediated via UPS rather than TCP/IP.
>
> As Mark Nottingham suggested and I tried to elaborate, this
> particular discussion may be interesting (or not), but, in the
> current context, isn't worth the energy it takes.

Well, no, it's exactly at the very core of the issue. See below for more.

> First, a UPC code for a can of beans isn't a URN.  If an
> identifier for those were documented and registered as an NID,
> or if it were treated as part of an identifier sub-space within
> the "epc" NID specified in RFC 5134, _that_ would be a URN.

Okay up to here. Let's assume that done.

> As
> a URN, the defining materials would presumably come with a lot
> of information about what it was and what operations could be
> performed with it.  For a URN based on that UPC associated with
> a can of beans, those operations might include whether its
> purpose is just to distinguish one brand or can-size of beans
> from another or whether it can be used to retrieve a product
> (see below).

No. The URN/UPC just stands for the can of beans. What you can do with 
it depends on where you use it. Here's where Phil's example comes in 
very handy. Amazon will provide different operations on that URN than 
e.g. a service by the registration authority or by a manufacturer who 
doesn't ship directly to end users.

> That set of distinctions is not just pedantry.  If "URN" mean
> whatever someone claims it means at a given moment,

That's not what we are talking about. The identifier still means the 
same. It's one and the same specific kind of can of beans.

> then we
> don't have a specific category of identifier, we just have a
> very generic term for some variety of identifier.  For the
> information it contains, one might as well have the above
> statement read "UPC code for a can of baked beans is an
> Ironduck".
>
> Even ignoring whether it is a URN or not, a UPC doesn't act as a
> UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a
> TCP-medidated locator.  It is an identifier of an abstraction of
> a class of objects.  To get the object to your doorstep, it is
> typically necessary to resolve it to a different product
> abstraction, to a warehouse and location in it, to a
> shelf-picking mechanism, and so on, typically through several
> step before a particular can-instance is finally chosen, boxed,
> labeled, and handed over to UPS (or some other transit carrier
> whose choice might be another item in the list of
> abstraction-resolutions.

Of course. That's what I wrote about in a separate mail. Even for a 
simple "locator" such as "http://www.ietf.org", there are many very 
similar (although much less physically visible) steps involved. And as 
in the case of something like "http://www.ietf.org", the average user on 
average doesn't want to care much about all these intermediate steps.

> In addition, like many URNs (see my notes on the URN list),
> there are other useful questions that apply to the
> generically-named object and not to the particular can that
> might be located.  For example, "what is the size of the can
> associated with that code" is a question about the generic named
> object.  "What is the sell-by date" probably still doesn't apply
> to a particular can that needs to be located and retrieved
> before the question can be answered -- perhaps it is sufficient
> to locate a case of cans and to do so in an appropriate database.
>
> So I suggest they are still different from http-type URLs in
> more ways than the [retrieval] method.   But, again as Mark
> Nottingham pointed out, it may be that the greatest value of
> this proposed separation is to get around the situation of
> different communities talking past each other and being
> unwilling to accept each other's perspective and legitimacy even
> to the extent needed to have a real conversation.

No, we have had different communities talking past each other in the 
past, and have surmounted that very well. The problem with any 
separation is that it eliminates any potential benefit of being able to 
both URLs and URNs interchangeably where they are interchangeable. Of 
course they are not always interchangeable. But that's no reason for 
separation.

Regards,   Martin.