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

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 25 Jun 2014 13:40:52 +0000

On June 19, 2014, Larry Masinter wrote:

> > Some of the intended/desired uses
> > are precisely not in an [Internet] protocol context.
> 
> 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.
> 
> > Even of
> > those that are, many do not follow your "A ------- UR* --->  B"
> > model because the URNs are used as indicators, not retrieval
> > indicators of some sort (most, but not all, uses with "HTML,
> > HTTP, XMPP, DNS or whatever" are for retrieval elements, but
> > some, including ones that Peter has identified for XMPP and
> > several recent I-Ds, are not).
> 
> I think the 'indicator' vs. 'for retrieval' distinction is not
> about the UR* but about the context of use, not the UR*
> itself.  This is a key point: you can use a 'http:' URI both
> 'as indicator' and 'for retrieval', and also you can use
> a 'urn:' URI for both. However, as a matter of implementation,
> Using 'urn:' URIs for retrieval doesn't work so well.

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?

> ========================================
> Let me try to explain in words what I meant by
> A -- UR* --> B.
> 
> Alice and Bob are communicating. Somehow. All communication
> involves a communication protocol. Protocols are simple or complex,
> are layered and modularized. HTTP is a protocol, but English is
> a protocol, "the web" is a protocol. Speaking broadly.
> 
> In the English email protocol which I am using now, English
> words and punctuation and UR*s are used as protocol
> elements.
> 
> As part of Alice communicating with Bob, Alice might include
> a UR*, embedded in "English email" or HTML or XMPP or XML,
> and you want to ask about the meaning of that UR*.
> Does it indicate, is it intended for retrieval, does Alice want
> Bob to try to retrieve whatever 'fetch'ing the UR* and understand
> something because of whatever Bob gets?
> 
> 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 

   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)

and

   As many other URI scheme definitions, the 'geo' URI provides resource
   identification independent of a specific application or protocol.
   Examples of potential protocol mappings and use cases can be found in
   Section 6. (§3.6)

So this is even protocol-independent.

2) xcon: (RFC 6501)

   An XCON-URI is not designed to be resolved, and an application MUST
   NOT attempt to perform a standard DNS lookup on the host portion of
   such a URI in an attempt to discover an IP address or port at which
   to connect. (§3.3.1)

3) data: (RFC 2397)

You could say that this is about packaging content transported through a specific protocol, but it neither about identification, nor about location.

4) crid: (RFC 4078)

   As addressed in [TVA-CR], the CRID is ultimately resolved either
   directly by the CRID authority or by another party.  If another party
   is providing resolution, the ability to resolve the CRID requires the
   flow of some information from the authority to the resolution
   provider, in order to tie the CRID to its resolution.  Examples of
   relationships between CRID authors and the suppliers of resolution
   information are given in [TVA-Sys].

   As described in [TVA-CR], there will in all likelihood be more than
   one CRID that can resolve directly or indirectly to a given single
   locator at a given time. (§6.3)

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. 

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

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

> > In retrospect, perhaps we would have been better off had we
> > avoided the generic URI idea entirely, preferring a wide variety
> > of URLs -- all intended for use in contexts that fit your model
> > and then invented a Universal Digital Indicator or Universal
> > Digital Flag that would have entirely different properties.
> 
> Disagree. To repeat: the nature of the context of use
> (such as indicate vs. for retrieval) is orthogonal the
> nature of the UR* scheme (http: or uuid:) or scheme type
> (urn or UDI Or UDF).

+1

> RFC5988 establishes a link type registry.
> http://www.iana.org/assignments/link-relations/link-relations.xhtml
> 
> which seems like a great vehicle for those designing
> applications that need additional link categorizations.
> Is there a use case where that won't do?

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

Best,

Lars