<pre>Internet Engineering Task Force (IETF)                    D. Thaler, Ed.
Request for Comments: 7595                                     Microsoft
Obsoletes: <a href="./rfc4395">4395</a>                                                T. Hansen
BCP: 35                                                AT&amp;T Laboratories
Category: Best Current Practice                                T. Hardie
ISSN: 2070-1721                                                   Google
                                                               June 2015


         <span class="h1">Guidelines and Registration Procedures for URI Schemes</span>

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 <a href="./rfc4395">RFC 4395</a>.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7595">http://www.rfc-editor.org/info/rfc7595</a>.

Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
   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.






<span class="grey">Thaler, et al.            Best Current Practice                 [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
     <a href="#section-1.1">1.1</a>.  URIs and IRIs . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-3">3</a>.  Requirements for Permanent Scheme Definitions . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-3.1">3.1</a>.  Demonstrable, New, Long-Lived Utility . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-3.2">3.2</a>.  Syntactic Compatibility . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-3.3">3.3</a>.  Well Defined  . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-3.4">3.4</a>.  Definition of Operations  . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-3.5">3.5</a>.  Context of Use  . . . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-3.6">3.6</a>.  Internationalization and Character Encoding . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.7">3.7</a>.  Clear Security and Privacy Considerations . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.8">3.8</a>.  Scheme Name Considerations  . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-3.9">3.9</a>.  Interoperability Considerations . . . . . . . . . . . . .   <a href="#page-9">9</a>
   <a href="#section-4">4</a>.  Guidelines for Provisional URI Scheme Registration  . . . . .   <a href="#page-9">9</a>
   <a href="#section-5">5</a>.  Guidelines for Historical URI Scheme Registration . . . . . .  <a href="#page-10">10</a>
   <a href="#section-6">6</a>.  Guidelines for Private URI Scheme Use . . . . . . . . . . . .  <a href="#page-10">10</a>
   <a href="#section-7">7</a>.  URI Scheme Registration Procedure . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-7.1">7.1</a>.  General . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-7.2">7.2</a>.  Registration Procedures . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
     <a href="#section-7.3">7.3</a>.  Change Control  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-7.4">7.4</a>.  URI Scheme Registration Template  . . . . . . . . . . . .  <a href="#page-13">13</a>
   <a href="#section-8">8</a>.  The "example" URI Scheme  . . . . . . . . . . . . . . . . . .  <a href="#page-14">14</a>
     <a href="#section-8.1">8.1</a>.  "example" URI Scheme Registration Request . . . . . . . .  <a href="#page-15">15</a>
   <a href="#section-9">9</a>.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>
   <a href="#section-10">10</a>. Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
   <a href="#section-11">11</a>. References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
     <a href="#section-11.1">11.1</a>.  Normative References . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
     <a href="#section-11.2">11.2</a>.  Informative References . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-18">18</a>
   Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-18">18</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-19">19</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Uniform Resource Identifier (URI) protocol element and generic
   syntax is defined by [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>].  Each URI begins with a scheme name,
   as defined by <a href="./rfc3986#section-3.1">Section&nbsp;3.1 of RFC 3986</a>, 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 [<a href="./rfc4395" title="&quot;Guidelines and Registration Procedures for New URI Schemes&quot;">RFC4395</a>], which in turn obsoleted [<a href="./rfc2717" title="&quot;Registration Procedures for URL Scheme Names&quot;">RFC2717</a>]
   and [<a href="./rfc2718" title="&quot;Guidelines for new URL Schemes&quot;">RFC2718</a>].  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



<span class="grey">Thaler, et al.            Best Current Practice                 [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   [<a href="./rfc2141" title="&quot;URN Syntax&quot;">RFC2141</a>].  URN "namespaces" [<a href="./rfc3406" title="&quot;Uniform Resource Names (URN) Namespace Definition Mechanisms&quot;">RFC3406</a>] 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.  In addition, this document provides an
   updated 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 defining documents for schemes;

   o  discourage multiple separate uses of the same scheme name;

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

   o  encourage registration by setting a low barrier for registration.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  URIs and IRIs</span>

   As originally defined, URIs only allowed a limited repertoire of
   characters chosen from US-ASCII.  An Internationalized Resource
   Identifier (IRI), as defined by [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>], extends the URI syntax to
   allow characters from a much greater repertoire to accommodate
   resource identifiers from the world's languages.  <a href="./rfc3987">RFC 3987</a> [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>]
   also defined a mapping between URIs and IRIs.  IRIs use the same
   scheme names as URIs.  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 [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

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



<span class="grey">Thaler, et al.            Best Current Practice                 [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Requirements for Permanent Scheme Definitions</span>

   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 URI schemes defined or normatively referenced by IETF
   Standards Track documents, 'permanent' registration status is
   REQUIRED.

   [<a id="ref-RFC3986">RFC3986</a>] 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 reused
   outside the generic syntax restrictions and that fragment identifiers
   are not scheme specific.  A scheme definition must specify the scheme
   name and the syntax of the scheme-specific part, which is clarified
   as follows:

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

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

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Demonstrable, New, Long-Lived Utility</span>

   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) [<a href="#ref-W3CWebArch">W3CWebArch</a>].  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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Syntactic Compatibility</span>

   [<a id="ref-RFC3986">RFC3986</a>] 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.  [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>] extended this generic
   syntax to cover IRIs.  All scheme specifications MUST define their
   own URI &lt;scheme-specific-part&gt; syntax.  Care must be taken to ensure






<span class="grey">Thaler, et al.            Best Current Practice                 [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   that all strings matching their scheme-specific syntax will also
   match the &lt;absolute-URI&gt; grammar described in [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>].

   New schemes SHOULD reuse the common URI components of [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>] 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 similar previously
   registered schemes.

   Schemes that are not intended for use with relative URIs SHOULD avoid
   use of the forward slash "/" character in order to avoid unintended
   processing, such as resolution of "." and ".." (dot segments).

   Schemes SHOULD avoid improper use of "//".  The use of double slashes
   in the first part of a URI is not a stylistic indicator that what
   follows is a URI: double slashes are intended for use ONLY when the
   syntax of the &lt;scheme-specific-part&gt; 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 (<a href="./rfc3986#section-3.2">Section&nbsp;3.2 of RFC 3986</a> has more details).  Schemes
   that do not contain a conformant hierarchical structure in their
   &lt;scheme-specific-part&gt; SHOULD NOT use double slashes following the
   "&lt;scheme&gt;:" string.

   New schemes SHOULD clearly define the role of reserved characters
   (see <a href="./rfc3986#section-2.2">Section&nbsp;2.2 of [RFC3986]</a>) 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.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Well Defined</span>

   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.

   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 SHOULD be



<span class="grey">Thaler, et al.            Best Current Practice                 [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   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, are
   represented in a valid URI.  See <a href="#section-3.6">Section 3.6</a> for guidelines for
   encoding strings or sequences of bytes 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 is allowed and why.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Definition of Operations</span>

   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 bidirectional 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.  For example, a
   common "default" operation today is to launch an application
   associated with the scheme name and let it use the other URI
   components as inputs to do something.  The default invocation, or
   dereferencing, of a URI SHOULD be "safe" in the sense described by
   Section 3.4 of [<a href="#ref-W3CWebArch">W3CWebArch</a>]; i.e., performing such an invocation
   should not incur any additional obligations by doing so.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Context of Use</span>

   In general, URIs are used within a broad range of protocols and
   applications.  For example, URIs are commonly used within hypertext
   documents as references 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



<span class="grey">Thaler, et al.            Best Current Practice                 [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   intended use and include references to documentation that define the
   applications and/or protocols cited.  This does not obviate the need
   for documentation on applications and/or protocols to discuss URI
   schemes relevant to them.

<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Internationalization and Character Encoding</span>

   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
   [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>] and <a href="#section-2.5">Section 2.5</a> (especially the last paragraph) of
   [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>] 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 issues (see, for
   example, [<a href="./rfc4690" title="&quot;Review and Recommendations for Internationalized Domain Names (IDNs)&quot;">RFC4690</a>]).

   Percent-encoded character sequences are automatically included by
   definition for characters given in IRI productions.  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.  In most
   cases, it is advisable to define the actual characters allowed in an
   IRI production in order to allow the 'pct-encoded' definition from
   <a href="./rfc3986#section-2.1">Section&nbsp;2.1 of [RFC3986]</a> at the same places and to add prose that
   limits percent escapes to those that can be created by converting
   valid UTF-8 character sequences to percent-encoding.

<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>.  Clear Security and Privacy Considerations</span>

   Definitions of schemes MUST be accompanied by a clear analysis of the
   security and privacy implications for systems that use the scheme;
   this follows the practice of Security Consideration sections within
   IANA registrations [<a href="./rfc5226" title="">RFC5226</a>].

   In particular, <a href="./rfc3986#section-7">Section&nbsp;7 of RFC 3986</a> [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>] describes general
   security considerations for URIs while [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>] gives those for
   IRIs.  The definition of an individual scheme should note which of
   these apply to the specified scheme, in addition to any more scheme-
   specific concerns.  For example, if the scheme-specific part is
   privacy sensitive, then that should be documented.






<span class="grey">Thaler, et al.            Best Current Practice                 [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>.  Scheme Name Considerations</span>

   <a href="./rfc3986#section-3.1">Section&nbsp;3.1 of RFC 3986</a> defines the syntax of a URI scheme name; this
   syntax remains the same for IRIs.  New scheme 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 name itself MUST be
   registered using lowercase letters.

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

   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 <a href="./rfc5378#section-3.4">Section&nbsp;3.4 of [RFC5378]</a>).

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

   A scheme name is not a "protocol."  However, like a service name as
   defined in <a href="./rfc6335#section-5">Section&nbsp;5 of [RFC6335]</a>, it often identifies a particular
   protocol or application.  If a scheme name has a one-to-one
   correspondence with a service name, then the names SHOULD be the
   same.

   Some organizations desire their own namespace for URI scheme names
   for private use (see <a href="#section-6">Section 6</a>).  In doing so, it is important to
   prevent collisions and to make it possible to identify the owner of a
   private-use scheme.  To accomplish these two goals, such
   organizations SHOULD use a prefix based on their domain name,
   expressed in reverse order.  For example, a URI scheme name of
   com.example.mything might be used by the organization that owns the
   example.com domain name.  Care must be taken, however, if the
   organization later loses the domain name embedded in their scheme
   names since domain name registrations are not permanent.  To
   associate the private-use scheme name with the original organization,
   the private-use scheme can be registered using the registration
   procedure in <a href="#section-7">Section 7</a>.

   Furthermore, to prevent collisions with private-use scheme names, new
   scheme names registered MUST NOT contain a "." unless actually
   constructed from a reversed domain name.





<span class="grey">Thaler, et al.            Best Current Practice                 [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>.  Interoperability Considerations</span>

   If the person or group registering the scheme is aware of any details
   regarding the scheme that might impact interoperability, identify
   them, for example, proprietary or uncommon encoding methods, or
   incompatibility with types or versions of any underlying protocol.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Guidelines for Provisional URI Scheme Registration</span>

   '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 apply:

   o  The scheme name must meet the syntactic requirements of
      <a href="#section-3.8">Section 3.8</a>.

   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 Designated Expert can approve a request
      to modify an existing entry to note the separate use.

   o  Contact information identifying the person supplying the
      registration must be included.  Previously unregistered schemes
      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 clear security considerations
      (<a href="#section-3.7">Section 3.7</a>) 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
      <a href="#section-3">Section 3</a>, the differences and reasons SHOULD be noted.









<span class="grey">Thaler, et al.            Best Current Practice                 [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Guidelines for Historical URI Scheme Registration</span>

   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 whose 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 as to where the scheme was previously defined or
   documented.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Guidelines for Private URI Scheme Use</span>

   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 MUST be used and 'provisional'
   registration is strongly encouraged (unless the scheme name is
   constructed from a domain name), as discussed in <a href="#section-3.8">Section 3.8</a>.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  URI Scheme Registration Procedure</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  General</span>

   The IANA policy (using terms defined in [<a href="./rfc5226" title="">RFC5226</a>]) for 'provisional'
   registration was formerly Expert Review; this document changes the
   policy to First Come First Served.  The policy for 'permanent' and
   'historical' registration continues to be Expert Review.

   The registration procedure is intended to be very lightweight for
   noncontentious 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 standardization is anticipated, the working group or individuals
   concerned are advised to submit an early 'permanent' registration
   request rather than waiting until the standardization process has run
   its course.  IANA will pass this to the Designated Expert who may
   recommend 'provisional' registration until the specification is
   approved as a standard.  This will provide an opportunity for
   feedback while specification development and review is still active,
   and while the submitter(s) are still in a position to respond to any



<span class="grey">Thaler, et al.            Best Current Practice                [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   issues that might be raised.  If and when the specification is
   approved as a standard, the submitters should submit a request to
   change the registration status to 'permanent'.

   The role of the Designated Expert in the procedure for 'permanent'
   registrations described here is to ensure that the normal open review
   process has been properly followed and to raise possible concerns
   about wider implications of proposals for the use and deployment of
   URIs.  Nothing in the procedure empowers the Designated Expert to
   override properly arrived-at IETF or working group consensus.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Registration Procedures</span>

   Someone wishing to register a new scheme MUST:

   1.  Check the IANA "Uniform Resource Identifier (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 <a href="#section-7.4">Section 7.4</a>.  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 scheme registration request can also be submitted in some
       other form (as part of another document or as a stand-alone
       document), but the scheme registration request will be treated as
       an "IETF Contribution" under the guidelines of [<a href="./rfc5378" title="&quot;Rights Contributors Provide to the IETF Trust&quot;">RFC5378</a>].

   3.  If the registration request is for a 'permanent' registration
       (or, optionally, for any other registration if desired):

       1.  Review the requirements in <a href="#section-3">Section 3</a>.

       2.  Send a copy of the scheme registration request or a pointer
           to the document containing the request (with specific
           reference to the section that requests the scheme
           registration) 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 can be discussed on
           uri@w3.org; schemes for a network protocol can 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.





<span class="grey">Thaler, et al.            Best Current Practice                [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


       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) scheme registration request (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 required sections
       of the scheme registration request are missing or any citations
       are not correct, IANA will reject the registration request.  A
       registrant can resubmit a corrected request if desired.

   2.  If the request is for 'provisional' registration and no entry
       already exists in the current registry for the same name, IANA
       adds the registration to the registry under the First Come First
       Served policy.

   3.  Otherwise, IANA enters the registration request in the IANA
       registry with the status marked as "Pending Review", and the
       remainder of this section applies.

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

   5.  The Designated Expert will evaluate the request against the
       criteria of the requested status.

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

       *  Request additional review or discussion as necessary.

   7.  If an entry already exists for the same name, the Designated
       Expert will determine whether the request should be rejected or
       whether the existing entry should be modified to note the
       separate use.  This conflict process applies regardless of the
       requested status or the status of the existing entry.



<span class="grey">Thaler, et al.            Best Current Practice                [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   8.  Once the Designated Expert approves registration for a given
       status, IANA updates the registration to indicate the approved
       status.  If the Designated Expert instead rejects the
       registration, the "Pending Review" request is removed from the
       registry.

   Either based on an explicit request or independently initiated, the
   Designated Expert or the 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.  Typically, this
   would only occur if the use is considered a standard (not necessarily
   an IETF standard).

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Change Control</span>

   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.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  URI Scheme Registration Template</span>

   This template describes the fields that MUST be supplied in a scheme
   registration request suitable for adding to the registry:

   Scheme name:
     See <a href="#section-3.8">Section 3.8</a> for guidelines.

   Status:
     This reflects the status requested and must be one of 'Permanent',
     'Provisional', or 'Historical'.

   Applications/protocols that use this scheme name:
     See <a href="#section-3.5">Section 3.5</a>.



<span class="grey">Thaler, et al.            Best Current Practice                [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


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

   Change controller:
     Organization or person (often the author), including contact
     information, authorized to change this.

   References:
     Include full citations for all referenced documents.  Scheme
     registration requests 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 previous version of this specification required the following
   additional fields in a scheme registration request.  These fields are
   no longer part of the template.  The answers instead belong in the
   scheme specification.

   Scheme syntax:
     See <a href="#section-3.2">Section 3.2</a> for guidelines.

   Scheme semantics:
     See <a href="#section-3.3">Section 3.3</a> and <a href="#section-3.4">Section 3.4</a> for guidelines.

   Encoding considerations:
     See <a href="#section-3.3">Section 3.3</a> and <a href="#section-3.6">Section 3.6</a> for guidelines.

   Interoperability considerations:
     See <a href="#section-3.9">Section 3.9</a> for guidelines.

   Security considerations:
     See <a href="#section-3.7">Section 3.7</a> for guidelines.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  The "example" URI Scheme</span>

   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.









<span class="grey">Thaler, et al.            Best Current Practice                [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   The "example" scheme is specified as follows:

   Scheme syntax:  The entire range of allowable syntax specified in
     [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>] is allowed for "example" URIs.  Similarly, the entire
     range of allowable syntax specified in [<a href="./rfc3987" title="&quot;Internationalized Resource Identifiers (IRIs)&quot;">RFC3987</a>] is allowed for
     "example" IRIs.  For example, &lt;example:foo&gt;, &lt;example:/foo&gt;, and
     &lt;example://foo&gt; are all valid.

   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 <a href="./rfc3986#section-2.5">Section&nbsp;2.5 of [RFC3986]</a> for
     guidelines.

   Interoperability considerations:  None.

   Security considerations:  None.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  "example" URI Scheme Registration Request</span>

   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

   Change controller:  IETF

   References:  <a href="#section-8">Section 8</a> of this document (<a href="./rfc7595">RFC 7595</a>).

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

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

   The updated template has an additional field for the status of the
   scheme, and the procedures for entering new name schemes have been
   augmented.  <a href="#section-7">Section 7</a> establishes the process for new scheme
   registration.




<span class="grey">Thaler, et al.            Best Current Practice                [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   IANA has done the following:

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

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

   o  Added the "example" URI scheme to the registry (see the template
      in <a href="#section-8.1">Section 8.1</a> for registration).

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Security Considerations</span>

   All registered values are expected to contain clear security
   considerations as discussed in <a href="#section-3.7">Section 3.7</a>.  However, 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.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC2141">RFC2141</a>]  Moats, R., "URN Syntax", <a href="./rfc2141">RFC 2141</a>, DOI 10.17487/RFC2141,
              May 1997, &lt;<a href="http://www.rfc-editor.org/info/rfc2141">http://www.rfc-editor.org/info/rfc2141</a>&gt;.

   [<a id="ref-RFC3986">RFC3986</a>]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              <a href="./rfc3986">RFC 3986</a>, DOI 10.17487/RFC3986, January 2005,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3986">http://www.rfc-editor.org/info/rfc3986</a>&gt;.

   [<a id="ref-RFC5226">RFC5226</a>]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
              DOI 10.17487/RFC5226, May 2008,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>&gt;.





<span class="grey">Thaler, et al.            Best Current Practice                [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   [<a id="ref-RFC5378">RFC5378</a>]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
              Contributors Provide to the IETF Trust", <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, <a href="./rfc5378">RFC 5378</a>,
              DOI 10.17487/RFC5378, November 2008,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5378">http://www.rfc-editor.org/info/rfc5378</a>&gt;.

   [<a id="ref-RFC6335">RFC6335</a>]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", <a href="https://www.rfc-editor.org/bcp/bcp165">BCP 165</a>,
              <a href="./rfc6335">RFC 6335</a>, DOI 10.17487/RFC6335, August 2011,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6335">http://www.rfc-editor.org/info/rfc6335</a>&gt;.

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Informative References</span>

   [<a id="ref-RFC2717">RFC2717</a>]  Petke, R. and I. King, "Registration Procedures for URL
              Scheme Names", <a href="./rfc2717">RFC 2717</a>, DOI 10.17487/RFC2717, November
              1999, &lt;<a href="http://www.rfc-editor.org/info/rfc2717">http://www.rfc-editor.org/info/rfc2717</a>&gt;.

   [<a id="ref-RFC2718">RFC2718</a>]  Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
              "Guidelines for new URL Schemes", <a href="./rfc2718">RFC 2718</a>,
              DOI 10.17487/RFC2718, November 1999,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2718">http://www.rfc-editor.org/info/rfc2718</a>&gt;.

   [<a id="ref-RFC3406">RFC3406</a>]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", <a href="https://www.rfc-editor.org/bcp/bcp66">BCP 66</a>, <a href="./rfc3406">RFC 3406</a>, DOI 10.17487/RFC3406,
              October 2002, &lt;<a href="http://www.rfc-editor.org/info/rfc3406">http://www.rfc-editor.org/info/rfc3406</a>&gt;.

   [<a id="ref-RFC3864">RFC3864</a>]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", <a href="https://www.rfc-editor.org/bcp/bcp90">BCP 90</a>, <a href="./rfc3864">RFC 3864</a>,
              DOI 10.17487/RFC3864, September 2004,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3864">http://www.rfc-editor.org/info/rfc3864</a>&gt;.

   [<a id="ref-RFC3987">RFC3987</a>]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", <a href="./rfc3987">RFC 3987</a>, DOI 10.17487/RFC3987,
              January 2005, &lt;<a href="http://www.rfc-editor.org/info/rfc3987">http://www.rfc-editor.org/info/rfc3987</a>&gt;.

   [<a id="ref-RFC4395">RFC4395</a>]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", <a href="./rfc4395">RFC 4395</a>,
              DOI 10.17487/RFC4395, February 2006,
              &lt;<a href="http://www.rfc-editor.org/info/rfc4395">http://www.rfc-editor.org/info/rfc4395</a>&gt;.

   [<a id="ref-RFC4690">RFC4690</a>]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", <a href="./rfc4690">RFC 4690</a>, DOI 10.17487/RFC4690, September 2006,
              &lt;<a href="http://www.rfc-editor.org/info/rfc4690">http://www.rfc-editor.org/info/rfc4690</a>&gt;.





<span class="grey">Thaler, et al.            Best Current Practice                [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


   [<a id="ref-W3CWebArch">W3CWebArch</a>]
              W3C Technical Architecture Group, "Architecture of the
              World Wide Web, Volume One", W3C Recommendation, December
              2004, &lt;<a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>&gt;.

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 draft versions of this document.

   Parts of this document are based on [<a href="./rfc2717" title="&quot;Registration Procedures for URL Scheme Names&quot;">RFC2717</a>], [<a href="./rfc2718" title="&quot;Guidelines for new URL Schemes&quot;">RFC2718</a>] and
   [<a href="./rfc3864" title="&quot;Registration Procedures for Message Header Fields&quot;">RFC3864</a>].  Some of the ideas about use of URIs were taken from the
   "Architecture of the World Wide Web" [<a href="#ref-W3CWebArch">W3CWebArch</a>].

Contributor

   Larry Masinter was an author of the document from which this work is
   derived, and he continued as author of this version through the
   working group and IESG evaluation period.  His many contributions are
   gratefully acknowledged.

























<span class="grey">Thaler, et al.            Best Current Practice                [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7595">RFC 7595</a>                  URI Scheme Guidelines                June 2015</span>


Authors' Addresses

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

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


   Tony Hansen
   AT&amp;T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   United States

   EMail: tony+urireg@maillennium.att.com


   Ted Hardie
   Google

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

























Thaler, et al.            Best Current Practice                [Page 19]
</pre>