Internet DRAFT - draft-thaler-appsawg-uri-scheme-reg
draft-thaler-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: August 18, 2014 T. Hardie
Google
L. Masinter
Adobe
February 14, 2014
Guidelines and Registration Procedures for New URI Schemes
draft-thaler-appsawg-uri-scheme-reg-00
Abstract
This document updates the guidelines and recommendations, as well as
the IANA registration processes, for the definition of Uniform
Resource Identifier (URI) schemes. It obsoletes RFC 4395.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Thaler, et al. Expires August 18, 2014 [Page 1]
Internet-Draft New URI Schemes February 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Guidelines for Permanent Scheme Definitions . . . . . . . . . 4
3.1. Demonstratable, 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 . . . . . . . . . . . . . . . . . . . . . 6
3.6. Internationalization and Character Encoding . . . . . . . 7
3.7. Clear Security Considerations . . . . . . . . . . . . . . 7
3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 7
4. Guidelines for Provisional URI Scheme Registration . . . . . 8
5. Guidelines for Historical URI Scheme Registration . . . . . . 9
6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 9
7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Registration Procedures . . . . . . . . . . . . . . . . . 10
7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 12
7.4. URI Scheme Registration Template . . . . . . . . . . . . 12
8. The "example" Scheme . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The Uniform Resource Identifier (URI) protocol element and generic
syntax is defined by [RFC3986]. Each URI begins with a scheme name,
as defined by Section 3.1 of RFC 3986, that refers to a specification
for identifiers within that scheme. The URI syntax provides a
federated and extensible naming system, where each scheme's
specification may further restrict the syntax and define the
semantics of identifiers using that scheme.
This document obsoletes [RFC4395], which in turn obsoleted [RFC2717]
and [RFC2718]. Recent documents have used the term "URI" for all
resource identifiers, avoiding the term "URL" and reserving the term
Thaler, et al. Expires August 18, 2014 [Page 2]
Internet-Draft New URI Schemes February 2014
"URN" explicitly for those URIs using the "urn" scheme name
([RFC2141]). URN "namespaces" ([RFC3406]) are specific to the "urn"
scheme and are not covered explicitly by this specification.
This document provides updated guidelines for the definition of new
schemes, for consideration by those who are defining, registering, or
evaluating those definitions, as well as a process and mechanism for
registering schemes within the IANA URI Schemes registry. There is a
single namespace for registered schemes. The intent of the registry
is to:
o provide a central point of discovery for established URI scheme
names, and easy location of their defining documents;
o discourage use of the same scheme name for different purposes;
o help those proposing new scheme names to discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encourage registration by setting a low barrier for registration.
As originally defined, URIs only allowed a limited repertoire of
characters chosen from US-ASCII. An Interationalized Resource
Identifier (IRI), as defined by [RFC3987], extends the URI syntax to
allow characters from a much greater repertoire, to accomodate
resource identifiers from the world's languages. RFC 3987 [RFC3987]
also defined a mapping between URIs and IRIs. A URI scheme name is
the same as the corresponding IRI scheme name. Thus, there is no
separate, independent registry or registration process for IRI
schemes: the URI Schemes registry is used for both URIs and IRIs.
Those who wish to describe resource identifiers that are useful as
IRIs should define the corresponding URI syntax, and note that the
IRI usage follows the rules and transformations defined in [RFC3987].
[RFC3986] defines the overall syntax for URIs as:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
A scheme definition cannot override the overall syntax for URIs. For
example, this means that fragment identifiers (#) cannot be re-used
outside the generic syntax restrictions. A scheme definition must
specify the scheme name and the syntax of the scheme-specific part,
which is clarified as follows:
Thaler, et al. Expires August 18, 2014 [Page 3]
Internet-Draft New URI Schemes February 2014
URI = scheme ":" scheme-specific-part [ "#" fragment ]
scheme-specific-part = hier-part [ "?" query ]
2. Terminology
Within this document, the key words MUST, MAY, SHOULD, REQUIRED,
RECOMMENDED, and so forth are used within the general meanings
established in [RFC2119], within the context that they are
requirements on future registrations.
This document distinguishes between a "scheme specification", being a
document defining the syntax and semantics of a scheme, vs. a "scheme
registration request" being the request submitted to IANA. The term
"scheme definition" refers generically to the syntax and semantics of
a scheme, typically documented in a scheme specification.
3. Guidelines for Permanent Scheme Definitions
This section gives considerations for new schemes. Meeting these
guidelines is REQUIRED for permanent scheme registration. Permanent
status is appropriate for, but not limited to, use in standards. For
IETF Standards-Track documents, Permanent registration status is
REQUIRED.
3.1. Demonstratable, New, Long-Lived Utility
In general, the use and deployment of new schemes in the Internet
infrastructure may be costly; some parts of URI processing may be
scheme-dependent. Introducing a new scheme may 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 should 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. [[CREF1: Previously, "scheme definition"
above was "registration document", which was ambiguous as to whether
the scheme specification or the IANA registration request was meant.
But the template in this document has no field for this, so updated
as currently written. --DT]]
Thaler, et al. Expires August 18, 2014 [Page 4]
Internet-Draft New URI Schemes February 2014
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 previously registered
schemes.
Schemes that are not intended for use with relative URIs SHOULD avoid
use of the forward slash "/" character, which is used for
hierarchical delimiters, and the complete path segments "." and ".."
(dot-segments).
Schemes should avoid improper use of "//". The use of double slashes
in the first part of a URI is not an artistic indicator that what
follows is a URI: Double slashes are intended for use ONLY when the
syntax of the <scheme-specific-part> contains a hierarchical
structure. In URIs from such schemes, the use of double slashes
indicates that what follows is the top hierarchical element for a
naming authority. (Section 3.2 of RFC 3986 has more details.)
Schemes that do not contain a conformant hierarchical structure in
their <scheme-specific-part> SHOULD NOT use double slashes following
the "<scheme>:" string.
New schemes SHOULD clearly define the role of [RFC3986] reserved
characters in URIs of the scheme being defined. The syntax of the
new scheme should be clear about which of the "reserved" set of
characters are used as delimiters within the URIs of the new scheme,
and when those characters must be escaped, versus when they may be
used without escaping.
3.3. Well-Defined
While URIs may or may 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 August 18, 2014 [Page 5]
Internet-Draft New URI Schemes February 2014
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 MUST be
complete, and in sufficient detail so that the mapping in both
directions is clear: how to map from a URI into an identifier or set
of protocol actions or name in the target namespace, and how legal
values in the base namespace, or legal protocol interactions, might
be represented in a valid URI. In particular, the mapping SHOULD
describe the mechanisms for encoding binary or character strings
within valid character sequences in a URI (see Section 3.6 for
guidelines). If not all legal values or protocol interactions of the
base standard can be represented using the scheme, the definition
SHOULD be clear about which subset are allowed, and why.
3.4. Definition of Operations
As part of the definition of how a URI identifies a resource, a
scheme definition SHOULD define the applicable set of operations that
may be performed on a resource using the URI as its identifier. A
model for this is HTTP; an HTTP resource can be operated on by GET,
POST, PUT, and a number of other operations 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.
3.5. Context of Use
In general, URIs are used within a broad range of protocols and
applications. Most commonly, URIs are used as references to
resources within directories or hypertext documents, as hyperlinks to
other resources. In some cases, a scheme is intended for use within
Thaler, et al. Expires August 18, 2014 [Page 6]
Internet-Draft New URI Schemes February 2014
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.
3.6. Internationalization and Character Encoding
When describing schemes in which (some of) the elements of the URI
are actually representations of human-readable text, care should be
taken not to introduce unnecessary variety in the ways in which
characters are encoded into octets and then into URI characters; see
[RFC3987] and Section 2.5 of [RFC3986] for guidelines. If URIs of a
scheme contain any text fields, the scheme definition MUST describe
the ways in which characters are encoded and any compatibility issues
with IRIs of the scheme.
The scheme specification SHOULD be as restrictive as possible
regarding what characters are allowed in the URI, because some
characters can create several different security considerations (see,
for example [RFC4690]).
All percent-encoded variants are automatically included by definition
for any character given in an IRI production. This means that if you
want to restrict the URI percent-encoded forms in some way, you must
restrict the Unicode forms that would lead to them.
3.7. Clear Security Considerations
Definitions of schemes MUST be accompanied by a clear analysis of the
security implications for systems that use the scheme; this follows
the practice of Security Consideration sections within IANA
registrations [RFC5226].
In particular, Section 7 of RFC 3986 [RFC3986] describes general
security considerations for URIs, while [RFC3987] gives those for
IRIs. The definition of an individual scheme should note which of
these apply to the specified scheme.
3.8. Scheme Name Considerations
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this
syntax remains the same for IRIs. New registered schemes
registrations MUST follow this syntax, which only allows a limited
repertoire of characters (taken from US-ASCII). Although the syntax
for the scheme name in URIs is case insensitive, the scheme names
itself MUST be registered using lowercase letters.
Thaler, et al. Expires August 18, 2014 [Page 7]
Internet-Draft New URI Schemes February 2014
Scheme names should be short, but also sufficiently descriptive and
distinguished to avoid problems.
Avoid 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].)
Avoid using names that are either very general purpose or associated
in the community with some other application or protocol. Avoid
scheme names that are overly general or grandiose in scope (e.g.,
that allude to their "universal" or "standard" nature.)
Organizations that desire their own namespace for URI scheme names
are encouraged to use a prefix based on their domain name, expressed
in reverse order. For example, a URI scheme name of com.example.info
might be used by the organization that owns the example.com domain
name. [[CREF2: Open Issue: Should we define a mechanism to register
a scheme prefix ("web+", "ms-", etc.)? --DT]] [[CREF3: Open Issue:
Are strings that look like reversed FQDNs (other than grandfathered
ones like "iris.beep") reserved for use as such? Proposed answer is
Yes, new schemes should not use a "." unless they are actually
constructed from a domain name. --DT]]
4. Guidelines for Provisional URI Scheme Registration
Provisional registration can be used for schemes that are not part of
any standard, but that are intended for use (or observed to be in
use) outside 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.
[[CREF4: Open issue: previously this also RECOMMENDED following the
same guidelines as for permanent registration. However, this higher
bar disincented people to register schemes at all, and hence
interfered with the goals of the registry. Hence tentatively
removed, but need to confirm consensus on this. --DT]] For a
provisional registration, the following are REQUIRED:
o The scheme name meets the syntactic requirements of Section 3.8
and the encoding requirements of Section 3.6.
o There MUST NOT already be an entry with the same scheme name. (In
the unfortunate case that there are multiple, different uses of
the same scheme name, the IESG may approve a request to modify an
existing entry to note the separate use.) [[CREF5: Open Issue:
Must the IESG do this? Why not the Expert Reviewer? --??]]
Thaler, et al. Expires August 18, 2014 [Page 8]
Internet-Draft New URI Schemes February 2014
o Contact information identifying the person supplying the
registration is included. Previously unregistered schemes
discovered in use may be registered by third parties (even if not
on behalf of those who created the scheme). In this case, both
the registering party and the scheme creator SHOULD be identified.
o If no permanent, citable specification for the scheme definition
is included, credible reasons for not providing it SHOULD be
given.
o The scheme definition SHOULD include a clear Security
Considerations (Section 3.7) or explain why a full security
analysis is not available (e.g., in a third-party scheme
registration).
o If the scheme definition does not meet the guidelines laid out in
Section 3, the differences and reasons SHOULD be noted.
5. Guidelines for Historical URI Scheme Registration
In some circumstances, it is appropriate to note a scheme that was
once in use or registered but for whatever reason is no longer in
common use or the use is not recommended. In this case, it is
possible for an individual to request that the URI scheme be
registered (newly, or as an update to an existing registration) as
'historical'. Any scheme that is no longer in common use MAY be
designated as historical; the registration should contain some
indication to where the scheme was previously defined or documented.
6. Guidelines for Private URI Scheme Use
Unregistered schemes can cause problems if used outside a private
environment within a single organization. For example, the use could
leak out beyond the closed environment, or other colliding uses of
the same scheme name could occur within the closed environment. As
such, a unique namespace (see Section 3.8) should be used, and it is
strongly encouraged to do a Provisional registration even in such
cases. [[CREF6: TODO: This is closely related to the open issue of
prefix registrations. --DT]]
7. URI Scheme Registration Procedure
7.1. General
[[CREF7: We are updating this, but have not made changes. --??]]
[[CREF8: Open Issue: Should Provisional status just use First Come
First Serve? Someone suggested FCFS with Expert Review afterwards,
but the benefit and efficacy of a subsequent Expert Review seems
Thaler, et al. Expires August 18, 2014 [Page 9]
Internet-Draft New URI Schemes February 2014
dubious to me and might only serve to deter registrations in the
first place, which is the problem we're trying to solve. --DT]] The
scheme registration process is described in the terminology of
[RFC5226]. The registration process is an optional mailing list
review, followed by "Expert Review". The registration request should
note the desired status. The Designated Expert will evaluate the
request against the criteria of the requested status. In the case of
a permanent registration request, the Designated Expert may:
o Accept the specification of the scheme for permanent registration.
o Suggest provisional registration instead.
o Request IETF review and IESG approval; in the meanwhile, suggest
provisional registration.
Scheme definitions contained within other IETF documents
(Informational, Experimental, or Standards-Track RFCs) must also
undergo Expert Review; in the case of Standards-Track documents,
permanent registration status approval is REQUIRED.
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.
[[CREF9: TODO: We don't want this. --??]] If parties achieve
consensus on a registration proposal that does not fully conform to
the strict wording of this procedure, this should be drawn to the
attention of a relevant member of the IESG.
7.2. Registration Procedures
Someone wishing to register a new scheme MUST:
1. Check the IANA URI Schemes registry to see whether there is
already an entry for the desired name. If there is already an
entry under the name, choose a different scheme name, or update
the existing scheme definition.
2. Prepare a scheme registration request using the template
specified in Section 7.4. The scheme registration request may be
contained in an Internet Draft, submitted alone, or as part of
some other permanently available, stable, protocol specification.
Thaler, et al. Expires August 18, 2014 [Page 10]
Internet-Draft New URI Schemes February 2014
The completed template may also be submitted in some other form
(as part of another document or as a stand-alone document), but
the contents will be treated as an "IETF Contribution" under the
guidelines of [RFC3978]. [[CREF10: Open Issue: I think the last
phrase above about RFC 3978 is problematic, as it just serves to
discourage registration. For example, third-party registrations
may have no way to grant such rights or make such assertions.
Similarly, a standard published by another SDO may have policy/
process issues having a request treated as an IETF contribution.
Recommend deleting this sentence. --DT]]
3. If the registration request is for a Permanent registration:
1. Send a copy of the completed template or a pointer to the
containing document (with specific reference to the section
with the completed template) to the mailing list uri-
review@ietf.org , requesting review. In addition, request
review on other relevant mailing lists as appropriate. For
example, general discussion of URI syntactical issues could
be discussed on uri@w3.org; schemes for a network protocol
could be discussed on a mailing list for that protocol.
Allow a reasonable time for discussion and comments. Four
weeks is reasonable for a permanent registration requests.
2. Respond to review comments and make revisions to the proposed
registration as needed to bring it into line with the
guidelines given in this document.
4. Submit the (possibly updated) registration template (or pointer
to document containing it) to IANA at iana@iana.org.
Upon receipt of a scheme registration request, the following steps
MUST be followed:
1. IANA checks the submission for completeness; if sections are
missing or citations are not correct, IANA may reject the
registration request.
2. IANA checks the current registry for a entry with the same name;
if such an entry exists, IANA may reject the registration
request.
3. IANA enters the registration request in the IANA registry, with
status marked as "Pending Review".
4. IANA requests Expert Review of the registration request against
the corresponding guidelines from this document.
Thaler, et al. Expires August 18, 2014 [Page 11]
Internet-Draft New URI Schemes February 2014
5. The Designated Expert may request additional review or
discussion, as necessary.
6. If Expert Review recommends 'provisional' or 'permanent'
registration, IANA adds the registration to the registry with
appropriate review.
7. Unless Expert Review has explicitly rejected the registration
request within two weeks, IANA should automatically add the
registration to the registry as 'provisional'.
Either based on an explicit request or independently initiated, the
Designated Expert or IESG may request the upgrade of a 'provisional'
registration to a 'permanent' one. In such cases, IANA should update
the status of the corresponding entry. [[CREF11: Open Issue: Say
more about guidance to the Designated Expert. Under what
circumstance should this happen? --DT]]
7.3. Change Control
Registrations may 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 may be updated by the original registrant
or anyone designated by the original registrant. In addition, the
IESG may reassign responsibility for a provisional registration
scheme, or may 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 may 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' may be
requested by anyone authorized to update the provisional
registration.
7.4. URI Scheme Registration Template
This template describes the fields that must be supplied in a scheme
registration request:
Scheme name:
See Section 3.8 for guidelines.
Status:
Thaler, et al. Expires August 18, 2014 [Page 12]
Internet-Draft New URI Schemes February 2014
This reflects the status requested, and should be one of
'permanent', 'provisional', or 'historical'.
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.
Applications/protocols that use this scheme name:
See Section 3.5.
Interoperability considerations:
If the person or group registering the scheme is aware of any
details regarding the scheme that might impact interoperability,
identify them here. For example: proprietary or uncommon encoding
methods; inability to support multibyte character sets;
incompatibility with types or versions of any underlying protocol.
Security considerations:
See Section 3.7 for guidelines.
Contact:
Person (including contact information) to contact for further
information.
Author/Change controller:
Person (including contact information) authorized to change this.
References:
Include full citations for all referenced documents. Registration
templates for provisional registration may be included in an
Internet Draft; when the documents expire or are approved for
publication as an RFC, the registration will be updated.
[[CREF12: Open Issue: Some of the fields above may serve to deter
registration. Should some of them NOT be required for Provisional
registrations (including third-party ones)? For example, the
requirement to have clear security considerations is not appropriate
for third-party registrations. Typically one is forced to fill in
something like "Unknown, use with care." These seem to me to be more
appropriate inside the specification (if any) in the references,
rather than being required in the request template. Thus, as new
specifications update the uses (e.g., allow use with another HTTP
Thaler, et al. Expires August 18, 2014 [Page 13]
Internet-Draft New URI Schemes February 2014
method), the IANA registry itself shouldn't be required to be
updated. --DT]]
8. The "example" Scheme
There is a need for a scheme name that can be used for examples in
documentation without fear of conflicts with current or future actual
schemes. The scheme "example" is hereby registered as a Permanent
scheme for that purpose.
Scheme name: example
Status: permanent
Scheme syntax: The entire range of allowable syntax specified in
[RFC3986] is allowed for "example" URIs.
Scheme semantics: URIs in the "example" scheme should 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.
Applications/protocols that use this scheme name: An "example" URI
should be used for documentation purposes only. It MUST NOT be
used for any protocol.
Interoperability considerations: None.
Security considerations: None.
Contact: N/A
Author/Change controller: IETF
References: This RFC XXXX.
RFC Editor Note: Replace XXXX with this RFC's reference.
9. IANA Considerations
Previously, the former "URL Scheme" registry was replaced by the
"Uniform Resource Identifier (URI) Schemes" registry. The process
was based on [RFC5226] "Expert Review" with an initial (optional)
mailing list review.
Thaler, et al. Expires August 18, 2014 [Page 14]
Internet-Draft New URI Schemes February 2014
The updated template has an additional field for the status of the
scheme, and the procedures for entering new name schemes have been
augmented. Section 7 establishes the process for new scheme
registration.
IANA is requested to do the following:
o Update the URI Schemes registry to point to this document.
o Combine the "Permanent URI Schemes", "Provisional URI Schemes",
and "Historical URI Schemes" sub-registries into a single common
registry with an additional "Status" column containing the status
(Permanent, Provisional, Historical, or Pending Review).
o Add the "example" URI scheme to the registry (see the template
above for registration).
10. Security Considerations
All registered values are expected to contain accurate security
consideration sections; 'permanent' registered scheme names are
expected to contain complete definitions.
Information concerning possible security vulnerabilities of a
protocol may change over time. Consequently, claims as to the
security properties of a registered scheme may change as well. As
new vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing documentation, so
that users are not misled as to the true security properties of a
registered scheme.
11. Acknowledgements
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
Thaler, et al. Expires August 18, 2014 [Page 15]
Internet-Draft New URI Schemes February 2014
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,
March 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
12.2. Informative References
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC
4395, February 2006.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
Recommendations for Internationalized Domain Names
(IDNs)", RFC 4690, September 2006.
Thaler, et al. Expires August 18, 2014 [Page 16]
Internet-Draft New URI Schemes February 2014
[W3CWebArch]
W3C Technical Architecture Group, "Architecture of the
World Wide Web, Volume One", December 2004,
<http://www.w3.org/TR/webarch/>.
Appendix A. Changes Since RFC 4395
1. Combined the Historical, Permanent, and Provisional URI Schemes
registries into one registry with a status column. This is done
to make it easier to prevent duplicates and see existing
conventions.
2. Clarified that a "URI scheme name" and an "IRI scheme name" are
the same thing and thus use the same IANA registry.
3. Clarified that mailing list review is not required for
Provisional registrations.
4. Added the "example:" URI scheme.
5. Added text about when to use Provisional registration.
6. Updated convention for Private scheme prefix to use "." instead
of "-" between domain name labels, to reduce chance of collision.
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
Thaler, et al. Expires August 18, 2014 [Page 17]
Internet-Draft New URI Schemes February 2014
Ted Hardie
Google
Phone: +1 408 628 5864
Email: ted.ietf@gmail.com
Larry Masinter
Adobe
345 Park Ave.
San Jose, CA 95110
US
Phone: +1 408 536 3024
Email: masinter@adobe.com
URI: http://larry.masinter.net
Thaler, et al. Expires August 18, 2014 [Page 18]
