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

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

--On Friday, April 17, 2015 21:16 +0100 Graham Klyne
<[e-mail]> wrote:

> On 16/04/2015 23:35, John C Klensin wrote:
>> 
>> 
>> --On Thursday, April 16, 2015 16:46 -0400 Tony Hansen
>> <[e-mail]> wrote:
>> 
>>> Just now, I've re-reviewed all references to 3986 within
>>> draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere
>>> that it should be construed as >updating< 3986. There are
>...
>> In the spirit of moving on, I'd prefer to avoid requiring
>> another rev and will happily settle for the assurance that
>> everyone involved will provide support for my pushing back if
>> anyone stands up and says "you can't do <X> in URNs because
>> draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit
>> it".
>...

> I assume you meant "draft-ietf-appsawg-uri-scheme-reg" above
> (not "*-urn-*"). 

Yes.  Sorry.

>  I'd be pushing back on any aspect which
> appeared to change what is required by RFC3986.

Then we are in agreement (!).

Because my concern still seems to be unclear, let me try to
explain it in a different way and as a series of logical
statements and propositions.  I do not believe that anything in
the first three bullets below should be controversial.  The
fourth one may be but, IMO, only if long-established principles
and terminology in computer science have become irrelevant to
the IETF and, at the risk of invoking another conversation, the
Humpty Dumpty philological system has taken over entirely.

(1) The community approved RFCs 2141 and 3406 as a Proposed
Standardsd and BCP, respectively.  RFC 1737 provides useful
information and context, but it is an Informational document and
has never been seriously claimed to represent community
consensus.   I note that such a document would not be allowed to
have "Requirements" in its title today.  It is interesting the
the title of RFC 1736 includes "Recommendations", not
"Requirements".

(2) RFC 3986 is not identified as updating, altering, or
restricting any of 2141 or 3406, nor, for that matter, 1737.
RFC 2396 is not identified as changing any of those
specifications either.  The sentences in Section 1.1.3 of RFC
3986 (and Section 1.2 of 1737 read as an explanatory and
tutorial "overview" not normative requirements.

(3) RFC 3986 Section 1.1.3 indicates that "A URI can be further
classified as a locator, a name, or both".   While that text
reinforces the (IMO, unfortunate) confusion between generic
name-class URIs and the "urn" scheme, there appears to be
nothing in 3986 (in that section or otherwise) that allows, much
less requires, one scheme to constrain another, either within
classes or across them.  It would be as unreasonable to claim
that the definition of the "urn" scheme imposes a constraint on
a hypothetical member of the "both" class at is would be to
claim that the definition of the "xmpp" or "sip" schemes
constrain the "http" scheme.

(4) While the title and abstract of 3986 appear very clear that
it, and its normative requirements, are about syntax, the
document also contains a great deal of explanatory, descriptive,
and other semantic information.  It is possible to separate
those things from the syntax, if necessary by modifying 3986
which does not (and could not) contain provisions that write its
provisions into stone with no possibility of modification.

At least so far, the IETF has not given up on the importance of
good sense and deployment experience and practices (sometimes
included under "running code") in interpreting written standards
and practices, including "BCP" documents that lay out procedures
or hopes for the future rather than documenting practices
already in widespread use.  When a standards-track document
exists, specifies things that are widely deployed and have been
for years, is associated with values in a registry, and clearly
anticipates certain future extensions, a claim that a later set
of documents prevent those extensions (or bar a designated
expert from approving IANA's installing an updated
registration), that would be a serious issue, requiring wide and
careful community review of the tradeoffs involved.  

I do not believe that either draft-ietf-appsawg-uri-scheme-reg
or RFC 3986 impose such requirements on the "urn" scheme.
Therefore, I do not believe there is a substantive problem with
draft-ietf-appsawg-uri-scheme-reg even though (as with most
other IETF documents) we could, if so inclined, quibble over
exact choices of words for months or years.  I am not so
inclined if it can be avoided.   

On the other hand, if claims are made that
draft-ietf-appsawg-uri-scheme-reg either adds constraints to
those that are clearly present in RFC 3986 or reinterprets (or
"clarifies") text in 3986 to impose stronger or different
requirements than are present there, especially on URI schemes
that existed long before 3986 and that were not explicitly
modified by it (or registration of updates to them), then there
are, IMO, serious problems with either the interpretation, of
this new specification, or both and fairness and reasonableness
require that they be sorted out now.

Finally, an observation: It has been said many times that the
primary purpose of  draft-ietf-appsawg-uri-scheme-reg is to make
registrations easier, especially for schemes that are, or are
reasonably expected to become, widely deployed and significant
to the Internet.    It seems ironic, perhaps even perverse, that
a document that is justified on that basis is being held up
because of claims that it will, as soon as approved, impose more
stringent requirements on one or more URI schemes that are
already broadly deployed and demonstrably important to the
community.

> (All of this leaves me wondering if it would be helpful to
> state that explicitly in the registration document, but at
> this stage in the process I'm reluctant to introduce
> suggestions for shadow-dodging changes.)

See above.

best,
   john