Subject: Re: [urn] IETF does protocol design, not philosophy

From: Larry Masinter <[email-masked]>
Date: Sun, 6 Jul 2014 03:11:45 +0000

> > I meant "protocol" in the broad sense. I can't think of
> > any use cases that do not involve protocols. UR*'s
> > are strings to be used in protocols, and any use
> > that doesn't involve a communication is out of scope:
> > for discussion of UR* uses, for this working group, for
> > the IETF.

> My reading of this is that a URI (in the sense of a string conforming to
> the URI syntax as specified in RFC 3986 *and* using one of the registered
> URI schemes [1]) can be used as both an 'indicator' and 'for retrieval',
> but that you say that if you cannot use it 'for retrieval', it should be out
> of scope for IETF. Have I understood that correctly?

Not what I meant. I just meant that you should use Shanon 
information theory terminology rather than philosophy of
language when talking about 'identifiers', if you're writing
for the IETF. It's a terminology and perspective issue.

> > My point is that the answer is the same whether the context
> > is English email or HTML or any other protocol: no one can
> > know for certain what Alice intended by the UR*, the
> > ambiguity is intrinsic, no amount of words in RFCs will
> > change that. If there is to be any disambiguation, it has
> > to be carried out of band or elsewhere in the protocol.
> > ==========================
> 
> But there are plenty of examples of registered URI schemes that are not
> specifying resolution or usage in protocols. Some examples:

> 1) geo: (RFC 5870) explicitly says that

I think you missed the point. Where is a 'geo:' URI *used*.
Every URI Is used in a context. The context might be this
Restaurant Review Protocol conversation:

Q1: "tell me about restaurants in Toronto"
A2: "Here's a good one XX"
Q3:  "Where is XX?"
A4:  "Here it is 'geo:blahblah'

Now, why are they using 'geo:blahblah' instead of 'blahblah'?
Presumably because at step A4 could could have a pointer
to some other way of describing where the restaurant was.
 
>    Data contained in a 'geo' URI identifies a physical resource: a
>    spatial location identified by the geographic coordinates and the CRS
>    encoded in the URI. (§3.4)

Sure, that's fine. The reason you leave the flexibility in the space.
But you don't have to solve philosophical questions ("do geo
locations track plate tectonics") unless they're important for
reliable working of the protocols that use them.

> 3) data: (RFC 2397)
(I invented this one)
 
> To me, this seems very similar to the URN scenario, where the resolution
> protocol is not part of the UR* scheme, but we rely on external
> resolution services that may or may not be authoritative.

There's some kind of conflict between saying that you rely on
a service but the service is not 'authoritative'. I  think because
I think 'authoritative' must always come with a 'to whom'.

If you rely on the service, it is authoritative to you.
If you use it but don't trust it completely, then it's
not any more authoritative than a HTTP proxy cache.

> > > In particular, Alice may want
> > > to inquire whether a URN with a particular NID and NSS exists in
> > > some data structure or transaction and then take an action on
> > > that basis that is indicated by the URN but that has nothing to
> > > do with communicating the URN to Bob or otherwise executing or
> > > resolving it.
> >
> > I don't understand. How did Alice get the URN? And how
> > did the creator of the data structure or transaction
> > get the URN?
> 
> A colleague of hers sent her an email with an attachment. The
> attachment turned out to be a document and on the first page of that
> document a URN identifying that document was printed.

So the URN has been communicated to  Alice in the context
That the document author intended people who retrieved the
document and printed it would see the URN. The communicating
parties are the document author and Alice's colleague and
Alice. 

> > I'd say that if there is no communication path that passes
> > the UR* as an opaque string, then you don't have a URI or
> > URL or URN, you just have a string that looks like one and
> > we have nothing to say because it doesn't matter what
> > we say.
> 
> Of course we cannot know if urn:uuid:6e8bc430-9c3a-11d9-9669-
> 0800200c9a66 actually is a URN, but since it starts with urn:, a qualified
> guess would be that it is one and a user with knowledge of that would
> try to use it as such.

I agree, the question 'is this actually a URN' is meaningless. 

> Can you please elaborate a bit on which part the link types would play in
> a URN resolution scenario? I admit I don't quite grasp that...

I think the scenario is prior to 'URN resolution'. You are
given a UR* (urn, url, uri). You ask 'is this for retrieval or is it
for identity without retrieval'.  Put the answer in a 'link type'.
The other possible link types will also be useful.