Subject: Re: [urn] Resolution services (was: Re: suggested change for -12 of rfc2141bis section 7.3.6)

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 1 Jun 2015 10:46:46 +0000

John,

On Friday, May 29, 2015 2:33 PM, John C Klensin wrote:
> 
> It is possible that we are arguing about an already-solved
> problem here.  Or not... see below.
> 
> --On Thursday, May 28, 2015 18:17 -0600 Peter Saint-Andre - &yet
> <[email-masked]> wrote:
> 
> >>> I seem to be in the rough about my desire to remove all
> >>> discussion of resolution from the syntax and registration
> >>> specification. Every time we talk about resolution, we seem
> >>> to fall down a rat hole of unusual size. Since we're not
> >>> replacing RFC 2276 in parallel with replacing RFC 2141 and
> >>> RFC 3406, I feel like we're flying blind with respect to all
> >>> resolution-related topics.
> >>
> >> If I understand you correctly, your suggestion is concentrate
> >> on syntax (and as little semantics as possible) making
> >> 2141bis fly as soon as possible. Once that is done, we go on
> >> to revise 3406. WFM. That said, I don't think we can specify
> >> registrations procedures without discussion resolution since
> >> one important aspect of persistent naming is the ability to
> >> find the named object through its name. And in most cases
> >> this is done through some kind of lookup service and it is
> >> indeed an important question who has the canonical registry.
> >> I don't think we can offload that on to IANA...
> >
> > I'm suggesting that we concentrate on syntax (2141bis) and
> > namespace registrations (3406bis) - those are easier to
> > specify because we have more experience with them. We don't
> > have experience with URN resolution or at least those folks
> > haven't been involved here, so I suggest that we updated RFC
> > 2276 separately and address the resolution-related topics then.
> 
> Let me try this a slightly different way, but reaching the same
> conclusion.  As Peter points out, we know, or are close to
> knowing, how to update and replace 2141 and 3406.  We also have
> very specific problems that we are trying to solve.  In the case
> of 2141, allowing, for various reasons and in response to
> various requirements, more syntax than 2141 permits: the things
> we've been calling q-components and r-components; the
> f-components / fragments that some of the opinions on RFC 3986
> claim that 2141 could not disallow if it wanted to; and either
> the use of the "/" within the NSS or p-components.  In the case
> of 3406, it establishes a registration procedure for namespaces
> that has been perceived as sufficiently onerous to discourage
> namespaces from being registered, something I think we've
> concluded is a bad idea.

Indeed...

> Now, if we start looking at resolution, we end up not only in
> the territory of 2276 but also 3401ff.  There are some
> historical issues with 2277 related to how much consensus it
> represented at the time and how informed that consensus was.  It
> is an Informational, rather than a Standards Track, document,
> which may or may not mean much.    More important today, 3401
> (and 3402-3405) claim to be a more or less consistent
> implementation spec for the ideas in 2276, modifying those ideas
> slightly in the process.  With the exception of one, non-URN,
> application, DDDS has not been broadly adopted or used.
> Anything that was proposed today and based on any of those specs
> would almost certainly have to include specific analysis of the
> architecture and implementations and what had and had not
> succeeded.  To the best of my knowledge, no one has started that
> work or even volunteered to do it.

OK, I got that. I guess that my (and most people from outside of IETF) only think of http-based resolution, e. g. http://nbn-resolving.org.
> 
> At the same time, most of the URNs we have seen in active use
> either don't need resolution services or use resolution
> mechanisms intrinsic in other standards or protocols.  URNs used
> in XMPP, ISBN and ISSN, and XML all come immediately to mind as
> examples.

The Finnish urn resolver does support Finnish ISBNs: http://urn.fi/URN:ISBN:952-10-0093-7 but that is probably an exception to the rule. 
> 
> I think Keith's most recent comments
> (http://www.ietf.org/mail-archive/web/urn/current/msg03076.html)
> are largely consistent with the above although his perspective
> is different.
> 
> Briefly addressing a more recent note:
> 
> --On Friday, May 29, 2015 07:35 +0000 "Svensson, Lars"
> <[email-masked]> wrote:
> 
> > But can we really specify the registration procedure without
> > asking the registrants to say anything about resolution
> > services?
> 
> I think we have little choice, for the reasons outlined above
> and in Keith's and Peter's notes.   However, we provided some
> time ago for comments about resolution when those are
> appropriate and I haven't seen proposals to remove those
> provisions.  See in particular (in
> draft-ietf-urnbis-rfc2141bis-urn-11):
> 
> 	Section 7.1, numbered item 6     and
> 	Section 7.3.6
> 
> I've expressed some concerns earlier about the second paragraph
> of the latter because of the interaction and reference to 2276
> (for the reasons above), but don't recall anyone else expressing
> interest in that issue.  However, it seems to me that this text
> provides mechanisms that allow a registration to say any of the
> following in the registration specification:
> 
>  (i) This namespace is indicator-only and unlikely to be
> 	resolved (or resolution would be meaningless).
>  (ii) Resources associated with this namespace are
> 	located and resolved according to the mechanism
> 	specified in ...
>  (iii) While the identifier is universal and persistent,
> 	registration is likely to be a local matter.
>  (iv) We know what these are, aren't ready to say
> 	anything general about resolution yet, but will update
> 	the registration when we figure that out.
>  (v0 ... and so on
> 
> It seems to me that provides a way to record whatever
> information is known and which the registrants think is
> appropriate to supply while avoiding  unrealistic requirements
> to specific things that neither we nor the registrant knows or
> requiring that all URNs be resolvable or resolvable in one of an
> enumerated set of ways.
> 
> What else do you think is both useful and feasible?   Is the
> current text ok or would you suggest improvements, particularly
> to say either more or less?

No, the current text sounds feasible. I guess the reviewers will look carefully at that section.

Best,

Lars

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Jun 2015 01:15:59 -0400

Lars,

--On Monday, June 01, 2015 10:46 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>...
>> represented at the time and how informed that consensus was.
>> It is an Informational, rather than a Standards Track,
>> document, which may or may not mean much.    More important
>> today, 3401 (and 3402-3405) claim to be a more or less
>> consistent implementation spec for the ideas in 2276,
>> modifying those ideas slightly in the process.  With the
>> exception of one, non-URN, application, DDDS has not been
>> broadly adopted or used. Anything that was proposed today and
>> based on any of those specs would almost certainly have to
>> include specific analysis of the architecture and
>> implementations and what had and had not succeeded.  To the
>> best of my knowledge, no one has started that work or even
>> volunteered to do it.
> 
> OK, I got that. I guess that my (and most people from outside
> of IETF) only think of http-based resolution, e. g.
> http://nbn-resolving.org.

Ah.  The piece of explanation I left out.  If one is going to do
"http-based resolution", one can ultimately do one of four
classes of methods (or, as noted below, a combination of them).
(I'm going to ignore namespaces that don't resolve in this note,
which doesn't imply they aren't important or, indeed, that
tricks can't be invented to accommodate them in any or all of
the approaches that follow.)

(i) Bind the resolution domain tightly to the namespace at
resolution time and permanently so that the URN becomes little
more than an abbreviation.  In other words and doing a bit of
handwaving, 
     urn:example-namespace:foo-bar-baz

would be registered as using, e.g., "namespace.example.net" as a
resolver and would then be equivalent to something like:
     http://namespace.example.net/example-namespace?foo-bar-baz

dealing with the additional syntax options we expect to have in
2141bis would require more conventions about syntax and more
handwaving, but is not a difficult problem.   

I note that this sort of registration-time tight binding/
abbreviation model violates several people's assumptions about
what persistence is all about.  In particular, if the existence
and utility of the "namespace.example.net" domain cannot be
guaranteed for a very long time for the "example-namespace" NID
and similarly for all other NIDs, the approach doesn't meet
their criteria for persistent URHs.

In addition, finding the binding itself either requires that it
be included in the code of any system that intends to use/allow
that namespace or that a real-time lookup be performed on the
contents of an IANA registry that maps namespaces to resolvers.
The former would eliminate the possibility of doing anything
generic with URNs because a system would have to reject any URN
containing an NID it didn't recognize.  The latter would
require, not only resolution-time access to an IANA registry
(something IANA generally has not allowed for technical reasons)
and, if the registry entries are allowed to be changed/updated,
models for synchronization and timeouts so that caches of the
registries work (that is one of those technical reasons).

(ii) In a different, but potentially somewhat more persistent
and useful, variation on "really just an abbreviation", adopt a
model that has recently come up as the "useless prefix" theory,
e.g.,
     urn:example-namespace:foo-bar-baz

would really be a different way to write
     example-namespace:foo-bar-baz
or
     example-namespace://namespace.example.net/foo-bar-baz

or some such thing.  Those are obviously not "http resolution"
unless they introduced another level of indirection.  They are,
however, the only options that introduce the level of opacity
some of us have sometimes argued for without running afoul of
restrictions in RFC 3986 in a major way (given some recent
discussions, even this option wouldn't help with fragments and
maybe some other things).

(iii) Bind namespaces to a general-purpose namespace resolution
mechanism that can supply information about where to find a
resolver and the instructions to give it.   DDDS is a member of
this family.  To all intents and purposes, the form of it that
has been fully specified, implemented, and deployed operates by
associating an NID, for instance "exampleNID", with a domain
name in a subtree reserved for that use, for instance something
like "exampleNID.urn.arpa".  That domain name "owns" records
that provide one or more substitution templates that define how
to map the NSS (and, presumably, other information) associated
with the NID (and maybe the NID string itself) into a URI or
preferential list of URIs.

At the time 2276, and especially 3401ff, were written, many
people assumed that _all_ namespaces using the "urn:" scheme
would behave this way, i.e., that this approach is very similar
to the first one but loosens the binding between namespace and
actual resolver by introducing an intermediate level
resolver-finding and syntax-finding layer, thereby eliminating
the most important of the persistence problems.   

When combined with the observation that not all URNs used today
work that way, that view of things is one of the reasons I (and
maybe others) periodically make comments that we should have
left "URN" as an abstract term paralleling "URL" and used
something like "ddds:" where we now use "urn:" and expect that
treatment.   In more practical form, it is a key reason why
discussions about putting strong references to 2276 and/or 3401
into 2141bis cause me (at least) some anxiety.

(iv) Something else, in which the binding between the URN and
some HTTP URL, or for that matter, other URLs or actions is left
to other specifications.  This is where ISBN is one of a family
of useful examples.  Without affecting the integrity or
persistence of the urns with an NID of "isbn", one can use and
interpret such a URN as an abstract identifier suited mostly for
identity tests but not resolved; as something that is resolved
locally to an inventory number, accession number, shelf or bin,
or other locator (more typically using a database lookup than
anything necessarily involving HTTP or other URIs); or mapped
(back?) into, e.g., a  {publisher, title, edition, binding,
medium}-tuple by an ISBN-specific resolution method reliant
either on a centralized database or walking the
country-publisher tree and then asking the publisher.  The last
of these lends itself nicely to http URIs but certainly does not
require them (and I think your example of urn.fi below is an
excellent example).

At present and modulo a lot of handwaving, we seem to be at the
fourth option even though some of us would like to see more
generic approaches along the lines of (iii) for some or all URN
namespaces and, while some of us understand the issues better
then we did a few weeks ago, there is probably some lingering
disagreement about how necessary, desirable, or feasible it is
to limit flexibility in the namespace -> resolver -> object
bindings.  A different version of the latter is that, if you
create a namespace and define it as associated with a certain
resolution mechanism or type of resolution mechanism, is it
appropriate for me to substitute a resolution mechanism of my
own for either my or more general purposes.  We also don't have
strong agreement about how much information about resolution
should be allowed or required in the IANA registration template.

>> mechanisms intrinsic in other standards or protocols.  URNs
>> used in XMPP, ISBN and ISSN, and XML all come immediately to
>> mind as examples.
> 
> The Finnish urn resolver does support Finnish ISBNs:
> http://urn.fi/URN:ISBN:952-10-0093-7 but that is probably an
> exception to the rule. 

Depends on which rule.   Using the typology above, this is a
mixture between method (i) (i.e., "the URN is just an
abbreviation") and method (iv) (i.e., "the information is
obtained externally", in this case what domain goes into the
template URL).  But that example also points out why (iv) is
not, in practice, as bad an idea as it probably seemed when RFC
2276 was written.  I don't want to get confused with what
actually happens with ISBNs (and, in particular, the question of
what the resolver at urn.fi does with non-Finnish ISBNs and
namespaces it has never heard of), so suppose we had an
International Non-Standard Example Number (INSEN), an INSEN
management agency, and a URN namespace with NID "insen".
Suppose that the management agency established a resolution
convention such that resolvers for
urn:insen:whatever-goes-in-the-NSS used the form
     http://<domain>/urn:insen:whatever-goes-in-the-NSS

and also established conventions about how those resolvers
worked, including conventions about what to do if the first 10
characters in the path were not "urn:insen:".  Now, they might
also have a registry of resolvers that were certified as
following their rules, but you, as someone looking up one of
these insen URNs, ultimately just have a trust issue: you would
need to trust that whatever resolver you decided to use would
return correct results, that any resolvers you used (perhaps as
fallback or load-sharing) would return compatible or identical
results, and you just wouldn't call on any resolvers you didn't
trust.  If you decided to delegate that trust problem to the
management agency and its list... well, up to you.

And none of that needs to be part of the URN spec.

By the way, as a design issue for the long term, I think that
using a little depth in the domain tree such that, e.g., for the
resolvers for the URN namespace "penguin", it would be better to
look for 
    http://penguin.urn.aq/penguin-registration-number    or
    http://penguin.urn.ar/penguin-registration-number    etc.

rather than 
    http://urn.aq/urn:penquin:penguin-registration-number

The deeper domain structure probably be a better idea, if only
because the user would get a much faster and more clear
indication if the appropriate resolver database were not
present, as I expect it might not be for 
   http://urn.fi/urn:penquin:penguin-registration-number

or
    http://urn.aq/urn:tiger:tiger-registration-number

>...
>> current text ok or would you suggest improvements,
>> particularly to say either more or less?
> 

Thanks.

best,
   john

p.s. Perhaps it is just because I've been thinking about this
too much, but I wonder if we've got enough confusion about these
issues that it would be useful to have some of the above
information organized and written down in more accessible form
than this message and its predecessor.  Especially with my
co-editor hat momentarily on, I'd hate to clutter 2141bis up
with it, but, if anyone feels strongly that it should be
preserved, we could probably organize an informational document
fairly quickly, much more so if someone else volunteered to at
least collaborate on the work.