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

From: John C Klensin <[email-masked]>
Date: Mon, 21 Mar 2016 20:21:14 -0400

(Sorry -- tried sending this from the wrong address, so it is
arriving last in the group of four, not first as intended)

Sean,

I've gone through your 21 February notes, and Martin's
response, multiple times, written text each time, and then put
that text aside.  I did it again Friday and Saturday.  I'm
going to comment on some of the issues you raise in drastically
revised and refocused separate notes, but I think there is a
higher-level conclusion on which we need to focus (i.e., people
who want to capture the essence of what I have to say and
suggest without getting into the details can probably skip the
other three notes especially if their main objective is
finishing up as soon as possible; those who feel passionately
about r-components should probably read all four).

My conclusion is close to one that I believe we reached many
weeks ago, perhaps even before your note proposing what I
abstracted as resolver IDs, which is that the WG simply did not
have the energy to pin resolvers and resolver mechanisms down.
Given time, I'd personally enjoy working on some of the issues
with you, but I just cannot see any hope of doing so
successfully within the context of the present Working Group,
its charter, and its long-overdue schedule.  

Now it may be that implies that I (or the WG, because it was
mentioned on the list) made a mistake in trying to take a baby
step in defining the r-component syntax as containing a
resolver-ID and a string.  If trying to push the boundary even
that far simply exposes a family of other issues that we feel a
need to resolve in order to make progress, then it is probably
more desirable to simply pull that syntax out of 2141bis and
treat the entire r-component as opaque (modulo a restriction on
occurrence of terminating strings without encoding; see below)
until and unless other standards come along.

In that regard, I note another issue that people seem to be
making different assumptions about and that is whether the
choice of resolver is appropriately an alternative to a
q-component or part of the NSS to determine what information is
retrieved.  In other words (and as a silly example), if I have
a URN like 
   urn:ietf:rfc:2141
can I use
   urn:ietf:rfc:2141?+RFCPageCounter
to get the number of pages in
the thing?  Is that a plausible alternative to
   urn:ietf:rfc:2141?=pagecount
or something like it?

>From looking back at discussions since we separated r-component
and q-component, I think there are people in the WG who believe
in a "yes" answer (perhaps passionately), people who believe in
a "no" answer (perhaps passionately), and people for whom the
topic is the source of a headache.  The only thing about it
that seems clear to me is that our trying to reach strong
consensus about a conclusion will drop us into another rathole.

In particular, note that Martin's comments on your note includes:

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

> I think I understand what John is trying to say: If there's a
> resolverID "info", and that's (for simplicity's sake) defined
> to return info about the author(s) and the length of the
> document in bytes, then it's not possible for a namespace
> maintainer to say that for the particular namespace, the
> "info" resolver also returns the date of creation, or doesn't
> return the length in bytes, and so on. 
>...

This was what I was trying to say.  However, the mere question
of whether it is reasonable to define a resolver whose
function is to return particular metadata seems to be
controversial, especially when one starts making suggestions
about namespace independence.

Similarly, it seems fairly clear to me that, as soon as we
start pursuing the question about selecting information to be
obtained by choice of resolver, we are also going to need to
consider whether the semantics and interpretation of a
q-component are a function of the choice of resolver rather
than that of the namespace.  See the "embedded characters" note
for an example of where the question might lead.  Again, I
think that issue can be sorted out, but don't see a way to do
it in this WG as it is now chartered and functioning. 

I'm going to post three other notes (with deliberately
different subject lines) immediately after this one.  Reading
them may be helpful in understanding whether the conclusions
that follows are reasonable but, again, my own key priority at
this point is moving forward and getting 2141bis published, not
how rich and detailed we can make that spec.

Conclusions and summary (each of these conclusions requires a
decision by the WG or instructions from the Co-chairs):

(1) We are not going to be able to fully specify r-components
in this WG under this charter and work plan.  Things that
cannot be "fully specified" include drilling down into the
details of resolver functions, syntax of whatever follows the
resolverID, whether name-value pairs or similar construction
should be required, what sorts of registration models would go
with such pairs, registration procedures for resolverIDs,
applicability scope for such IDs, etc.  The document contains
too much, rather than too little, text in some of those areas
now, and, to the extent to which the the excess or explanatory
material adds confusion, it should be removed rather than
debated and fixed.

(2) I am operating, and working on 2141bis, on the assumption
that I correctly understood Andy's conclusions about WG
consensus and his instructions about how we should proceed with
r-component and q-component syntax as using two character
sequences to introduce each, with the first character being "?"
and the second at the discretion of the document editors.  If
that assumption is not correct, I need new instructions.  If it
is, it would help the WG move forwzrd if the topic were dropped
unless someone identifies a genuinely new issue.

(3) The syntax model for r-components in 2141bis-15 is fairly
restrictive, including arbitrarily restricting resolverIDs to
the same characters allowed in NIDs.  If we cannot agree on
that, and noting that some possible changes would require
careful examination of RFC 3986 to see if they are even
possible within the constraints of that document, I suggest
that we drop the idea of dividing the r-component into a
resolverID and string entirely, making the entire r-component
opaque until other standards are specified.

(4) It is no secret in this WG or elsewhere that I don't like
the character reservation, syntax definition, or encoding
specifications of RFC 3986 very much (or at all).  However,
they are what we are stuck with and, IMO, discussions about the
inherent problems with 3986-style encoding or other issues
belong in a discussion of 3986, not in efforts to use or
constrain URNs to fix or work around them.   I'm happy to be
wrong about that and do whatever the WG wants, but am at the
point where I need instructions from the Co-chairs on the
subject, especially when the problems interact with (2) above.

(5) One of my main inferences from Sean's notes and the
comments above is that, in the absence of active discussion in
the WG and/or instructions to the contrary from the Co-chairs,
I am to pull as much discussion of r-components out of 2141bis
as possible, reducing it to a brief statement about the intent
to support instructions about how to "resolve" a URN but that
more specific definitions and use are to be the subject of
future standardization and the whole construct is reserved
until that occurs.   That leaves two subsidiary questions:

(5.1) Should I retain the "resolverID: string" syntax entirely,
including the NID-like syntax for resolverID unless the WG
directs otherwise, or should I remove that as well?

(5.2) Should I put placeholders, with similar "reserved for
future standardizing" text, into the registration template so
they at leave have a field for it in the registry.  I see some
advantages to doing so, mainly saving IANA future difficulties
by defining and structuring the NID registry now and then
having to redefine or restructure it in the future, and no
disadvantages, but maybe I'm missing something.  If this is a
big deal for anyone, I/we could ask IANA if they care.

Barry and Andy, one implication of the above is that, unless you
tell me, really soon now, what tentative decisions to make
about the above, -16 is certainly not going to make the posting
deadline.   My personal recommendation is that, if it works for
your schedules, we give the WG a week (or, if you prefer,
more), time to react to these notes (and, implicitly,
additional time to react to Sean's notes) and then you give me
the go-ahead to fold the conclusions into -16 and get it
posted.

best,
    john

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 22 Mar 2016 18:32:23 +0900

Hello John, others,

> material adds confusion, it should be removed rather than

I agree. Specification of r-components would either need some careful 
design-team(-like) work, or some existing running code. The later 
doesn't exist, and neither does the time and energy for the former.

> opaque until other standards are specified.

I agree with dropping, mainly because of the reasons for (1).

> constrain URNs to fix or work around them.

Yes. In particular also because there IS a large amount of running code 
related to RFC 3986.

> I'm happy to be

I support removal, but would be okay to leave it in if that helps consensus.

> big deal for anyone, I/we could ask IANA if they care.

I don't mind somebody asking IANA, but I think for them, adding an 
additional column to a registry isn't rocket science. On the other hand, 
having a field in a registry template where all the registrants are 
going to wonder what to put in (and our answer would be "nothing for the 
moment, that's just for the future") will be highly confusing.

Regards,   Martin.