RFC 2717 (rfc2717) - Page 3 of 10
Registration Procedures for URL Scheme Names
Alternative Format: Original Text Document
RFC 2717 Registration Procedures for URL Scheme Names November 1999
2.3 Additional Registration Trees
From time to time and as required by the community, the IESG may
create new top-level registration trees. These trees may require
significant, little or no registration, and may allow change control
to rest in the hands of individuals or groups other than IETF. A new
tree should only be created if no existing tree can be shown to
address the set of needs of some sector of the community.
3.0 Requirements for Scheme Name Registration
3.1 General Requirements
All new URL schemes, regardless of registration tree, MUST conform to
the generic syntax for URLs as specified in RFC 2396.
3.2 The IETF Tree
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 2718, 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.
The NAMES of schemes registered in the IETF tree MUST NOT contain the
dash (also known as the hyphen and minus sign) character ('-')
USASCII value 2Dh. Use of this character can cause confusion with
schemes registered in alternative trees (see section 3.3).
An analysis of the security issues inherent in the new URL scheme is
REQUIRED. (This is in accordance with the basic requirements for all
IETF protocols.) URL schemes registered in the IETF tree should not
introduce additional security risks into the Internet Architecture.
For example, URLs should not embed information which should remain
confidential, such as passwords, nor should new schemes subvert the
security of existing schemes or protocols (i.e. by layering or
tunneling).
Petke & King Best Current Practice