Network Working Group T. Hansen
Internet-Draft AT&T Laboratories
Expires: April 15, 2005 T. Hardie
Qualcomm, Inc.
L. Masinter
Adobe Systems
October 15, 2004
Guidelines and Registration Procedures for new URI Schemes
draft-hansen-2717bis-2718bis-uri-guidelines-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document provides guidelines and recommendations for the
definition of new URI schemes, and a mechanism to register those URI
schemes.
Hansen, et al. Expires April 15, 2005 [Page 1]
Internet-Draft New URI Schemes October 2004
This is a first draft attempt to capture the sense of direction for
updates to RFC 2717 and RFC 2718. These changes were discussed at
the August 26, 2004 URIREV4 BOF: see
http://lists.w3.org/Archives/Public/uri/2004Aug/0007.html for the
minutes. Please send comments to uri@w3.org.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Guidelines for new URI schemes . . . . . . . . . . . . . . . . 5
2.1 Important Considerations . . . . . . . . . . . . . . . . . 5
2.1.1 non-Locator schemes . . . . . . . . . . . . . . . . . 5
2.1.2 Demonstratable, new, long-lived utility . . . . . . . 5
2.1.3 Syntactic compatibility . . . . . . . . . . . . . . . 5
2.1.4 Avoid improper use of "//" following "<scheme>:" . . . 6
2.1.5 Compatibility with relative URIs . . . . . . . . . . . 6
2.2 Is the scheme well defined? . . . . . . . . . . . . . . . 6
2.2.1 Clear mapping from other name spaces . . . . . . . . . 6
2.2.2 URI schemes associated with network protocols . . . . 7
2.2.3 Definition of non-protocol URI schemes . . . . . . . . 7
2.2.4 Definition of URI schemes not associated with data
resources . . . . . . . . . . . . . . . . . . . . . . 7
2.2.5 Character encoding . . . . . . . . . . . . . . . . . . 7
2.2.6 Definition of operations . . . . . . . . . . . . . . . 8
2.3 Demonstrated utility . . . . . . . . . . . . . . . . . . . 8
2.3.1 Proxy into HTTP/HTML . . . . . . . . . . . . . . . . . 8
2.4 Are there security considerations? . . . . . . . . . . . . 9
2.5 Does it start with UR? . . . . . . . . . . . . . . . . . . 9
2.6 Non-considerations . . . . . . . . . . . . . . . . . . . . 9
2.6.1 Are all objects accessible? . . . . . . . . . . . . . 9
3. URI Scheme Name Registration . . . . . . . . . . . . . . . . . 10
3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 The Permanent URI Scheme Name Status . . . . . . . . . 10
3.1.2 The Provisional URI Scheme Name Status . . . . . . . . 10
3.2 Requirements for Scheme Name Registration . . . . . . . . 10
3.2.1 General Requirements . . . . . . . . . . . . . . . . . 10
3.2.2 Permanent URI Scheme Names . . . . . . . . . . . . . . 11
3.2.3 Provisional URI Scheme Names . . . . . . . . . . . . . 11
3.3 Registration Procedures . . . . . . . . . . . . . . . . . 12
3.3.1 Permanent URI Scheme Names . . . . . . . . . . . . . . 12
3.3.2 Provisional URI Scheme Names . . . . . . . . . . . . . 13
3.3.3 Objections to Registration . . . . . . . . . . . . . . 13
3.4 Change Control . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 Permanent URI Scheme Names . . . . . . . . . . . . . . 14
3.4.2 Provisional URI Scheme Names . . . . . . . . . . . . . 14
3.5 New URI Scheme Registration Template . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Hansen, et al. Expires April 15, 2005 [Page 2]
Internet-Draft New URI Schemes October 2004
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
7.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19
Hansen, et al. Expires April 15, 2005 [Page 3]
Internet-Draft New URI Schemes October 2004
1. Introduction
A Uniform Resource Identifier (URI) is a compact string
representation for identifying resources. RFC XXXX [6] defines the
general syntax of URIs. This document provides guidelines for the
definition of new URI schemes (for consideration by those who are
defining and registering or evaluating those definitions), and a
process and mechanism for registering URI schemes. This document
replaces RFCs 2717 [2] and 2718 [3].
The original terminology for the URI protocol element attempted to
draw a distinction between 'locators': identifiers used for accessing
resources available on the Internet, and 'names': identifiers used
for naming possibly abstract resources, independent of any mechanism
for accessing them. The intent was to use the designation "URL"
(Uniform Resource Locator) for those identifiers that were locators,
and "URN" (Uniform Resource Name) for those identifiers that were
names. In practice, the line between 'locator' and 'name' cannot be
drawn precisely: locators can be used as names, and names can be used
as locators.
As a result, recent documents have used the term "URI" for all
resource identifiers following the definition of RFC XXXX [6],
avoiding the term "URL", and reserving the term "URN" explicitly for
those URIs using the "urn" scheme name (RFC 2141 [1]). URNs remain a
distinct class of URIs because of the requirements set out in RFC
3406 [8]; this document's procedures do not update or supersede the
procedures set out in RFC 3406.
RFC 2717 defined a set of registration trees in which URI schemes
could be registered, one of which was called the IETF Tree, to be
managed by IANA. The registration process is needed to ensure that
the names of all such new schemes are guaranteed not to collide.
Further, the registration process ensures that URI schemes intended
for wide spread, public use are developed in an orderly,
well-specified, and public manner.
RFC 2717 also allowed additional registration trees to be approved by
the IESG, although no such registration trees have been approved.
This document eliminates the distinction between different 'trees'
for URI schemes, and instead establishes a single namespace for
registered values. Within that namespace, there are values that are
approved as meeting a set of criteria for URI schemes; other scheme
names may also be registered provisionally or without necessarily
passing the review process or criteria. Its intent is to:
o provide a central point of discovery for established URI scheme
names, and easy location of their defining documents;
Hansen, et al. Expires April 15, 2005 [Page 4]
Internet-Draft New URI Schemes October 2004
o discourage multiple definitions of URI scheme names for different
purposes;
o and to help those proposing new URI scheme names to discern
established trends and conventions, and to avoid names that might
be confused with existing ones.
2. Guidelines for new URI schemes
2.1 Important Considerations
This section lists important considerations for URI scheme
definitions. It is useful for all URI definitions, whether standards
track or not, to follow these guidelines. The review process for
IETF standards track URI schemes may require review against these
criteria.
2.1.1 non-Locator schemes
While it is acknowledged that URIs may or may not be useful as
locators, it is important that the URI scheme definition itself be
clear as to how it is expected to function. Schemes that are not
intended to be used as locators must describe how the resource
identified should be interpreted by software that obtains a URI of
that scheme.
2.1.2 Demonstratable, new, long-lived utility
Because URI schemes are a single, global namespace, the unbounded
registration of new schemes is harmful to the Internet community.
For this reason, new URI schemes should have clear utility to the
broad Internet community, beyond that available with already
registered URI schemes.
2.1.3 Syntactic compatibility
RFC XXXX [6] defines a generic syntax for URI schemes with
hierarchical components and a naming authority. New URI schemes
should follow this syntax if appropriate. The generic handling of
relative URIs depends on this.
URI schemes that are not intended for use with relative URIs should
avoid use of the forward slash "/" character, which is used for
hierarchical delimiters.
In some circumstances, when a URI scheme does not fit into the
existing RFC XXXX syntax, the new scheme definition should follow the
syntax of other previously registered schemes, if possible.
Hansen, et al. Expires April 15, 2005 [Page 5]
Internet-Draft New URI Schemes October 2004
2.1.4 Avoid improper use of "//" following "<scheme>:"
The use of double slashes as the first component of the
<scheme-specific-part> of a URI is not simply an artistic indicator
that what follows is a URI: Double slashes are used ONLY when the
syntax of the URI's <scheme-specific-part> contains a hierarchical
structure as described in RFC XXXX. In URIs from such schemes, the
use of double slashes indicates that what follows is the top
hierarchical element for a naming authority. (See section ???? of
RFC XXXX for more details.) URI schemes which do not contain a
conformant hierarchical structure in their <scheme-specific-part>
should not use double slashes following the "<scheme>:" string.
2.1.5 Compatibility with relative URIs
URI schemes should use the generic URI syntax if they are intended to
be used with relative URIs. A description of the allowed relative
forms should be included in the scheme's definition. Many
applications use relative URIs extensively. Specifically,
o Can the scheme be parsed according to RFC XXXX - for example, if
the tokens "//", "/", ";", or "?" are used, do they have the
meaning given in RFC XXXX?
o Does the scheme make sense to use it in relative URIs like those
RFC XXXX specifies?
o If the scheme syntax is designed to be broken into pieces, does
the documentation for the scheme's syntax specify what those
pieces are, why it should be broken in this way, and why the
breaks aren't where RFC XXXX says that they usually should be?
o If the scheme has a hierarchy, does it go left-to-right and with
slash separators like RFC XXXX?
2.2 Is the scheme well defined?
It is important that the semantics of the "resource" that a URI
"locates" be well defined. This might mean different things
depending on the nature of the URI scheme.
2.2.1 Clear mapping from other name spaces
In many cases, new URI schemes are defined as ways to translate other
protocols and name spaces into the general framework of URIs. The
"ftp" URI scheme translates from the FTP protocol, while the "mid"
URI scheme translates from the Message-ID field of messages.
In either case, the description of the mapping must be complete, must
describe how characters get encoded or not in URIs, must describe
exactly how all legal values of the base standard can be represented
using the URI scheme, and exactly which modifiers, alternate forms
Hansen, et al. Expires April 15, 2005 [Page 6]
Internet-Draft New URI Schemes October 2004
and other artifacts from the base standards are included or not
included. These requirements are elaborated below.
2.2.2 URI schemes associated with network protocols
Most new URI schemes are associated with network resources that have
one or several network protocols that can access them. The 'ftp',
'news', and 'http' schemes are of this nature. For such schemes, the
specification should completely describe how URIs are translated into
protocol actions in sufficient detail to make the access of the
network resource unambiguous. If an implementation of the URI scheme
requires some configuration, the configuration elements must be
clearly identified. (For example, the 'news' scheme, if implemented
using NTTP, requires configuration of the NTTP server.)
2.2.3 Definition of non-protocol URI schemes
In some cases, URI schemes do not have particular network protocols
associated with them, because their use is limited to contexts where
the access method is understood. This is the case, for example, with
the "cid" and "mid" URI schemes. For these URI schemes, the
specification should describe the notation of the scheme and a
complete mapping of the locator from its source.
2.2.4 Definition of URI schemes not associated with data resources
Most URI schemes locate Internet resources that correspond to data
objects that can be retrieved or modified. This is the case with
"ftp" and "http", for example. However, some URI schemes do not; for
example, the "mailto" URI scheme corresponds to an Internet mail
address.
If a new URI scheme does not locate resources that are data objects,
the properties of names in the new space must be clearly defined.
2.2.5 Character encoding
When describing URI schemes in which (some of) the elements of the
URI are actually representations of sequences of characters, care
should be taken not to introduce unnecessary variety in the ways in
which characters are encoded into octets and then into URI
characters. Unless there is some compelling reason for a particular
scheme to do otherwise, translating character sequences into UTF-8
(RFC 2279 [4]) and then subsequently using the %HH encoding for
unsafe octets is recommended.
Hansen, et al. Expires April 15, 2005 [Page 7]
Internet-Draft New URI Schemes October 2004
2.2.6 Definition of operations
In some contexts (for example, HTML forms) it is possible to specify
any one of a list of operations to be performed on a specific URI.
(Outside forms, it is generally assumed to be something you GET.)
The URI scheme definition should describe all well-defined operations
on the URI identifier, and what they are supposed to do.
Some URI schemes (for example, "telnet") provide location information
for hooking onto bi-directional data streams, and don't fit the
"infoaccess" paradigm of most URIs very well; this 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 type is described.
2.3 Demonstrated utility
URI schemes should have demonstrated utility. New URI schemes are
expensive things to support. Often they require special code in
browsers, proxies, and/or servers. Having a lot of ways to say the
same thing needless complicates these programs without adding value
to the Internet.
The kinds of things that are useful include:
o Things that cannot be referred to in any other way.
o Things where it is much easier to get at them using this scheme
than (for instance) a proxy gateway.
2.3.1 Proxy into HTTP/HTML
One way to provide a demonstration of utility is via a gateway which
provides objects in the new scheme for clients using an existing
protocol. It is much easier to deploy gateways to a new service than
it is to deploy browsers that understand the new URI object.
Things to look for when thinking about a proxy are:
o Is there a single global resolution mechanism whereby any proxy
can find the referenced object?
o If not, is there a way in which the user can find any object of
this type, and "run his own proxy"?
o Are the operations mappable one-to-one (or possibly using
modifiers) to HTTP operations?
o Is the type of returned objects well defined?
Hansen, et al. Expires April 15, 2005 [Page 8]
Internet-Draft New URI Schemes October 2004
* as MIME content-types?
* as something that can be translated to HTML?
o Is there running code for a proxy?
2.4 Are there security considerations?
Above and beyond the security considerations of the base mechanism a
scheme builds upon, one must think of things that can happen in the
normal course of URI usage.
In particular:
o Does the user need to be warned that such a thing is happening
without an explicit request (GET for the source of an IMG tag, for
instance)? This has implications for the design of a proxy
gateway, of course.
o Is it possible to fake URIs of this type that point to different
things in a dangerous way?
o Are there mechanisms for identifying the requester that can be
used or need to be used with this mechanism (the From: field in a
mailto: URI, or the Kerberos login required for AFS access in the
AFS: URI, for instance)?
o Does the mechanism contain passwords or other security information
that are passed inside the referring document in the clear (as in
the "ftp" URI, for instance)?
2.5 Does it start with UR?
Any scheme starting with the letters "U" and "R", in particular if it
attaches any of the meanings "uniform", "universal" or "unifying" to
the first letter, is going to cause intense debate, and generate much
heat (but maybe little light).
Any such proposal should either make sure that there is a large
consensus behind it that it will be the only scheme of its type, or
pick another name.
2.6 Non-considerations
Some issues that are often raised but are not relevant to new URI
schemes include the following.
2.6.1 Are all objects accessible?
Can all objects in the world that are validly identified by a scheme
be accessed by any UA implementing it?
Sometimes the answer will be yes and sometimes no; often it will
depend on factors (like firewalls or client configuration) not
Hansen, et al. Expires April 15, 2005 [Page 9]
Internet-Draft New URI Schemes October 2004
directly related to the scheme itself.
3. URI Scheme Name Registration
3.1 General
In order to increase the efficiency and flexibility of the URI scheme
name registration process, the need is recognized for multiple
registration statuses. The registration requirements and specific
registration procedures for each status differ, allowing the overall
registration procedure to accommodate the different natural
requirements for URI schemes. For example, a scheme that will be
recommended for wide support and implementation by the Internet
community requires a more complete review than a scheme intended to
be used for resources associated with proprietary software.
The first step in registering a new URI scheme name is to determine
which status the scheme should be registered with. Determination of
the proper category is based on the intended use for the new scheme
and the desired syntax for the scheme name.
There are two statuses of URI scheme name registration defined in
this document: permanent and provisional.
3.1.1 The Permanent URI Scheme Name Status
The permanent URI scheme name status is intended for URI schemes of
general interest to the Internet community. The status exists for
URI schemes that require a substantive review and approval process.
It is expected that applicability statements for particular
applications will be published from time to time that recommend
implementation of, and support for, URI schemes that have proven
particularly useful in those contexts.
3.1.2 The Provisional URI Scheme Name Status
The Provisional URI scheme name category is intended for any URI
scheme proposed by any developer, without making any claim about its
usefulness or the quality of its definition. These URI scheme names
are intended for private or experimental use.
3.2 Requirements for Scheme Name Registration
3.2.1 General Requirements
All new URI schemes, regardless of registration status, MUST conform
to the generic syntax for URIs as specified in RFC XXXX.
Hansen, et al. Expires April 15, 2005 [Page 10]
Internet-Draft New URI Schemes October 2004
3.2.2 Permanent URI Scheme Names
Permanent registration of a URI scheme requires publication of the
URI scheme syntax and semantics in either an Informational or
Standards Track RFC. In general, the creation of a new permanent URI
scheme requires a Standards Track RFC. An Informational RFC may be
employed for registration only in the case of a URI scheme which is
already in wide usage and meets other standards set forth in Section
2, such as "demonstrated utility" within the Internet Architecture;
the IESG shall have broad discretion in determining whether an
Informational RFC is suitable in any given case, and may either
recommend changes to such document prior to publication, or reject it
for publication. An Informational RFC purporting to describe a URI
scheme shall not be published without IESG approval. This is a
departure from practice for Informational RFCs as set forth in RFC
2026 [7], for the purpose of ensuring that the registration of URI
schemes shall serve the best interests of the Internet community.
The NAMES of permanent URI name schemes MUST NOT contain the dash
(also known as the hyphen and minus sign) character ('-') USASCII
value 2Dh. Use of this character can cause confusion with private
URI name schemes.
An analysis of the security issues inherent in the new URI scheme is
REQUIRED. (This is in accordance with the basic requirements for all
IETF protocols.) Permanent URI name schemes should not introduce
additional security risks into the Internet Architecture. For
example, URIs should not embed information which should remain
confidential, such as passwords, nor should new schemes subvert the
security of existing schemes or protocols (i.e. by layering or
tunneling).
The "owner" of a permanet URI scheme name is assumed to be the IETF
itself. Modification or alteration of the specification requires the
same level of processing (e.g. Informational or Standards Track RFC)
as used for the initial registration. Schemes originally defined via
an Informational RFC may, however, be replaced with Standards Track
documents.
3.2.3 Provisional URI Scheme Names
Registration of a provisional URI scheme does not imply any kind of
endorsement by the IETF, IANA or any other body.
The main requirements for a provisional URI scheme are that it SHOULD
have a citable specification, and there MUST NOT be a corresponding
entry (with the same URI scheme name) with a permanent status.
Hansen, et al. Expires April 15, 2005 [Page 11]
Internet-Draft New URI Schemes October 2004
The specification SHOULD indicate an email address for sending
technical comments and discussion of the proposed URI scheme.
Provisional URI name schemes MUST conform to the generic URI syntax,
RFC XXXX. The provisional URI name scheme's defining document MAY
set forth additional syntax and semantics requirements above and
beyond those specified in RFC XXXX.
All new provisional URI schemes SHOULD follow the Guidelines for URI
Schemes, set forth in Section 2.
An analysis of the security issues inherent in the new URI scheme is
encouraged. Regardless of what security analysis is or is not
performed, all descriptions of security issues must be as accurate as
possible. In particular, a statement that there are "no security
issues associated with this scheme" must not be confused with "the
security issues associates with this scheme have not been assessed"
or "the security issues associated with this scheme cannot be
predicted because of <reason>".
There is absolutely no requirement that provisional URI name schemes
be secure or completely free from risks. Nevertheless, the URI name
scheme's defining document must set forth the standard for security
considerations, and in any event all known security risks SHOULD be
identified.
3.3 Registration Procedures
3.3.1 Permanent URI Scheme Names
The first step in registering a new permanent URI scheme is to
publish an IETF Internet-Draft detailing the syntax and semantics of
the proposed scheme. The draft must, minimally, address all of the
items covered by the template provided in Section 3.5 of this
document. There must be an IANA considerations section in the
Internet-Draft calling for registration of the URI scheme and
referencing information as required by the registration template
within the same document.
After all issues raised during a review period of no less than 4
weeks have been addressed, submit the draft to the IESG for review.
The IESG will review the proposed new scheme and either refer the
scheme to a working group (existing or new) or directly present the
scheme to the IESG for a last call. In the former case, the working
group is responsible for submitting a final version of the draft to
the IESG for approval at such time as it has received adequate review
and deliberation.
Hansen, et al. Expires April 15, 2005 [Page 12]
Internet-Draft New URI Schemes October 2004
Registration of the URI scheme is then processed as part of the RFC
publication process.
3.3.2 Provisional URI Scheme Names
Registration of provisional URI scheme names may be submitted by one
of the following methods:
o An IANA considerations section in a defining RFC, calling for
registration of the URI scheme and referencing information as
required by the registration template within the same document.
Registration of the URI scheme is then processed as part of the
RFC publication process.
o Send a copy of the template to the designated email discussion
list [????]. Allow a reasonable period - at least 2 weeks - for
discussion and comments, then send the template to IANA at the
designated email address [????]. IANA will publish the template
information if the requested name and the specification document
meet the criteria noted in Section 3.2.3, unless the IESG or their
designated expert have requested that it not be published (see
Section 3.3.3). IESG's designated expert should confirm to IANA
that the registration criteria have been satisfied.
When a new permanent URI scheme name is recorded, IANA will remove
any corresponding entries (with the same URI scheme name and
protocol) from the provisional registry.
Companies and other bodies that desire a private name space for URI
scheme names are encouraged to use a prefix based on their domain
name, expressed in reverse order. For example, a URI scheme name of
com-example-info might be registered by the vendor that owns the
example.com domain name.
3.3.3 Objections to Registration
Listing of an entry in the provisional repository should not be
lightly refused. An entry MAY be refused if there is some credible
reason to believe that such registration will be harmful. In the
absence of such objection, IANA SHOULD allow any registration that
meets the criteria set out in Section 3.2.2 and Section Section
3.2.3. Some reasonable grounds for refusal might be:
o There is IETF consensus that publication is considered likely to
harm the Internet technical infrastructure in some way.
o Disreputable or frivolous use of the registration facilities.
o The proposal is sufficiently lacking in purpose, or misleading
about its purpose, that it can be held to be a waste of time and
effort.
o Conflict with some current IETF activity.
Hansen, et al. Expires April 15, 2005 [Page 13]
Internet-Draft New URI Schemes October 2004
Note that objections or disagreements about technical detail are not,
of themselves, considered grounds to refuse listing in the
provisional repository. After all, one of its purposes is to allow
developers to communicate with a view to combining their ideas,
expertise and energy to the maximum benefit of the Internet
community.
Publication in an RFC or other form of Open Standard document (per
RFC 2026 [7], section 7) is sufficient grounds for publication in the
permanent registry.
To assist IANA in determining whether or not there is a sustainable
objection to any registration, IESG nominates a designated expert to
liaise with IANA about new registrations. For the most part, the
designated expert's role is to confirm to IANA that the registration
criteria have been satisfied.
The IESG or their designated expert MAY require any change or
commentary to be attached to any registry entry.
Note: It is not an error for two different entities to register the
same provisional URI scheme name for two different purposes. One of
the purposes for this registry is to help make people aware of what
URI scheme names are being used by other entities.
The IESG is the final arbiter of any objection.
3.4 Change Control
3.4.1 Permanent URI Scheme Names
Permanent URI name schemes are "owned" by the IETF itself and may be
changed, as needed, by updating the RFC that describes them. Schemes
described by Standards Track RFC may be replaced with new Standards
Track RFCs. Informational RFCs may be replaced by new Informational
RFCs or Standards Track RFCs.
3.4.2 Provisional URI Scheme Names
Provisional URL schemes that are undocumented may be changed by their
owner at any time without notifying the IETF.
Provisional URL schemes that have been documented by an Informational
RFC, may be changed at any time by the owner. However, an updated
Informational RFC which details the changes made, must be submitted
to the IESG.
The owner of a provisional URL scheme and documented by an
Hansen, et al. Expires April 15, 2005 [Page 14]
Internet-Draft New URI Schemes October 2004
Informational RFC may pass responsibility for the registration to
another person or agency by informing the IESG.
The IESG may reassign responsibility for a provisional URL scheme
registered in an alternative tree and documented by an Informational
RFC. The most common case of this will be to enable changes to be
made to schemes where the scheme name is privately owned, and the
owner of the scheme name has died, moved out of contact or is
otherwise unable to make changes that are important to the community.
The IESG may reclassify a provisional URL scheme and documented via
an Informational RFC as "historic", if it determines that the scheme
is no longer in use.
IANA MAY remove any provisional URI scheme entry whose corresponding
specification document is no longer available (e.g., expired
Internet-draft, or URI not resolvable). Anyone may notify IANA of
any such cases by sending an email to the designated email address
[????]. Before removing an entry for this reason, IANA SHOULD
contact the registered Author/Change controller to determine whether
a replacement for the specification document (consistent with the
requirements of section Section 3.2) is available.
3.5 New URI Scheme Registration Template
The following issues should be addressed when documenting a new URI
scheme:
URI scheme name.
Status. This will be one of 'permanent', 'provisional' or
'historic'.
URI scheme syntax. This should be expressed in a clear and concise
manner. The use of ABNF is encouraged. Please refer to Section
2.1 for guidance on designing and explaining your scheme's syntax.
Character encoding considerations. It is important to identify what
your scheme supports in this regard. It is obvious that for
interoperability, it is best if there is a means to support
character sets beyond USASCII, but especially for private schemes,
this may not be the case.
Intended usage. What sort of resource is being identified? If this
is not a 'resource' type of URI (e.g. mailto:), explain the
action that should be initiated by the consumer of the URI. If
there is a MIME type associated with this resource, please
identify it.
Applications and/or protocols which use this URI scheme name.
Including references to documentation which defines the
applications and/or protocols cited is especially useful.
Hansen, et al. Expires April 15, 2005 [Page 15]
Internet-Draft New URI Schemes October 2004
Interoperability considerations. If you are aware of any details
regarding your scheme which might impact interoperability, please
identify them here. For example: proprietary or uncommon encoding
method; inability to support multibyte character sets;
incompatibility with types or versions of underlying protocol (if
scheme is tunneled over another protocol).
Security considerations.
Relevant publications.
Contact. Person & email address to contact for further information.
Author/Change controller.
Application/protocol. Applications and/or protocols which use this
URI scheme name.
4. IANA Considerations
This document updates the Uniform Resource Identifier (URI) Schemes
registration table. The template has an additional field for the
status of the URI name scheme, and the procedures for entering new
name schemes have been augmented. All existing URI name schemes in
the existing table should be given the status of 'permanent'.
5. Security Considerations
New URI schemes are required to address all security considerations
in their definitions.
Information that creates or updates a registration needs to be
authenticated.
Information concerning possible security vulnerabilities of a
protocol may change over time. Consequently, claims as to the
security properties of a registered URI scheme may change as well.
As new vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing documentation, so
that users are not misled as to the true security properties of a
registered URI scheme.
6. Acknowledgements
Some of the text for the provisional registration status is based on
[9].
7. References
7.1 Normative References
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
Hansen, et al. Expires April 15, 2005 [Page 16]
Internet-Draft New URI Schemes October 2004
[2] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
[3] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6] "Uniform Resource Identifiers (URI): Generic Syntax", ????.
7.2 Informative References
[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[8] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
[9] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures
for Message Header Fields", BCP 90, RFC 3864, September 2004.
Authors' Addresses
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
EMail: tony+urireg@maillennium.att.com
Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Suite 200
Campbell, CA
USA
EMail: hardie@qualcomm.com
Hansen, et al. Expires April 15, 2005 [Page 17]
Internet-Draft New URI Schemes October 2004
Larry Masinter
Adobe Systems
345 Park Ave
San Jose, CA 95110
US
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Hansen, et al. Expires April 15, 2005 [Page 18]
Internet-Draft New URI Schemes October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hansen, et al. Expires April 15, 2005 [Page 19]
