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


INTERNET-DRAFT                                               Rich Petke
<draft-ietf-urlreg-procedures-01.txt>       CompuServe Network Services
                                                         April 30, 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 October 31, 1998.


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] 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 for which there is not currently a URL scheme registered.
   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.funnypictures).

   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.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/" and
   all registered URL scheme names will be listed in the periodically
   issued "Assigned Numbers" RFC [currently STD 2, RFC 1700].  The
   scheme syntax and semantics description and other supporting
   material may also be published as an Informational RFC by sending it
   to "rfc-editor@isi.edu" (please follow the instructions to RFC
   authors [RFC-1543]).


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:

     o Security considerations
     o TBD


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 template 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 XXX

     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

   RFC [URI-SYNTAX]

   RFC [URL-GUIDELINES]


5.0  Author's Address

   Rich Petke
   CNS/WorldCom
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 430
   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.

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