Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review

[John C Klensin <[e-mail]>]

Barry has commented on the more important part of this, but an
observation on the other part...

--On Thursday, April 02, 2015 10:43 +0100 Graham Klyne
<[e-mail]> wrote:

>> If we can agree that this is not applicable to existing
>> registered scheme definitions or updates to them and that
>> future URN-like schemes are unlikely, then that is a
>> non-issue.  If we cannot, the AppsAWG and IESG should be
>> formally aware (the former has certainly been told about this
>> in various area meetings) that the current consensus within
>> URNBIS is to separate URNs from the semantic requirements of
>> 3986 [2].  That position was the result of a difficult
>> compromise in which the main alternative was to separate URNs
>> entirely from what the WG believes are the many assumptions
>> (most derived from locators) and some of the confusing
>> language in 3986.
> 
> Procedural matters aside, I think this is an important
> clarification, and that urn: URIs SHOULD be constrained by
> this.  This is not about existing and new URI schemes, but
> about what is required to be a a valid URI.

Procedural issues very much not aside, I would like to see if we
can navigate the very large collection of URI issues (including
those being discussed outside IETF) in a way that doesn't make
everything so dependent on everything else that we cannot move
any document (including this one) forward without moving
everything else forward at the same time.

If, as you suggest, language in
draft-ietf-appsawg-uri-scheme-reg-05 "clarifies" what is
required to be a valid URI, especially in a way that affects
both existing and future ones, then it necessarily updates 3986.
If it does that, then it is missing the required "Updates"
indication (trivial) and the required explanation of what parts
or provisions of 3986 are being updated and how.  So, if you
believe the above, you have just made a significant procedural
objection to processing the draft in its current form.   While
that might be a minor issue for some documents, easily corrected
by an RFC Editor note, I believe there is ample reason to
believe that a description of what is being updated and why
would turn out to be controversial and difficult in terms of
achieving consensus.

At least from my perspective, the problem goes beyond that and
into issues I have identified earlier.  If
draft-ietf-appsawg-uri-scheme-reg modifies what it is possible
to do in ongoing URN work beyond whatever is clearly specified
in 3986, then any of the active participants in URNBIS (or those
concerned about its output, whether actively participating or
not) are entitled to raise the issue of whether openness and
fairness allows draft-ietf-appsawg-uri-scheme-reg to be
processed independently of the URN documents that it claims to
restrict.   Equally frighteningly, if
draft-ietf-appsawg-uri-scheme-reg changes the fundamental
validity criteria for URIs as specified (or claimed to be
specified) in 3986, it presumably [re]opens all of the issues
about what 3986 actually requires rather than recommending or
discussing and probably requires reaching consensus on and
documenting such topics as those raised in the rather extensive
threads about 3986 validity and scope that showed up in January
and not moving _any_ of these documents forward until 3986bis
(the right place to apply such clarifications) is ready for IETF
Last Call.

Another complication is that if there is disagreement in the
community about the scope of draft-ietf-appsawg-uri-scheme-reg
before it is even approved, you are a partisan for one position
in that matter and that combination might cause reasonable
people to be concerned about perceptions of possible
interactions between those issues and your role as Designated
Expert.  

I hope we can avoid going into a place where all of these issues
become procedurally interlocked but when some of the authors and
a subset of the (I believe few) people who carefully reviewed
draft-ietf-appsawg-uri-scheme-reg disagree on its scope and
applicability, we are not in good shape for avoiding that
outcome.

    john