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

From: John C Klensin <[email-masked]>
Date: Wed, 01 Apr 2015 15:33:18 -0400

Hi.

I've been thinking more about Larry's claim [1] that
draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis"
below) constrains work going on in the URNBIS WG and, in
particular, draft-ietf-urnbis-rfc2141bis-urn and have been
studying both documents.

This is not a late review in the usual sense.  Under normal
circumstances, I would consider a WG document to update a
registration model to be routine and in good hands and reached
precisely that conclusion about this specification after
glancing through an early version.  What has changed is the
assertion that this document constrains the work of the URNBIS
WG and actually invalidates decisions already made there.  If
true, that raises significant issues of a variety that, had they
arisen after IESG approval, would properly have resulted in
appeals.   I think we should consider it fortunate that the
issue has arisen before things reached IESG balloting.

Some of Larry's comments involve substantive issues about URNs
or decisions made in, or under consideration by, the URNBIS WG.
I assume that they will be taken up in an ordinary way on that
WG's list (a response from me to some of them can be expected
soon although it seemed important to get these notes out first).
However, the interactions between 4395bis and the URN work raise
some fundamental questions about 4395bis that I hope can be
resolved without either holding it up significantly or dropping
it into a procedural quagmire. 

We have a situation in which two WGs (notably two WGs that are
responsible to the same AD) are aware of each other's work and
claims are made that the work conflicts or that one effort
dominates the other.   Certainly both the principles of openness
and fairness that are called out repeatedly in RFC 2026 and our
long-term practices suggest that the relevant documents should
be considered at the same time and, as appropriate, be reviewed
and achieve at least rough consensus in both WGs unless the
conflicts can be eliminated in other ways.   In particular,
neither WG (or document authors) should be able to establish
their document as controlling the other by creating a race
condition.

In this case, the following specific issues seem relevant to
resolving, eliminating, or clarifying the claimed conflict about
controlling text.

(1) I note that there has been a title change between RFC 4395
("Guidelines and Registration Procedures for New URI Schemes")
and 4395bis ("Guidelines and Registration Procedures for URI
Schemes") that the authors of the latter did not consider
significant enough to note in their discussion of changes in
Appendix A.

The third paragraph of Section 1 begins "This document provides
updated guidelines for the definition of new schemes..." and
"new" is repeated at the beginning of Section 3 and at several
other points in the document.  I infer from that, as well as the
above, that the change of title is not intended to be
substantive and that, in particular, the procedures established
or updated by this document do not alter or constrain any of 

 (i) Procedures for updating established registrations
	
 (ii) The ability for a new registration to specify
	appropriate updating procedures for that scheme
	definition
	
 (iii) The ability for the authoritative entity for a
	particular already-registered scheme to change the rules
	for updating that scheme.  When that scheme definition
	is part of an IETF standards-track document, the usual
	rules for updating standards-track documents apply.
	
and that,
 (iv) As (probably) pointed out at the end of the second
	paragraph of the introduction, URN namespaces are not
	part of the scope of this document.

As I read 4395bis, all of those statements seem clear to me.
However, if Larry, especially in his capacity as a listed
co-author of 4395bis, reads it in a different way, I think some
clarification is probably necessary (and that, if there is no
agreement that these are really clarifications, that the
document should be returned to the WG):

 Clarification #1: Either restore "new" to the title and
	add it to the Abstract or insert an explicit statement
	in the Introduction that reflects the above, ideally all
	three.
	
 Clarification #2: Either clarify very precisely what
	"explicitly" means in the sentence  'URN "namespaces"
	([RFC3406]) are specific to the "urn" scheme and are not
	covered explicitly by this specification.' (a sentence
	4395bis appears to have incorporated without change from
	4395) or drop "explicitly" from that sentence.

(2) Section 3 of 4395bis cites the "overall syntax for URIs"
from RFC 3986 and then says 

	"A scheme definition cannot override the overall syntax
	for URIs.  For example, this means that fragment
	identifiers cannot be re-used outside the generic syntax
	restrictions, and fragment identifiers are not
	scheme-specific."

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.

The paragraph quoted above appears to be new to 4395bis, does
not appear to be noted in the appendix that lists changes, and I
wonder why it was felt to be necessary.  Whether it is
applicable to the "urn" scheme or not, the statement is
factually false.  The only constraint the "overall syntax for
URIs" imposes on what 3986 calls a "fragment" is that it be
preceded by "#", that it extend to the end of the URI, and that
it obey the usual rules about permitted characters and character
escaping.   Statements about fragment identifiers being
scheme-specific are _semantic_ restrictions and, absent a good
deal of semantics, I can't even figure out what "fragment
identifiers cannot be re-used outside the generic syntax
restrictions" might mean.

 Clarification #3: Either explicitly exempt URNs (either
	by name or by "not applicable to existing
	registrations") or fix that paragraph to clarify the
	difference between syntax and semantic restrictions.  In
	the interest of correctness and technical accuracy, a
	fix seems preferable to an exemption.  The thing I think
	we should avoid (even though it would be easy from a
	textual standpoint) is having to put text in the URNBIS
	documents that updates 4395bis to remove this particular
	apparent requirement.   If we have to have a battle over
	the applicability of that text, it seems to me that the 
   time to do it is while both documents are still under
	consideration, i.e., now.

(3) I observe that 4395bis appears to considerably increase and
tighten the binding to 3986 relative to 4395, with the above
being just one example.  Those who have been watching
developments closely are aware that there are multiple efforts
in progress in different organizations that have the intent to
revise or even supercede 3986.  The IETF has not taken a strong
position about those other efforts and there have apparently
been AD-level discussions about ceding generic URI work to other
bodies.   Given that state of uncertainty and the IETF's
presumed desire to avoid having changes in the status of 3986
drag this 4395bis specification into obsolescence, it would seem
desirable to make this document and procedure less, rather than
more, dependent on specific text and wording in 3986.
Alternately, if the intent of those additional dependencies is
to try to defend against internal or external alterations to
3986, I believe that should be handled up front rather than
trying to use this registration specification as a back door.

 Clarification #4/ Recommendation: The authors or others
	should make a careful pass through this document,
	eliminating specific dependencies on 3986 where possible
	and clarifying the intent of what remains sufficiently
	to preserve the effectiveness of this specification
	should 3986 be superceded.   If that is not feasible,
	the IANA Considerations section of this document should
	be clear about the status of the registration procedure
	(and the registry that it specifies) should the
	references on which the spec is normatively dependent be
	superceded (that would probably be a good idea for all
	registration specifications that are not self-contained,
	but it is important in this case because there appears
	to be a real possibility that documents that supercede
	3986 will not be under IETF change control).

(4) The second sentence of the first paragraph of Section 3.3
("Well-defined") says:

	"Schemes that are not intended to be used as locators
	SHOULD describe how the resource identified can be
	determined or accessed by software that obtains a URI of
	that scheme."

If this is intended to be applicable to URN or URN-like schemes
that are used as what URNBIS has been calling "indicators", it
is not clear what the requirement statement means.  Requirement
statements without clean meaning vis-a-vis all of the cases to
which they might apply are undesirable and are indeed "technical
deficiencies".

 Clarification #5: Either clarify the excluded cases
	implied by the "SHOULD" or explicitly exempt URNs and
	any similar schemes that might be developed or
	registered in the future.

(5)  The last paragraph of Section 3.3, much of it copied intact
from RFC 4395, suggests a requirement that all "legal protocol
interactions" of another protocol must be capable of being
mapped into the URI and calls out "ftp" as an example.  One
significant change from 4395 (not noted in the Appendix that
lists changes) is the transformation from an informal "must"
suggestion about the mapping model to a normative "MUST".  That
"MUST" actually contradicts the final sentence of the paragraph
which begins "If not all legal values or protocol interactions
of the base standard can be represented..."

This raises two issues.  First, if 4395bis (especially its
normative requirements) is to be applied retroactively to
existing registrations, then the registration of the ftp scheme
is now invalid (whether that last sentence is considered as a
path to an exception or not).  First, the discussion in RFC
1738, which is referenced as the definition of the scheme from
the IANA registry, is not complete relative to the functionality
of the FTP protocol as of the time RFC 1738 was written and does
not explain the exceptions.  It even says that it is incomplete
with the rather magical sentence (in Section 3.2.2 of RFC 1738)
that reads "The mechanism for doing so is not spelled out here."
The IETF has also chosen to standardize a number of extensions
to FTP (including, in these IPv6 and security-conscious days,
RFCs 2428 and 4217) that have not been reflected in either the
registration or in an update to RFC 1738.  Second, even for new
registrations, changing informal guidance that happens to use
the word "must" to a normative absolute requirement (with
"MUST") should require much more careful review and evaluation
by the community than this change appears to have gotten
(especially given the apparent contradiction it introduces).

FWIW, I haven't done a careful review, but it is not clear to me
that even the "http:" scheme, as reflected in the IANA registry,
would be considered valid by the criteria in 4395bis given
functionality changes introduced by HTTP2 and other relatively
recent changes and extensions.

I note, also FWIW, that Section 3.4 is much more balanced and
reasoned and that it uses "SHOULD" consistently and not "MUST".

Retroactive application of Section 3.7 ("Clear Security
Considerations") would also invalidate a number of existing
registrations.

 Clarification #6: This example, which has nothing to do
	with URNs or, unless the long-expired
	draft-hoffman-ftp-uri is considered, any other active
	URI-defining work in the IETF, points out another reason
	why it is important that this 4395bis document
	explicitly disclaim applicability to any
	already-registered scheme or updates to it except as the
	most general guidance and recommendations of issues to 
   be considered.
	
 Clarification #7: The MUST in the cited paragraph should
	be, at most, a "SHOULD" or the paragraph should be
	reworded to correctly reflect realistic intent.

 Clarification #8/Recommendation: The list of Changes in
	Appendix A should be expanded to reflect all changes
	from general guidance (expressed in, e.g., "must" or
	"should") to normative requirements.  Treating such
	changes as editorial corrections is appropriate only
	when the context clearly indicates normative intent and
	the changes do not introduce contradictions either
	within the text or to established practices.

(6) URN work has made it clear that defining the scope of
applicability of a URI scheme is, at best, a shared
responsibility between whatever documentation defines the scheme
and the documentation that defines the referencing context.
Attempts to shift all of that responsibility to the scheme
definition, as Section 3.5 can be interpreted to do, is
unrealistic if only because the scheme definition cannot predict
referencing contexts that might be defined or redefined in the
future.  Given that the current text uses a "SHOULD", it is
probably ok, but a clarification that contexts that incorporate
URI references also bear some responsibility for describing the
schemes that are valid and meaningful (preferably on an
inclusion basis) would be helpful to avoid outrageous claims in
the future.  Anyone contemplating a 4395ter might consider
whether adding an "applicable application, protocol, or context"
field to the IANA registry would be useful.

 Clarification #9: Add a sentence to Section 3.5 to
	clarify that its provisions do not eliminate the
	requirement for the applications and/or protocols from
	which URIs are used to discuss the schemes that are (or
	are not) relevant and appropriate for use in those
	contexts.

(7) In my capacity as someone who is supposed to know a bit
about i18n issues, I think I understand the intent that
motivated the inclusion of the last paragraph of Section 3.6.
However, after reading that paragraph several times, I am not
sure what it actually means.  If the term "variant" (which I
would encourage authors to avoid) is interpreted in its ICANN
usage or even as defined in Section 7.2 of RFC 6365, I am _sure_
I don't know what the paragraph means.

 Clarification #10: That paragraph needs to be rewritten
	and carefully checked by i18n experts.  Encouraging the
	registration to make a clear statement about
	normalization and/or other comparison-related issues
	would probably be desirable.

(8) Section 7.3 is not explicit that an updated registration can
change the mechanism for future updates, nor that registrations,
especially those associated with IETF documents, can specify
update/change mechanisms different from those specified in this
document.   Had I been asked a month ago, I would have said that
both were obvious and that further explanation was not required.
Since recent discussions have called both into question, I think
some clarification is needed.

 Clarification #11: Add text to Section 7.3 to make it
	explicit that scheme registrations MAY specify updating
	procedures that are more specific than those outlined in
	4395bis, including identifying other approval mechanisms
	or responsible parties, and that scheme registration
	updates may modify the updating mechanism as well as
	other aspects of the registration.

 Clarification #12: In the template shown in Section 7.4,
	add to the "Change controller:" entry a statement
	equivalent to "Any special considerations about updating
	or updating procedures should also appear as part of
	this item."

(9) Further evidence that this document is confused about
existing registrations, retroactive application, and its own
requirements appears in Section 8.   The "example" URI scheme
registration that is specified in that section does not appear
to conform to the "fields that MUST be supplied" requirements of
Section 7.4: there is no contact given and the "Change
controller" field is identified as "Author/Change controller".
If that flexibility was intended by Section 7.4, the document
should say so.

thanks,
    john

[1]
http://www.ietf.org/mail-archive/web/urn/current/msg02873.html

[2]
https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/