doc: Add RFC documents

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]
+