[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2718) 00 01 02 03 04 05 06 RFC 4395

Network Working Group                                          T. Hansen
Internet-Draft                                         AT&T Laboratories
Obsoletes: 2717,2718 (if approved)                             T. Hardie
Expires: August 24, 2005                                  Qualcomm, Inc.
                                                             L. Masinter
                                                           Adobe Systems
                                                       February 20, 2005

      Guidelines and Registration Procedures for  new URI Schemes

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document provides guidelines and recommendations for the
   definition of Uniform Resource Identifier (URI) schemes.  It also
   updates the process and IANA registry for URI schemes.

Hansen, et al.           Expires August 24, 2005                [Page 1]

Internet-Draft               New URI Schemes               February 2005

   Please send comments to uri@w3.org [12].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Guidelines for URI scheme definitions  . . . . . . . . . . . .  4
     2.1   Demonstratable, new, long-lived utility  . . . . . . . . .  4
     2.2   Syntactic compatibility  . . . . . . . . . . . . . . . . .  4
     2.3   Well-Defined . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4   Definition of operations . . . . . . . . . . . . . . . . .  5
     2.5   Internationalization and character encoding  . . . . . . .  6
     2.6   Clear security considerations  . . . . . . . . . . . . . .  6
     2.7   Scheme Name considerations . . . . . . . . . . . . . . . .  6
   3.  Guidelines for Provisional URI Scheme Registration . . . . . .  7
   4.  Guidelines for Historical URI Scheme Registration  . . . . . .  7
   5.  URI Scheme Registration Procedure  . . . . . . . . . . . . . .  7
     5.1   General  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2   Registration Procedures  . . . . . . . . . . . . . . . . .  8
     5.3   Change Control . . . . . . . . . . . . . . . . . . . . . .  9
     5.4   URI Scheme Registration Template . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2   Informative References . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 13

Hansen, et al.           Expires August 24, 2005                [Page 2]

Internet-Draft               New URI Schemes               February 2005

1.  Introduction

   The Uniform Resource Identifier (URI) protocol element and generic
   syntax is defined by RFC 3986 [5].  Each URI begins with a scheme
   name, as defined by Section 3.1 of RFC 3986, that refers to a
   specification for identifiers within that scheme.  The URI syntax
   provides a federated and extensible naming system,  where each
   scheme's specification may further restrict the syntax and semantics
   of identifiers using that scheme.  This document provides guidelines
   for the definition of new URI schemes, for considerations by those
   who are defining, registering, or evaluating those definitions, as
   well as a process and mechanism for registering URI schemes within
   the IANA URI scheme registry.  This document obsoletes both RFCs 2717
   [2] and 2718 [3].

   RFCs 2717 and 2718 draw a distinction between 'locators' --
   identifiers used for accessing resources available on the Internet,
   and 'names' -- identifiers used for naming possibly abstract
   resources, independent of any mechanism for accessing them.  The
   intent was to use the designation "URL" (Uniform Resource Locator)
   for those identifiers that were locators, and "URN" (Uniform Resource
   Name) for those identifiers that were names.  In practice, the line
   between 'locator' and 'name' has been difficult to draw: locators can
   be used as names, and names can be used as locators.

   As a result, recent documents have used the term "URI" for all
   resource identifiers, avoiding the term "URL", and reserving the term
   "URN" explicitly for those URIs using the "urn" scheme name (RFC 2141
   [1]).  URN "namespaces" (RFC 3406 [9]) are specific to the "urn"
   scheme and not covered explicitly by this document.

   RFC 2717 defined a set of registration trees in which URI schemes
   could be registered, one of which was called the IETF Tree, to be
   managed by IANA.  RFC 2717 proposed that additional registration
   trees might be approved by the IESG.  However, no such registration
   trees have been approved.

   This document eliminates RFC 2717's distinction between different
   'trees' for URI schemes; instead there is a single namespace for
   registered values.  Within that namespace, there are values that are
   approved as meeting a set of criteria for URI schemes.  Other scheme
   names may also be registered provisionally, without necessarily
   meeting those criteria.  The intent of the registry is to:
   o  provide a low barrier for provisional registrations of URI scheme
   o  provide a central point of discovery for established URI scheme
      names, and easy location of their defining documents;

Hansen, et al.           Expires August 24, 2005                [Page 3]

Internet-Draft               New URI Schemes               February 2005

   o  discourage multiple definitions of URI scheme names for different
   o  help those proposing new URI scheme names to discern established
      trends and conventions, and avoid names that might be confused
      with existing ones.

2.  Guidelines for URI scheme definitions

   This section gives some considerations when defining new URI schemes.
   Meeting these guidelines is REQUIRED for permanent URI scheme
   registration, and RECOMMENDED for provisional registration.

2.1  Demonstratable, new, long-lived utility

   Because URI schemes are a single, global namespace, the unbounded
   registration of new schemes is harmful to the Internet community.
   For this reason, new URI schemes should have clear utility to the
   broad Internet community, beyond that available with already
   registered URI schemes.

2.2  Syntactic compatibility

   RFC 3986 [5] defines the generic syntax for all URI schemes, along
   with the syntax of common URI components that are used by many URI
   schemes to define hierarchical identifiers.  All URI scheme
   specifications must define their own syntax such that all strings
   matching their scheme-specific syntax will also match the
   <absolute-URI> grammar described in Section 4.3 of RFC 3986.

   New URI schemes should reuse the common URI components of RFC 3986
   for the definition of hierarchical naming schemes.  However, if there
   is a strong reason for a URI scheme to not use the hierarchical
   syntax, then the new scheme definition should at least follow the
   syntax of previously registered schemes, if possible.

   URI schemes that are not intended for use with relative URIs should
   avoid use of the forward slash "/" character, which is used for
   hierarchical delimiters, and the complete path segments "." and ".."

   Avoid improper use of "//".  The use of double slashes in the first
   part of a URI is not an artistic indicator that what follows is a
   URI: Double slashes are used ONLY when the syntax of the URI's
   <scheme-specific-part> contains a hierarchical structure as described
   in RFC 3986.  In URIs from such schemes, the use of double slashes
   indicates that what follows is the top hierarchical element for a
   naming authority.  (See section 3.2 of RFC 3986 for more details.)
   URI schemes that do not contain a conformant hierarchical structure

Hansen, et al.           Expires August 24, 2005                [Page 4]

Internet-Draft               New URI Schemes               February 2005

   in their <scheme-specific-part> should not use double slashes
   following the "<scheme>:" string.

2.3  Well-Defined

   While URIs may or may not be useful as locators in practice, a URI
   scheme definition itself should be clear as to how it is expected to
   function.  Schemes that are not intended to be used as locators
   should still describe how the resource indicated can be identified by
   software that obtains a URI of that scheme.

   For schemes that function as locators, it is important that the
   mechanism of resource location be clearly defined.  This might mean
   different things depending on the nature of the URI scheme.

   In many cases, new URI schemes are defined as ways to translate
   between other namespaces or protocols and the general framework of
   URIs.  For example, the "ftp" URI scheme translates into the FTP
   protocol, while the "mid" URI scheme translates into a Message-ID
   identifier of an email message.  For such schemes, the description of
   the mapping must be complete, and in sufficient detail so that the
   mapping in both directions is clear: how to map from a URI into an
   identifier or set of protocol actions or name in the target
   namespace, and how legal values in the base namespace, or legal
   protocol interactions, might be represented in a valid URI.  In
   particular, the mapping should describe the mechanisms for encoding
   binary or character strings within valid character sequences in a
   URI.  If not all legal values or protocol interactions of the base
   standard can be represented using the URI scheme, the definition
   should be clear about which subset are allowed, and why.

2.4  Definition of operations

   In addition to the definition of how a URI identifies a resource, a
   URI scheme definition should also define, if applicable, the set of
   operations that may be performed on a resource using the URI as its
   identifier.  A basis for this model was HTTP; a HTTP resource can be
   operated on by GET, POST, PUT and a number of other operations
   available through the HTTP protocol.  The URI scheme definition
   should describe all well-defined operations on the URI identifier,
   and what they are supposed to do.

   Some URI schemes don't fit into the "information access" paradigm of
   URIs.  For example, "telnet" provides location information for
   initiating a bi-directional data stream to a remote host; the only
   operation defined is to initiate the connection.  In any case, the
   operations appropriate for a URI scheme should be documented.

Hansen, et al.           Expires August 24, 2005                [Page 5]

Internet-Draft               New URI Schemes               February 2005

   NOTE: It is perfectly valid to say that "no operation apart from GET
   is defined for this URI".  It is also valid to say that "there's only
   one operation defined for this URI, and it's not very GET-like".  The
   important point is that what is defined on this type is described.

2.5  Internationalization and character encoding

   When describing URI schemes in which (some of) the elements of the
   URI are actually representations of human-readable text, care should
   be taken not to introduce unnecessary variety in the ways in which
   characters are encoded into octets and then into URI characters; see
   section 2.5 of RFC 3986 for guidelines.

   There is no separate registry or registration process for
   Internationalized Resource Identifiers (IRIs) [6].  URI scheme
   definitions SHOULD be compatible with that specification.

2.6  Clear security considerations

   Definitions of URI schemes should be accompanied by a clear analysis
   of the security implications for systems that use the URI scheme.

   In particular, section 7 of RFC 3986 describes general security
   considerations for URI schemes.  The definition of an individual URI
   scheme should note which of these apply to the specified scheme.

2.7  Scheme Name considerations

   Section 3.1 of RFC 3986 defines the syntax of a URI scheme name.  New
   scheme registrations MUST comply.  Note that although scheme names
   are case insensitive, scheme names must be registered using lowercase

   URI scheme names should be short, but also sufficiently descriptive
   and distinguished to avoid problems.

   Avoid trademark names or other symbols that might have problems with
   the 'ownership' or rights to use the name in Internet protocols.

   Avoid using names that are either very general purpose or associated
   in the community with some other application or protocol.  Avoid
   scheme names that are overly general or grandiose in scope (e.g.,
   that allude to their "universal" or "standard" nature when the
   described namespace is not.)

   Organizations that desire a private name space for URI scheme names
   are encouraged to use a prefix based on their domain name, expressed
   in reverse order.  For example, a URI scheme name of com-example-info

Hansen, et al.           Expires August 24, 2005                [Page 6]

Internet-Draft               New URI Schemes               February 2005

   might be registered by the vendor that owns the example.com domain

3.  Guidelines for Provisional URI Scheme Registration

   While the guidelines in Section 2 are RECOMMENDED for provisional
   registration, the requirements are:
      The scheme name meets the syntactic requirements of Section 2.7.
      There is not already a entry with the same URI scheme name.
      (Modification of a registration entry to note multiple uses of the
      same scheme name requires IESG approval.)
      Contact information identifying the person supplying the
      registration is included.  Previously unregistered URI schemes
      discovered in use may be registered by third parties on behalf of
      those who created the URI scheme; in this case, both the
      registering party and the scheme creator should be identified.
      If no permanent, citable specification for the URI scheme
      definition is included, credible reasons for not providing it
      should be given.
      A valid security considerations section, as required by section 6
      of [7].
      If the scheme definition does not meet the guidelines laid out in
      Section 2, the differences and reasons SHOULD be noted.

4.  Guidelines for Historical URI Scheme Registration

   In some circumstances, it is appropriate to note a URI scheme that
   was once in use or registered but for whatever reason is no longer in
   common use or the use is not recommended.  In this case, it is
   possible for an individual to request that the URI scheme be
   registered (newly, or as an update to an existing registration) as
   'historical'.  Any scheme that is no longer in common use may be
   designated as historical; the registration should contain some
   indication to where the scheme was previously defined or documented.

5.  URI Scheme Registration Procedure

5.1  General

   The URI registration process is described in the terminology of [7].
   The registration process is an optional mailing list review, followed
   by "Expert Review".  The registration request should note the desired
   status.  The Designated Expert will evaluate the request against the
   criteria of the requested status.  In the case of a permanent
   registration request, the Designated Expert may:
      Accept the URI scheme name for Permanent registration.
      Suggest provisional registration instead.

Hansen, et al.           Expires August 24, 2005                [Page 7]

Internet-Draft               New URI Schemes               February 2005

      Request IETF review and IESG approval; in the meanwhile, suggest
      provisional registration.

   URI scheme definitions contained within other IETF documents
   (Informational, Experimental or Standards-Track RFCs) must also
   undergo Expert Review; in the case of Standards-Track documents,
   permanent registration status approval is required.

5.2  Registration Procedures

   Someone wishing to register a URI scheme should:
   1.  Check the IANA URI scheme registry to see whether or not there is
       already an entry for the desired name.  If there is already an
       entry under the name, choose a different URI scheme name.
   2.  Prepare a URI scheme registration template, as specified in
       Section 5.4.
   3.  The URI scheme registration template may be contained in an
       Internet Draft (alone, or as part of some other protocol
       specification), but this is not necessary.
   4.  To facilitate review, send a copy of the template or a pointer to
       the containing document (with specific reference to the section
       with the template) to the mailing list uri@w3.org, requesting
   5.  Allow for at least two weeks for discussion and comments.  Make
       revisions as appropriate based on review comments.
   6.  Submit the (possibly updated) registration template (or pointer
       to document containing it) to IANA at iana@iana.org [13],
       specifying whether 'permanent' or 'provisional' registration is

   Upon receipt of a URI scheme registration request, IANA:
   1.  Checks the submission for completeness; if sections are missing
       or citations are not correct, IANA rejects the registration
   2.  Checks the current registry for a entry with the same name; if
       such a registry exists, IANA rejects the registration request.
   3.  Requests Expert Review of the registration request against the
       corresponding guidelines.
   4.  If the Designated Expert recommends registration in either
       'permanent' or 'provisional' registration, add the registration
       to the appropriate registry.
   5.  Unless Expert Review has explicitly rejected the registration
       within two weeks, IANA should automatically add the registration
       in the 'provisional' registry.

   Either based on an explicit request or independently initiated, the
   Designated Expert or IESG may request the upgrade of a 'provisional'
   registration to a 'permanent' one.  In such cases, IANA should remove

Hansen, et al.           Expires August 24, 2005                [Page 8]

Internet-Draft               New URI Schemes               February 2005

   the corresponding entry from the provisional registry.

5.3  Change Control

   Registrations may be updated in each registry by the same mechanism
   as required for an initial registration.  In cases where the original
   definition of the scheme is contained in an IESG-approved document,
   update of the specification also requires IESG approval.

   Provisional registrations may be updated by the original registrant
   or anyone designated by them.  In addition, the IESG may reassign
   responsibility for a provisional registration scheme.

   The most common case of this will be to enable changes to be made to
   schemes where the original registrator is out of contact, or
   unwilling or unable to make changes.

   Transition to or from 'permanent' status requires IESG approval;
   transition from 'provisional' to 'historical' may be requested by
   anyone authorized to update the provisional registration.

5.4  URI Scheme Registration Template

   This template describes the fields that must be supplied in a URI
   scheme registration request:
   URI scheme name.  See Section 2.7 for guidelines.
   Status.  This reflects the status requested, and should be one of
      'permanent', 'provisional' or 'historical'.
   URI scheme syntax.  See Section 2.2 for guidelines.
   URI scheme semantics See Section 2.3 for guidelines.
   Encoding considerations.  See Section 2.5 for guidelines.
   Applications and/or protocols that use this URI scheme name.  Include
      references to documentation that define the applications and/or
      protocols cited.
   Interoperability considerations.  If you are aware of any details
      regarding your scheme that 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 any underlying protocol.
   Security considerations.  See Section 2.6 for guidelines.
   Contact.  Person & email address to contact for further information.
   Author/Change controller.
   Application/protocol.  Applications and/or protocols that use this
      URI scheme name.
   References Include full citations for all referenced documents.
      Registration templates for provisional registration may be
      included in an Internet Draft; when the documents expire or are
      approved for publication as an RFC, the registration will be

Hansen, et al.           Expires August 24, 2005                [Page 9]

Internet-Draft               New URI Schemes               February 2005


6.  IANA Considerations

   This document replaces the current "URL Scheme" registry with a new
   Uniform Resource Identifier scheme registry, establishes a new
   registration template and a new process for registration.  The
   process is based on [7] "Expert Review" with an initial (optional)
   mailing list review.

   The template has an additional field for the status of the URI name
   scheme, and the procedures for entering new name schemes have been
   augmented.  Section Section 5 establishes the process for new URI
   scheme registration.

   To transition to the new registry, all URL name schemes in the
   existing table should be given 'permanent' status.

7.  Security Considerations

   All registered values are expected to contain accurate security
   consideration sections; 'permanent' registered scheme names are
   expected to contain complete definitions.

   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URI 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 URI scheme.

8.  Acknowledgements

   Many thanks to Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel,
   and other members of the uri@w3.org [14] mailing list for their
   comments on earlier drafts.

   Parts of this document are based on [2], [3] and [10].  Some of the
   ideas about use of URIs were taken from the 'Architecture of the
   World Wide Web' [11]; section 2.4.1 gives some reasons for
   registering schemes, and also some guidelines for use of URIs.

9.  References

9.1  Normative References

   [1]  Moats, R., "URN Syntax", RFC 2141, May 1997.

Hansen, et al.           Expires August 24, 2005               [Page 10]

Internet-Draft               New URI Schemes               February 2005

   [2]  Petke, R. and I. King, "Registration Procedures for URL Scheme
        Names", BCP 35, RFC 2717, November 1999.

   [3]  Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
        "Guidelines for new URL Schemes", RFC 2718, November 1999.

   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        RFC 2279, January 1998.

   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifier (URI): Generic Syntax", STD 66, RFC 3986, January

   [6]  Duerst, M. and M. Suignard, "Internationalized Resource
        Identifiers (IRIs)", RFC 3987, January 2005.

   [7]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

9.2  Informative References

   [8]   Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.

   [9]   Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
         "Uniform Resource Names (URN) Namespace Definition Mechanisms",
         BCP 66, RFC 3406, October 2002.

   [10]  Klyne, G., Nottingham, M. and J. Mogul, "Registration
         Procedures for Message Header Fields", BCP 90, RFC 3864,
         September 2004.

   [11]  W3C Technical Architecture  Group, "Architecture of the World
         Wide Web, Volume One", December 2004,


   [12]  <mailto:uri@w3.org>

   [13]  <mailto:iana@iana.org>

   [14]  <mailto:uri@w3.org>

Hansen, et al.           Expires August 24, 2005               [Page 11]

Internet-Draft               New URI Schemes               February 2005

Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748

   Email: tony+urireg@maillennium.att.com

   Ted Hardie
   Qualcomm, Inc.
   675 Campbell Technology Parkway
   Suite 200
   Campbell, CA

   Email: hardie@qualcomm.com

   Larry Masinter
   Adobe Systems
   345 Park Ave
   San Jose, CA  95110

   Phone: +1 408 536 3024
   Email: LMM@acm.org
   URI:   http://larry.masinter.net

Hansen, et al.           Expires August 24, 2005               [Page 12]

Internet-Draft               New URI Schemes               February 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hansen, et al.           Expires August 24, 2005               [Page 13]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/