[Uri-review] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-historic-00.txt)

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

Alexey,

It seems to me that the TN3270 discussion has started to
conflate two separate issues and that we might derive something
useful from that discussion:

	(1) Whether the URI scheme is properly specified and in
	use
	
	(2) Whether the underlying applications protocol is
	well-specified, in use, and still useful.

For TN3270, the answer to "properly specified" is clearly "no"
because, as several people have pointed out, there really is no
spec, just a reservation.  It may still be in use, and several
people have made credible suggestions that is actually the case.
Certainly the answer to (2) is "yes".  

Having a tn3270 URI in use without a spec is actually troubling
because there is no way to tell whether all uses of the keyword
are consistent.   However, deprecating the keyword or dropping
it from the registry is not a solution to that problem.  Either
getting a spec or warning people off would be a superior
approach.

That situation is very different from the "mailserver" case,
where there really isn't an underlying application protocol in
active use, at least as far as I know.

Perhaps that difference is a useful differentiating factor.  For
some years, we had the implicit assumption that every
application protocol deserved a URI.  I've personally always
felt that was a bad assumption because of mismatches between the
operational model of some protocols and the URI model, but I
lost that argument.  Looking at the situation from the
perspective of today's environment, I suggest that:

(1) We move URI schemes to Historic only if we are justified and
willing to move the underlying applications protocol
specifications to Historic -or- if no such protocol spec exists
and there is no reasonable prospect of getting one.

I note that, using that criterion, "mailserver" would go to
Historic and "tn3270" would not.  I haven't done enough research
to have an opinion about "afs", but see below.

(2) We instruct IANA to separate the "Provisional" category of
the URI Scheme registry into two categories: 

	* Provisional (defined more or less as work in progress)
	and
	
	* Reserved keyword

and move any of the now-provisional keywords for which there are
adequate protocol specs but no adequate URI spec (existing or in
active progress) into it.  I note that RFC 1738 describes the
keywords it lists as "proposed at various times" with
"...suggested that IANA reserve...", not "Provisional".  After a
quick search, I haven't been able to discover any instructions
to IANA to identify them as Provisional.  Unless such
instructions exist, one could sensibly interpret the separation
suggested here as correcting an error.

It seems to me that, until and unless the IETF takes a strong
position against the "all application protocols can reasonably
be associated with a URI" model, having a facility to reserve
application-associated keywords for applications that are
well-defined and URI schemes that might be developed in the
future would promote interoperability by providing a warning
that the keyword should not be generally used until (and unless)
a spec is produced.

If we took that approach, we could safely put both tn3270 and
afs into "Reserved" if only because it is not clear to me that
making a more careful decision about the latter would be worth
the effort it would take.   We could similarly move anything
else in the Provisional list that is associated with an expired
I-D to Reserved.

If there is sympathy for this approach and an I-D is needed to
establish rules for adding new entries to the "Reserved"
category, I guess I'm willing to quickly turn out a first draft.
That draft could also formally create the category if needed
but, as noted above, I think its absence is an error on IANA's
part.

    john