Subject: [urn] another problem with 2141bis-10

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2015 10:48:42 -0400

I realized after I got home from Dallas that another problem with 
2141bis is that it doesn't specify which parts of a URN that contains 
f-, p-, and/or q-components are significant for resolution and should be 
presented to a resolution service.   If this varies from one namespace 
to another, it's going to make it much harder to build general-purpose 
resolution code.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Mar 2015 10:38:28 -0400

--On Saturday, March 28, 2015 10:48 -0400 Keith Moore
<[email-masked]> wrote:

> I realized after I got home from Dallas that another problem
> with 2141bis is that it doesn't specify which parts of a URN
> that contains f-, p-, and/or q-components are significant for
> resolution and should be presented to a resolution service.
> If this varies from one namespace to another, it's going to
> make it much harder to build general-purpose resolution code.

Keith,

I think we are getting to the stage where a much smaller actual
list of issues are driving a larger set of manifestations, where
the latter make the "problem" list look longer.   No negative
criticism intended because I think it is useful to understand
the manifestations too, but I would urge everyone to try to keep
the issues list as focused as possible.  In addition, I refer to
postings below that occurred after you sent the note cited
above; it is only because it raises a different manifestation
that I think it is worth responding to separately.

In this case, unless I'm mistaken, the issue ultimately involves
which components, or parts of components, are intended for the
resolution process (when there is one) and which ones are
expected to be passed through to the target (whose meaning may,
again, vary).     I discussed that in more general terms in a
note posted yesterday with subject line containing "Fragments
and URN pass-through components",
http://www.ietf.org/mail-archive/web/urn/current/msg02878.html.
As pointed out there, this is a relatively old issue that has
been raised, in different forms, several times previously on the
mailing list.

DWIW, I think there is another possible response as far as the
specific issue of "what should be passed to a resolution
service" is concerned.   We don't have enough of a specification
of generic URI resolution services to either think about APIs
or, IMO, even to think about the "what should be passed"
question meaningfully.  Part of that is discussed in more detail
in another one of yesterday's notes (subject containing
"General-purpose resolution service",
http://www.ietf.org/mail-archive/web/urn/current/msg02877.html).
The relationship between DDDS and DNS NAPTR records (and the
associated regular expression) could be the foundation for such
a specification except:

(i) As that posting indicates, DDDS is one of many potential
mechanisms for linking URN NIDs to resolution services, but it
is not ubiquitous and we have no cross-namespace mechanism for
identifying and invoking others.

(ii) Even if DDDS were ubiquitous, its NAPTR regular expression
mechanism did not anticipate information that is not clearly
part of the NSS.  I haven't studied it in nearly enough detail
in recent years to have an opinion as to whether changes are
needed and, if so, whether they are obvious or require
significant thinking and work.

That said, it is possible, at least in principle (but not with
the present DDDS), to simply pass everything to a resolution
service and then have that resolution service, after figuring
out whatever it needs to figure out about the properties of the
namespace, to pass back either specifically-designated
pass-through elements or anything it doesn't recognize for
passing through to the target.  

Most of that is extremely speculative.  What is clear is that
neither "review and revise DDDS" or a restriction equivalent to
"do nothing that might require a DDDS update" is on the WG's
charter.  "Define a truly generic resolution service and
mechanisms that behave well with URN namespaces that do not
resolve at all" is not either [1].  As I have argued in earlier
notes, in the absence of such a generic resolution service or at
least the supporting infrastructure and data model for it, our
only choice is pushing a lot of things down to per-namespace
decisions.   I'm not wild about that either, but the situation
seems to be what it is... and the decisions, circumstances, and
logic that have gotten us there are not the result of decisions
taken by this WG.

    john

[1] I have been wondering whether it would be possible to define
a data representations and model that would exist at one level
of abstraction above DDDS, really span the whole space of
present and future URN namespaces.  I would assume it would
permit turning the answers to many of these questions (including
"does it resolve at all" and "how does one distinguish between,
e.g., content or metadata to which a URN might refer" as well as
"how do I get <that> to to something that can answer/resolve the
question" into a table-driven exercise.  But designing or
discussing it is clearly not on the WG's agenda.  Moreover, if
is were powerful enough to be useful, it might raise a different
version of some of your questions about undermining persistence
by changing definitions out from under the URN string.