WDIFF

draft-hansen-2717bis-2718bis-uri-guidelines-00.txt --> draft-hansen-2717bis-2718bis-uri-guidelines-01.txt

Network Working Group T. Hansen
Internet-Draft AT&T Laboratories
Expires: April 15, 2005
Updates: 2717,2718 (if approved) T. Hardie
Expires: June 8, 2005 Qualcomm, Inc.
L. Masinter
Adobe Systems
October 15,
December 8, 2004

Guidelines and Registration Procedures for new URI Schemes
draft-hansen-2717bis-2718bis-uri-guidelines-00.txt
draft-hansen-2717bis-2718bis-uri-guidelines-01.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, June 8, 2005.

Abstract

This document provides guidelines and recommendations for the
definition of new URI schemes, and a mechanism to register those URI
schemes. The registration requirements have been simplified by
providing for provisional registrations that need no technical review

Hansen, et al. Expires April 15, June 8, 2005 [Page 1]

Internet-Draft New URI Schemes October December 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. may share names with existing scheme names.

Please send comments to uri@w3.org. uri@w3.org [10].

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
2. Guidelines for new URI schemes . . . . . . . . . . . . . . . . 5 4
2.1 Important Considerations Demonstratable, new, long-lived utility . . . . . . . . . 4
2.2 Syntactic compatibility . . . . . . . . . 5
2.1.1 non-Locator schemes . . . . . . . . 4
2.3 Well-Defined . . . . . . . . . 5
2.1.2 Demonstratable, new, long-lived utility . . . . . . . 5
2.1.3 Syntactic compatibility . . . . . . . 4
2.4 Definition of operations . . . . . . . . 5
2.1.4 Avoid improper use of "//" following "<scheme>:" . . . 6
2.1.5 Compatibility with relative URIs . . . . . . 5
2.5 Character encoding . . . . . 6
2.2 Is the scheme well defined? . . . . . . . . . . . . . . . 6
2.2.1
2.6 Clear mapping from other name spaces security considerations . . . . . . . . . 6
2.2.2 URI schemes associated with network protocols . . . . 7
2.2.3 Definition of non-protocol URI schemes . 6
2.7 Scheme Name considerations . . . . . . . 7
2.2.4 Definition of URI schemes not associated with data
resources . . . . . . . . . 6
3. URI Scheme Registration Procedure . . . . . . . . . . . . . . 7
2.2.5 Character encoding
3.1 General . . . . . . . . . . . . . . . . . . 7
2.2.6 Definition of operations . . . . . . . 7
3.2 Provisional URI Scheme Considerations . . . . . . . . 8
2.3 Demonstrated utility . . 8
3.3 Registration Procedures . . . . . . . . . . . . . . . . . 8
2.3.1 Proxy into HTTP/HTML .
3.4 Change Control . . . . . . . . . . . . . . . . 8
2.4 Are there security considerations? . . . . . . 9
3.5 New URI Scheme Registration Template . . . . . . 9
2.5 Does it start with UR? . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . 9
2.6 Non-considerations . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . 9
2.6.1 Are all objects accessible? . . . . . . . 11
6. Acknowledgements . . . . . . 9
3. URI Scheme Name Registration . . . . . . . . . . . . . . . . . 10
3.1 General 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 The Permanent URI Scheme Name Status . 12
7.1 Normative References . . . . . . . . 10
3.1.2 The Provisional URI Scheme Name Status . . . . . . . . 10
3.2 Requirements for Scheme Name Registration . . . . 12
7.2 Informative References . . . . 10
3.2.1 General Requirements . . . . . . . . . . . . . . . 12
Authors' Addresses . . 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 . . . . .
Intellectual Property and Copyright Statements . . . . . . . . 14
3.5 New URI Scheme Registration Template . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16

Hansen, et al. Expires April 15, June 8, 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 December 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 both RFCs 2717 [2] and 2718 [3].

The original terminology for the URI protocol element attempted to
draw a distinction between 'locators': 'locators' -- identifiers used for
accessing resources available on the Internet, and 'names': '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: has been difficult to draw: 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], identifiers, 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 proposed that additional registration
trees to might be approved by the IESG, although however, no such registration
trees have been approved.

This document eliminates the RFC 2717's distinction between different
'trees' for URI schemes, and schemes; instead establishes there is 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 schemes. Other scheme
names may also be registered provisionally or without necessarily
passing the any review process or criteria. Its The intent of the registry
is to:
o provide a low barrier for provisional registrations of URI scheme
names
o provide a central point of discovery for established URI scheme
names, and easy location of their defining documents;
o discourage, but not prevent, multiple definitions of URI scheme
names for different purposes;

Hansen, et al. Expires April 15, June 8, 2005 [Page 4] 3]

Internet-Draft New URI Schemes October December 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 gives some considerations for when defining new URI scheme
definitions. It is schemes.
These are useful for all URI definitions, whether standards
track schemes (whether or not, to follow these guidelines. The review process for not standards track);
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

2.1 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

2.2 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. syntax.

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

If there 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 strong reason 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 scheme to 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 RFC XXXX
syntax, the new scheme starting with definition should follow the letters "U" and "R", in particular syntax of other
previously registered schemes, if it
attaches any possible.

Avoid improper use of the meanings "uniform", "universal" or "unifying" to "//". The use of double slashes in the first letter,
part of a URI is going to cause intense debate, and generate much
heat (but maybe little light).

Any such proposal should either make sure not simply an artistic indicator that there what follows
is a large
consensus behind it that it will be URI: Double slashes are used ONLY when the only scheme syntax of its type, or
pick another name.

2.6 Non-considerations

Some issues 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 are often raised but are not relevant to new what follows is the top hierarchical element for a
naming authority. (See section ???? of RFC XXXX for more details.)
URI schemes include the following.

2.6.1 Are all objects accessible?

Can all objects that do not contain a conformant hierarchical structure
in their <scheme-specific-part> should not use double slashes
following the world "<scheme>:" string.

2.3 Well-Defined

While URIs may or may not be useful as locators in practice, a URI
scheme definition itself should be clear as to how it is expected to

Hansen, et al. Expires June 8, 2005 [Page 4]

Internet-Draft New URI Schemes December 2004

function. Schemes that are validly not intended to be used as locators
should still describe how the resource indicated can be identified by
software that obtains a scheme
be accessed by any UA implementing it?

Sometimes URI of that scheme.

For schemes that function as locators, it is important that the answer will
mechanism of resource location be yes and sometimes no; often it will
depend clearly defined. This might mean
different things depending 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. nature of the URI Scheme Name Registration

3.1 General scheme.

In order many cases, new URI schemes are defined as ways to increase the efficiency translate other
protocols and flexibility name spaces into the general framework of URIs. For
example, the "ftp" 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 translates from the overall
registration procedure to accommodate FTP protocol, while
the different natural
requirements for "mid" URI schemes. For example, a scheme that will translates from the Message-ID field of
messages. For such schemes, the description of the mapping must be
recommended for wide support and implementation by
complete, must describe how characters get encoded or not in URIs,
must describe exactly how all legal values of the Internet
community requires a more complete review than a scheme intended to base standard can
be used for resources represented using the URI scheme, and exactly which modifiers,
alternate forms and other artifacts from the base standards are
included or not included. These requirements are elaborated below.

In some cases, URI schemes do not have particular network protocols
associated with proprietary software.

The first step in registering them, because their use as a new URI scheme name locator is limited to determine
which status the scheme should be registered with. Determination of
contexts where the proper category access method is based on understood. This is the case,
for example, with the "cid" and "mid" URI schemes. For these URI
schemes, the specification should describe the intended use for notation of the new scheme
scheme, the contexts of use, and a complete mapping of the desired syntax for locator
from its source.

2.4 Definition of operations

In addition to the scheme name.

There are two statuses definition of how a URI scheme name registration defined in
this document: permanent and provisional.

3.1.1 The Permanent URI Scheme Name Status

The permanent identifies a resource, a
URI scheme name status is intended for URI schemes definition should also define, if applicable, the set of
general interest to
operations that may be performed on a resource using the Internet community. URI as its
identifier. The status exists basis for
URI schemes that require a substantive review and approval process.
It this model is expected that applicability statements for particular
applications will HTTP; a HTTP resource can be published from time to time that recommend
implementation of,
operated on by GET, POST, PUT and support for, URI schemes that have proven
particularly useful in those contexts.

3.1.2 The Provisional URI Scheme Name Status a number of other operations
available through the HTTP protocol. The Provisional URI scheme name category is intended for any URI scheme proposed by any developer, without making any claim about its
usefulness or definition
should describe all well-defined operations on the quality of its definition. These URI scheme names identifier,
and what they are intended for private or experimental use.

3.2 Requirements for Scheme Name Registration

3.2.1 General Requirements

All new supposed to do.

Some URI schemes, regardless schemes (for example, "telnet") provide location information
for hooking onto bi-directional data streams, and don't fit the
"infoaccess" paradigm of registration status, MUST conform most URIs very well; this should be
documented.

NOTE: It is perfectly valid to the generic syntax say that "no operation apart from GET
is defined for URIs as specified in RFC XXXX. 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.

Hansen, et al. Expires April 15, June 8, 2005 [Page 10] 5]

Internet-Draft New URI Schemes October December 2004

3.2.2 Permanent

2.5 Character encoding

When describing URI Scheme Names

Permanent registration schemes in which (some of) the elements of a the
URI scheme requires publication 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 syntax to do otherwise, translating character sequences into UTF-8
(RFC 2279 [4]) and semantics in either an Informational or
Standards Track RFC. In general, then subsequently using the creation %HH encoding for
unsafe octets is recommended.

2.6 Clear security considerations

Definitions of a new permanent URI
scheme requires a Standards Track RFC. An Informational RFC may schemes should be
employed accompanied by a clear analysis
of the security implications for registration only in systems that use 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 scheme.
o Does the Internet Architecture; user need to be warned that such a thing is happening
without an explicit request (GET for the IESG shall have broad discretion in determining whether source of an
Informational RFC is suitable in any given case, and may either
recommend changes IMG tag, for
instance)?
o Is it possible to such document prior fake URIs of this type that point to publication, or reject it different
things in a dangerous way?
o Are there mechanisms for publication. An Informational RFC purporting identifying the requester that can be
used or need to describe a URI
scheme shall not be published without IESG approval. This is used with this mechanism (the From: field in a
departure from practice
mailto: URI, or the Kerberos login required for Informational RFCs as set forth AFS access in RFC
2026 [7], for the purpose of ensuring that the registration of URI
schemes shall serve the best interests of
AFS: URI, for instance)?
o Does the Internet community.

The NAMES of permanent URI name schemes MUST NOT mechanism 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 passwords or other security issues inherent information
that are passed inside the referring document in the new URI scheme is
REQUIRED. (This is clear (as in accordance with
the basic requirements "ftp" URI, for all
IETF protocols.) Permanent instance)?
o 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. (e.g., by layering or tunneling).

The "owner" of a permanet

2.7 Scheme Name considerations

URI scheme name is assumed to names should be the IETF
itself. Modification short, but also sufficiently descriptive
and distinguished to avoid problems.

Avoid trademark names or alteration of other symbols that might have problems with
the specification requires 'ownership' or rights to use the
same level of processing (e.g. Informational name in Internet protocols.

Avoid using names that are either very general purpose or Standards Track RFC)
as used for associated
in the initial registration. Schemes originally defined via
an Informational RFC may, however, be replaced community 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 some other body.

The main requirements for application or protocol.

Organizations that desire a provisional private name space for URI scheme names
are that it SHOULD
have encouraged to use a citable specification, and there MUST NOT be prefix based on their domain name, expressed
in reverse order. For example, a corresponding
entry (with the same URI scheme name) name of com-example-info
might be registered by the vendor that owns the example.com domain
name.

Any scheme starting with a permanent status. the letters "U" and "R", in particular if it

Hansen, et al. Expires April 15, June 8, 2005 [Page 11] 6]

Internet-Draft New URI Schemes October December 2004

The specification SHOULD indicate an email address for sending
technical comments and discussion

attaches any of the proposed URI scheme.

Provisional URI name schemes MUST conform meanings "uniform", "universal" or "unifying" 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 first letter, is or going to cause intense debate, and generate much
heat (but maybe little light). Any such proposal should either make
sure that there is not
performed, all descriptions of security issues must be as accurate as
possible. In particular, a statement large consensus behind it that there are "no security
issues associated with this scheme" must not it will be confused with "the
security issues associates with this scheme have not been assessed"
or "the security issues associated with this the
only scheme cannot be
predicted because of <reason>".

There is absolutely no requirement that provisional URI name schemes
be secure its type, 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 pick another name.

3. URI Scheme Names Registration Procedure

3.1 General

The first step in goals for registering a new permanent URI scheme is Schemes are to
publish an IETF Internet-Draft detailing the syntax and semantics avoid (when possible)
duplicate use of the proposed scheme. The draft must, minimally, address all same URI scheme name for different purposes, to
allow implementors of the
items covered by the template provided in Section 3.5 software that processes URIs to find
appropriate information about URI schemes, and to encourage and
facilitate technical review of this
document. There must be an IANA considerations section in URI scheme definitions before
corresponding software is deployed.

To allow others to determine the
Internet-Draft calling for registration results of technical review, the URI
scheme and
referencing information as required by the registration template
within the same document.

After all issues raised during process has two outcomes for URI scheme
proposals: a 'provisional' status for URI schemes whose definitions
have not been reviewed or were not accepted by the review period of no less than 4
weeks process,
and a 'permanent' status for those schemes that have been addressed, submit accepted by
IETF review. Review is based on general agreement that the draft to URI
scheme definition proposed meets the IESG requirements in Section 2.

Provisional status is useful for review. registering legacy URI schemes that
have already been widely deployed without registration, and for which
review at this time would be inappropriate. Provisional status may
also be useful for private or experimental use.

Permanent status is intended for use by IETF standards-track
protocols. The IESG will status requires a substantive review the proposed new scheme and either refer the
scheme approval
process.

A person wishing to register a working group (existing or new) or directly present the URI scheme to should first determine
whether the IESG scheme is appropriate for 'permanent' status, meets the
guidelines, and if 'permanent' status is desirable.

Provisional registration of a last call. In URI scheme merely requires providing
IANA with the former case, information in the URI scheme registration template
(Section 3.5). It is useful to also provide this information in an
Internet Draft, especially if the working
group scheme is responsible intended for submitting ultimate
registration as a final version 'permanent' URI scheme.

Permanent registration of the draft to
the IESG for approval at such time as it has received adequate a URI scheme requires IETF review and deliberation. IESG
approval. In many cases, permanent registration involves the
promotion of an existing provisional registration. In general, the
creation of a new permanent URI scheme requires a Standards Track

Hansen, et al. Expires April 15, June 8, 2005 [Page 12] 7]

Internet-Draft New URI Schemes October December 2004

Registration of the

RFC. In some cases, a URI scheme is then processed as part of the registration in an Informational
RFC
publication process.

3.3.2 may be approved by the IESG for 'permanent' URI registration.

3.2 Provisional URI Scheme Names Considerations

Registration of a provisional URI scheme names may be submitted by one does not require or imply
any kind of endorsement by the following methods:
o An IETF, IANA considerations section in a defining RFC, calling or any other body.

The main requirement for
registration of the a provisional URI scheme and referencing information as
required by the registration template within is that there MUST
NOT already be a corresponding permanent entry with the same document.
Registration URI
scheme name. In cases where separate communities have already
established differing uses of the same URI scheme name for different
purposes, it is then processed as part of the
RFC publication process.
o Send a copy of the template possible to the designated email discussion
list [????]. Allow a reasonable period - at least 2 weeks - have two or more provisional
registrations for
discussion and comments, then send the template to IANA at the
designated email address [????]. IANA will publish same URI scheme name.

A provisional registration MUST also identify the template
information if person submitting
the requested name registration, and the SHOULD contain a citable specification document
meet for the criteria noted
URI scheme definition, unless credible reasons for not providing this
are given.

All new provisional URI schemes SHOULD follow the Guidelines for URI
Schemes, set forth in Section 3.2.3, unless 2.

In particular, an analysis of the IESG security issues inherent in the new
URI scheme is encouraged. Regardless of what security analysis is or their
designated expert have requested that it
is not performed, all descriptions of security issues must be published (see
Section 3.3.3). IESG's designated expert should confirm to IANA as
accurate as possible. In particular, a statement that the registration criteria there are "no
security issues associated with this scheme" must not be confused
with "the security issues associates with this scheme have not been satisfied.

When a new permanent URI
assessed" or "the security issues associated with this scheme name cannot
be predicted because of <reason>". There is recorded, IANA will remove
any corresponding entries (with the same not a requirement that
provisional URI scheme name and
protocol) schemes be secure or completely free from the provisional registry.

Companies and other bodies that desire a private name space for risks,
but all known security risks SHOULD be identified.

Previously unregistered URI
scheme names are encouraged to use a prefix based on their domain
name, expressed schemes discovered in reverse order. For example, a URI scheme name of
com-example-info might use may be
registered by the vendor that owns the
example.com domain name.

3.3.3 Objections to Registration

Listing third parties on behalf of an entry in those who created the provisional repository should not be
lightly refused. An entry MAY be refused if there is some credible
reason URI
scheme.

3.3 Registration Procedures

Someone wishing to believe that such registration will be harmful. In register a URI scheme should:
1. Check 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 URI scheme registry to
harm the Internet technical infrastructure in some way.
o Disreputable see whether or frivolous use of not there is
already an entry for the registration facilities.
o The proposal desired name. If there is sufficiently lacking already a
permanent entry under the name, choose a different URI scheme
name.
2. Prepare a URI scheme registration template, as specified in purpose, or misleading
about its purpose, that it can
Section 3.5. The URI scheme registration template may be held
contained in an Internet Draft, to be a waste of time and
effort.
o Conflict with some current IETF activity. facilitate discussion or if

Hansen, et al. Expires April 15, June 8, 2005 [Page 13] 8]

Internet-Draft New URI Schemes October December 2004

Note that objections or disagreements about technical detail are not,

the URI scheme is intended for permanent status.
3. If desired, send a copy of themselves, considered grounds the template or a pointer to the
Internet Draft (and containing section number) to refuse listing the mailing
list uri-review@ietf.org; participate in the
provisional repository. After all, one discussion and
review of its purposes is to the URI scheme; allow
developers to communicate with a view to combining their ideas,
expertise reasonable period (at least 2
weeks) for discussion and energy to comments.
4. Submit the maximum benefit of registration template (or a pointer to the Internet
community.

Publication in an RFC or other form of Open Standard document (per
RFC 2026 [7],
Draft and containing section 7) is sufficient grounds for publication in the
permanent registry.

To assist number) to IANA in determining whether at iana@iana.org
[11].

Upon receipt of a URI scheme registration request, IANA:
1. Checks the submission for completeness; if sections are missing
or citations are not there is a sustainable
objection to any registration, IESG nominates a designated expert to
liaise with correct, IANA about new registrations. For rejects the most part, registration
request.
2. Checks the
designated expert's role is to confirm to IANA current registry for a 'permanent' entry of that name;
if such a registry exists, IANA rejects the registration request.
3. Adds 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 'provisional' registry.

Registration of a 'permanent' URI scheme name happens through the approval
of publication of an RFC that contains instructions for two different purposes. One registration
in the 'IANA considerations' section of the purposes document. The IETF
review should consider whether the URI scheme meets the guidelines in
Section 2; in addition, permanent registration when there are
multiple provisional registrations for this registry is to help make people aware of what the same scheme name should be
avoided.

In some cases, a new 'permanent' URI scheme names are being used by other entities.

The IESG is will upgrade a previous
'provisional' registration; IANA should remove the final arbiter of any objection. corresponding
entry from the provisional registry, unless the IANA considerations
section specifies otherwise.

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 that 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, June 8, 2005 [Page 14] 9]

Internet-Draft New URI Schemes October December 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
that had been 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.

A URL scheme that has been registered by a third party may be
reassigned to the proper owners of that scheme name.

The IESG may reclassify a provisional URL URI scheme and documented via
an Informational RFC as "historic", if it determines
that the scheme is no longer in use. (This may be done in
conjunction with marking a protocol as "historic".)

IANA MAY may remove any provisional URI scheme entry whose corresponding
specification document is no longer available (e.g., expired
Internet-draft, the
Internet-draft expired, or URI not the URL citation is no longer resolvable).
Anyone may notify IANA of any such cases by sending an email to the designated email address
[????].
iana@iana.org [12]. 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 2
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 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.

Hansen, et al. Expires June 8, 2005 [Page 10]

Internet-Draft New URI Schemes December 2004

Applications and/or protocols which that use this URI scheme name.
Including references to documentation which that 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 that 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 any underlying protocol
(if the scheme is tunneled over another protocol).
Security considerations.
Relevant publications. For the case of provisional URI scheme
entries, this may be the URL of a document more completely
describing the scheme.
Contact. Person & email address to contact for further information.
Author/Change controller.
Application/protocol. Applications and/or protocols which that 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'.

This document updates the procedures to be followed by IANA when
receiving a URI scheme name registration template.

5. Security Considerations

New URI schemes are required expected 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

Hansen, et al. Expires June 8, 2005 [Page 11]

Internet-Draft New URI Schemes December 2004

[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] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers
Identifier (URI): Generic Syntax", ????. October 2004.

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.

URIs

[10] <mailto:uri@w3.org>

[11] <mailto:iana@iana.org>

[12] <mailto:iana@iana.org>

Hansen, et al. Expires June 8, 2005 [Page 12]

Internet-Draft New URI Schemes December 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, June 8, 2005 [Page 18] 13]

Internet-Draft New URI Schemes October December 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 (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, June 8, 2005 [Page 19] 14]

----