Subject: [urn] r-component namespace independence (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component)

From: John C Klensin <[email-masked]>
Date: Mon, 21 Mar 2016 19:59:51 -0400

(trying to extract the important bits from your note and
Martin's and handle your three separate sets of remarks
separately, but people may need to go back and look at the
original notes to find enough context)

--On Sunday, February 21, 2016 13:04 -0800 Sean Leonard
<[email-masked]> wrote:

>...  
>>>   From that view, it follows that r-component is
>>> namespace-independent, in the sense that the maintainers of
>>> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a
>>> stab at their own spins on the resolverID "foo" or "info" or
>>> "abcdefg". The namespaces of "resolverID" and therefore
>>> r-components more generally are global and orthogonal to the
>>> NID / NSS part.
>> I hope that is consistent with what the text says.  However,
>> the intent of the text was that maintainers of particular
>> namespaces _do_ get to specify what resolverIDs are used with
>> them, just not how a given resolverID that they intend to
>> permit is interpreted.
> 
> I am confused with these two statements/positions and do not
> see how to separate them.

Yes, I agree, it is confusing and I was confused.
However...

> I think an example from you would be very helpful.
> 
> As you wrote: "maintainers of particular namespaces [get] to
> specify what resolverIDs are used with them". And: namespace
> maintainers do not get to specify "how a given resolverID that
> they intend to permit is interpreted".
> 
> So the maintainer of urn:isbn can say the resolverID "info"
> can be used, and "get" cannot be used. The maintainer of
> urn:oid can say the resolverID "info" can be used, and "get"
> can also be used.

> But why do they say some resolverIDs can be used or not, when
> they have no way to promulgate what it means?

And, again, no way to predict the future.
 
> It is like saying: "You can use the number 6 in this protocol,
> but not the number 7. Oh, but you can do whatever you want
> when you receive a 6."

For better or worse, we have done that a lot in IETF protocols.
I don't think that is helpful for this case.  See below.

>...
> I actually do not care whether the resolverID is
> namespace-dependent or namespace-independent. As I have
> pointed out, a resolver receives both the resolverID and the
> NID (plus the NSS, of course), so at the level of resolver
> behavior, the behavior will always be namespace-dependent
> because it depends on the identity of the thing being named.

Yes.  That is part of what I was trying to get at.  I think
some people has suggested otherwise, that they want resolver
definitions and resolvers that are completely
namespace-independent with no dependency on the rest of the
URN.  What they want may or may not be possible, but that is a
separate issue; see below and my base note today.

> Right now the specification equivocates because sometimes it
> says independent and sometimes it says dependent. That is a
> problem.

Yes.  As discussed in the base note, I think the best solution
right now is to pull all of that text out.

> Upon reasoning it through, my position was:
> 
> "people writing durable, universal naming
> schemes should not be required to be in the business
> (directly) of dictating what resolution services get developed
> or not, and vice-versa. I.e., the URN namespace registration
> template should not require new URN namespaces to specify a
> set of resolution ops."

Ok.
 
> This is based on making it easier to register URNs. If
> resolverIDs (resolver operations) are namespace-dependent, we
> must expect the URN registration template to define resolution
> a lot better. That is more work. And it may change over time
> based on different parties' needs.

Ok.  And that is actually persuasive for me.
 
>... 

--On Monday, February 22, 2016 14:21 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>> This is based on making it easier to register URNs. If
>> resolverIDs (resolver operations) are namespace-dependent, we
>> must expect the URN registration template to define
>> resolution a lot better. That is more work. And it may change
>> over time based on different parties' needs.
> 
> I guess I'm with Sean here. Sean maybe implied this, but I
> didn't see it stated explicitly: It would make introduction of
> new resolution services (which might perfectly well be able to
> deal with preexisting URN namespaces) a lot more difficult. We
> don't have any magic to update specs or registrations
> automatically.
> 
> So at the most, I'd want to limit us to something like
> "Namespace registrations MAY indicate some of the types of
> resolvers suitable for the namespace (by listing the relevant
> resolverIDs). Such a list does not restrict the use of
> resolvers to only the listed types."

After reviewing all of the comments and reviewing the document
again, I think even that is too much.  I think we need to say
nothing more than "reserved for future standardization" because
the above leads into its own set of issues that would need to be
resolved.

There is an interesting question about what to do about the
registration template -- see base note. 

At this point, I see the best way to resolve the issues being to
pull all of the text out and leave r-components for future
standardization.   In other words, I think the conclusion from
the above (and other things) is to tear any text that attempts
to explain the status and evaluation of r-components out.  I
don't know whether it is worth trying to preserve the two-part
syntax idea (i.e., separation of resolverID from the rest) or
whether that should be dropped as well.

Again, see base note.

    john