Subject: Re: [urn] version -18

From: [email-masked] (Henry S. Thompson)
Date: Thu, 17 Nov 2016 13:12:43 +0000

First, my apologies for taking so long to get back to this.

I've been asked to comment on the revision of terminology around
names/namespaces etc. which is to be found in the current draft (18
[1]), in part in response to comments I had made on previous drafts.

Overall I think things are much better, thank you.  I have a few
remaining nits to pick, which will follow in individual messages for
ease of reference etc.

ht

[1] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 17 Nov 2016 13:22:11 +0000

There are two parts to this

  External: the current use of these terms is incompatible with the
            3986

  Internal: The definitions and uses of 'abstract designator' are
            inconsistent

TL;DR:

 1) 3986 distinguishes between 'resource' and 'representation', and so
    should we;

 2) The term 'abstract designator' should be dropped.

Part 1 -- 3986 incompatibility

URNs are URIs, that is, Uniform Resource Identifiers.  Every URI
identifies something, as the name implies, and 3986 uses the term
'resource' as the cover term for _anything_ that is identified by a
URI.  It explicitly places _no_ constraint on what a URI can identify.
In other words, anything can be a resource: real, imaginary, abstract,
concrete, individual, set (finite or infinite), ...

The current draft does not define the term 'resource'.  It often uses
it in ways which are consistent with 3986's definition, for example in
phrases such as "resource identifier" (lower case in original),
"identified resource", "The kinds of resources identified by URNs" and
"persistent identification of resources".  This longer exposition is
also pretty much compatible with 3986:

  URNs (either individually or entire URN namespaces as defined below)
  that do not resolve to URLs at all or that resolve to metadata or
  non-Internet objects are among URN use cases explicitly permitted by
  this specification; each leaves the concept of "resolution" somewhat
  more abstract and difficult than the simple case of resolution to a
  URL. [1.1, 2nd para]

But the current draft also uses 'resource' in many ways which are
clearly incompatible with 3986.  3986 is very careful to distinguish
between the resource _identified_ by a URI on the one hand, and
_representations_ of that resource and _metadata_ about it on the
other.  The latter are much more concrete, and the kind of thing you
can get your hands on/interact with (see section 1.2.2 of 3986 [1]).
Some examples of where the current draft is incompatible with this
position:

  "A URN [may] be ... an abstract designator that is persistent but
  that does not identify a resource" [Abstract, Introduction]
  Per 3986, _all_ URIs identify something, which it calls a resource.

  "media type of those resources" [2.3.3, next-to-last para]
  Per 3986, resources do not in general have media types,
  _representations_, e.g. as returned in messages, have media types.

I don't think this will be hard to fix -- there's already a
distinction between what is identified and the outcome of a resolution
attempt, as well as between resolution and retrieval, and the wording
around these just needs to be tightened up a bit, with the word
'resource' used a bit less.  Whether the idea behind 3986's word
'representation' needs to be imported, along with the word, will I
think be an editorial decision to be made in the course of the
tightening-up effort.

Part 2 -- 'abstract designator'

Here are some examples of the use of this term which taken together
leave me confused as to what is meant:

  A URN [may] be ... an abstract designator that is persistent but
  that does not identify a resource [Abstract, Introduction]

  If there are or will be resolution services available for a URN,
  this document calls the URN a "resource identifier" in roughly the
  sense that term is used in [RFC3986].  If there is no intention to
  provide any resolution services, and the distinction is important,
  this document calls the URN an "abstract designator". [1.2, near the
  end]

  If the URN does not resolve to a URL (i.e., is an abstract
  designator) or if it resolves directly to an object or a non-URL
  resource designator [2.3.2, 3rd para] [note that this is the only
  use of the phrase 'resource designator' in the draft]

  If the URN does not resolve to a URL (e.g., is an abstract
  designator) [2.3.3, 2nd para]

  because a URN might not specify the location of a resource or even
  point indirectly to one [4.1, 2nd para]

  (e.g., URNs within some URN namespaces are intended to act as
  abstract designators and thus are not intended to be resolved)
  [6.4.6 1st para]

  Clarified that there can be URNs that neither resolve to URLs nor
  are abstract designators. [F.8., 6th bullet.  I _think_ this refers
  to the quote above from section 2.3.2]

It is often argued that 3986 implies that there are two in-principle
possibilities for any URI (including URNs) as far as resolution is
concerned (where the possibility that resolution may involve more than
one step is assumed):

  1) Resolution services are or could be provided, but the results of
     resolution necessarily consist only of metadata about the
     identified resource, that is, no _representation_ of that
     resource is or could be available;

  2) Resolution services are or could be provided, and the results of
     resolution may in practice and could in principle include one or
     more representations.

However I think the above quotes from the current draft taken together
provide evidence that it considers there to be a
_threefold_ distinction, adding

  3) No resolution services of any kind are provided or envisaged;

However the quotes also demonstrate that no consistent interpretation
for the term 'abstract designator', e.g. as (1) or (3) (or their union),
is possible.

Although at first it may seem that the most likely intended meaning
for the term is (3), in fact I don't think this makes any sense.  An
identifier about which _no_ information is provided is useless, or
rather, it makes no sense to make it available, as no-one when
encountering it will be able to make anything of it.  Registering a
URN namespace must surely imply the intent of providing _some_
information about the resources identified by URNs which use it, even
if that is only metadata to the effect that all interesting
information about such resources is available offline in such-and-such
a way.

Or, more simply, the difference between (1) and (3) is surely a
contingent one, bearing in mind the timescales over which we expect
URNs to persist.  It would be an odd namespace indeed for which the
defining documents mandated that no-one could ever implement a
resolution service providing useful metadata!

What I think is the key distinction being implicitly appealed to is
the _representability_ of resources in a namespace.  The draft appears
to use the acronym 'URL' to _mean_ a URI which is (at least in
principle) resolvable to a representation.  But I'd much prefer if the
difference between (2) vs (1) union (3) were _not_ equated with
"resolve(s) to a URL", because

  a) For 3986 and many users of URLs (understanding 'URL' to mean
     'non-URN URI'), many URLs identify resources for which no
     representations are possible;

  b) There are perfectly good ways which are _not_ mediated by URLs at
     all to access representations for resources.

So in summary I'm arguing that the only non-contingent property worth
naming with 'abstract' or something like it is a property of
_resources_, not of URNs.  As such it's not really relevant to this
specification.

My most-preferred outcome: just remove the term 'abstract designator'
altogether, and only discuss briefly the contingent nature of
resolution, as sometimes yielding metadata, and sometimes (perhaps
indirectly) access to representations.

ht

[1] https://tools.ietf.org/html/rfc3986#section-1.2.2

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 17 Nov 2016 15:31:27 +0000

TL;DR: Replace 'resolve to a URL' with 'resolve to a Locator'
throughout

The current draft (correcly, IMO) defines 'URN' as "A name that is a
member of a URN namespace", that is, a name of the form urn:nid:...

It doesn't list 'URL' as a term, but does say, towards the end of
section 1.2 *Terminology* 

  this document uses the term Uniform Resource Locator (URL), rather
  than the generic term Uniform Resource Identifier (URI), to refer to
  locators; see also Section 1.1.3 of [RFC3986].

I think this either partakes of, or at least encourages, a confusion
between properties of URI schemes and properties of individual URIs,
thereby missing the key point of the referenced section of 3986:

  An individual scheme does not have to be classified as being just
  one of "name" or "locator".  Instances of URIs from any given scheme
  may have the characteristics of names or locators or both... [1]

That is, although many http: URIs are locators, some are names (and
some are both), and although all urn: URIs are names, some may be
locators as well.

A URI is a locator if it can be dereferenced, if, for example "[there
are] services related to the identified resource, such as
... delivering a document object from a convenient source" [2].
That's not a property of the URI as such, but of its context of use
and the services available therefrom.  As that quote indicates, some
URNs may have that property in some circumstances.

On the other hand, just because a resolution service provides you with
an http: URI when invoked on a URN does not mean you are now on your
way to a document object, because that http: URI may itself be a name
and not a locator.

So, I'd suggest that you add a new term to the term list in section
1.2, as follows:

   Locator: A retrieval-enabled URI

and use that term in most of the places where 'URL' is currently used.

The penultimate paragraph of section 1.2 would then need to read
something along these lines:

   This document uses the terms "resolution" and "resolver" in roughly
   the sense in which they were used in the original discussion of
   architectural principles for URNs [RFC2276], i.e., "resolution" is
   the act of supplying services related to the identified resource,
   such as translating the persistent URN into one or more current
   Locators for the resource, delivering metadata about the resource
   in an appropriate format, or even delivering a document object from
   a convenient source without requiring further intermediaries.  At
   the time of this writing, resolution services are described in
   [RFC2483].

   Section 1.1.3 of [RFC3986] helpfully observes that "A URI can be
   ... classified as a locator, a name, or both" and goes on to define
   locators as URIs which "provide a means of locating the resource
   [which they identify] by describing its primary access mechanism
   (e.g., its network 'location')".  This is what we mean by
   'retrieval-enabled' above, and we use the term 'Locator' to refer
   to the class of individual URIs which have this property.

A few places where 'URL' is effectively used as shorthand for
"non-urn-scheme-URI' will require some more explicit rewriting, e.g.

  The URN r-component has no syntactic counterpart in URLs

 -->

  The URN r-component has no syntactic counterpart in any other URI
  scheme that we are aware of

The overall point here is that RFCs are meant for the entire
community, and it's at best misleading for an RFC to redefine a widely
used term to have a meaning other than the one already in wide (and
documented) use.  I do of course understand that there exists a
sub-community within which this distinct meaning is understood and
intended, but this spec can and should reach out more widely.  So note
that I'm _not_ proposing that the spec should use 'URL' as defined in
3986, but rather use 'URN' to mean urn:nid:..., as it does already, to
use 'URI' as the generic, and _not to use 'URL' at all_.

ht

[1] https://tools.ietf.org/html/rfc3986#section-1.1.3
[2] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18#section-1.2
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]