2004/id/draft-ietf-urlreg-procedures-02.txt


INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-02.txt>        WorldCom Advanced Networks
                                                          July 17, 1998


             Registration Procedures for URL Scheme Names


Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

   Distribution of this memo is unlimited.

   This Internet Draft expires January 15, 1999.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document defines the process by which new URL schemes 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.
   RFC [URI-SYNTAX] [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 registration procedures which use the Internet
   Assigned Numbers Authority (IANA) as a central registry for such URL
   scheme names and the IETF RFC mechanism for scheme review, where 
   appropriate.


2.0  URL Scheme Name Registration

   Registration of a new URL scheme name starts with the construction
   of a registration proposal.  Registration may occur in several
   different registration trees, which have different requirements as
   discussed below.  In general, the new registration proposal is
   circulated and reviewed in a fashion appropriate to the tree
   involved.  The URL scheme name is then registered if the proposal is
   acceptable.  The following sections describe the requirements and
   procedures used for each of the different registration trees.


2.1.  Registration Trees and URL Schemes

   In order to increase the efficiency and flexibility of the
   registration process, three different formats of URL scheme names
   may be registered.  The registration requirements for each format
   differ allowing the 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 that is used with resources associated with proprietary
   software.  The following subsections define registration "trees" and
   the associated URL scheme name formats available at this time.  Note
   that some URL schemes defined prior to this document do not conform
   to the naming conventions described below.  See Appendix A for a
   discussion of those schemes.


2.1.1.  IETF Tree

   The IETF tree is intended for URL schemes of general interest to the
   Internet Community.  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.

   URL scheme names in the IETF tree are normally denoted by names that
   are not explicitly faceted, i.e., do not contain period (".")
   characters.

   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.1.2.  Vendor Tree

   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 formally
   belongs to the vendor or organization registering the scheme name.
   Changes to the specification will be made at their request, as
   discussed in subsequent sections.

   Registrations in the vendor tree will be distinguished by the
   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,
   ("bigcompany" in the example above).  Accordingly, once a producer
   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.".

   While public exposure and review of URL scheme names to be
   registered in the vendor tree is not required, using the ietf-types
   list for review is strongly encouraged to improve the quality of
   those specifications.  Registrations in the vendor tree may be
   submitted directly to the IANA.


2.1.3.  Personal or Vanity Tree

   Registrations for URL schemes created experimentally or as part of
   products that are not distributed commercially may be registered in
   the personal or vanity tree.  The registrations are distinguished by
   the leading facet "prs.".

   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.

   While public exposure and review of URL scheme names to be
   registered in the personal tree is not required, using the
   ietf-types list for review is strongly encouraged to improve the
   quality of those specifications.  Registrations in the personal tree
   may be submitted directly to the IANA.


2.1.4.  Additional Registration Trees

   From time to time and as required by the community, the IANA may,
   with the advice and consent of the IESG, create new top-level
   registration trees.  It is explicitly assumed that these trees may
   be created for external registration and management by well-known
   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.


2.2.  Registration Requirements

   URL scheme name registration proposals are all expected to conform
   to various requirements laid out in the following sections.  Note
   that requirement specifics sometimes vary depending on the
   registration tree, again as detailed in the following sections.


2.2.1. Scheme Names

   All new URL scheme names, regardless of registration tree, MUST
   conform to the syntax specified for scheme names in RFC [URI-SYNTAX].


2.2.2. URL Syntax

   All new URL schemes registered in the IETF tree, MUST conform to the
   generic syntax for URLs as specified in RFC [URI-SYNTAX].  URL
   schemes registered in the vendor and personal trees are encouraged
   to conform to the generic 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].


2.2.3.  Security Requirements

   An analysis of the security issues inherent in the new URL scheme is
   required for all registrations in the IETF tree.  (This is in
   accordance with the basic requirements for all IETF protocols.)  A
   similar analysis for schemes registered in the vendor or personal
   trees is encouraged but not required.  However, regardless of what
   security analysis has or has not been done, all descriptions of
   security issues must be as accurate as possible regardless of
   registration tree.  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
   any tree be secure or completely free from risks.  Nevertheless, all
   known security risks must be identified in the registration of a URL
   scheme name, again regardless of registration tree.

   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 subsequent sections.


2.2.4.  Publication Requirements

   Proposals for URL schemes registered in the IETF tree must be
   published as RFCs.  RFC publication of vendor and personal URL
   schemes is encouraged but not required.  In all cases IANA will
   retain copies of all URL scheme proposals and "publish" them as part
   of the URL scheme names registration tree itself.

   Other than in the IETF tree, the registration of a URL scheme name
   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.  This is too difficult and
   too lengthy a process for the convenient registration of URL scheme
   names.

   The IETF tree exists for URL schemes that do require a substantive
   review and approval process with the vendor and personal trees exist
   for those that do not. 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.

   As discussed above, registration of a top-level type requires
   standards-track processing and, hence, RFC publication.


2.3.  Registration Procedure

   The following procedure has been implemented by the IANA for review
   and approval of new URL scheme names.  This is not a formal
   standards process, but rather an administrative procedure intended
   to allow community comment and sanity checking without excessive
   time delay.  For registration in the IETF tree, the normal IETF
   processes should be followed, treating posting of an internet-draft
   and announcement on the ietf-types list (as described in the next
   subsection) as a first step.  For registrations in the vendor or
   personal tree, the initial review step described below may be
   omitted and the URL scheme name may be registered directly by
   submitting the template and an explanation directly to IANA
   (at iana@iana.org).  However, authors of vendor or personal URL
   scheme specifications are encouraged to seek community review and
   comment whenever that is feasible.


2.3.1.  Present the URL scheme name to the Community for Review

   Send a proposed URL scheme name registration to the
   "ietf-types@iana.org" mailing list for a two week review period.
   This mailing list has been established for the purpose of reviewing
   proposed URL schemes.  URL scheme names proposed to this mailing
   list are not formally registered and should not be used until the
   registration procedure is complete.

   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.  The submitter may submit a revised registration, or
   withdraw the registration completely, at any time.


2.3.2.  IESG Approval

   URL scheme names registered in the IETF tree must be submitted to
   the IESG for approval.


2.3.3.  IANA Registration

   Provided that the URL scheme name meets the requirements for URL
   scheme names and has obtained approval that is necessary, the author
   may submit the registration request to the IANA, which will register
   the scheme name and make the URL scheme name registration available
   to the community.


2.4.  Comments on URL Scheme Name Registrations

   Comments on registered URL scheme names may be submitted by members
   of the community to IANA.  These comments will be passed on to the
   "owner" of the URL scheme name if possible.  Submitters of comments
   may request that their comment be attached to the URL scheme name
   registration itself, and if IANA approves of this the comment will
   be made accessible in conjunction with the scheme name registration
   itself.


2.5.  Location of Registered URL Scheme Name List

   URL scheme name registrations will be posted in the anonymous FTP
   directory
   "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".
   The scheme syntax and semantics description and other supporting
   material may also be published as an Informational RFC by sending it
   to the RFC Editor (please follow the instructions to RFC authors,
   RFC-2223 [3]).


2.6.  IANA Procedures for Registering URL scheme names

   The IANA will only register URL scheme names in the IETF tree in
   response to a communication from the IESG stating that a given
   registration has been approved. Vendor and personal types will be
   registered by the IANA automatically and without any formal review
   as long as the following minimal conditions are met:

   Scheme Name Syntax:  The syntax of the requested scheme name
   (including the assigned producer designation in the case of vendor
   tree registrations), MUST conform to the syntax for such as
   specified in RFC [URI-SYNTAX].  While encouraged, 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
   scheme name MUST include a discussion of the security
   considerations inherent in the scheme.

   Contact Person:  The application MUST include accurate information
   regarding a person to contact about the registration.

   Author/Change Controller:  The application must specify the author
   and/or entity responsible for change control of the proposed scheme.

   For vendor tree registrations, IANA will assign unique designations
   to each producer registering one or more scheme names.


2.7.  Change Control

   Once a URL scheme name has been published by IANA, the author 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)   Publish the revised scheme syntax and semantics on the
          ietf-types list.

    (2)   Leave at least two weeks for comments.

    (3)   Publish using IANA after formal review if required.

   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-types 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.


2.8.  Registration Template

     To: ietf-types@iana.org
     Subject: Registration of URL Scheme Name <name>

     URL Scheme Name:

     Security considerations:

     Interoperability considerations:

     Published specification:

     Applications which use this URL scheme name:

     Additional information:

     Person & email address to contact for further information:

     Intended usage:

     (One of COMMON, LIMITED USE or OBSOLETE)

     Author/Change controller:

     (Any other information that the author deems interesting may be
     added below this line.)


3.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 registrations,
   so that users are not misled as to the true security properties of a
   registered URL scheme.

   Delegations of a name space should only be assigned to someone with
   adequate security.


4.0 References

   [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
       Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998

   [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
       "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998

   [3] Postel, J., Reynolds, J., "Instructions to RFC Authors",
       RFC 2223, October 1997.


5.0  Author's Address

   Rich Petke
   WorldCom Advanced Networks
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000
   USA

   Phone: +1 614 723 4157
   Fax:   +1 614 723 1333
   EMail: rpetke@compuserve.net


Appendix A -- Grandfathered URL Scheme Names

   A number of URL scheme names, in use prior to 1998, would, if
   registered under the guidelines in this document, be placed into
   either the vendor or personal trees.  Re-registration of those types
   to reflect the appropriate trees is encouraged, but not required.
   Ownership and change control principles outlined in this document
   apply to those types as if they had been registered in the trees
   described above.

   ABOUT:

   AOL:

1
2	INTERNET-DRAFT R. Petke
3	<draft-ietf-urlreg-procedures-02.txt> WorldCom Advanced Networks
4	July 17, 1998
5
6
7
8	Registration Procedures for URL Scheme Names
9
10
11
12	Status of this Memo
13
14	This document is an Internet-Draft. Internet-Drafts are working
15	documents of the Internet Engineering Task Force (IETF), its areas,
16	and its working groups. Note that other groups may also distribute
17	working documents as Internet-Drafts.
18
19	Internet-Drafts are draft documents valid for a maximum of six
20	months and may be updated, replaced, or obsoleted by other documents
21	at any time. It is inappropriate to use Internet-Drafts as
22	reference material or to cite them other than as "work in progress."
23
24	To view the entire list of current Internet-Drafts, please check
25	the "1id-abstracts.txt" listing contained in the Internet-Drafts
26	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
27	(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
28	(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
29	(US West Coast).
30
31	Distribution of this memo is unlimited.
32
33	This Internet Draft expires January 15, 1999.
34
35	Copyright Notice
36
37	Copyright (C) The Internet Society (1998). All Rights Reserved.
38
39	Abstract
40
41	This document defines the process by which new URL schemes are
42	registered.
43
44
45	1.0 Introduction
46
47	A Uniform Resource Locator (URL) is a compact string representation
48	of the location for a resource that is available via the Internet.
49	RFC [URI-SYNTAX] [1] defines the general syntax and semantics of
50	URIs, and, by inclusion, URLs. URLs are designated by including a
51	"scheme" and then a "scheme-specific part". Many URL schemes are
52	already defined, however, new schemes may need to be defined in the
53	future in order to accommodate new Internet protocols and/or
54	procedures.
55
56	A registration process is needed to ensure that the names of all
57	such new schemes are guaranteed not to collide. Further, the
58	registration process ensures that URL schemes intended for wide
59	spread, public use are developed in an orderly, well-specified, and
60	public manner.
61
62	This document defines registration procedures which use the Internet
63	Assigned Numbers Authority (IANA) as a central registry for such URL
64	scheme names and the IETF RFC mechanism for scheme review, where
65	appropriate.
66
67
68	2.0 URL Scheme Name Registration
69
70	Registration of a new URL scheme name starts with the construction
71	of a registration proposal. Registration may occur in several
72	different registration trees, which have different requirements as
73	discussed below. In general, the new registration proposal is
74	circulated and reviewed in a fashion appropriate to the tree
75	involved. The URL scheme name is then registered if the proposal is
76	acceptable. The following sections describe the requirements and
77	procedures used for each of the different registration trees.
78
79
80	2.1. Registration Trees and URL Schemes
81
82	In order to increase the efficiency and flexibility of the
83	registration process, three different formats of URL scheme names
84	may be registered. The registration requirements for each format
85	differ allowing the registration procedure to accommodate the
86	different natural requirements for URL schemes. For example, a
87	scheme that will be recommended for wide support and implementation
88	by the Internet Community requires a more complete review than a
89	scheme that is used with resources associated with proprietary
90	software. The following subsections define registration "trees" and
91	the associated URL scheme name formats available at this time. Note
92	that some URL schemes defined prior to this document do not conform
93	to the naming conventions described below. See Appendix A for a
94	discussion of those schemes.
95
96
97	2.1.1. IETF Tree
98
99	The IETF tree is intended for URL schemes of general interest to the
100	Internet Community. Registration in the IETF tree requires approval
101	by the IESG and publication of the URL scheme syntax and semantics
102	as some form of RFC, usually a standards track RFC.
103
104	URL scheme names in the IETF tree are normally denoted by names that
105	are not explicitly faceted, i.e., do not contain period (".")
106	characters.
107
108	The "owner" of a URL scheme name registration in the IETF tree is
109	assumed to be the IETF itself. Modification or alteration of the
110	specification requires the same level of processing (e.g. standards
111	track) as required for the initial registration.
112
113
114	2.1.2. Vendor Tree
115
116	The vendor tree is used for URL schemes associated with commercially
117	available products. "Vendor" or "producer" are construed as
118	equivalent and very broadly in this context.
119
120	A registration may be placed in the vendor tree by anyone who needs
121	to identify a scheme for (1) specifying the location of a resource
122	available via the Internet (2) which may be accessed using a
123	protocol (or mechanism) for which there is not currently a URL
124	scheme registered in the IETF tree. The registration formally
125	belongs to the vendor or organization registering the scheme name.
126	Changes to the specification will be made at their request, as
127	discussed in subsequent sections.
128
129	Registrations in the vendor tree will be distinguished by the
130	leading facet "vnd.". That must be followed by an IANA-approved
131	designation of the producer's name, which is then followed by a URL
132	scheme name or product designation (e.g. vnd.bigcompany.telepathic).
133
134	IANA will assign unique designations for producer names,
135	("bigcompany" in the example above). Accordingly, once a producer
136	has successfully registered a scheme name, (e.g.
137	"vnd.bigcompany.telepathic"), only registrations for new scheme
138	names that originate from "bigcompany" will begin with
139	"vnd.bigcompany.".
140
141	While public exposure and review of URL scheme names to be
142	registered in the vendor tree is not required, using the ietf-types
143	list for review is strongly encouraged to improve the quality of
144	those specifications. Registrations in the vendor tree may be
145	submitted directly to the IANA.
146
147
148	2.1.3. Personal or Vanity Tree
149
150	Registrations for URL schemes created experimentally or as part of
151	products that are not distributed commercially may be registered in
152	the personal or vanity tree. The registrations are distinguished by
153	the leading facet "prs.".
154
155	The owner of "personal" registrations and associated specifications
156	is the person or entity making the registration, or one to whom
157	responsibility has been transferred as described below.
158
159	While public exposure and review of URL scheme names to be
160	registered in the personal tree is not required, using the
161	ietf-types list for review is strongly encouraged to improve the
162	quality of those specifications. Registrations in the personal tree
163	may be submitted directly to the IANA.
164
165
166	2.1.4. Additional Registration Trees
167
168	From time to time and as required by the community, the IANA may,
169	with the advice and consent of the IESG, create new top-level
170	registration trees. It is explicitly assumed that these trees may
171	be created for external registration and management by well-known
172	permanent bodies, such as scientific societies, for URL schemes
173	specific to the sciences they cover. In general, the quality of
174	review of specifications for one of these additional registration
175	trees is expected to be equivalent to that which IETF would give to
176	registrations in its own tree. Establishment of these new trees
177	will be announced through RFC publication approved by the IESG.
178
179
180	2.2. Registration Requirements
181
182	URL scheme name registration proposals are all expected to conform
183	to various requirements laid out in the following sections. Note
184	that requirement specifics sometimes vary depending on the
185	registration tree, again as detailed in the following sections.
186
187
188	2.2.1. Scheme Names
189
190	All new URL scheme names, regardless of registration tree, MUST
191	conform to the syntax specified for scheme names in RFC [URI-SYNTAX].
192
193
194	2.2.2. URL Syntax
195
196	All new URL schemes registered in the IETF tree, MUST conform to the
197	generic syntax for URLs as specified in RFC [URI-SYNTAX]. URL
198	schemes registered in the vendor and personal trees are encouraged
199	to conform to the generic syntax but are not required to do so in
200	order to be registered.
201
202	All new URL schemes SHOULD follow the Guidelines for URL Schemes,
203	set forth in RFC [URL-GUIDELINES] [2].
204
205
206	2.2.3. Security Requirements
207
208	An analysis of the security issues inherent in the new URL scheme is
209	required for all registrations in the IETF tree. (This is in
210	accordance with the basic requirements for all IETF protocols.) A
211	similar analysis for schemes registered in the vendor or personal
212	trees is encouraged but not required. However, regardless of what
213	security analysis has or has not been done, all descriptions of
214	security issues must be as accurate as possible regardless of
215	registration tree. In particular, a statement that there are "no
216	security issues associated with this scheme" must not be confused
217	with "the security issues associates with this scheme have not been
218	assessed".
219
220	There is absolutely no requirement that URL schemes registered in
221	any tree be secure or completely free from risks. Nevertheless, all
222	known security risks must be identified in the registration of a URL
223	scheme name, again regardless of registration tree.
224
225	The security considerations section of all registrations is subject
226	to continuing evaluation and modification, and in particular may be
227	extended by use of the "comments on URL scheme name" mechanism
228	described in subsequent sections.
229
230
231	2.2.4. Publication Requirements
232
233	Proposals for URL schemes registered in the IETF tree must be
234	published as RFCs. RFC publication of vendor and personal URL
235	schemes is encouraged but not required. In all cases IANA will
236	retain copies of all URL scheme proposals and "publish" them as part
237	of the URL scheme names registration tree itself.
238
239	Other than in the IETF tree, the registration of a URL scheme name
240	does not imply endorsement, approval, or recommendation by IANA or
241	IETF or even certification that the specification is adequate. To
242	become Internet Standards, protocol, data objects, or whatever must
243	go through the IETF standards process. This is too difficult and
244	too lengthy a process for the convenient registration of URL scheme
245	names.
246
247	The IETF tree exists for URL schemes that do require a substantive
248	review and approval process with the vendor and personal trees exist
249	for those that do not. It is expected that applicability statements
250	for particular applications will be published from time to time that
251	recommend implementation of, and support for, URL schemes that have
252	proven particularly useful in those contexts.
253
254	As discussed above, registration of a top-level type requires
255	standards-track processing and, hence, RFC publication.
256
257
258	2.3. Registration Procedure
259
260	The following procedure has been implemented by the IANA for review
261	and approval of new URL scheme names. This is not a formal
262	standards process, but rather an administrative procedure intended
263	to allow community comment and sanity checking without excessive
264	time delay. For registration in the IETF tree, the normal IETF
265	processes should be followed, treating posting of an internet-draft
266	and announcement on the ietf-types list (as described in the next
267	subsection) as a first step. For registrations in the vendor or
268	personal tree, the initial review step described below may be
269	omitted and the URL scheme name may be registered directly by
270	submitting the template and an explanation directly to IANA
271	(at iana@iana.org). However, authors of vendor or personal URL
272	scheme specifications are encouraged to seek community review and
273	comment whenever that is feasible.
274
275
276	2.3.1. Present the URL scheme name to the Community for Review
277
278	Send a proposed URL scheme name registration to the
279	"ietf-types@iana.org" mailing list for a two week review period.
280	This mailing list has been established for the purpose of reviewing
281	proposed URL schemes. URL scheme names proposed to this mailing
282	list are not formally registered and should not be used until the
283	registration procedure is complete.
284
285	The intent of the public posting is to solicit comments and feedback
286	on the choice of scheme name, the syntax and semantics of the
287	scheme, and a review of any interoperability or security
288	considerations. The submitter may submit a revised registration, or
289	withdraw the registration completely, at any time.
290
291
292	2.3.2. IESG Approval
293
294	URL scheme names registered in the IETF tree must be submitted to
295	the IESG for approval.
296
297
298	2.3.3. IANA Registration
299
300	Provided that the URL scheme name meets the requirements for URL
301	scheme names and has obtained approval that is necessary, the author
302	may submit the registration request to the IANA, which will register
303	the scheme name and make the URL scheme name registration available
304	to the community.
305
306
307	2.4. Comments on URL Scheme Name Registrations
308
309	Comments on registered URL scheme names may be submitted by members
310	of the community to IANA. These comments will be passed on to the
311	"owner" of the URL scheme name if possible. Submitters of comments
312	may request that their comment be attached to the URL scheme name
313	registration itself, and if IANA approves of this the comment will
314	be made accessible in conjunction with the scheme name registration
315	itself.
316
317
318	2.5. Location of Registered URL Scheme Name List
319
320	URL scheme name registrations will be posted in the anonymous FTP
321	directory
322	"ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".
323	The scheme syntax and semantics description and other supporting
324	material may also be published as an Informational RFC by sending it
325	to the RFC Editor (please follow the instructions to RFC authors,
326	RFC-2223 [3]).
327
328
329	2.6. IANA Procedures for Registering URL scheme names
330
331	The IANA will only register URL scheme names in the IETF tree in
332	response to a communication from the IESG stating that a given
333	registration has been approved. Vendor and personal types will be
334	registered by the IANA automatically and without any formal review
335	as long as the following minimal conditions are met:
336
337	Scheme Name Syntax: The syntax of the requested scheme name
338	(including the assigned producer designation in the case of vendor
339	tree registrations), MUST conform to the syntax for such as
340	specified in RFC [URI-SYNTAX]. While encouraged, the syntax for the
341	actual scheme does not have to conform to the general syntax
342	specified in RFC [URI-SYNTAX].
343
344	Security Considerations: The application for registration of a
345	scheme name MUST include a discussion of the security
346	considerations inherent in the scheme.
347
348	Contact Person: The application MUST include accurate information
349	regarding a person to contact about the registration.
350
351	Author/Change Controller: The application must specify the author
352	and/or entity responsible for change control of the proposed scheme.
353
354	For vendor tree registrations, IANA will assign unique designations
355	to each producer registering one or more scheme names.
356
357
358	2.7. Change Control
359
360	Once a URL scheme name has been published by IANA, the author may
361	request a change to its definition. The descriptions of the
362	different registration trees above designate the "owners" of each
363	type of registration. The change request follows the same
364	procedure as the registration request:
365
366	(1) Publish the revised scheme syntax and semantics on the
367	ietf-types list.
368
369	(2) Leave at least two weeks for comments.
370
371	(3) Publish using IANA after formal review if required.
372
373	Changes should be requested only when there are serious omission or
374	errors in the published specification. When review is required, a
375	change request may be denied if it renders entities that were valid
376	under the previous definition invalid under the new definition.
377
378	The owner of a URL scheme registration may pass responsibility for
379	the registration to another person or agency by informing IANA and
380	the ietf-types list; this can be done without discussion or review.
381
382	The IESG may reassign responsibility for a URL scheme name. The
383	most common case of this will be to enable changes to be made to
384	schemes where the author of the registration has died, moved out of
385	contact or is otherwise unable to make changes that are important to
386	the community.
387
388	URL scheme name registrations may not be deleted; URL scheme names
389	which are no longer believed appropriate for use can be declared
390	OBSOLETE by a change to their "intended use" field; such URL scheme
391	names will be clearly marked in the lists published by IANA.
392
393
394	2.8. Registration Template
395
396	To: ietf-types@iana.org
397	Subject: Registration of URL Scheme Name <name>
398
399	URL Scheme Name:
400
401	Security considerations:
402
403	Interoperability considerations:
404
405	Published specification:
406
407	Applications which use this URL scheme name:
408
409	Additional information:
410
411	Person & email address to contact for further information:
412
413	Intended usage:
414
415	(One of COMMON, LIMITED USE or OBSOLETE)
416
417	Author/Change controller:
418
419	(Any other information that the author deems interesting may be
420	added below this line.)
421
422
423	3.0 Security Considerations
424
425	Information that creates or updates a registration needs to be
426	authenticated.
427
428	Information concerning possible security vulnerabilities of a
429	protocol may change over time. Consequently, claims as to the
430	security properties of a registered URL scheme may change as well.
431	As new vulnerabilities are discovered, information about such
432	vulnerabilities may need to be attached to existing registrations,
433	so that users are not misled as to the true security properties of a
434	registered URL scheme.
435
436	Delegations of a name space should only be assigned to someone with
437	adequate security.
438
439
440	4.0 References
441
442	[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
443	Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998
444
445	[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
446	"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998
447
448	[3] Postel, J., Reynolds, J., "Instructions to RFC Authors",
449	RFC 2223, October 1997.
450
451
452	5.0 Author's Address
453
454	Rich Petke
455	WorldCom Advanced Networks
456	5000 Britton Road
457	P. O. Box 5000
458	Hilliard, OH 43026-5000
459	USA
460
461	Phone: +1 614 723 4157
462	Fax: +1 614 723 1333
463	EMail: rpetke@compuserve.net
464
465
466	Appendix A -- Grandfathered URL Scheme Names
467
468	A number of URL scheme names, in use prior to 1998, would, if
469	registered under the guidelines in this document, be placed into
470	either the vendor or personal trees. Re-registration of those types
471	to reflect the appropriate trees is encouraged, but not required.
472	Ownership and change control principles outlined in this document
473	apply to those types as if they had been registered in the trees
474	described above.
475
476	ABOUT:
477
478	AOL:
479