Movatterモバイル変換

Network Working Group                                          R. PetkeRequest for Comments: 2717                           UUNET TechnologiesBCP: 35                                                         I. KingCategory: Best Current Practice                   Microsoft Corporation                                                          November 1999Registration Procedures for URL Scheme NamesStatus 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 19991.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 inRFC 2119.2.0 URL Scheme Name Registration Trees2.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 19992.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 Registration3.1 General Requirements   All new URL schemes, regardless of registration tree, MUST conform to   the generic syntax for URLs as specified inRFC 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 inRFC 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 inRFC 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 (seesection 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 inRFC 2396.   All new URL schemes SHOULD follow the Guidelines for URL Schemes, set   forth inRFC 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 Procedures4.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 insection 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 whoPetke & 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 insection 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 Control5.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 19996.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 toRFC 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 19997.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",RFC2223, October 1997.Petke & King             Best Current Practice                  [Page 8]

RFC 2717      Registration Procedures for URL Scheme Names November 19999.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.comPetke & King             Best Current Practice                  [Page 9]

RFC 2717      Registration Procedures for URL Scheme Names November 199910.  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]