draft-ietf-urlreg-procedures-03.txt   draft-ietf-urlreg-procedures-04.txt 
INTERNET-DRAFT R. Petke INTERNET-DRAFT R. Petke
<draft-ietf-urlreg-procedures-03.txt> WorldCom Advanced Networks <draft-ietf-urlreg-procedures-04.txt> MCIWORLDCOM Advanced Networks
August 7, 1998 November 1, 1998
Registration Procedures for URL Scheme Names Registration Procedures for URL Scheme Names
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check To learn the current status of any Internet-Draft, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu Rim).
(US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires February 7, 1999. This Internet-Draft expires April 30, 1999.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This document defines the process by which new URL schemes are This document defines the process by which new URL scheme names are
registered. registered.
1.0 Introduction 1.0 Introduction
A Uniform Resource Locator (URL) is a compact string representation A Uniform Resource Locator (URL) is a compact string representation
of the location for a resource that is available via the Internet. of the location for a resource that is available via the Internet.
RFC [URI-SYNTAX] [1] defines the general syntax and semantics of RFC 2396 [1] defines the general syntax and semantics of URIs, and,
URIs, and, by inclusion, URLs. URLs are designated by including a by inclusion, URLs. URLs are designated by including a "<scheme>:"
"<scheme>:" and then a "<scheme-specific-part>". Many URL schemes and then a "<scheme-specific-part>". Many URL schemes are already
are already defined, however, new schemes may need to be defined in defined, however, new schemes may need to be defined in the future
the future in order to accommodate new Internet protocols and/or in order to accommodate new Internet protocols and/or procedures.
procedures.
A registration process is needed to ensure that the names of all A registration process is needed to ensure that the names of all
such new schemes are guaranteed not to collide. Further, the such new schemes are guaranteed not to collide. Further, the
registration process ensures that URL schemes intended for wide registration process ensures that URL schemes intended for wide
spread, public use are developed in an orderly, well-specified, and spread, public use are developed in an orderly, well-specified, and
public manner. public manner.
This document defines registration procedures which use the Internet This document defines the registration procedures to be followed
Assigned Numbers Authority (IANA) as a central registry for such URL when new URL schemes are created. A separate document, RFC
scheme names and the IETF RFC mechanism for scheme review, where [URL-GUIDELINES], Guidelines for URL Schemes [2], provides
appropriate. 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.
2.0 URL Scheme Name Registration 2.0 URL Scheme Name Registration Trees
2.1 General
In order to increase the efficiency and flexibility of the URL In order to increase the efficiency and flexibility of the URL
scheme name registration process, several different registration scheme name registration process, two different registration "trees"
"trees" have been created. The registration requirements and have been created. The registration requirements and specific
specific registration procedures for each tree differ, allowing the registration procedures for each tree differ, allowing the overall
overall registration procedure to accommodate the different natural registration procedure to accommodate the different natural
requirements for URL schemes. For example, a scheme that will be requirements for URL schemes. For example, a scheme that will be
recommended for wide support and implementation by the Internet recommended for wide support and implementation by the Internet
Community requires a more complete review, prior to registration, community requires a more complete review than a scheme intended to
than a scheme intended to be used for resources associated with be used for resources associated with proprietary software.
proprietary software.
Each of the URL scheme name registration trees also imparts a
specific syntax to the scheme name being registered.
Registration of a new URL scheme name may occur in any ONE of the
established registration trees.
The first step in registering a new URL scheme name is to determine The first step in registering a new URL scheme name is to determine
which registration tree the scheme should be registered in. which registration tree the scheme should be registered in.
Determination of the proper registration tree is based on the Determination of the proper registration tree is based on the
intended use for the new scheme, the desired syntax for the scheme intended use for the new scheme and the desired syntax for the
name, and the ability to meet the registration requirements for the scheme name.
desired tree.
Note that some URL schemes defined prior to this document do not Note that some URL schemes defined prior to this document do not
conform to the naming conventions described below. See Appendix A conform to the naming conventions described below. See Appendix A
for a discussion of those schemes. for a discussion of those schemes.
The following subsections define the registration trees available at
this time, the purpose of each tree, the requirements for
registration in each tree, and the associated URL scheme name
formats that are applied to names registered in each tree.
2.1 General Requirements
All new URL scheme NAMES, regardless of registration tree, MUST
conform to the syntax specified in RFC [URI-SYNTAX] for scheme
names.
2.2 The IETF Tree 2.2 The IETF Tree
2.2.1 Purpose
The IETF tree is intended for URL schemes of general interest to the The IETF tree is intended for URL schemes of general interest to the
Internet Community. The tree exists for URL schemes that require a Internet community. The tree exists for URL schemes that require a
substantive review and approval process; the vendor and personal substantive review and approval process. It is expected that
trees exist for those that do not. It is expected that
applicability statements for particular applications will be applicability statements for particular applications will be
published from time to time that recommend implementation of, and published from time to time that recommend implementation of, and
support for, URL schemes that have proven particularly useful in support for, URL schemes that have proven particularly useful in
those contexts. those contexts.
2.2.2 Registration Requirements 2.3 The OID Tree
Registration in the IETF tree requires approval by the IESG and
publication of the URL scheme syntax and semantics as some form of
RFC, usually a standards track RFC.
All new URL schemes registered in the IETF tree, MUST conform to the
generic syntax for URLs as specified in RFC [URI-SYNTAX].
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.) There is absolutely no requirement that all
URL schemes registered in the IETF tree be secure or completely free
from risks. Nevertheless, all known security risks must be
identified.
The security considerations section of all registrations is subject
to continuing evaluation and modification, and in particular may be
extended by use of the "comments on URL scheme names" mechanism
described in section 4.0.
2.2.3 Ownership
The "owner" of a URL scheme name registration 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. standards
track) as required for the initial registration.
2.2.4 Syntax of URL Scheme Names
URL scheme names in the IETF tree are normally denoted by names that
are not explicitly faceted, i.e., do not contain period (".")
characters. For example, "http", "ftp", "mailto", etc.
2.3 The Vendor Tree
2.3.1 Purpose
The vendor tree is used for URL schemes associated with commercially
available products. "Vendor" or "producer" are construed as
equivalent and very broadly in this context.
A registration may be placed in the vendor tree by anyone who needs
to identify a scheme for (1) specifying the location of a resource
available via the Internet (2) which may be accessed using a
protocol (or mechanism) for which there is not currently a URL
scheme registered in the IETF tree.
The registration of a URL scheme name in the vendor tree does not
imply endorsement, approval, or recommendation by IANA or IETF or
even certification that the specification is adequate. To become
Internet Standards, protocol, data objects, or whatever must go
through the IETF standards process and the registration in the IETF
tree.
2.3.2 Registration Requirements
RFC publication of vendor URL schemes is encouraged but not
required. Material may be published as an Informational RFC by
sending it to the RFC Editor (please follow the instructions to RFC
authors, RFC-2223 [3]).
While public exposure and review of URL scheme names to be
registered in the vendor tree is not required, using the
ietf-url-schemes list for review is strongly encouraged to improve
the quality of those specifications.
URL schemes registered in the vendor tree are encouraged to conform
to the generic URL syntax but are not required to do so in order to
be registered.
All new URL schemes SHOULD follow the Guidelines for URL Schemes,
set forth in RFC [URL-GUIDELINES] [2].
While not required, 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".
There is absolutely no requirement that URL schemes registered in The OID tree is intended for URL schemes which will be used in a
the vendor tree be secure or completely free from risks. proprietary manner. The trees exists to provide a mechanism for
Nevertheless, all known security risks SHOULD be identified in the ensuring that scheme names do not collide. The syntax and semantics
registration. of URL schemes created in the OID tree do not have to be reviewed or
publicly disclosed.
The security considerations section of all registrations is subject Creating a URL scheme name in the OID tree does not imply
to continuing evaluation and modification, and in particular may be endorsement, approval, or recommendation by the IETF or even
extended by use of the "comments on URL scheme name" mechanism certification that the specification is adequate, even if the scheme
described in section 4.0. was published as an IETF Internet-Draft and/or reviewed by IETF
participants. To become Internet Standards, protocols, data
objects, or whatever must go through the IETF standards process and
registration in the IETF tree.
2.3.3 Ownership of Registration 2.4 Additional Registration Trees
The registration formally belongs to the vendor or organization From time to time and as required by the community, the IESG may
registering the scheme name. Changes to the specification will be create new top-level registration trees.
made at their request, as discussed in subsequent sections.
2.3.4 Syntax of URL Scheme Names 3.0 Requirements for Scheme Name Registration
Registrations in the vendor tree will be distinguished by the 3.1 General Requirements
leading facet "vnd.". That must be followed by an IANA-approved
designation of the producer's name, which is then followed by a URL
scheme name or product designation (e.g. vnd.bigcompany.telepathic).
IANA will assign unique designations for producer names, All new URL scheme NAMES, regardless of registration tree, MUST
("bigcompany" in the example above). Accordingly, once a producer conform to the syntax specified in RFC 2396 for scheme NAMES.
has successfully registered a scheme name,
(e.g. "vnd.bigcompany.telepathic"), only registrations for new
scheme names that originate from "bigcompany" will begin with
"vnd.bigcompany.".
2.4 The Personal or Private Tree 3.2 The IETF Tree
2.4.1 Purpose Registration in the IETF tree requires publication of the URL scheme
syntax and semantics in either an Informational or Standards Track
RFC.
Registrations for URL schemes created experimentally or as part of In addition to having a conforming scheme NAME (see section 3.1),
products that are not distributed commercially may be registered in all new URL schemes registered in the IETF tree, MUST conform to the
the personal tree. Unlike the IETF and vendor trees which guarantee generic syntax for URLs as specified in RFC 2396.
the uniqueness of registered scheme names, registrations in the
personal tree are NOT guaranteed to be unique. Multiple sites may
register the same scheme name but use it in different (and
incompatible) ways.
The registration of a URL scheme name in the personal tree does not An analysis of the security issues inherent in the new URL scheme is
imply endorsement, approval, or recommendation by IANA or IETF or REQUIRED. (This is in accordance with the basic requirements for
even certification that the specification is adequate. To become all IETF protocols.) There is absolutely no requirement that all
Internet Standards, protocol, data objects, or whatever must go URL schemes registered in the IETF tree be secure or completely free
through the IETF standards process and the registration in the IETF from risks. Nevertheless, all known security risks must be
tree. identified.
2.4.2 Registration Requirements 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.
RFC publication of personal URL schemes is encouraged but not 3.3 The OID Tree
required. Materials may be published as an Informational RFC by
sending it to the RFC Editor (please follow the instructions to RFC
authors, RFC-2223 [3]).
While public exposure and review of URL scheme names to be While public exposure and review of a URL scheme created in the OID
registered in the personal tree is not required, using the tree is not required, using the IETF Internet-Draft mechanism for
ietf-url-schemes list for review is strongly encouraged to improve peer review is strongly encouraged to improve the quality of the
the quality of those specifications. specification. RFC publication of OID tree URL schemes is
encouraged but not required. Material may be published as an
Informational RFC by sending it to the RFC Editor (please follow the
instructions to RFC authors, RFC 2223 [3]).
URL schemes registered in the personal tree are encouraged to URL schemes created in the OID tree are encouraged to conform to the
conform to the generic URL syntax but are not required to do so in generic URL syntax, RFC 2396, but are not required to do so.
order to be registered.
All new URL schemes SHOULD follow the Guidelines for URL Schemes, All new URL schemes SHOULD follow the Guidelines for URL Schemes,
set forth in RFC [URL-GUIDELINES] [2]. set forth in RFC [URL-GUIDELINES] [2].
While not required, an analysis of the security issues inherent in While not required, an analysis of the security issues inherent in
the new URL scheme is encouraged. Regardless of what security the new URL scheme is encouraged. Regardless of what security
analysis is or is not performed, all descriptions of security issues analysis is or is not performed, all descriptions of security issues
must be as accurate as possible. In particular, a statement that must be as accurate as possible. In particular, a statement that
there are "no security issues associated with this scheme" must not there are "no security issues associated with this scheme" must not
be confused with "the security issues associates with this scheme be confused with "the security issues associates with this scheme
have not been assessed". have not been assessed".
There is absolutely no requirement that URL schemes registered in There is absolutely no requirement that URL schemes created in the
the personal tree be secure or completely free from risks. OID tree be secure or completely free from risks. Nevertheless, all
Nevertheless, all known security risks SHOULD be identified in the known security risks SHOULD be identified.
registration.
The security considerations section of all registrations is subject
to continuing evaluation and modification, and in particular may be
extended by use of the "comments on URL scheme name" mechanism
described in section 4.0.
2.4.3 Ownership of Registration
The owner of "personal" registrations and associated specifications
is the person or entity making the registration, or one to whom
responsibility has been transferred as described below.
2.4.4 Syntax of URL Scheme Names The registration of a URL scheme created in the OID tree formally
belongs to the entity to which the OID is assigned. Changes to the
specification of an OID tree URL scheme which is documented by an
Informational RFC shall only be accepted from the owner of the OID
or with the permission of the owner of the OID.
Registrations in the personal tree are distinguished by the leading The syntax of URL scheme names for schemes created in the OID tree
facet "prs.". For example, "prs.fiberreflection". is simply the text string "OID-" followed by the numeric OID
including any embedded hyphens. URL scheme names are case
insensitive so the letters in the text string "OID-" need not be
capitalized. No variations on this formula are permitted.
2.5 Additional Registration Trees Examples of valid URL scheme names in the OID tree:
From time to time and as required by the community, the IANA may, OID-2-16-840-1-113779-2-1:
with the advice and consent of the IESG, create new top-level Oid-2-16-840-1-113779-2-1-100:
registration trees. It is explicitly assumed that these trees may OiD-2-16-840-1-113779-3:
be created for external registration and management by well-known oid-2-16-840-1-113779-123:
permanent bodies, such as scientific societies, for URL schemes
specific to the sciences they cover. In general, the quality of
review of specifications for one of these additional registration
trees is expected to be equivalent to that which IETF would give to
registrations in its own tree. Establishment of these new trees
will be announced through RFC publication approved by the IESG.
3.0 Registration Procedures 4.0 Registration Procedures
The following sections detail the procedures to follow to register a 4.1 The IETF Tree
new URL scheme name in a specific registration tree. With the
exception of registration in the IETF tree, these procedures are not
a formal standards process, but rather an administrative procedure
intended to allow community comment and sanity checking without
excessive time delay.
3.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.
Complete the registration template (section 7.0 of this document) After all issues raised during a review period of no less than 4
and submit it to the IESG for review. Generally the details of weeks have been addressed, submit the draft to the IESG for review.
the proposed new URL scheme should already be documented in an
Internet-Draft and the registration template should reference this
draft.
The IESG will review the proposed new scheme and either refer the 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 a working group (existing or new) or directly present the
registration and associated documentation to the IESG for a last scheme to the IESG for a last call. In the former case, the working
call. In the former case, the working group is responsible for group is responsible for submitting a final version of the draft to
re-submitting it to the IESG for approval at such time as it has the IESG for approval at such time as it has received adequate
received adequate review and deliberation. review and deliberation.
After the IESG has approved the registration, it will forward the
registration paperwork and documentation to IANA for publication on
the ietf-url-schemes list and official registration in the IETF
tree.
Authors proposing new URL schemes for the IETF tree are encouraged
to present the proposed schemes to the IETF as a whole, via the
Internet-Drafts mechanism, well in advance of submission to the
IESG.
3.2 The Vendor Tree
Complete the registration template (section 7.0 of this document) as
completely as possible.
While not required, it is recommended and encouraged that vendors
submit a copy of the completed registration template (which includes
references to any additional documentation), to the ietf-url-schemes
list for peer review and comment. The quality of URL schemes can
usually be improved through such a process. The amount of feedback
received regarding the proposed scheme should serve as an indication
of how long to keep the proposal in peer review before proceeding
with the registration.
Forward the completed registration template to IANA (iana@iana.org).
IANA will review the registration template to ensure that it meets
the requirements necessary for registration. If it does not meet
the necessary requirements, the application will be rejected and
returned to the submitter and the registration process will be
terminated. Authors may choose to amend the information presented
in the registration template and re-submit it to IANA who will treat
the re-submission as a new registration request.
IANA will assign the unique designation for the producer's name at
this time if one has not already been assigned to the producer
making the registration request.
Regardless of whether or not the accepted registration template has
previously been posted to the ietf-url-schemes list for review, IANA
will post the template to the list along with an indication that the
template has been officially received by IANA for registration.
IANA will then wait for two (2) weeks for comments on and community
review of the registration request.
The intent of the public posting is to solicit comments and feedback
on the choice of scheme name, the syntax and semantics of the
scheme, and a review of any interoperability or security
considerations (if such information is disclosed in the application
or associated documentation).
IANA will forward all comments received during this review period to
the person designated as the contact person in the registration
template.
The submitter may submit a revised registration, or withdraw the
registration completely, at any time.
After the two week review period has expired, IANA shall register
the URL scheme name in the vendor tree.
URL scheme names proposed to this mailing list are not formally
registered and should not be used until the registration procedure
is completed by IANA.
3.3 The Personal Tree
The registration procedure for URL scheme names in the personal tree 4.2 The OID Tree
is identical as that specified for the vendor tree with the
exception of IANA assigning the vendor a unique name.
4.0 Comments on URL Scheme Name Registrations Registration of URL schemes created in the OID tree is automatic
because the scheme name is based on a previously registered entity,
an OID. There is no requirement to publish any documentation for
the URL scheme, however, doing so may be advantageous and is
encouraged.
Comments on registered URL scheme names may be submitted by members The recommended form for documenting a URL scheme created in the OID
of the community to IANA. These comments will be passed on to the tree is via an Informational RFC. The RFC should address all of the
"owner" of the URL scheme name if possible. Submitters of comments items covered by the template provided in section 6 of this
may request that their comment be attached to the URL scheme name document.
registration itself, and if IANA approves of this the comment will
be made accessible in conjunction with the scheme name registration
itself.
5.0 Change Control 5.0 Change Control
Once a URL scheme name has been published by IANA, the owner of the 5.1 Schemes in the IETF Tree
scheme name may request a change to its definition. The descriptions
of the different registration trees above designate the owners of
each type of registration. The change request follows the same
procedure as the registration request:
(1) Complete the registration template.
(2) Publish the revised scheme syntax and semantics on the
ietf-url-schemes list if peer review is requested.
(3) Submit the revised registration to IANA.
Changes should be requested only when there are serious omission or
errors in the published specification. When review is required, a
change request may be denied if it renders entities that were valid
under the previous definition invalid under the new definition.
The owner of a URL scheme registration may pass responsibility for
the registration to another person or agency by informing IANA and
the ietf-url-schemes list; this can be done without discussion or
review.
The IESG may reassign responsibility for a URL scheme name. The
most common case of this will be to enable changes to be made to
schemes where the author of the registration has died, moved out of
contact or is otherwise unable to make changes that are important to
the community.
URL scheme name registrations may not be deleted; URL scheme names
which are no longer believed appropriate for use can be declared
OBSOLETE by a change to their "intended use" field; such URL scheme
names will be clearly marked in the lists published by IANA.
6.0 IANA Considerations
6.1 Discussion List
A discussion list named "ietf-url-schemes" needs to be created and
maintained at "iana.org". The list MUST be open and MUST NOT
require the submitter to be subscribed to the list in order to
process a post.
6.2 Location of Registered URL Scheme Name List
URL scheme name registrations need to be posted in the anonymous
FTP directory
"ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".
6.3 Procedures for Registering URL Scheme Names
Scheme names in the IETF tree will only be registered in response
to a communication from the IESG stating that a given registration
has been approved.
Scheme names in the vendor tree will be registered automatically
provided that the registration template contains at least the
information specified below. Assignment of unique scheme names
shall be on a first come, first served basis.
Scheme names in the personal tree will be registered automatically URL schemes created in the IETF tree are "owned" by the IETF itself
provided that the registration template contains at least the and may be changed, as needed, by updating the RFC that describes
information specified below. No attempt shall be made to prevent them. Schemes described by Standards Track RFC but be replaced with
multiple applications from registering the same scheme name even if new Standards Track RFCs. Informational RFCs may be replaced by new
the use of the schemes are different and incompatible. Informational RFCs or Standards Track RFCs.
The following minimal information must be specified for a 5.2 Schemes in the OID Tree
registration in the vendor or personal tree:
Scheme Name Syntax: The syntax of the requested scheme name Undocumented URL schemes created in the OID tree may be changed by
(including the assigned producer designation in the case of vendor their owner at any time without notifying the IETF.
tree registrations), MUST conform to the syntax for such as
specified in RFC [URI-SYNTAX]. While encouraged to do so, the
syntax for the actual scheme does not have to conform to the
general syntax specified in RFC [URI-SYNTAX].
Security Considerations: The application for registration of a URL schemes created in the OID tree that have been documented by an
scheme name MUST include a discussion of the security considerations Informational RFC, may be changed at any time by the owner, however,
inherent in the scheme. an updated Informational RFC which details the changes made, must be
submitted to the IESG.
Contact Person: The application MUST include accurate information The owner of a URL scheme registered in the OID tree and documented
regarding a person to contact about the registration. by an Informational RFC may pass responsibility for the registration
to another person or agency by informing the IESG.
Author/Change Controller: The application MUST specify the author The IESG may reassign responsibility for a URL scheme registered in
and/or entity responsible for change control of the proposed scheme. the OID 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 owner of the OID has died, moved out of contact or is
otherwise unable to make changes that are important to the
community.
7.0 Registration Template The IESG may reclassify a URL scheme created in the OID tree and
documented via an Informational RFC as "historic" if it determines
that the scheme is no longer in use.
To: iana@iana.org 6.0 Registration Template
Subject: Registration of URL Scheme Name <name>
URL Scheme Name: The following issues should be addressed when documenting a new URL
scheme:
Character encoding considerations: URL scheme name.
Security considerations: URL scheme syntax. This should be expressed in a clear and
concise manner. The use of ABNF is encouraged. Please refer to
RFC [URL-GUIDELINES] for guidance on designing and explaining
your scheme's syntax.
Interoperability considerations: 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.
Published specification: 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 which use this URL scheme name: Applications and/or protocols which use this URL scheme name.
Additional information: 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).
Person & email address to contact for further information: Security considerations.
Intended usage: Relevant publications.
(One of COMMON, LIMITED USE or OBSOLETE) Person & email address to contact for further information.
Author/Change controller: Author/Change controller.
(Any other information that the author deems interesting may be Applications and/or protocols which use this URL scheme name.
added below this line.)
8.0 Security Considerations 7.0 Security Considerations
Information that creates or updates a registration needs to be Information that creates or updates a registration needs to be
authenticated. authenticated.
Information concerning possible security vulnerabilities of a Information concerning possible security vulnerabilities of a
protocol may change over time. Consequently, claims as to the protocol may change over time. Consequently, claims as to the
security properties of a registered URL scheme may change as well. security properties of a registered URL scheme may change as well.
As new vulnerabilities are discovered, information about such As new vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing registrations, vulnerabilities may need to be attached to existing documentation,
so that users are not misled as to the true security properties of a so that users are not misled as to the true security properties of a
registered URL scheme. registered URL scheme.
Delegations of a name space should only be assigned to someone with 8.0 References
adequate security.
9.0 References
[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998 Identifiers (URI): Generic Syntax", RFC 2396, August 1998
[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August
1998
[3] Postel, J., Reynolds, J., "Instructions to RFC Authors", [3] Postel, J., Reynolds, J., "Instructions to RFC Authors",
RFC 2223, October 1997. RFC 2223, October 1997.
10.0 Author's Address 9.0 Author's Address
Rich Petke Rich Petke
WorldCom Advanced Networks MCIWORLDCOM Advanced Networks
5000 Britton Road 5000 Britton Road
P. O. Box 5000 P. O. Box 5000
Hilliard, OH 43026-5000 Hilliard, OH 43026-5000
USA USA
Phone: +1 614 723 4157 Phone: +1 614 723 4157
Fax: +1 614 723 1333 Fax: +1 614 723 8407
EMail: rpetke@compuserve.net EMail: rpetke@wcom.net
Appendix A -- Grandfathered URL Scheme Names Appendix A -- Grandfathered URL Scheme Names
A number of URL scheme names, in use prior to 1998, would, if A number of URL scheme names, in use prior to 1998, would, if
registered under the procedures specified in this document, be registered under the procedures specified in this document, be
placed into either the vendor or personal trees. Re-registration placed into the OID tree. Re-registration of those types to reflect
of those types to reflect the appropriate trees is encouraged, but the appropriate tree or documentation of the schemes in an
not required. Ownership and change control principles outlined in Informational RFC is encouraged, but not required. Ownership and
this document apply to those types as if they had been registered in change control principles outlined in this document apply to those
the trees described above. types as if they had been registered in the OID tree.
ABOUT: ABOUT: (No information available at this time.)
AOL: AOL: (No information available at this time.)
 End of changes. 74 change blocks. 
421 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/