Subject: [urn] rfc2141bis-14/-15 metacomment about URN definitions

From: John C Klensin <[email-masked]>
Date: Sat, 21 Nov 2015 04:13:07 -0500

Hi.

After reviewing Sean's and Juha's comments on -14 and thinking
about a set of issues that have been bothering me (and, in
different ways, I think others) for months, I want to take a
half-step back, not about the nature of URNs but about the
definition and documentation process.

It seems to me that we have a pair of difficult problems.  On
the one hand, we are trying to define URNs independent of both
the properties and capabilities of any particular namespace.  We
are also trying to define URNs broadly enough that different
ones may resolve directly to digital objects, to URLs, to
metadata, or not at all.  Those "resolutions" may depend on the
namespace (see "isbn" versus "isbn-metadata" in my response to
Juha as well as the XMPP ones that we've sometimes called
indicators).  

However, even "resolve to object" URN namespaces might be usable
as indicators in other contexts so whether or not something
resolves (or is always treated by resolving it) may not be a
necessary property of a namespace.  For example, if a namespace
had a strict and predictable assignment rule (consider
"urn:ietf:rfc:NNNN" as an example) but an assignment rule within
the namespace that resolution is not possible until the RFC is
actually published, then "urn:ietf:rfc:9999" is perfectly valid
from a syntax standpoint while "urn:ietf:rfc:ABCD" is not.  One
would probably want a resolver that would somehow be able to
report "syntax error in NSS for that sub-namespace" for one of
those cases, "syntax valid but no such object", and "here is
your object" (or a URL for it) for 
    urn:ietf:rfc:3986

Even more obviously, one reason why it is important to have
clear rules for determining equality of URNs involves
non-resolution applications.  I think we have agreed that,
unlike some varieties of URLs, the ultimate arbiter of equality
is not to retrieve and compare target objects.

Each of us has different ideas about what types and applications
of URNs are most important and about how to characterize them.
Each of us has a different number of applications we can
actually consider and remember at the same time.  But, at least
IMO, 2141bis must be written to include all of the applications
or, at least, to not exclude any by focusing on or assuming
others.  I think relatively recent comments from Keith, Sean,
and Juha (in earliest-first order) show examples in which
2141bis-14 fails at that.

And that is the easier of the two difficult clusters of problems
we face.

When we start talking about what is done with URNs and how --
something we have been characterizing as the "resolver" or
"resolution" problem-- we also encounter multiple models.  If we
were in the business of specifying an API, things would be
easier (although consensus perhaps not).  However, our job, at
least as I understand it, it to specify things in a way that is
not biased toward any particular implementation.  The difficulty
is that, while it is helpful (as Keith and others have pointed
out) to think about applications and implementation scenarios,
different of us have different scenarios and different ways of
thinking about them.  Sean's proposed substitute document and
its "exemplar implementation" section is very helpful in
illustrating the problem -- that example is great for some range
of cases and at least one way of thinking about the issue.  It
appears to me to be inadequate or confusing for others.  Maybe
example implementation outlines like that are exactly the right
way to show how things could work but, if we are going to do it
that way, I suggest that we need at least one other (and
preferably very different) parallel worked example.  Noting that
the posted version of -14 is already 33 pages long and that
Sean's proposed substitute is 46 pages, that would make for a
very long document, perhaps comparable to RFC 3986 if that is a
benchmark for "too long for any but the most dedicated people to
read".

We can continue to try to fix those issues with more qualifying
or alternative language (as parts of Juha's recent note
suggest), or we can try to incorporate some of the explanation
above into introductory material that advices people as to how
to read and interpret the spec.  Or we can do the latter but
keep trying to apply patches along the lines of the former.

Advice from the WG would be helpful.

best,
     john