RFC2717 - Registration Procedures for URL Scheme Names

Network Working Group R. Petke

Request for Comments: 2717 UUNET Technologies

BCP: 35 I. King

Category: Best Current Practice Microsoft Corporation

November 1999

Registration Procedures for URL Scheme Names

Status of this Memo

This document specifies an Internet Best Current Practices for the

Internet Community, and requests discussion and suggestions for

improvements. Distribution of this memo is unlimited.

Abstract

This document defines the process by which new URL scheme names are

registered.

1.0 IntrodUCtion

A Uniform Resource Locator (URL) is a compact string representation

of the location for a resource that is available via the Internet.

RFC2396 [1] defines the general syntax and semantics of URIs, and,

by inclusion, URLs. URLs are designated by including a "<scheme>:"

and then a "<scheme-specific-part>". Many URL schemes are already

defined, however, new schemes may need to be defined in the future in

order to accommodate new Internet protocols and/or procedures.

A 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 URL schemes intended for wide spread, public use

are developed in an orderly, well-specified, and public manner.

This document defines the registration procedures to be followed when

new URL schemes are created. A separate document, RFC2718,

Guidelines for URL Schemes [2], provides guidelines for the creation

of new URL schemes. The primary focus of this document is on the

<scheme> portion of new URL schemes, referred to as the "scheme name"

throughout this document.

1.1 Notation

The key Words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC2119.

2.0 URL Scheme Name Registration Trees

2.1 General

In order to increase the efficiency and flexibility of the URL scheme

name registration process, the need is recognized for multiple

registration "trees". The registration requirements and specific

registration procedures for each tree differ, allowing the overall

registration procedure to accommodate the different natural

requirements for URL 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 URL scheme name is to determine

which registration tree the scheme should be registered in.

Determination of the proper registration tree is based on the

intended use for the new scheme and the desired syntax for the scheme

name.

This document will discuss in detail the tree that reflects current

practice, under IETF ownership and control. It will also set forth

an outline to assist authors in creating new trees to address

differing needs for wide acceptance and interoperability, ease of

creation and use, and type and "strength" of ownership.

2.2 The IETF Tree

The IETF tree is intended for URL schemes of general interest to the

Internet community. The tree exists for URL 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, URL schemes that have proven particularly useful in

those contexts.

2.3 Additional Registration Trees

From time to time and as required by the community, the IESG may

create new top-level registration trees. These trees may require

significant, little or no registration, and may allow change control

to rest in the hands of individuals or groups other than IETF. A new

tree should only be created if no existing tree can be shown to

address the set of needs of some sector of the community.

3.0 Requirements for Scheme Name Registration

3.1 General Requirements

All new URL schemes, regardless of registration tree, MUST conform to

the generic syntax for URLs as specified in RFC2396.

3.2 The IETF Tree

Registration in the IETF tree requires publication of the URL scheme

syntax and semantics in either an Informational or Standards Track

RFC. In general, the creation of a new URL scheme requires a

Standards Track RFC. An Informational RFCmay be employed for

registration only in the case of a URL scheme which is already in

wide usage and meets other standards set forth in RFC2718, such as

"demonstrated utility" within the Internet Architecture; the IESG

shall have broad discretion in determining whether an Informational

RFCis suitable in any given case, and may either recommend changes

to such document prior to publication, or reject it for publication.

An Informational RFCpurporting to describe a URL scheme shall not be

published without IESG approval. This is a departure from practice

for Informational RFCs as set forth in RFC2026, for the purpose of

ensuring that the registration of URL schemes shall serve the best

interests of the Internet community.

The NAMES of schemes registered in the IETF tree 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

schemes registered in alternative trees (see section 3.3).

An analysis of the security issues inherent in the new URL scheme is

REQUIRED. (This is in accordance with the basic requirements for all

IETF protocols.) URL schemes registered in the IETF tree should not

introduce additional security risks into the Internet Architecture.

For example, URLs 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 URL scheme name registered in the IETF tree 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.3 Alternative Trees

While public exposure and review of a URL scheme created in an

alternative tree is not required, using the IETF Internet-Draft

mechanism for peer review is strongly encouraged to improve the

quality of the specification. RFCpublication of alternative tree

URL schemes is encouraged but not required. Material may be

published as an Informational RFCby sending it to the RFCEditor

(please follow the instructions to RFCauthors, RFC2223 [3]).

The defining document for an alternative tree may require public

exposure and/or review for schemes defined in that tree via a

mechanism other than the IETF Internet-Draft mechanism.

URL schemes created in an alternative tree must conform to the

generic URL syntax, RFC2396. The tree's defining document may set

forth additional syntax and semantics requirements above and beyond

those specified in RFC2396.

All new URL schemes SHOULD follow the Guidelines for URL Schemes, set

forth in RFC2718 [2].

An analysis of the security issues inherent in the new URL 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 URL schemes created in an

alternative tree be secure or completely free from risks.

Nevertheless, the tree's defining document must set forth the

standard for security considerations, and in any event all known

security risks SHOULD be identified.

Change control must be defined for a new tree. Change control may be

vested in the IETF, or in an individual, group or other entity. The

change control standard for the tree must be approved by the IESG.

The syntax for alternative trees shall be as follows: each tree will

be identified by a unique prefix, which must be established in the

same fashion as a URL scheme name in the IETF tree, except that the

prefix must be defined by a Standards Track document. Scheme names

in the new tree are then constructed by prepending the prefix to an

identifier unique to each scheme in that tree, as prescribed by that

tree's identifying document:

For instance, the "foo" tree would allow creation of scheme names of

the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes

an arbitrary USASCII string following the tree's unique prefix.

4.0 Registration Procedures

4.1 The IETF Tree

The first step in registering a new URL scheme in the IETF tree 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 6 of this 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.

4.2 Alternative Trees

Registration of URL schemes created in an alternative tree may be

formal, through IETF documents, IANA registration, or other

acknowledged organization; informal, through a mailing list or other

publication mechanism; or nonexistent. The registration mechanism

must be documented for each alternative tree, and must be consistent

for all URL scheme names created in that tree.

It is the responsibility of the creator of the tree's registration

requirements to establish that the registration mechanism is workable

as described; it is within the discretion of the IESG to reject the

document describing a tree if it determines the registration

mechanism is impractical or creates an undue burden on a party who

will not accept it. (For instance, if an IANA registration mechanism

is proposed, IESG might reject the tree if its mechanism would create

undue liability on the part of IANA.)

While the template in section 6 of this document is intended to apply

to URL scheme names in the IETF tree, it is also offered as a

guideline for those documenting alternative trees.

5.0 Change Control

5.1 Schemes in the IETF Tree

URL schemes created in the IETF tree are "owned" by the IETF itself

and may be changed, as needed, by updating the RFCthat describes

them. Schemes described by Standards Track RFCbut be replaced with

new Standards Track RFCs. Informational RFCs may be replaced by new

Informational RFCs or Standards Track RFCs.

5.2 Schemes in Alternative Trees

URL schemes in an alternative tree that are undocumented (as allowed

by that tree's rules) may be changed by their owner at any time

without notifying the IETF.

URL schemes created in an alternative tree that have been documented

by an Informational RFC, may be changed at any time by the owner,

however, an updated Informational RFCwhich details the changes made,

must be submitted to the IESG.

The owner of a URL scheme registered in an alternative tree and

documented by an Informational RFCmay pass responsibility for the

registration to another person or agency by informing the IESG.

The IESG may reassign responsibility for a 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 by the rules of its tree,

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 URL scheme created in an alternative tree

and documented via an Informational RFCas "historic" if it

determines that the scheme is no longer in use.

6.0 Registration Template

The following issues should be addressed when documenting a new URL

scheme:

URL scheme name.

URL scheme syntax. This should be expressed in a clear and

concise manner. The use of ABNF is encouraged. Please refer to

RFC2718 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 URL (e.g. mailto:), explain the

action that should be initiated by the consumer of the URL. If

there is a MIME type associated with this resource, please

identify it.

Applications and/or protocols which use this URL scheme name.

Including references to documentation which defines the

applications and/or protocols cited is especially useful.

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.

Person & email address to contact for further information.

Author/Change controller.

Applications and/or protocols which use this URL scheme name.

7.0 Security Considerations

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 URL 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 URL scheme.

If the IESG agrees to delegate the registration and change control

functions of an alternative tree to a group or individual outside of

the IETF, that group or individual should have sufficient security

procedures in place to authenticate registration changes.

8.0 References

[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource

Identifiers (URI): Generic Syntax", RFC2396, August 1998.

[2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,

"Guidelines for new URL Schemes", RFC2718, November 1999.

[3] Postel, J. and J. Reynolds, "Instructions to RFCAuthors", RFC

2223, October 1997.

9.0 Authors' Addresses

Rich Petke

UUNET Technologies

5000 Britton Road

P. O. Box 5000

Hilliard, OH 43026-5000

USA

Phone: +1 614 723 4157

Fax: +1 614 723 8407

EMail: rpetke@wcom.net

Ian King

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052-6399

USA

Phone: +1 425-703-2293

Fax: +1 425-936-7329

EMail: iking@microsoft.com

10. Full Copyright Statement

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.