WDIFF

draft-hansen-2717bis-2718bis-uri-guidelines-02.txt --> draft-hansen-2717bis-2718bis-uri-guidelines-03.txt

Network Working Group T. Hansen
Internet-Draft AT&T Laboratories
Obsoletes: 2717,2718 (if approved) T. Hardie
Expires: July 4, August 24, 2005 Qualcomm, Inc.
L. Masinter
Adobe Systems
January 3,
February 20, 2005

Guidelines and Registration Procedures for new URI Schemes
draft-hansen-2717bis-2718bis-uri-guidelines-02.txt
draft-hansen-2717bis-2718bis-uri-guidelines-03.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 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 July 4, August 24, 2005.

Abstract

This document provides guidelines and recommendations for the
definition of new URI schemes, Uniform Resource Identifier (URI) schemes. It also
updates the process and a mechanism to register those IANA registry for URI schemes. The registration requirements have been simplified by
providing for provisional registrations that need no technical review

Hansen, et al. Expires July 4, August 24, 2005 [Page 1]

Internet-Draft New URI Schemes January February 2005

and may share names with existing scheme names.

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

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Guidelines for new URI schemes . . . . scheme definitions . . . . . . . . . . . . 4
2.1 Demonstratable, new, long-lived utility . . . . . . . . . 4
2.2 Syntactic compatibility . . . . . . . . . . . . . . . . . 4
2.3 Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 4 5
2.4 Definition of operations . . . . . . . . . . . . . . . . . 5
2.5 Character Internationalization and character encoding . . . . . . . . . . . . . . . . . . . . 6
2.6 Clear security considerations . . . . . . . . . . . . . . 6
2.7 Scheme Name considerations . . . . . . . . . . . . . . . . 6
3. Guidelines for Provisional URI Scheme Registration Procedure . . . . . . 7
4. Guidelines for Historical URI Scheme Registration . . . . . . 7
5. URI Scheme Registration Procedure . . 7
3.1 General . . . . . . . . . . . . 7
5.1 General . . . . . . . . . . . . . 7
3.2 Provisional URI Scheme Considerations . . . . . . . . . . 8
3.3 . . 7
5.2 Registration Procedures . . . . . . . . . . . . . . . . . 8
3.4
5.3 Change Control . . . . . . . . . . . . . . . . . . . . . . 9
3.5 New
5.4 URI Scheme Registration Template . . . . . . . . . . . 10
4. . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 10
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
7.2 10
9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 12
Intellectual Property and Copyright Statements . . . . . . . . 14 13

Hansen, et al. Expires July 4, August 24, 2005 [Page 2]

Internet-Draft New URI Schemes January February 2005

1. Introduction

The Uniform Resource Identifier (URI) protocol element and generic
syntax is defined by RFC 3986 [5]. Each URI begins with a compact string
representation for identifying resources. scheme
name, as defined by Section 3.1 of RFC XXXX [6] defines 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
general syntax and semantics
of URIs. identifiers using that scheme. This document provides guidelines
for the definition of new URI schemes (for consideration schemes, for considerations by those
who are
defining and registering defining, registering, or evaluating those definitions), and definitions, as
well as a process and mechanism for registering URI schemes. schemes within
the IANA URI scheme registry. This document
replaces obsoletes both RFCs 2717
[2] and 2718 [3].

The original terminology for the URI protocol element attempted to

RFCs 2717 and 2718 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' 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, 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 URN "namespaces" (RFC 3406 [8]; this document's procedures do
not update or supersede [9]) are specific to the procedures set out in RFC 3406. "urn"
scheme and not covered explicitly by this document.

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. RFC 2717 proposed that additional registration
trees might be approved by the IESG, however, IESG. However, no such registration
trees have been approved.

This document eliminates RFC 2717's distinction between different
'trees' for URI schemes; instead 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 scheme
names may also be registered provisionally or provisionally, without necessarily
passing any review process or
meeting those criteria. 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 July 4, August 24, 2005 [Page 3]

Internet-Draft New URI Schemes January February 2005

o discourage multiple definitions of URI scheme names for different
purposes;
o help those proposing new URI scheme names to discern established
trends and conventions, and avoid names that might be confused
with existing ones.

2. Guidelines for new URI schemes scheme definitions

This section gives some considerations when defining new URI schemes.
These are useful
Meeting these guidelines is REQUIRED for all schemes (whether or not standards track);
IETF standards track permanent URI schemes may require review against these
criteria. scheme
registration, and RECOMMENDED for provisional registration.

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.2 Syntactic compatibility

RFC XXXX [6] 3986 [5] defines a the generic syntax for all URI schemes schemes, along
with
hierarchical the syntax of common URI components and a naming authority. New that are used by many URI
schemes
should follow this syntax. to define hierarchical identifiers. All URI schemes scheme
specifications must define their own syntax such that are not intended for use with relative URIs should
avoid use all strings
matching their scheme-specific syntax will also match the
<absolute-URI> grammar described in Section 4.3 of RFC 3986.

New URI schemes should reuse the forward slash "/" character, which is used common URI components of RFC 3986
for the definition of hierarchical delimiters.

If naming schemes. However, if there
is a strong reason for a URI scheme to not use the RFC XXXX hierarchical
syntax, then the new scheme definition should at least follow the
syntax of other previously registered schemes, if possible.

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, and the complete path segments "." and ".."
(dot-segments).

Avoid improper use of "//". The use of double slashes in the first
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. 3986. 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 ???? 3.2 of RFC XXXX 3986 for more details.)
URI schemes that do not contain a conformant hierarchical structure

Hansen, et al. Expires August 24, 2005 [Page 4]

Internet-Draft New URI Schemes February 2005

in their <scheme-specific-part> should not use double slashes
following the "<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 July 4, 2005 [Page 4]

Internet-Draft New URI Schemes January 2005
function. Schemes that are not intended to be used as locators
should still describe how the resource indicated can be identified by
software that obtains a URI of that scheme.

For schemes that function as locators, it is important that the
mechanism of resource location be clearly defined. This might mean
different things depending on the nature of the URI scheme.

In many cases, new URI schemes are defined as ways to translate
between other namespaces or protocols and name spaces into the general framework of
URIs. For example, the "ftp" URI scheme translates from into the FTP
protocol, while the "mid" URI scheme translates from the into a Message-ID field
identifier of
messages. an email message. For such schemes, the description of
the mapping must be complete, must describe and in sufficient detail so that the
mapping in both directions is clear: how characters get encoded to map from a URI into an
identifier or not set of protocol actions or name in URIs,
must describe exactly the target
namespace, and how all legal values of in the base standard can namespace, or legal
protocol interactions, might be 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 them, because their use as in a locator 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, valid URI. In
particular, the specification mapping should describe the notation mechanisms for encoding
binary or character strings within valid character sequences in a
URI. If not all legal values or protocol interactions of the base
standard can be represented using the URI scheme, the contexts of use, definition
should be clear about which subset are allowed, and a complete mapping of the locator
from its source. why.

2.4 Definition of operations

In addition to the definition of how a URI identifies a resource, a
URI scheme definition should also define, if applicable, the set of
operations that may be performed on a resource using the URI as its
identifier. The A basis for this model is was HTTP; a HTTP resource can be
operated on by GET, POST, PUT and a number of other operations
available through the HTTP protocol. 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 don't fit into the "information access" paradigm of
URIs. For example, "telnet") provide "telnet" provides location information for hooking onto
initiating a bi-directional data streams, and don't fit stream to a remote host; the
"infoaccess" paradigm of most URIs very well; this only
operation defined is to initiate the connection. In any case, the
operations appropriate for a URI scheme should be documented.

Hansen, et al. Expires August 24, 2005 [Page 5]

Internet-Draft New URI Schemes February 2005

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.

Hansen, et al. Expires July 4, 2005 [Page 5]

Internet-Draft New URI Schemes January 2005

2.5 Character Internationalization and character encoding

When describing URI schemes in which (some of) the elements of the
URI are actually representations of sequences of characters, 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. Unless there characters; see
section 2.5 of RFC 3986 for guidelines.

There is some compelling reason no separate registry or registration process for a particular
Internationalized Resource Identifiers (IRIs) [6]. URI 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.
definitions SHOULD be compatible with that specification.

2.6 Clear security considerations

Definitions of URI schemes should be accompanied by a clear analysis
of the security implications for systems that use the URI scheme.
o Does the user need to be warned that such a thing is happening
without an explicit request (GET

In particular, section 7 of RFC 3986 describes general security
considerations for the source URI schemes. The definition of an IMG tag, for
instance)?
o Is it possible to fake URIs individual URI
scheme should note which of this type that point these apply 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)?
o URI schemes should not subvert the security of existing schemes or
protocols (e.g., by layering or tunneling). specified scheme.

2.7 Scheme Name considerations

Section 3.1 of RFC 3986 defines the syntax of a URI scheme name. New
scheme registrations MUST comply. Note that although scheme names
are case insensitive, scheme names must be registered using lowercase
letters.

URI scheme names should be short, but also sufficiently descriptive
and distinguished to avoid problems.

Avoid trademark names or other symbols that might have problems with
the 'ownership' or rights to use the name in Internet protocols.

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 when the
described namespace is not.)

Organizations 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

Hansen, et al. Expires July 4, August 24, 2005 [Page 6]

Internet-Draft New URI Schemes January February 2005

might be registered by the vendor that owns the example.com domain
name.

3. Guidelines for Provisional URI Scheme Registration Procedure

3.1 General

The goals for registering URI Schemes

While the guidelines in Section 2 are to avoid (when possible)
duplicate use RECOMMENDED for provisional
registration, the requirements are:
The scheme name meets the syntactic requirements of Section 2.7.
There is not already a entry with the same URI scheme name for different purposes, to
allow implementors name.
(Modification of software that processes URIs to find
appropriate information about URI schemes, and a registration entry to encourage and
facilitate technical review note multiple uses of URI the
same scheme definitions before
corresponding software is deployed.

To allow others to determine name requires IESG approval.)
Contact information identifying the person supplying the results
registration is included. Previously unregistered URI schemes
discovered in use may be registered by third parties on behalf of technical review,
those who created the URI scheme; in this case, both the
registering party and the scheme registration process has two outcomes creator should be identified.
If no permanent, citable specification for the URI scheme
proposals: a 'provisional' status
definition is included, credible reasons for URI schemes whose definitions
have not been reviewed or were not accepted by the review process,
and a 'permanent' status for those schemes that have been accepted providing it
should be given.
A valid security considerations section, as required by
IETF review. Review is based on general agreement that section 6
of [7].
If the URI scheme definition proposed meets does not meet the requirements guidelines laid out in
Section 2.

Provisional status is useful for registering legacy URI schemes that
have already been widely deployed without registration, 2, the differences and for which
review at this time would be inappropriate. Provisional status may
also reasons SHOULD be useful noted.

4. Guidelines for private or experimental use.

Permanent status Historical URI Scheme Registration

In some circumstances, it is intended for use by IETF standards-track
protocols. The status requires a substantive review and approval
process.

A person wishing appropriate to register note a URI scheme should first determine
whether that
was once in use or registered but for whatever reason is no longer in
common use or the scheme use is appropriate not recommended. In this case, it is
possible for 'permanent' status, meets an individual to request that the
guidelines, and if 'permanent' status is desirable.

Provisional registration of a URI scheme merely requires providing
IANA with the information 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 URI scheme registration template
(Section 3.5). It is useful should contain some
indication to also provide this information in an
Internet Draft, especially if where the scheme is intended for ultimate
registration as a 'permanent' was previously defined or documented.

5. URI scheme.

Permanent registration of a Scheme Registration Procedure

5.1 General

The URI scheme requires IETF review and IESG
approval. In many cases, permanent registration involves process is described in the
promotion terminology of [7].
The registration process is an existing provisional registration. In general, optional mailing list review, followed
by "Expert Review". The registration request should note the
creation of a new permanent URI scheme requires a Standards Track
RFC. desired
status. The Designated Expert will evaluate the request against the
criteria of the requested status. In some cases, the case of a URI scheme permanent
registration in an Informational
RFC may be approved by request, the Designated Expert may:
Accept the IESG for 'permanent' URI scheme name for Permanent registration.
Suggest provisional registration instead.

Hansen, et al. Expires July 4, August 24, 2005 [Page 7]

Internet-Draft New URI Schemes January February 2005

3.2 Provisional URI Scheme Considerations

Registration of a provisional URI scheme does not require or imply
any kind of endorsement by the IETF, IANA or any other body.

The main requirement for a provisional URI scheme is that there MUST
NOT already be a corresponding permanent entry with the same URI
scheme name. In cases where separate communities have already
established differing uses of the same URI scheme name for different
purposes, it is possible to have two or more provisional
registrations for the same URI scheme name.

A provisional registration MUST also identify the person submitting
the registration,

Request IETF review and SHOULD contain a citable specification for the
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 2.

In particular, an analysis of the security issues inherent IESG approval; 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 not a requirement that meanwhile, suggest
provisional registration.

URI name schemes be secure or completely free from risks,
but all known security risks SHOULD be identified.

Previously unregistered URI schemes discovered in use may be
registered by third parties on behalf of those who created scheme definitions contained within other IETF documents
(Informational, Experimental or Standards-Track RFCs) must also
undergo Expert Review; in the URI
scheme.

3.3 case of Standards-Track documents,
permanent registration status approval is required.

5.2 Registration Procedures

Someone wishing to register a URI scheme should:
1. Check the IANA URI scheme registry to see whether or not there is
already an entry for the desired name. If there is already a
permanent an
entry under the name, choose a different URI scheme name.
2. Prepare a URI scheme registration template, as specified in
Section 3.5. 5.4.
3. The URI scheme registration template may be contained in an
Internet Draft, to facilitate discussion Draft (alone, or if
the URI scheme as part of some other protocol
specification), but this is intended for permanent status.
3. If desired, not necessary.
4. To facilitate review, send a copy of the template or a pointer to
the
Internet Draft (and containing document (with specific reference to the section number)
with the template) to the mailing

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

Internet-Draft New URI Schemes January 2005 list uri-review@ietf.org; participate in the discussion and
review of the URI scheme; allow a reasonable period (at uri@w3.org, requesting
review.
5. Allow for at least 2
weeks) two weeks for discussion and comments.
4. Make
revisions as appropriate based on review comments.
6. Submit the (possibly updated) registration template (or a pointer
to the Internet
Draft and document containing section number) it) to IANA at iana@iana.org
[11]. [13],
specifying whether 'permanent' or 'provisional' registration is
requested.

Upon receipt of a URI scheme registration request, IANA:
1. Checks the submission for completeness; if sections are missing
or citations are not correct, IANA rejects the registration
request.
2. Checks the current registry for a 'permanent' entry of that with the same name; if
such a registry exists, IANA rejects the registration request.
3. Adds the registration to the 'provisional' registry.

Registration of a 'permanent' URI scheme happens through the approval
of publication of an RFC that contains instructions for registration
in the 'IANA considerations' section of the 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 the same scheme name should be
avoided.

In some cases, a new 'permanent' URI scheme will upgrade a previous
'provisional' registration; IANA should remove the corresponding
entry from the provisional registry, unless the IANA considerations
section specifies otherwise.

3.4 Change Control

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.

Provisional URL schemes that are undocumented may be changed by their
owner at any time without notifying exists, IANA rejects the IETF.

Provisional URL schemes that have been documented by an Informational
RFC, may be changed at any time by registration request.
3. Requests Expert Review of the owner. However, an updated
Informational RFC that details registration request against the changes made, must be submitted
corresponding guidelines.
4. If the Designated Expert recommends registration in either
'permanent' or 'provisional' registration, add the registration
to the IESG.

The owner of a provisional URL scheme and documented by appropriate registry.
5. Unless Expert Review has explicitly rejected the registration
within two weeks, IANA should automatically add the registration
in the 'provisional' registry.

Either based on an
Informational RFC explicit request or independently initiated, the
Designated Expert or IESG may pass responsibility for request the upgrade of a 'provisional'
registration to
another person or agency by informing the IESG. a 'permanent' one. In such cases, IANA should remove

Hansen, et al. Expires July 4, August 24, 2005 [Page 9] 8]

Internet-Draft New URI Schemes January February 2005

The IESG may reassign responsibility for a

the corresponding entry from the provisional URL scheme
that had been documented registry.

5.3 Change Control

Registrations may be updated in each registry by the same mechanism
as required for an Informational RFC. The most common
case of this will be to enable changes to be made to schemes initial registration. In cases where the scheme name is privately owned, and the owner original
definition of the scheme name
has died, moved out of contact or is otherwise unable to make changes
that are important to contained in an IESG-approved document,
update of the community.

A URL scheme that has been registered by a third party specification also requires IESG approval.

Provisional registrations may be
reassigned to updated by the proper owners of that scheme name.

The IESG may reclassify a URI scheme as "historic", if it determines
that original registrant
or anyone designated by them. In addition, the scheme is no longer in use. (This IESG may be done in
conjunction with marking reassign
responsibility for a protocol as "historic".)

IANA may remove any provisional URI scheme entry whose corresponding
specification document is no longer available (e.g., the
Internet-draft expired, or registration scheme.

The most common case of this will be to enable changes to be made to
schemes where the URL citation original registrator is no longer resolvable).
Anyone may notify IANA out of any such cases by sending an email contact, or
unwilling or unable to
iana@iana.org [12]. Before removing an entry for this reason, IANA
SHOULD contact the registered Author/Change controller make changes.

Transition to determine
whether a replacement for or from 'permanent' status requires IESG approval;
transition from 'provisional' to 'historical' may be requested by
anyone authorized to update the specification document is available.

3.5 New provisional registration.

5.4 URI Scheme Registration Template

The following issues should

This template describes the fields that must be addressed when documenting supplied in a new URI
scheme:
scheme registration request:
URI scheme name. See Section 2.7 for guidelines.
Status. This will reflects the status requested, and should be one of
'permanent', 'provisional' or
'historic'. 'historical'.
URI scheme syntax. This should be expressed in a clear and concise
manner. The use of ABNF is encouraged. Please refer to See Section 2 2.2 for guidance on designing and explaining your scheme's syntax.
Character encoding considerations. It is important to identify what
your guidelines.
URI scheme supports in this regard. It is obvious that semantics See Section 2.3 for
interoperability, it is best if there is a means to support
character sets beyond USASCII, but, especially guidelines.
Encoding considerations. See Section 2.5 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. guidelines.
Applications and/or protocols that use this URI scheme name.
Including Include
references to documentation that defines define the applications and/or
protocols cited is especially useful.

Hansen, et al. Expires July 4, 2005 [Page 10]

Internet-Draft New URI Schemes January 2005 cited.
Interoperability considerations. If you are aware of any details
regarding your scheme 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). 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. See Section 2.6 for guidelines.
Contact. Person & email address to contact for further information.
Author/Change controller.
Application/protocol. Applications and/or protocols that use this
URI scheme name.

4. scheme name.
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

Hansen, et al. Expires August 24, 2005 [Page 9]

Internet-Draft New URI Schemes February 2005

updated.

6. IANA Considerations

This document updates replaces the current "URL Scheme" registry with a new
Uniform Resource Identifier (URI) Schemes scheme registry, establishes a new
registration table. template and a new process for registration. The
process is based on [7] "Expert Review" with an initial (optional)
mailing list review.

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 Section Section 5 establishes the process for new URI
scheme registration.

To transition to the new registry, all URL 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. 'permanent' status.

7. Security Considerations

New URI schemes

All registered values are expected to address all contain accurate security considerations
in their definitions.

Information that creates or updates a registration needs
consideration sections; 'permanent' registered scheme names are
expected to be
authenticated. 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 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.

8. Acknowledgements

Thanks go

Many thanks to Paul Hoffmann who contributed significantly to the
development of this document. Thanks also go to Hoffmann, Ira McDonald McDonald, Roy Fielding, Stu Weibel,
and the other members of the uri@w3.org [13] [14] mailing list for their
comments on earlier drafts.

Hansen, et al. Expires July 4, 2005 [Page 11]

Internet-Draft New URI Schemes January 2005

Parts of this document are based on [2], [3] and [9].

7. [10]. Some of the
ideas about use of URIs were taken from the 'Architecture of the
World Wide Web' [11]; section 2.4.1 gives some reasons for
registering schemes, and also some guidelines for use of URIs.

9. References

7.1

9.1 Normative References

[1] Moats, R., "URN Syntax", RFC 2141, May 1997.

Hansen, et al. Expires August 24, 2005 [Page 10]

Internet-Draft New URI Schemes February 2005

[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
Identifier (URI): Generic Syntax", STD 66, RFC 2396, August 1998. 3986, January
2005.

[6] Berners-Lee, T., Fielding, R. Duerst, M. and L. Masinter, "Uniform M. Suignard, "Internationalized Resource
Identifier (URI): Generic Syntax",
Identifiers (IRIs)", RFC 3987, January 2005.

[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 2004.

7.2 1998.

9.2 Informative References

[7]

[8] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.

[8]

[9] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.

[9]

[10] 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> W3C Technical Architecture Group, "Architecture of the World
Wide Web, Volume One", December 2004,
<http://www.w3.org/TR/webarch/>.

URIs

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

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

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

Hansen, et al. Expires July 4, August 24, 2005 [Page 12] 11]

Internet-Draft New URI Schemes January February 2005

Authors' Addresses

Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA

EMail:

Email: tony+urireg@maillennium.att.com

Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Suite 200
Campbell, CA
USA

EMail:

Email: hardie@qualcomm.com

Larry Masinter
Adobe Systems
345 Park Ave
San Jose, CA 95110
US

Phone: +1 408 536 3024
EMail:
Email: LMM@acm.org
URI: http://larry.masinter.net

Hansen, et al. Expires July 4, August 24, 2005 [Page 13] 12]

Internet-Draft New URI Schemes January February 2005

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 (2005). 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 July 4, August 24, 2005 [Page 14] 13]

----