summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2717.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2717.txt')
-rw-r--r--doc/rfc/rfc2717.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2717.txt b/doc/rfc/rfc2717.txt
new file mode 100644
index 0000000..801b7d2
--- /dev/null
+++ b/doc/rfc/rfc2717.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group R. Petke
+Request for Comments: 2717 UUNET Technologies
+BCP: 35 I. King
+Category: Best Current Practice Microsoft Corporation
+ November 1999
+
+
+ Registration Procedures for URL Scheme Names
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ This document defines the process by which new URL scheme names are
+ registered.
+
+1.0 Introduction
+
+ A Uniform Resource Locator (URL) is a compact string representation
+ 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 "<scheme>:"
+ and then a "<scheme-specific-part>". Many URL schemes are already
+ defined, however, new schemes may need to be defined in the future in
+ order to accommodate new Internet protocols and/or procedures.
+
+ A registration process is needed to ensure that the names of all such
+ new schemes are guaranteed not to collide. Further, the registration
+ process ensures that URL schemes intended for wide spread, public use
+ are developed in an orderly, well-specified, and public manner.
+
+ This document defines the registration procedures to be followed when
+ new URL schemes are created. A separate document, RFC 2718,
+ Guidelines for URL Schemes [2], provides guidelines for the creation
+ of new URL schemes. The primary focus of this document is on the
+ <scheme> 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 Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119.
+
+2.0 URL Scheme Name Registration Trees
+
+2.1 General
+
+ In order to increase the efficiency and flexibility of the URL scheme
+ name registration process, the need is recognized for multiple
+ registration "trees". The registration requirements and specific
+ registration procedures for each tree differ, allowing the overall
+ registration procedure to accommodate the different natural
+ requirements for URL schemes. For example, a scheme that will be
+ recommended for wide support and implementation by the Internet
+ community requires a more complete review than a scheme intended to
+ be used for resources associated with proprietary software.
+
+ The first step in registering a new URL scheme name is to determine
+ which registration tree the scheme should be registered in.
+ Determination of the proper registration tree is based on the
+ intended use for the new scheme and the desired syntax for the scheme
+ name.
+
+ This document will discuss in detail the tree that reflects current
+ practice, under IETF ownership and control. It will also set forth
+ an outline to assist authors in creating new trees to address
+ differing needs for wide acceptance and interoperability, ease of
+ creation and use, and type and "strength" of ownership.
+
+2.2 The IETF Tree
+
+ The IETF tree is intended for URL schemes of general interest to the
+ Internet community. The tree exists for URL schemes that require a
+ substantive review and approval process. It is expected that
+ applicability statements for particular applications will be
+ published from time to time that recommend implementation of, and
+ support for, URL schemes that have proven particularly useful in
+ those contexts.
+
+
+
+
+
+
+
+
+
+
+Petke & King Best Current Practice [Page 2]
+
+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 [Page 3]
+
+RFC 2717 Registration Procedures for URL Scheme Names November 1999
+
+
+ The "owner" of a URL scheme name registered in the IETF tree is
+ assumed to be the IETF itself. Modification or alteration of the
+ specification requires the same level of processing (e.g.
+ Informational or Standards Track RFC) as used for the initial
+ registration. Schemes originally defined via an Informational RFC
+ may, however, be replaced with Standards Track documents.
+
+3.3 Alternative Trees
+
+ While public exposure and review of a URL scheme created in an
+ alternative tree is not required, using the IETF Internet-Draft
+ mechanism for peer review is strongly encouraged to improve the
+ quality of the specification. RFC publication of alternative tree
+ URL schemes is encouraged but not required. Material may be
+ published as an Informational RFC by sending it to the RFC Editor
+ (please follow the instructions to RFC authors, RFC 2223 [3]).
+
+ The defining document for an alternative tree may require public
+ exposure and/or review for schemes defined in that tree via a
+ mechanism other than the IETF Internet-Draft mechanism.
+
+ URL schemes created in an alternative tree must conform to the
+ generic URL syntax, RFC 2396. The tree's defining document may set
+ forth additional syntax and semantics requirements above and beyond
+ those specified in RFC 2396.
+
+ All new URL schemes SHOULD follow the Guidelines for URL Schemes, set
+ forth in RFC 2718 [2].
+
+ An analysis of the security issues inherent in the new URL scheme is
+ encouraged. Regardless of what security analysis is or is not
+ performed, all descriptions of security issues must be as accurate as
+ possible. In particular, a statement that there are "no security
+ issues associated with this scheme" must not be confused with "the
+ security issues associates with this scheme have not been assessed"
+ or "the security issues associated with this scheme cannot be
+ predicted because of <reason>".
+
+ There is absolutely no requirement that URL schemes created in an
+ alternative tree be secure or completely free from risks.
+ Nevertheless, the tree's defining document must set forth the
+ standard for security considerations, and in any event all known
+ security risks SHOULD be identified.
+
+ Change control must be defined for a new tree. Change control may be
+ vested in the IETF, or in an individual, group or other entity. The
+ 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 will
+ be identified by a unique prefix, which must be established in the
+ same fashion as a URL scheme name in the IETF tree, except that the
+ prefix must be defined by a Standards Track document. Scheme names
+ in the new tree are then constructed by prepending the prefix to an
+ identifier unique to each scheme in that tree, as prescribed by that
+ tree's identifying document:
+
+ <prefix>'-'<tree-specific identifier>
+
+ For instance, the "foo" tree would allow creation of scheme names of
+ the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
+ an arbitrary USASCII string following the tree's unique prefix.
+
+4.0 Registration Procedures
+
+4.1 The IETF Tree
+
+ The first step in registering a new URL scheme in the IETF tree is to
+ publish an IETF Internet-Draft detailing the syntax and semantics of
+ the proposed scheme. The draft must, minimally, address all of the
+ 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 the
+ scheme to a working group (existing or new) or directly present the
+ scheme to the IESG for a last call. In the former case, the working
+ group is responsible for submitting a final version of the draft to
+ the IESG for approval at such time as it has received adequate review
+ and deliberation.
+
+4.2 Alternative Trees
+
+ Registration of URL schemes created in an alternative tree may be
+ formal, through IETF documents, IANA registration, or other
+ acknowledged organization; informal, through a mailing list or other
+ publication mechanism; or nonexistent. The registration mechanism
+ must be documented for each alternative tree, and must be consistent
+ for all URL scheme names created in that tree.
+
+ It is the responsibility of the creator of the tree's registration
+ requirements to establish that the registration mechanism is workable
+ as described; it is within the discretion of the IESG to reject the
+ document describing a tree if it determines the registration
+ mechanism is impractical or creates an undue burden on a party who
+
+
+
+
+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 mechanism
+ is proposed, IESG might reject the tree if its mechanism would create
+ undue liability on the part of IANA.)
+
+ While the template in section 6 of this document is intended to apply
+ to URL scheme names in the IETF tree, it is also offered as a
+ guideline for those documenting alternative trees.
+
+5.0 Change Control
+
+5.1 Schemes in the IETF Tree
+
+ URL schemes created in the IETF tree are "owned" by the IETF itself
+ and may be changed, as needed, by updating the RFC that describes
+ them. Schemes described by Standards Track RFC but be replaced with
+ new Standards Track RFCs. Informational RFCs may be replaced by new
+ Informational RFCs or Standards Track RFCs.
+
+5.2 Schemes in Alternative Trees
+
+ URL schemes in an alternative tree that are undocumented (as allowed
+ by that tree's rules) may be changed by their owner at any time
+ without notifying the IETF.
+
+ URL schemes created in an alternative tree that have been documented
+ 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 and
+ documented by an Informational RFC may pass responsibility for the
+ registration to another person or agency by informing the IESG.
+
+ The IESG may reassign responsibility for a URL scheme registered in
+ an alternative tree and documented by an Informational RFC. The most
+ common case of this will be to enable changes to be made to schemes
+ 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 is
+ otherwise unable to make changes that are important to the community.
+
+ The IESG may reclassify a URL scheme created in an alternative tree
+ and documented via an Informational RFC as "historic" if it
+ 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 Template
+
+ The following issues should be addressed when documenting a new URL
+ scheme:
+
+ URL scheme name.
+
+ URL scheme syntax. This should be expressed in a clear and
+ concise manner. The use of ABNF is encouraged. Please refer to
+ RFC 2718 for guidance on designing and explaining your scheme's
+ syntax.
+
+ Character encoding considerations. It is important to identify
+ what your scheme supports in this regard. It is obvious that for
+ interoperability, it is best if there is a means to support
+ character sets beyond USASCII, but especially for private schemes,
+ this may not be the case.
+
+ Intended usage. What sort of resource is being identified? If
+ this is not a 'resource' type of URL (e.g. mailto:), explain the
+ action that should be initiated by the consumer of the URL. If
+ there is a MIME type associated with this resource, please
+ identify it.
+
+ Applications and/or protocols which use this URL scheme name.
+ Including references to documentation which defines the
+ applications and/or protocols cited is especially useful.
+
+ Interoperability considerations. If you are aware of any details
+ regarding your scheme which might impact interoperability, please
+ identify them here. For example: proprietary or uncommon encoding
+ method; inability to support multibyte character sets;
+ incompatibility with types or versions of underlying protocol (if
+ 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 Considerations
+
+ Information that creates or updates a registration needs to be
+ authenticated.
+
+ Information concerning possible security vulnerabilities of a
+ protocol may change over time. Consequently, claims as to the
+ security properties of a registered URL scheme may change as well.
+ As new vulnerabilities are discovered, information about such
+ vulnerabilities may need to be attached to existing documentation, so
+ that users are not misled as to the true security properties of a
+ registered URL scheme.
+
+ If the IESG agrees to delegate the registration and change control
+ functions of an alternative tree to a group or individual outside of
+ the IETF, that group or individual should have sufficient security
+ procedures in place to authenticate registration changes.
+
+8.0 References
+
+ [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+ 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", RFC
+ 2223, October 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petke & King Best Current Practice [Page 8]
+
+RFC 2717 Registration Procedures for URL Scheme Names November 1999
+
+
+9.0 Authors' Addresses
+
+ Rich Petke
+ UUNET Technologies
+ 5000 Britton Road
+ P. O. Box 5000
+ Hilliard, OH 43026-5000
+ USA
+
+ Phone: +1 614 723 4157
+ Fax: +1 614 723 8407
+ EMail: rpetke@wcom.net
+
+
+ Ian King
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ USA
+ Phone: +1 425-703-2293
+ Fax: +1 425-936-7329
+ EMail: iking@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petke & King Best Current Practice [Page 9]
+
+RFC 2717 Registration Procedures for URL Scheme Names November 1999
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petke & King Best Current Practice [Page 10]
+