Subject: [urn] r-components and resolverID

From: John C Klensin <[email-masked]>
Date: Tue, 12 Apr 2016 06:35:43 -0400

Hi.

I have been waiting and hoping from feedback about the
r-component issues from more of the WG but, since it has not
arrived and some of what arrived earlier seemed contradictory,
it is time for an editorial decision.  

I've gone all the way through the document and thought more
about the 3406 language about the relationship between resolvers
and the registration process.  That has led me to the conclusion
that we've gotten distracted to the point that any discussion of
r-components in 2141bis is premature.  So, absent new arguments
or instructions to the contrary from the WG or Co-chairs, the
-16 version of 2141bis will:

(1) Retain the distinction between r-component and q-component,
including the "?+" and "?=" syntax distinctions.

(2) Remove the resolverID material entirely.  As a side effect,
this means we don't need to debate whether resolverIDs should
have the same syntax as NIDs or something else.

(3) Add an explicit statement prohibiting the use of
r-components until and unless they are developed, specified, and
standardized.

For those who want to understand the reasoning (other than lack
of strong WG support for including that bit of syntax and
explanation), see below.  Others can safely stop reading.

RFCs 2141 and 3406 very clearly make resolution mechanisms part
of the namespace and expect that those mechanisms will be
specified as part of the registration.  That can be done by
discussion, identification of a Resolution Discovery System in
which the NID is registered, or presumably something else (such
as a statement that URNs associated with the namespace are never
resolved, i.e., are "abstract designators" in the language of
2141bis).

Our earliest discussions of r-components assumed they would
contain instructions _to_ the resolver, just as q-components
(and f-components) contain (slightly different types of)
instructions to the resource.  Somehow, we drifted into the
notion that the r-component might specify the resolver itself.
That may or may not be a good idea, but it leads to a series of
other questions, such as whether the resolver material in the
registration template (see the material under "Process for
identifier resolution" in Appendix A of 3406) is optional,
whether a particular namespace registration can leave out
resolver information and make r-components mandatory, and so on.
It is, at best, unlikely that we can resolve (sic) such
questions without a complete r-component design and
specification.  We have concluded that we aren't going to allow
such a specification to get into the WG's critical path, so the
baby step toward a separate resolverID comes back out.

There is a separate argument that specifying a resolver as part
of a URN effectively crosses the conceptual boundary to separate
schemes or locators with more complex syntax, e.g., that
   URN:foo:example-NSS?+bar: baz
should really not be a URN at all but something more like
   bar:foo:example-NSS/baz      or
   barfoo:example-NSS/baz
but we don't need to have that discussion at this point (either).

Again, if anyone objects and has new arguments, please speak up.

best,
    john

---

From: Sean Leonard <[email-masked]>
Date: Tue, 12 Apr 2016 06:18:46 -0700

Hi John,

I have feedback and comments. However, due to IETF 95 happening, I am 
sure that I, and other participants, have been very busy with other 
things. Given the speed at which this working group has progressed, 
another week or two would not be unreasonable.

Thank you for writing out some of the possible paths forward.

(Also I would like to point out, that just because I have been one of 
the few persistent voices in this discussion, should not discount my 
contributions. Quite the opposite, in fact. Especially since I am an 
implementer. Others are always welcome to express their own opinions. I 
did ask that we meet at IETF 95 so that these issues could be discussed 
in person with others in the room or in the virtual meeting, but that 
did not happen.)

Regards,

Sean

On 4/12/2016 3:35 AM, John C Klensin wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn