Internet DRAFT - draft-ietf-appsawg-uri-scheme-reg
draft-ietf-appsawg-uri-scheme-reg
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 10, 2015 T. Hardie
Google
L. Masinter
Adobe
April 8, 2015
Guidelines and Registration Procedures for URI Schemes
draft-ietf-appsawg-uri-scheme-reg-06
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 10, 2015.
Copyright Notice
Copyright (c) 2015 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 10, 2015 [Page 1]
Internet-Draft URI Scheme Guidelines April 2015
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
1.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Permanent Scheme Definitions . . . . . . . . 4
3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4
3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5
3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Definition of Operations . . . . . . . . . . . . . . . . 6
3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 7
3.6. Internationalization and Character Encoding . . . . . . . 7
3.7. Clear Security and Privacy Considerations . . . . . . . . 7
3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 8
3.9. Interoperability Considerations . . . . . . . . . . . . . 9
4. Guidelines for Provisional URI Scheme Registration . . . . . 9
5. Guidelines for Historical URI Scheme Registration . . . . . . 10
6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 10
7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Registration Procedures . . . . . . . . . . . . . . . . . 11
7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 13
7.4. URI Scheme Registration Template . . . . . . . . . . . . 13
8. The "example" URI Scheme . . . . . . . . . . . . . . . . . . 14
8.1. "Example" URI Scheme Registration Request . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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.
Thaler, et al. Expires October 10, 2015 [Page 2]
Internet-Draft URI Scheme Guidelines April 2015
This document obsoletes [RFC4395], which in turn obsoleted [RFC2717]
and [RFC2718]. 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
([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 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 avoid names that might be confused
with existing ones;
o encourage registration by setting a low barrier for registration.
1.1. URIs and IRIs
As originally defined, URIs only allowed a limited repertoire of
characters chosen from US-ASCII. An Internationalized Resource
Identifier (IRI), as defined by [RFC3987], extends the URI syntax to
allow characters from a much greater repertoire, to accommodate
resource identifiers from the world's languages. RFC 3987 [RFC3987]
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 [RFC3987].
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], as 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
Thaler, et al. Expires October 10, 2015 [Page 3]
Internet-Draft URI Scheme Guidelines April 2015
registration request" being the completed template 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 URI schemes defined or normatively referenced by IETF
Standards-Track documents, 'permanent' registration status is
REQUIRED.
[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, and 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 ]
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.
Thaler, et al. Expires October 10, 2015 [Page 4]
Internet-Draft URI Scheme Guidelines April 2015
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
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 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 <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 reserved characters
(see [RFC3986], Section 2.2) 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.
Thaler, et al. Expires October 10, 2015 [Page 5]
Internet-Draft URI Scheme Guidelines April 2015
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
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 Section 3.6 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.
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. 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
Thaler, et al. Expires October 10, 2015 [Page 6]
Internet-Draft URI Scheme Guidelines April 2015
section 3.4 of [W3CWebArch]; i.e., performing such an invocation
should not incur any additional obligations by doing so.
3.5. Context of Use
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
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.
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 (especially the last paragraph) 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 issues (see, for
example [RFC4690]).
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, to allow the 'pct-encoded' definition from
Section 2.1 of [RFC3986] 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.
3.7. Clear Security and Privacy Considerations
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 [RFC5226].
Thaler, et al. Expires October 10, 2015 [Page 7]
Internet-Draft URI Scheme Guidelines April 2015
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, in addition to any more scheme-
specific concerns. For example, if the scheme-specific part is
privacy sensitive then that should be documented.
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 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 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.)
A scheme name is not a "protocol." However, like a service name as
defined in section 5 of [RFC6335], 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 Section 6). 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,
Thaler, et al. Expires October 10, 2015 [Page 8]
Internet-Draft URI Scheme Guidelines April 2015
the private use scheme can be registered using the registration
procedure in Section 7.
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.
3.9. Interoperability Considerations
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;
incompatibility with types or versions of any underlying protocol.
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 apply:
o The scheme name must meet the syntactic requirements of
Section 3.8.
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
(Section 3.7) or explain why a full security analysis is not
available (e.g., in a third-party scheme registration).
Thaler, et al. Expires October 10, 2015 [Page 9]
Internet-Draft URI Scheme Guidelines April 2015
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 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.
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
unless the scheme name is constructed from a domain name as discussed
in Section 3.8.
7. URI Scheme Registration Procedure
7.1. General
The IANA policy (using terms defined in [RFC5226]) for 'provisional'
registration was formerly Expert Review. The policy for 'permanent'
and 'historical' registration continues to be Expert Review, but this
document changes the policy for 'provisional' registration to First
Come First Served.
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 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
Thaler, et al. Expires October 10, 2015 [Page 10]
Internet-Draft URI Scheme Guidelines April 2015
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 opportunity for feedback
while specification development and review is still active, and the
submitter(s) are still in a position to respond to any 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.
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 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 [RFC3978].
3. If the registration request is for a 'permanent' registration
(or, optionally, for any other registration if desired):
1. Review the requirements in Section 3.
2. Send a copy of the scheme registration request or a pointer
to the containing document (with specific reference to the
section with the scheme registration request) 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
Thaler, et al. Expires October 10, 2015 [Page 11]
Internet-Draft URI Scheme Guidelines April 2015
that protocol. Allow a reasonable time for discussion and
comments. Four weeks is reasonable for a 'permanent'
registration request.
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 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.
Thaler, et al. Expires October 10, 2015 [Page 12]
Internet-Draft URI Scheme Guidelines April 2015
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.
8. Once Expert Review approves registration for a given status, IANA
updates the registration to indicate the approved status. If
Expert Review 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).
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, suitable for adding to the registry:
Scheme name:
See Section 3.8 for guidelines.
Status:
Thaler, et al. Expires October 10, 2015 [Page 13]
Internet-Draft URI Scheme Guidelines April 2015
This reflects the status requested, and must be one of 'permanent',
'provisional', or 'historical'.
Applications/protocols that use this scheme name:
See Section 3.5.
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 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:
See Section 3.9 for guidelines.
Security considerations:
See Section 3.7 for guidelines.
8. The "example" URI 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.
Thaler, et al. Expires October 10, 2015 [Page 14]
Internet-Draft URI Scheme Guidelines April 2015
The "example" scheme is specified as follows:
Scheme syntax: The entire range of allowable syntax specified in
[RFC3986] is allowed for "example" URIs. Similarly, the entire
range of allowable syntax specified in [RFC3987] is allowed for
"example" IRIs. For example, <example:foo>, <example:/foo>, and
<example://foo> 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 Section 2.5 of [RFC3986] for
guidelines.
Interoperability considerations: None.
Security considerations: None.
8.1. "Example" URI 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
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.
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.
Thaler, et al. Expires October 10, 2015 [Page 15]
Internet-Draft URI Scheme Guidelines April 2015
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 clear security
considerations as discussed in Section 3.7. 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.
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].
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.
Thaler, et al. Expires October 10, 2015 [Page 16]
Internet-Draft URI Scheme Guidelines April 2015
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6335] 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", BCP 165, RFC
6335, August 2011.
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.
[W3CWebArch]
W3C Technical Architecture Group, "Architecture of the
World Wide Web, Volume One", December 2004,
<http://www.w3.org/TR/webarch/>.
Thaler, et al. Expires October 10, 2015 [Page 17]
Internet-Draft URI Scheme Guidelines April 2015
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. Added a Notes column in the registry for notes approved by the
Designated Expert.
3. 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.
4. 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.
5. Updated process for handling of scheme name conflicts, so that
adding a note can be approved by the Designated Expert rather
than the IESG.
6. Clarified that a "URI scheme name" and an "IRI scheme name" are
the same thing and thus use the same IANA registry.
7. Clarified that a registration request falls under the "IETF
Contribution" rules, but the scheme's specification need not.
8. Added the "example:" URI scheme.
9. Added text about when to use 'provisional' registration.
10. Updated convention for Private use schemes to use "." (instead
of "-") between domain name labels, to reduce chance of
collision, and recommended use of a reverse domain name prefix
to allow identifying the owning organization.
11. Recommended that scheme definitions define a "default" operation
for when a URI is invoked.
12. Recommended that a scheme name be the same as the service name,
when there exists a 1:1 correspondence.
13. Elaborated on when a 'provisional' request should be upgraded to
Permanent.
Thaler, et al. Expires October 10, 2015 [Page 18]
Internet-Draft URI Scheme Guidelines April 2015
14. Clarified that since, per RFC 3986, fragment identifiers are not
scheme-specific and hence are not part of the scheme definition.
15. Added text about getting early review and registration for
schemes intended to become standards.
16. Added text about privacy as an example of what should be covered
in security considerations in a scheme definition.
17. Clarified the role of a Designated Expert in reviewing
Standards-Track registrations.
Authors' Addresses
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
Thaler, et al. Expires October 10, 2015 [Page 19]
Internet-Draft URI Scheme Guidelines April 2015
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 10, 2015 [Page 20]
