As per Relevance of the word registration, we have this rfc below:
Network Working Group R.
Request for Comments: 2717 UUNET
BCP: 35 I.
Category: Best Current Practice Microsoft
November 1999
Registration Procedures for URL Scheme
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document defines the process by which new URL scheme names
registered
1.0
A Uniform Resource Locator (URL) is a compact string
of the location for a resource that is available via the Internet
RFC 2396 [1] defines the general syntax and semantics of URIs, and
by inclusion, URLs. URLs are designated by including a ":"
and then a "specific-part>". Many URL schemes are
defined, however, new schemes may need to be defined in the future
order to accommodate new Internet protocols and/or procedures
A registration process is needed to ensure that the names of all
new schemes are guaranteed not to collide. Further, the
process ensures that URL schemes intended for wide spread, public
are developed in an orderly, well-specified, and public manner
This document defines the registration procedures to be followed
new URL schemes are created. A separate document, RFC 2718,
Guidelines for URL Schemes [2], provides guidelines for the
of new URL schemes. The primary focus of this document is on
portion of new URL schemes, referred to as the "scheme name
throughout this document
Petke & King Best Current Practice [Page 1]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
1.1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
2.0 URL Scheme Name Registration
2.1
In order to increase the efficiency and flexibility of the URL
name registration process, the need is recognized for
registration "trees". The registration requirements and
registration procedures for each tree differ, allowing the
registration procedure to accommodate the different
requirements for URL schemes. For example, a scheme that will
recommended for wide support and implementation by the
community requires a more complete review than a scheme intended
be used for resources associated with proprietary software
The first step in registering a new URL scheme name is to
which registration tree the scheme should be registered in
Determination of the proper registration tree is based on
intended use for the new scheme and the desired syntax for the
name
This document will discuss in detail the tree that reflects
practice, under IETF ownership and control. It will also set
an outline to assist authors in creating new trees to
differing needs for wide acceptance and interoperability, ease
creation and use, and type and "strength" of ownership
2.2 The IETF
The IETF tree is intended for URL schemes of general interest to
Internet community. The tree exists for URL schemes that require
substantive review and approval process. It is expected
applicability statements for particular applications will
published from time to time that recommend implementation of,
support for, URL schemes that have proven particularly useful
those contexts
Petke & King Best Current Practice [Page 2]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
2.3 Additional Registration
From time to time and as required by the community, the IESG
create new top-level registration trees. These trees may
significant, little or no registration, and may allow change
to rest in the hands of individuals or groups other than IETF. A
tree should only be created if no existing tree can be shown
address the set of needs of some sector of the community
3.0 Requirements for Scheme Name
3.1 General
All new URL schemes, regardless of registration tree, MUST conform
the generic syntax for URLs as specified in RFC 2396.
3.2 The IETF
Registration in the IETF tree requires publication of the URL
syntax and semantics in either an Informational or Standards
RFC. In general, the creation of a new URL scheme requires
Standards Track RFC. An Informational RFC may be employed
registration only in the case of a URL scheme which is already
wide usage and meets other standards set forth in RFC 2718, such
"demonstrated utility" within the Internet Architecture; the
shall have broad discretion in determining whether an
RFC is suitable in any given case, and may either recommend
to such document prior to publication, or reject it for publication
An Informational RFC purporting to describe a URL scheme shall not
published without IESG approval. This is a departure from
for Informational RFCs as set forth in RFC 2026, for the purpose
ensuring that the registration of URL schemes shall serve the
interests of the Internet community
The NAMES of schemes registered in the IETF tree MUST NOT contain
dash (also known as the hyphen and minus sign) character ('-')
USASCII value 2Dh. Use of this character can cause confusion
schemes registered in alternative trees (see section 3.3).
An analysis of the security issues inherent in the new URL scheme
REQUIRED. (This is in accordance with the basic requirements for
IETF protocols.) URL schemes registered in the IETF tree should
introduce additional security risks into the Internet Architecture
For example, URLs should not embed information which should
confidential, such as passwords, nor should new schemes subvert
security of existing schemes or protocols (i.e. by layering
tunneling).
Petke & King Best Current Practice [Page 3]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
The "owner" of a URL scheme name registered in the IETF tree
assumed to be the IETF itself. Modification or alteration of
specification requires the same level of processing (e.g
Informational or Standards Track RFC) as used for the
registration. Schemes originally defined via an Informational
may, however, be replaced with Standards Track documents
3.3 Alternative
While public exposure and review of a URL scheme created in
alternative tree is not required, using the IETF Internet-
mechanism for peer review is strongly encouraged to improve
quality of the specification. RFC publication of alternative
URL schemes is encouraged but not required. Material may
published as an Informational RFC by sending it to the RFC
(please follow the instructions to RFC authors, RFC 2223 [3]).
The defining document for an alternative tree may require
exposure and/or review for schemes defined in that tree via
mechanism other than the IETF Internet-Draft mechanism
URL schemes created in an alternative tree must conform to
generic URL syntax, RFC 2396. The tree's defining document may
forth additional syntax and semantics requirements above and
those specified in RFC 2396.
All new URL schemes SHOULD follow the Guidelines for URL Schemes,
forth in RFC 2718 [2].
An analysis of the security issues inherent in the new URL scheme
encouraged. Regardless of what security analysis is or is
performed, all descriptions of security issues must be as accurate
possible. In particular, a statement that there are "no
issues associated with this scheme" must not be confused with "
security issues associates with this scheme have not been assessed
or "the security issues associated with this scheme cannot
predicted because of ".
There is absolutely no requirement that URL schemes created in
alternative tree be secure or completely free from risks
Nevertheless, the tree's defining document must set forth
standard for security considerations, and in any event all
security risks SHOULD be identified
Change control must be defined for a new tree. Change control may
vested in the IETF, or in an individual, group or other entity.
change control standard for the tree must be approved by the IESG
Petke & King Best Current Practice [Page 4]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
The syntax for alternative trees shall be as follows: each tree
be identified by a unique prefix, which must be established in
same fashion as a URL scheme name in the IETF tree, except that
prefix must be defined by a Standards Track document. Scheme
in the new tree are then constructed by prepending the prefix to
identifier unique to each scheme in that tree, as prescribed by
tree's identifying document
'-'specific identifier
For instance, the "foo" tree would allow creation of scheme names
the form: "foo-blahblah:" and "foo-bar:", where the tree
an arbitrary USASCII string following the tree's unique prefix
4.0 Registration
4.1 The IETF
The first step in registering a new URL scheme in the IETF tree is
publish an IETF Internet-Draft detailing the syntax and semantics
the proposed scheme. The draft must, minimally, address all of
items covered by the template provided in section 6 of this document
After all issues raised during a review period of no less than 4
weeks have been addressed, submit the draft to the IESG for review
The IESG will review the proposed new scheme and either refer
scheme to a working group (existing or new) or directly present
scheme to the IESG for a last call. In the former case, the
group is responsible for submitting a final version of the draft
the IESG for approval at such time as it has received adequate
and deliberation
4.2 Alternative
Registration of URL schemes created in an alternative tree may
formal, through IETF documents, IANA registration, or
acknowledged organization; informal, through a mailing list or
publication mechanism; or nonexistent. The registration
must be documented for each alternative tree, and must be
for all URL scheme names created in that tree
It is the responsibility of the creator of the tree's
requirements to establish that the registration mechanism is
as described; it is within the discretion of the IESG to reject
document describing a tree if it determines the
mechanism is impractical or creates an undue burden on a party
Petke & King Best Current Practice [Page 5]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
will not accept it. (For instance, if an IANA registration
is proposed, IESG might reject the tree if its mechanism would
undue liability on the part of IANA.)
While the template in section 6 of this document is intended to
to URL scheme names in the IETF tree, it is also offered as
guideline for those documenting alternative trees
5.0 Change
5.1 Schemes in the IETF
URL schemes created in the IETF tree are "owned" by the IETF
and may be changed, as needed, by updating the RFC that
them. Schemes described by Standards Track RFC but be replaced
new Standards Track RFCs. Informational RFCs may be replaced by
Informational RFCs or Standards Track RFCs
5.2 Schemes in Alternative
URL schemes in an alternative tree that are undocumented (as
by that tree's rules) may be changed by their owner at any
without notifying the IETF
URL schemes created in an alternative tree that have been
by an Informational RFC, may be changed at any time by the owner
however, an updated Informational RFC which details the changes made
must be submitted to the IESG
The owner of a URL scheme registered in an alternative tree
documented by an Informational RFC may pass responsibility for
registration to another person or agency by informing the IESG
The IESG may reassign responsibility for a URL scheme registered
an alternative tree and documented by an Informational RFC. The
common case of this will be to enable changes to be made to
where the scheme name is privately owned by the rules of its tree
and the owner of the scheme name has died, moved out of contact or
otherwise unable to make changes that are important to the community
The IESG may reclassify a URL scheme created in an alternative
and documented via an Informational RFC as "historic" if
determines that the scheme is no longer in use
Petke & King Best Current Practice [Page 6]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
6.0 Registration
The following issues should be addressed when documenting a new
scheme
URL scheme name
URL scheme syntax. This should be expressed in a clear
concise manner. The use of ABNF is encouraged. Please refer
RFC 2718 for guidance on designing and explaining your scheme'
syntax
Character encoding considerations. It is important to
what your scheme supports in this regard. It is obvious that
interoperability, it is best if there is a means to
character sets beyond USASCII, but especially for private schemes
this may not be the case
Intended usage. What sort of resource is being identified?
this is not a 'resource' type of URL (e.g. mailto:), explain
action that should be initiated by the consumer of the URL.
there is a MIME type associated with this resource,
identify it
Applications and/or protocols which use this URL scheme name
Including references to documentation which defines
applications and/or protocols cited is especially useful
Interoperability considerations. If you are aware of any
regarding your scheme which might impact interoperability,
identify them here. For example: proprietary or uncommon
method; inability to support multibyte character sets
incompatibility with types or versions of underlying protocol (
scheme is tunneled over another protocol).
Security considerations
Relevant publications
Person & email address to contact for further information
Author/Change controller
Applications and/or protocols which use this URL scheme name
Petke & King Best Current Practice [Page 7]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
7.0 Security
Information that creates or updates a registration needs to
authenticated
Information concerning possible security vulnerabilities of
protocol may change over time. Consequently, claims as to
security properties of a registered URL scheme may change as well
As new vulnerabilities are discovered, information about
vulnerabilities may need to be attached to existing documentation,
that users are not misled as to the true security properties of
registered URL scheme
If the IESG agrees to delegate the registration and change
functions of an alternative tree to a group or individual outside
the IETF, that group or individual should have sufficient
procedures in place to authenticate registration changes
8.0
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
2223, October 1997.
Petke & King Best Current Practice [Page 8]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
9.0 Authors'
Rich
UUNET
5000 Britton
P. O. Box 5000
Hilliard, OH 43026-5000
Phone: +1 614 723 4157
Fax: +1 614 723 8407
EMail: rpetke@wcom.
Ian
Microsoft
One Microsoft
Redmond, WA 98052-6399
Phone: +1 425-703-2293
Fax: +1 425-936-7329
EMail: iking@microsoft.
Petke & King Best Current Practice [Page 9]
RFC 2717 Registration Procedures for URL Scheme Names November 1999
10. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Petke & King Best Current Practice [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
