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

[Graham Klyne <[e-mail]>]

On 02/04/2015 15:19, John C Klensin wrote:
> 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.

I certainly did not mean to suggest that.

I think that draft-ietf-appsawg-uri-scheme-reg-05 has no place "clarifying" what 
it is to be a URI - that is the role of RFC3986.  I did not think it does this, 
but if you think it does, I would be interested to understand where and why.

#g
--

> 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
>