RE: Proposed amendment to language of draft-ietf-url-procedures

Keith, 

My concern about that is demonstrated by the example of about: (pun not
intended), which was implemented in different ways by Netscape and
Microsoft.  While I agree that it is not a good thing to have two
non-interoperable implementations of the same scheme, it IS a good thing to
document what exists.  As discussed elsewhere, cautionary language should be
required in such a document ("the IETF does not endorse this usage").  

I do agree that the IESG should have discretion to reject submissions that
have nothing to do with the Internet, although I would offer a
counterexample: the aol: scheme, for reasons that have been previously
discussed.  Nonetheless, I agree that IESG should have broad discretion in
limiting URL scheme registrations supported by Informational RFCs.  Perhaps
the following rewrite of my proposed language meets that:
---------------
Registration in the IETF tree requires publication of the URL scheme syntax
and semantics in either an Informational or Standards Track RFC. In general,
the creation of a new URL scheme requires a Standards Track RFC.  An
Informational RFC may be employed for registration only in the case of a URL
scheme which is already in wide usage and meets other standards set forth in
[RFC-GUIDELINES], such as "demonstrated utility" within the Internet
Architecture; the IESG shall have broad discretion in determining whether an
Informational RFC is suitable in any given case, and may either recommend
changes to such document prior to publication, or reject it for publication.
An Informational RFC purporting to describe a URL scheme shall not be
published without IESG approval.  This is a departure from practice for
Informational RFCs as set forth in RFC 2026, for the purpose of ensuring
that the registration of URL schemes shall serve the best interests of the
Internet community.