Skip to main content

Guidelines and Registration Procedures for New URI Schemes
draft-ietf-appsawg-uri-scheme-reg-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7595.
Authors Dave Thaler , Tony Hansen , Ted Hardie , Larry M Masinter
Last updated 2014-03-31
Replaces draft-thaler-appsawg-uri-scheme-reg
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Awaiting External Review/Resolution of Issues Raised
Document shepherd Alexey Melnikov
IESG IESG state Became RFC 7595 (Best Current Practice)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-appsawg-uri-scheme-reg-00
Network Working Group                                     D. Thaler, Ed.
Internet-Draft                                                 Microsoft
Obsoletes: 4395 (if approved)                                  T. Hansen
Intended status: Best Current Practice                 AT&T Laboratories
Expires: October 2, 2014                                       T. Hardie
                                                                  Google
                                                             L. Masinter
                                                                   Adobe
                                                          March 31, 2014

       Guidelines and Registration Procedures for New URI Schemes
                  draft-ietf-appsawg-uri-scheme-reg-00

Abstract

   This document updates the guidelines and recommendations, as well as
   the IANA registration processes, for the definition of Uniform
   Resource Identifier (URI) schemes.  It obsoletes RFC 4395.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 2, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Thaler, et al.           Expires October 2, 2014                [Page 1]
Internet-Draft               New URI Schemes                  March 2014

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements for Permanent Scheme Definitions . . . . . . . .   4
     3.1.  Demonstrable, New, Long-Lived Utility . . . . . . . . . .   4
     3.2.  Syntactic Compatibility . . . . . . . . . . . . . . . . .   4
     3.3.  Well-Defined  . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Definition of Operations  . . . . . . . . . . . . . . . .   6
     3.5.  Context of Use  . . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Internationalization and Character Encoding . . . . . . .   7
     3.7.  Clear Security Considerations . . . . . . . . . . . . . .   7
     3.8.  Scheme Name Considerations  . . . . . . . . . . . . . . .   7
   4.  Guidelines for Provisional URI Scheme Registration  . . . . .   8
   5.  Guidelines for Historical URI Scheme Registration . . . . . .   9
   6.  Guidelines for Private URI Scheme Use . . . . . . . . . . . .   9
   7.  URI Scheme Registration Procedure . . . . . . . . . . . . . .   9
     7.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.2.  Registration Procedures . . . . . . . . . . . . . . . . .  10
     7.3.  Change Control  . . . . . . . . . . . . . . . . . . . . .  12
     7.4.  URI Scheme Registration Template  . . . . . . . . . . . .  12
   8.  The "example" Scheme  . . . . . . . . . . . . . . . . . . . .  14
     8.1.  "Example" Scheme Registration Request . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     12.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Changes Since RFC 4395 . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The Uniform Resource Identifier (URI) protocol element and generic
   syntax is defined by [RFC3986].  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 can further restrict the syntax and define the
   semantics of identifiers using that scheme.

   This document obsoletes [RFC4395], which in turn obsoleted [RFC2717]
   and [RFC2718].  Recent documents have used the term "URI" for all

Thaler, et al.           Expires October 2, 2014                [Page 2]
Internet-Draft               New URI Schemes                  March 2014

   resource identifiers, avoiding the term "URL" and reserving the term
   "URN" explicitly for those URIs using the "urn" scheme name
   ([RFC2141]).  URN "namespaces" ([RFC3406]) are specific to the "urn"
   scheme and are not covered explicitly by this specification.

   This document provides updated guidelines for the definition of new
   schemes, for consideration by those who are defining, registering, or
   evaluating those definitions, as well as a process and mechanism for
   registering schemes within the IANA URI Schemes registry.  There is a
   single namespace for registered schemes.  The intent of the registry
   is to:

   o  provide a central point of discovery for established URI scheme
      names, and easy location of their defining documents;

   o  discourage use of the same scheme name for different mechanisms
      (often, but not always, protocols);

   o  help those proposing new scheme names to discern established
      trends and conventions, and avoid names that might be confused
      with existing ones;

   o  encourage registration by setting a low barrier for registration.

   As originally defined, URIs only allowed a limited repertoire of
   characters chosen from US-ASCII.  An Interationalized Resource
   Identifier (IRI), as defined by [RFC3987], extends the URI syntax to
   allow characters from a much greater repertoire, to accomodate
   resource identifiers from the world's languages.  RFC 3987 [RFC3987]
   also defined a mapping between URIs and IRIs.  A URI scheme name is
   the same as the corresponding IRI scheme name.  Thus, there is no
   separate, independent registry or registration process for IRI
   schemes: the URI Schemes registry is used for both URIs and IRIs.
   Those who wish to describe resource identifiers that are useful as
   IRIs should define the corresponding URI syntax, and note that the
   IRI usage follows the rules and transformations defined in [RFC3987].

   [RFC3986] defines the overall syntax for URIs as:

             URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   A scheme definition cannot override the overall syntax for URIs.  For
   example, this means that fragment identifiers (#) cannot be re-used
   outside the generic syntax restrictions.  A scheme definition must
   specify the scheme name and the syntax of the scheme-specific part,
   which is clarified as follows:

Thaler, et al.           Expires October 2, 2014                [Page 3]
Internet-Draft               New URI Schemes                  March 2014

               URI = scheme ":" scheme-specific-part [ "#" fragment ]

               scheme-specific-part = hier-part [ "?" query ]

2.  Terminology

   Within this document, the key words MUST, MAY, SHOULD, REQUIRED,
   RECOMMENDED, and so forth are used within the general meanings
   established in [RFC2119], within the context that they are
   requirements on future registrations.

   This document distinguishes between a "scheme specification", being a
   document defining the syntax and semantics of a scheme, vs. a "scheme
   registration request" being the request submitted to IANA.  The term
   "scheme definition" refers generically to the syntax and semantics of
   a scheme, typically documented in a scheme specification.

3.  Requirements for Permanent Scheme Definitions

   This section gives considerations for new schemes.  Meeting these
   guidelines is REQUIRED for permanent scheme registration.  Permanent
   status is appropriate for, but not limited to, use in standards.  For
   IETF Standards-Track documents, Permanent registration status is
   REQUIRED.

3.1.  Demonstrable, New, Long-Lived Utility

   In general, the use and deployment of new schemes in the Internet
   infrastructure can be costly; some parts of URI processing are often
   scheme-dependent.  Introducing a new scheme might require additional
   software, not only for client software and user agents but also in
   additional parts of the network infrastructure (gateways, proxies,
   caches) [W3CWebArch].  Since scheme names share a single, global
   namespace, it is desirable to avoid contention over use of short,
   mnemonic scheme names.  New schemes ought to have utility to the
   Internet community beyond that available with already registered
   schemes.  The scheme specification SHOULD discuss the utility of the
   scheme being registered.

3.2.  Syntactic Compatibility

   [RFC3986] 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.  [RFC3987] extended this generic
   syntax to cover IRIs.  All scheme specifications MUST define their
   own URI <scheme-specific-part> syntax.  Care must be taken to ensure

Thaler, et al.           Expires October 2, 2014                [Page 4]
Internet-Draft               New URI Schemes                  March 2014

   that all strings matching their scheme-specific syntax will also
   match the <absolute-URI> grammar described in [RFC3986].

   New schemes SHOULD reuse the common URI components of [RFC3986] for
   the definition of hierarchical naming schemes.  If there is a strong
   reason for a scheme not to use the hierarchical syntax, then the new
   scheme definition SHOULD follow the syntax of previously registered
   schemes.

   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 ".."
   (dot-segments).  [[CREF1: Ticket #26: odd that we SHOULD prohibit the
   string ".." in a URI scheme where it can't be mistaken for a relative
   reference because there are no "/".  I.e., avoiding one of them, not
   both, is sufficient to prevent being mistaken for a relative
   reference, so why are we overly restrictive here.  --MN]]

   Schemes SHOULD avoid improper use of "//".  The use of double slashes
   in the first part of a URI is not an indicator that what follows is a
   URI: Double slashes are intended for use ONLY when the syntax of the
   <scheme-specific-part> contains a hierarchical structure.  In URIs
   from such schemes, the use of double slashes indicates that what
   follows is the top hierarchical element for a naming authority.
   (Section 3.2 of RFC 3986 has more details.)  Schemes that do not
   contain a conformant hierarchical structure in their <scheme-
   specific-part> SHOULD NOT use double slashes following the
   "<scheme>:" string.

   New schemes SHOULD clearly define the role of [RFC3986] reserved
   characters in URIs of the scheme being defined.  The syntax of the
   new scheme should be clear about which of the "reserved" set of
   characters are used as delimiters within the URIs of the new scheme,
   and when those characters must be escaped, versus when they can be
   used without escaping.

3.3.  Well-Defined

   While URIs might or might not be defined as locators in practice, a
   scheme definition itself MUST be clear as to how it is expected to
   function.  Schemes that are not intended to be used as locators
   SHOULD describe how the resource identified can be determined or
   accessed 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 scheme.

Thaler, et al.           Expires October 2, 2014                [Page 5]
Internet-Draft               New URI Schemes                  March 2014

   In many cases, new schemes are defined as ways to translate between
   other namespaces or protocols and the general framework of URIs.  For
   example, the "ftp" scheme translates into the FTP protocol, while the
   "mid" 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.  See Section 3.6 for guidelines 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 scheme, the definition
   SHOULD be clear about which subset are allowed, and why.

3.4.  Definition of Operations

   As part of the definition of how a URI identifies a resource, a
   scheme definition SHOULD define the applicable set of operations that
   can be performed on a resource using the URI as its identifier.  A
   model for this is HTTP methods; an HTTP resource can be operated on
   by GET, POST, PUT, and a number of other methods available through
   the HTTP protocol.  The scheme definition SHOULD describe all well-
   defined operations on the resource identifier, and what they are
   supposed to do.

   Some 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 scheme SHOULD be documented.

   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 scheme is described.

   Scheme definitions SHOULD define a "default" operation for when a URI
   is invoked (or "dereferenced") by an application.

3.5.  Context of Use

   In general, URIs are used within a broad range of protocols and
   applications.  Most commonly, URIs are used as references to
   resources within directories or hypertext documents, as hyperlinks to
   other resources.  In some cases, a scheme is intended for use within
   a different, specific set of protocols or applications.  If so, the
   scheme definition SHOULD describe the intended use and include

Thaler, et al.           Expires October 2, 2014                [Page 6]
Internet-Draft               New URI Schemes                  March 2014

   references to documentation that define the applications and/or
   protocols cited.

3.6.  Internationalization and Character Encoding

   When describing 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
   [RFC3987] and Section 2.5 of [RFC3986] for guidelines.  If URIs of a
   scheme contain any text fields, the scheme definition MUST describe
   the ways in which characters are encoded and any compatibility issues
   with IRIs of the scheme.

   The scheme specification SHOULD be as restrictive as possible
   regarding what characters are allowed in the URI, because some
   characters can create several different security considerations (see,
   for example [RFC4690]).

   All percent-encoded variants are automatically included by definition
   for any character given in an IRI production.  This means that if you
   want to restrict the URI percent-encoded forms in some way, you must
   restrict the Unicode forms that would lead to them.

3.7.  Clear Security Considerations

   Definitions of schemes MUST be accompanied by a clear analysis of the
   security implications for systems that use the scheme; this follows
   the practice of Security Consideration sections within IANA
   registrations [RFC5226].

   In particular, Section 7 of RFC 3986 [RFC3986] describes general
   security considerations for URIs, while [RFC3987] gives those for
   IRIs.  The definition of an individual scheme should note which of
   these apply to the specified scheme.

3.8.  Scheme Name Considerations

   Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this
   syntax remains the same for IRIs.  New registered schemes
   registrations MUST follow this syntax, which only allows a limited
   repertoire of characters (taken from US-ASCII).  Although the syntax
   for the scheme name in URIs is case insensitive, the scheme names
   itself MUST be registered using lowercase letters.

   Scheme names SHOULD be short, but also sufficiently descriptive and
   distinguished to avoid problems.

Thaler, et al.           Expires October 2, 2014                [Page 7]
Internet-Draft               New URI Schemes                  March 2014

   Schemes SHOULD NOT use names or other symbols that might cause
   problems with rights to use the name in IETF specifications and
   Internet protocols.  For example, be careful with trademark and
   service mark names.  (See Section 7.4 of [RFC3978].)

   Schemes SHOULD NOT use names that are either very general purpose or
   associated in the community with some other application or protocol.
   Schemes also SHOULD NOT use names that are overly general or
   grandiose in scope (e.g., that allude to their "universal" or
   "standard" nature.)

   Organizations that desire their own namespace for URI scheme names
   for private use (see Section 6) MUST use a prefix based on their
   domain name, expressed in reverse order.  For example, a URI scheme
   name of com.example.info might be used by the organization that owns
   the example.com domain name.  This is important to prevent
   collisions, and to make it possible to find the owner of a private
   use scheme.

   Furthermore, to prevent collisions with private use scheme names, new
   scheme names MUST NOT contain a "." unless actually constructed from
   a reversed domain name.  [[CREF2: Ticket #17: Are strings that look
   like reversed FQDNs (other than grandfathered ones like "iris.beep")
   reserved for use as such?  Proposed answer is Yes, and text above has
   been updated to reflect that proposal.  --DT]]

4.  Guidelines for Provisional URI Scheme Registration

   Provisional registration can be used for schemes that are not part of
   any standard, but that are intended for use (or observed to be in
   use) that is not limited to a private environment within a single
   organization.  Provisional registration can also be used as an
   intermediate step on the way to permanent registration, e.g., before
   the scheme specification is finalized as a standard.

   For a provisional registration, the following are REQUIRED:

   o  The scheme name meets the syntactic requirements of Section 3.8
      and the encoding requirements of Section 3.6.

   o  There MUST NOT already be an entry with the same scheme name.  (In
      the unfortunate case that there are multiple, different uses of
      the same scheme name, the IESG can approve a request to modify an
      existing entry to note the separate use.)  [[CREF3: Ticket #18:
      Must the IESG do this?  Why not the Expert Reviewer?  --??]]

   o  Contact information identifying the person supplying the
      registration is included.  Previously unregistered schemes

Thaler, et al.           Expires October 2, 2014                [Page 8]
Internet-Draft               New URI Schemes                  March 2014

      discovered in use can be registered by third parties (even if not
      on behalf of those who created the scheme).  In this case, both
      the registering party and the scheme creator SHOULD be identified.

   o  If no permanent, citable specification for the scheme definition
      is included, credible reasons for not providing it SHOULD be
      given.

   o  The scheme definition SHOULD include a clear Security
      Considerations (Section 3.7) or explain why a full security
      analysis is not available (e.g., in a third-party scheme
      registration).

   o  If the scheme definition does not meet the guidelines laid out in
      Section 3, the differences and reasons SHOULD be noted.

5.  Guidelines for Historical URI Scheme Registration

   In some circumstances, it is appropriate to note a 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.

6.  Guidelines for Private URI Scheme Use

   Unregistered schemes can cause problems if use is not limited to a
   private environment within a single organization, since the use could
   leak out beyond the closed environment.  Even within a closed
   environment, other colliding uses of the same scheme name could
   occur.  As such, a unique namespace (see Section 3.8) MUST be used,
   and it is strongly encouraged to do a Provisional registration even
   in such cases.

7.  URI Scheme Registration Procedure

7.1.  General

   The IANA policy (using terms defined in [RFC5226]) for Provisional
   registration was formerly Expert Review and is now changed to simply
   use a First Come First Served policy.  The policy for Permanent and
   Historic registration continues to be Expert Review.  [[CREF4:
   Updated text in this section per proposal to use FCFS as discussed at
   IETF 89 (ticket #19).  --DT]]

Thaler, et al.           Expires October 2, 2014                [Page 9]
Internet-Draft               New URI Schemes                  March 2014

   The registration procedure is intended to be very lightweight for
   non-contentious registrations.  For the most part, we expect the good
   sense of submitters and reviewers, guided by these procedures, to
   achieve an acceptable and useful consensus for the community.

   In exceptional cases, where the negotiating parties cannot form a
   consensus, the final arbiter of any contested registration shall be
   the IESG.

   If parties achieve consensus on a registration proposal that does not
   fully conform to the strict wording of this procedure, this should be
   drawn to the attention of a relevant member of the IESG.

7.2.  Registration Procedures

   Someone wishing to register a new scheme MUST:

   1.  Check the IANA URI Schemes registry to see whether there is
       already an entry for the desired name.  If there is already an
       entry under the name, choose a different scheme name, or update
       the existing scheme specification.

   2.  Prepare a scheme registration request using the template
       specified in Section 7.4.  The scheme registration request can be
       contained in an Internet Draft, submitted alone, or as part of
       some other permanently available, stable, protocol specification.
       The completed template can also be submitted in some other form
       (as part of another document or as a stand-alone document), but
       the completed template will be treated as an "IETF Contribution"
       under the guidelines of [RFC3978].  [[CREF5: Updated above text
       to clarify that the registration request (not the scheme's spec
       per se) is an IETF contribution, per ticket #21.  --DT]]

   3.  If the registration request is for a Permanent registration:

       1.  Review the requirements in Section 3.

       2.  Send a copy of the completed template or a pointer to the
           containing document (with specific reference to the section
           with the completed template) to the mailing list uri-
           review@ietf.org , requesting review.  In addition, request
           review on other relevant mailing lists as appropriate.  For
           example, general discussion of URI syntactical issues could
           be discussed on uri@w3.org; schemes for a network protocol
           could be discussed on a mailing list for that protocol.
           Allow a reasonable time for discussion and comments.  Four
           weeks is reasonable for a permanent registration request.

Thaler, et al.           Expires October 2, 2014               [Page 10]
Internet-Draft               New URI Schemes                  March 2014

       3.  Respond to review comments and make revisions to the proposed
           registration as needed to bring it into line with the
           guidelines given in this document.

   4.  Submit the (possibly updated) registration template (or pointer
       to document containing it) to IANA at iana@iana.org.

   Upon receipt of a scheme registration request, the following steps
   MUST be followed:

   1.  IANA checks the submission for completeness; if sections of the
       template are missing or citations are not correct, IANA will
       reject the registration request.

   2.  IANA checks the current registry for a entry with the same name;
       if such an entry exists, IANA will reject the registration
       request.  [[CREF6: Ticket #25: This contradicts section 4 which
       states, "In the unfortunate case that there are multiple,
       different uses of the same scheme name, the IESG can approve a
       request to modify an existing entry to note the separate use."
       Should IANA refer the request to the IESG rather than rejecting?
       Or should the applicant submit the template to the IESG rather
       than IANA?  --DT]]

   3.  If the request is for Provisional registration, IANA adds the
       registration to the registry, under the First Come First Served
       policy.

   4.  For requests for Permanent or Historic status, the remainder of
       this section applies.

   5.  IANA enters the registration request in the IANA registry, with
       status marked as "Pending Review".

   6.  IANA requests Expert Review of the registration request against
       the corresponding guidelines from this document.

   7.  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 specification of the scheme for permanent
          registration.

       *  Suggest provisional registration instead.

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

Thaler, et al.           Expires October 2, 2014               [Page 11]
Internet-Draft               New URI Schemes                  March 2014

       *  Request additional review or discussion, as necessary.

   8.  Once Expert Review approves registration for a given status, IANA
       adds the registration to the registry.

   Either based on an explicit request or independently initiated, the
   Designated Expert or IESG can request the upgrade of a 'provisional'
   registration to a 'permanent' one.  In such cases, IANA will update
   the status of the corresponding entry.  [[CREF7: Ticket #22: Say more
   about guidance to the Designated Expert.  Under what circumstance
   would the expert request this?  Why would the expert be able to
   request this differently than anyone else (following the normal
   process for a permanent registration, per the next section below)?
   --DT]]

7.3.  Change Control

   Registrations can be updated in the 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 can be updated by the original registrant
   or anyone designated by the original registrant.  In addition, the
   IESG can reassign responsibility for a provisional registration
   scheme, or can request specific changes to a scheme registration.
   This will enable changes to be made to schemes where the original
   registrant is out of contact, or unwilling or unable to make changes.

   Transition from 'provisional' to 'permanent' status can be requested
   and approved in the same manner as a new 'permanent' registration.
   Transition from 'permanent' to 'historical' status requires IESG
   approval.  Transition from 'provisional' to 'historical' can be
   requested by anyone authorized to update the provisional
   registration.

7.4.  URI Scheme Registration Template

   This template describes the fields that MUST be supplied in a scheme
   registration request:

   Scheme name:
     See Section 3.8 for guidelines.

   Status:
     This reflects the status requested, and must be one of 'permanent',
     'provisional', or 'historical'.

Thaler, et al.           Expires October 2, 2014               [Page 12]
Internet-Draft               New URI Schemes                  March 2014

   Applications/protocols that use this scheme name:
     See Section 3.5.

   Contact:
     Person (including contact information) to contact for further
     information.

   Author/Change controller:
     Person (including contact information) authorized to change this.

   References:
     Include full citations for all referenced documents.  Registration
     templates for provisional registration can be included in an
     Internet Draft; when the documents expire or are approved for
     publication as an RFC, the registration will be updated.  A scheme
     specification is only required for Permanent registration.

   The following fields are no longer required in a scheme registration
   request.  The answers instead belong in the scheme specification.

   Scheme syntax:
     See Section 3.2 for guidelines.

   Scheme semantics:
     See Section 3.3 and Section 3.4 for guidelines.

   Encoding considerations:
     See Section 3.3 and Section 3.6 for guidelines.

   Interoperability considerations:
     If the person or group registering the scheme is aware of any
     details regarding the scheme that might impact interoperability,
     identify them here.  For example: proprietary or uncommon encoding
     methods; inability to support multibyte character sets;
     incompatibility with types or versions of any underlying protocol.

   Security considerations:
     See Section 3.7 for guidelines.

   [[CREF8: Moved the following fields out of the template and into the
   requirements for a scheme specification, per ticket #23 and ticket
   #24: Scheme syntax, Scheme semantics, Encoding considerations,
   Interoperability considerations, and Security considerations.  --DT]]

Thaler, et al.           Expires October 2, 2014               [Page 13]
Internet-Draft               New URI Schemes                  March 2014

8.  The "example" Scheme

   There is a need for a scheme name that can be used for examples in
   documentation without fear of conflicts with current or future actual
   schemes.  The scheme "example" is hereby registered as a Permanent
   scheme for that purpose.

   The "example" scheme is specified as follows:

   Scheme syntax:  The entire range of allowable syntax specified in
     [RFC3986] is allowed for "example" URIs.

   Scheme semantics:  URIs in the "example" scheme are to be used for
     documentation purposes only.  The use of "example" URIs must not be
     used as locators, identify any resources, or specify any particular
     set of operations.

   Encoding considerations:  See Section 2.5 of [RFC3986] for
     guidelines.

   Interoperability considerations:  None.

   Security considerations:  None.

8.1.  "Example" Scheme Registration Request

   Scheme name:  example

   Status:  permanent

   Applications/protocols that use this scheme name:  An "example" URI
     is to be used for documentation purposes only.  It MUST NOT be used
     for any protocol.

   Contact:  N/A

   Author/Change controller:  IETF

   References:  Section 8 of this RFC XXXX.
     RFC Editor Note: Replace XXXX with this RFC's reference.

9.  IANA Considerations

   Previously, the former "URL Scheme" registry was replaced by the
   "Uniform Resource Identifier (URI) Schemes" registry.  The process
   was based on [RFC5226] "Expert Review" with an initial (optional)
   mailing list review.

Thaler, et al.           Expires October 2, 2014               [Page 14]
Internet-Draft               New URI Schemes                  March 2014

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

   IANA is requested to do the following:

   o  Update the URI Schemes registry to point to this document.

   o  Combine the "Permanent URI Schemes", "Provisional URI Schemes",
      and "Historical URI Schemes" sub-registries into a single common
      registry with an additional "Status" column containing the status
      (Permanent, Provisional, Historical, or Pending Review), and an
      additional "Notes" column which is normally empty, but may contain
      notes approved by the Designated Expert.

   o  Add the "example" URI scheme to the registry (see the template in
      Section 8.1 for registration).

10.  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 might change over time.  Consequently, claims as to the
   security properties of a registered scheme might change as well.  As
   new vulnerabilities are discovered, information about such
   vulnerabilities might need to be attached to existing documentation,
   so that users are not misled as to the true security properties of a
   registered scheme.

11.  Acknowledgements

   Thanks to Mark Nottingham and Graham Klyne and other members of the
   apps-discuss@ietf.org mailing list for their comments on this
   document.

   Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy
   Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and
   other members of the uri@w3.org mailing list for their comments on
   earlier versions.

   Parts of this document are based on [RFC2717], [RFC2718] and
   [RFC3864].  Some of the ideas about use of URIs were taken from the
   "Architecture of the World Wide Web" [W3CWebArch].

Thaler, et al.           Expires October 2, 2014               [Page 15]
Internet-Draft               New URI Schemes                  March 2014

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", RFC 3978,
              March 2005.

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

12.2.  Informative References

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

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

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

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

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

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35, RFC
              4395, February 2006.

   [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", RFC 4690, September 2006.

Thaler, et al.           Expires October 2, 2014               [Page 16]
Internet-Draft               New URI Schemes                  March 2014

   [W3CWebArch]
              W3C Technical Architecture Group, "Architecture of the
              World Wide Web, Volume One", December 2004,
              <http://www.w3.org/TR/webarch/>.

Appendix A.  Changes Since RFC 4395

   1.   Combined the Historical, Permanent, and Provisional URI Schemes
        registries into one registry with a status column.  This is done
        to make it easier to prevent duplicates and see existing
        conventions.

   2.   Simplified the process for Provisional registration
        significantly: changed from Expert Review to First Come First
        Served, and clarified that mailing list review is not required.

   3.   Added a Notes column for notes approved by the Designated
        Expert.

   4.   Clarified that a "URI scheme name" and an "IRI scheme name" are
        the same thing and thus use the same IANA registry.

   5.   Clarified that a registration request falls under the "IETF
        Contribution" rules, but the scheme's specification need not.

   6.   Added the "example:" URI scheme.

   7.   Added text about when to use Provisional registration.

   8.   Updated convention for Private use schemes to use "." instead of
        "-" between domain name labels, to reduce chance of collision,
        and noted that new schemes must only use "." with the reversed
        domain name convention.

   9.   Recommended that scheme definitions define a "default" operation
        for when a URI is invoked.

   10.  Moved the following fields out of the scheme registration
        request template and into the requirements for a scheme
        specification: Scheme syntax, Scheme semantics, Encoding
        considerations, Interoperability considerations, and Security
        considerations.

Authors' Addresses

Thaler, et al.           Expires October 2, 2014               [Page 17]
Internet-Draft               New URI Schemes                  March 2014

   Dave Thaler (editor)
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   US

   Phone: +1 425 703 8835
   Email: dthaler@microsoft.com

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

   Email: tony+urireg@maillennium.att.com

   Ted Hardie
   Google

   Phone: +1 408 628 5864
   Email: ted.ietf@gmail.com

   Larry Masinter
   Adobe
   345 Park Ave.
   San Jose, CA  95110
   US

   Phone: +1 408 536 3024
   Email: masinter@adobe.com
   URI:   http://larry.masinter.net

Thaler, et al.           Expires October 2, 2014               [Page 18]