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

Ian King <iking@microsoft.com>
Speech Product Group
MICROSOFT CORPORATION

INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-07.txt>                UUNET Technologies
                                                                I. King
                                                  Microsoft Corporation
                                                        August 12, 1999

             Registration Procedures for URL Scheme Names

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.  Internet-Drafts
   are draft documents valid for a maximum of six months and may be
   updated, replaced, or obsoleted by other documents at any time.  It
   is inappropriate to use Internet-Drafts as reference material or to
   cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt. 
 
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this Internet-Draft is unlimited.

   This Internet-Draft expires March 12, 2000.

Copyright Notice

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

Abstract

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

1.0 Introduction

   A Uniform Resource Locator (URL) is a compact string representation
   of the location for a resource that is available via the Internet.
   RFC 2396 [1] defines the general syntax and semantics of URIs, and,
   by inclusion, URLs.  URLs are designated by including a "<scheme>:"
   and then a "<scheme-specific-part>".  Many URL schemes are already
   defined, however, new schemes may need to be defined in the future
   in order to accommodate new Internet protocols and/or procedures.

   A registration process is needed to ensure that the names of all
   such new schemes are guaranteed not to collide.  Further, the
   registration process ensures that URL schemes intended for wide
   spread, public use are developed in an orderly, well-specified, and
   public manner.

   This document defines the registration procedures to be followed
   when new URL schemes are created.  A separate document, RFC
   [URL-GUIDELINES], Guidelines for URL Schemes [2], provides
   guidelines for the creation of new URL schemes.  The primary focus
   of this document is on the <scheme> portion of new URL schemes,
   referred to as the "scheme name" throughout this document.

1.1 Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2.0 URL Scheme Name Registration Trees

2.1 General

   In order to increase the efficiency and flexibility of the URL
   scheme name registration process, the need is recognized for
   multiple registration "trees".  The registration requirements and
   specific registration procedures for each tree differ, allowing the
   overall registration procedure to accommodate the different natural
   requirements for URL schemes.  For example, a scheme that will be
   recommended for wide support and implementation by the Internet
   community requires a more complete review than a scheme intended to
   be used for resources associated with proprietary software.

   The first step in registering a new URL scheme name is to determine
   which registration tree the scheme should be registered in.
   Determination of the proper registration tree is based on the
   intended use for the new scheme and the desired syntax for the
   scheme name.

   This document will discuss in detail the tree that reflects current
   practice, under IETF ownership and control.  It will also set forth
   an outline to assist authors in creating new trees to address
   differing needs for wide acceptance and interoperability, ease of
   creation and use, and type and "strength" of ownership.

2.2 The IETF Tree

   The IETF tree is intended for URL schemes of general interest to the
   Internet community.  The tree exists for URL schemes that require a
   substantive review and approval process.  It is expected that
   applicability statements for particular applications will be
   published from time to time that recommend implementation of, and
   support for, URL schemes that have proven particularly useful in
   those contexts.

2.3 Additional Registration Trees

   From time to time and as required by the community, the IESG may
   create new top-level registration trees.  These trees may require
   significant, little or no registration, and may allow change control
   to rest in the hands of individuals or groups other than IETF.  A
   new tree should only be created if no existing tree can be shown to
   address the set of needs of some sector of the community.

3.0 Requirements for Scheme Name Registration

3.1 General Requirements

   All new URL schemes, regardless of registration tree, MUST conform
   to the generic syntax for URLs as specified in RFC 2396.

3.2 The IETF Tree

   Registration in the IETF tree requires publication of the URL scheme
   syntax and semantics in either an Informational or Standards Track
   RFC.

   The NAMES of schemes registered in the IETF tree MUST NOT contain
   the dash (also known as the hyphen and minus sign) character ('-')
   USASCII value 2Dh.  Use of this character can cause confusion with
   schemes registered in alternative trees (see section 3.3).

   An analysis of the security issues inherent in the new URL scheme
   is REQUIRED. (This is in accordance with the basic requirements for
   all IETF protocols.) URL schemes registered in the IETF tree should
   not introduce additional security risks into the Internet Architec-
   ture. For example, URLs should not embed information which should
   remain confidential, such as passwords, nor should new schemes
   subvert the security of existing schemes or protocols (i.e. by
   layering or tunneling).

   The "owner" of a URL scheme name registered in the IETF tree is
   assumed to be the IETF itself.  Modification or alteration of the
   specification requires the same level of processing (e.g.
   Informational or Standards Track RFC) as used for the initial
   registration.  Schemes originally defined via an Informational RFC
   may, however, be replaced with Standards Track documents.

3.3 Alternative Trees

   While public exposure and review of a URL scheme created in an
   alternative tree is not required, using the IETF Internet-Draft
   mechanism for peer review is strongly encouraged to improve the
   quality of the specification.  RFC publication of alternative 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]).

   The defining document for an alternative tree may require public
   exposure and/or review for schemes defined in that tree via a
   mechanism other than the IETF Internet-Draft mechanism.

   URL schemes created in an alternative tree must conform to the
   generic URL syntax, RFC 2396.  The tree's defining document may set
   forth additional syntax and semantics requirements above and
   beyond those specified in RFC 2396.

   All new URL schemes SHOULD follow the Guidelines for URL Schemes,
   set forth in RFC [URL-GUIDELINES] [2].

   An analysis of the security issues inherent in the new URL scheme is
   encouraged.  Regardless of what security analysis is or is not
   performed, all descriptions of security issues must be as accurate
   as possible.  In particular, a statement that there are "no security
   issues associated with this scheme" must not be confused with "the
   security issues associates with this scheme have not been assessed"
   or "the security issues associated with this scheme cannot be
   predicted because of <reason>".

   There is absolutely no requirement that URL schemes created in an
   alternative tree be secure or completely free from risks.
   Nevertheless, the tree's defining document must set forth the
   standard for security considerations, and in any event all known
   security risks SHOULD be identified.

   Change control must be defined for a new tree.  Change control may
   be vested in the IETF, or in an individual, group or other entity.
   The change control standard for the tree must be approved by the
   IESG.

   The syntax for alternative trees shall be as follows: each tree will
   be identified by a unique prefix, which must be established in the
   same fashion as a URL scheme name in the IETF tree, except that the
   prefix must be defined by a Standards Track document.  Scheme names
   in the new tree are then constructed by prepending the prefix to an
   identifier unique to each scheme in that tree, as prescribed by that
   tree's identifying document:

      <prefix>'-'<tree-specific identifier>

   For instance, the "foo" tree would allow creation of scheme names of
   the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
   an arbitrary USASCII string following the tree's unique prefix.

4.0 Registration Procedures

4.1 The IETF Tree

   The first step in registering a new URL scheme in the IETF tree is
   to publish an IETF Internet-Draft detailing the syntax and
   semantics of the proposed scheme.  The draft must, minimally,
   address all of the items covered by the template provided in section
   6 of this document.

   After all issues raised during a review period of no less than 4
   weeks have been addressed, submit the draft to the IESG for review.

   The IESG will review the proposed new scheme and either refer the
   scheme to a working group (existing or new) or directly present the
   scheme to the IESG for a last call.  In the former case, the working
   group is responsible for submitting a final version of the draft to
   the IESG for approval at such time as it has received adequate
   review and deliberation.

4.2 Alternative Trees

   Registration of URL schemes created in an alternative tree may be
   formal, through IETF documents, IANA registration, or other
   acknowledged organization; informal, through a mailing list or
   other publication mechanism; or nonexistent.  The registration
   mechanism must be documented for each alternative tree, and must be
   consistent for all URL scheme names created in that tree.

   It is the responsibility of the creator of the tree's registration
   requirements to establish that the registration mechanism is
   workable as described; it is within the discretion of the IESG to
   reject the document describing a tree if it determines the
   registration mechanism is impractical or creates an undue burden on
   a party who will not accept it.  (For instance, if an IANA
   registration mechanism is proposed, IESG might reject the tree if
   its mechanism would create undue liability on the part of IANA.)

   While the template in section 6 of this document is intended to
   apply to URL scheme names in the IETF tree, it is also offered as a
   guideline for those documenting alternative trees.

5.0 Change Control

5.1 Schemes in the IETF Tree

   URL schemes created in the IETF tree are "owned" by the IETF itself
   and may be changed, as needed, by updating the RFC that describes
   them.  Schemes described by Standards Track RFC but be replaced with
   new Standards Track RFCs.  Informational RFCs may be replaced by new
   Informational RFCs or Standards Track RFCs.

5.2 Schemes in Alternative Trees

   URL schemes in an alternative tree that are undocumented (as allowed
   by that tree's rules) may be changed by their owner at any time
   without notifying the IETF.

   URL schemes created in an alternative tree that have been documented
   by an Informational RFC, may be changed at any time by the owner,
   however, an updated Informational RFC which details the changes
   made, must be submitted to the IESG.

   The owner of a URL scheme registered in an alternative tree and
   documented by an Informational RFC may pass responsibility for the
   registration to another person or agency by informing the IESG.

   The IESG may reassign responsibility for a URL scheme registered in
   an alternative tree and documented by an Informational RFC.  The
   most common case of this will be to enable changes to be made to
   schemes where the scheme name is privately owned by the rules of its
   tree, and the owner of the scheme name has died, moved out of
   contact or is otherwise unable to make changes that are important to
   the community.

   The IESG may reclassify a URL scheme created in an alternative tree
   and documented via an Informational RFC as "historic" if it
   determines that the scheme is no longer in use.

6.0  Registration Template

   The following issues should be addressed when documenting a new URL
   scheme:

      URL scheme name.

      URL scheme syntax.  This should be expressed in a clear and
      concise manner.  The use of ABNF is encouraged.  Please refer to
      RFC [URL-GUIDELINES] for guidance on designing and explaining
      your scheme's syntax.

      Character encoding considerations.  It is important to identify
      what your scheme supports in this regard.  It is obvious that for
      interoperability, it is best if there is a means to support
      character sets beyond USASCII, but especially for private
      schemes, this may not be the case.

      Intended usage.  What sort of resource is being identified?  If
      this is not a 'resource' type of URL (e.g. mailto:), explain the
      action that should be initiated by the consumer of the URL.  If
      there is a MIME type associated with this resource, please
      identify it.

      Applications and/or protocols which use this URL scheme name.
      Including references to documentation which defines the
      applications and/or protocols cited is especially useful.

      Interoperability considerations.  If you are aware of any details
      regarding your scheme which might impact interoperability, please
      identify them here.  For example: proprietary or uncommon
      encoding method; inability to support multibyte character sets;
      incompatibility with types or versions of underlying protocol
      (if scheme is tunneled over another protocol).

      Security considerations.

      Relevant publications.

      Person & email address to contact for further information.

      Author/Change controller.

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

7.0 Security Considerations

   Information that creates or updates a registration needs to be
   authenticated.

   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URL scheme may change as well.
   As new vulnerabilities are discovered, information about such
   vulnerabilities may need to be attached to existing documentation,
   so that users are not misled as to the true security properties of a
   registered URL scheme.

   If the IESG agrees to delegate the registration and change control
   functions of an alternative tree to a group or individual outside of
   the IETF, that group or individual should have sufficient security
   procedures in place to authenticate registration changes.

8.0 References

   [1]  Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, 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.

9.0  Authors' Address

   Rich Petke
   UUNET Technologies
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000
   USA
   Phone: +1 614 723 4157
   Fax:   +1 614 723 8407
   Email: rpetke@wcom.net

   Ian King
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA
   Phone: +1 425-703-2293
   FAX: +1 425-936-7329
   Email: iking@microsoft.com
1	Ian King <iking@microsoft.com>
2	Speech Product Group
3	MICROSOFT CORPORATION
4
5	INTERNET-DRAFT R. Petke
6	<draft-ietf-urlreg-procedures-07.txt> UUNET Technologies
7	I. King
8	Microsoft Corporation
9	August 12, 1999
10
11	Registration Procedures for URL Scheme Names
12
13	Status of this Memo
14
15	This document is an Internet-Draft and is in full conformance with
16	all provisions of Section 10 of RFC2026. Internet-Drafts are
17	working documents of the Internet Engineering Task Force (IETF), its
18	areas, and its working groups. Note that other groups may also
19	distribute working documents as Internet-Drafts. Internet-Drafts
20	are draft documents valid for a maximum of six months and may be
21	updated, replaced, or obsoleted by other documents at any time. It
22	is inappropriate to use Internet-Drafts as reference material or to
23	cite them other than as "work in progress."
24
25	The list of current Internet-Drafts can be accessed at
26	http://www.ietf.org/ietf/1id-abstracts.txt.
27
28	The list of Internet-Draft Shadow Directories can be accessed at
29	http://www.ietf.org/shadow.html.
30
31	Distribution of this Internet-Draft is unlimited.
32
33	This Internet-Draft expires March 12, 2000.
34
35	Copyright Notice
36
37	Copyright (C) The Internet Society (1999). All Rights Reserved.
38
39	Abstract
40
41	This document defines the process by which new URL scheme names are
42	registered.
43
44	1.0 Introduction
45
46	A Uniform Resource Locator (URL) is a compact string representation
47	of the location for a resource that is available via the Internet.
48	RFC 2396 [1] defines the general syntax and semantics of URIs, and,
49	by inclusion, URLs. URLs are designated by including a "<scheme>:"
50	and then a "<scheme-specific-part>". Many URL schemes are already
51	defined, however, new schemes may need to be defined in the future
52	in order to accommodate new Internet protocols and/or procedures.
53
54	A registration process is needed to ensure that the names of all
55	such new schemes are guaranteed not to collide. Further, the
56	registration process ensures that URL schemes intended for wide
57	spread, public use are developed in an orderly, well-specified, and
58	public manner.
59
60	This document defines the registration procedures to be followed
61	when new URL schemes are created. A separate document, RFC
62	[URL-GUIDELINES], Guidelines for URL Schemes [2], provides
63	guidelines for the creation of new URL schemes. The primary focus
64	of this document is on the <scheme> portion of new URL schemes,
65	referred to as the "scheme name" throughout this document.
66
67	1.1 Notation
68
69	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
70	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
71	document are to be interpreted as described in RFC 2119.
72
73	2.0 URL Scheme Name Registration Trees
74
75	2.1 General
76
77	In order to increase the efficiency and flexibility of the URL
78	scheme name registration process, the need is recognized for
79	multiple registration "trees". The registration requirements and
80	specific registration procedures for each tree differ, allowing the
81	overall registration procedure to accommodate the different natural
82	requirements for URL schemes. For example, a scheme that will be
83	recommended for wide support and implementation by the Internet
84	community requires a more complete review than a scheme intended to
85	be used for resources associated with proprietary software.
86
87	The first step in registering a new URL scheme name is to determine
88	which registration tree the scheme should be registered in.
89	Determination of the proper registration tree is based on the
90	intended use for the new scheme and the desired syntax for the
91	scheme name.
92
93	This document will discuss in detail the tree that reflects current
94	practice, under IETF ownership and control. It will also set forth
95	an outline to assist authors in creating new trees to address
96	differing needs for wide acceptance and interoperability, ease of
97	creation and use, and type and "strength" of ownership.
98
99	2.2 The IETF Tree
100
101	The IETF tree is intended for URL schemes of general interest to the
102	Internet community. The tree exists for URL schemes that require a
103	substantive review and approval process. It is expected that
104	applicability statements for particular applications will be
105	published from time to time that recommend implementation of, and
106	support for, URL schemes that have proven particularly useful in
107	those contexts.
108
109	2.3 Additional Registration Trees
110
111	From time to time and as required by the community, the IESG may
112	create new top-level registration trees. These trees may require
113	significant, little or no registration, and may allow change control
114	to rest in the hands of individuals or groups other than IETF. A
115	new tree should only be created if no existing tree can be shown to
116	address the set of needs of some sector of the community.
117
118	3.0 Requirements for Scheme Name Registration
119
120	3.1 General Requirements
121
122	All new URL schemes, regardless of registration tree, MUST conform
123	to the generic syntax for URLs as specified in RFC 2396.
124
125	3.2 The IETF Tree
126
127	Registration in the IETF tree requires publication of the URL scheme
128	syntax and semantics in either an Informational or Standards Track
129	RFC.
130
131	The NAMES of schemes registered in the IETF tree MUST NOT contain
132	the dash (also known as the hyphen and minus sign) character ('-')
133	USASCII value 2Dh. Use of this character can cause confusion with
134	schemes registered in alternative trees (see section 3.3).
135
136	An analysis of the security issues inherent in the new URL scheme
137	is REQUIRED. (This is in accordance with the basic requirements for
138	all IETF protocols.) URL schemes registered in the IETF tree should
139	not introduce additional security risks into the Internet Architec-
140	ture. For example, URLs should not embed information which should
141	remain confidential, such as passwords, nor should new schemes
142	subvert the security of existing schemes or protocols (i.e. by
143	layering or tunneling).
144
145	The "owner" of a URL scheme name registered in the IETF tree is
146	assumed to be the IETF itself. Modification or alteration of the
147	specification requires the same level of processing (e.g.
148	Informational or Standards Track RFC) as used for the initial
149	registration. Schemes originally defined via an Informational RFC
150	may, however, be replaced with Standards Track documents.
151
152	3.3 Alternative Trees
153
154	While public exposure and review of a URL scheme created in an
155	alternative tree is not required, using the IETF Internet-Draft
156	mechanism for peer review is strongly encouraged to improve the
157	quality of the specification. RFC publication of alternative tree
158	URL schemes is encouraged but not required. Material may be
159	published as an Informational RFC by sending it to the RFC Editor
160	(please follow the instructions to RFC authors, RFC 2223 [3]).
161
162	The defining document for an alternative tree may require public
163	exposure and/or review for schemes defined in that tree via a
164	mechanism other than the IETF Internet-Draft mechanism.
165
166	URL schemes created in an alternative tree must conform to the
167	generic URL syntax, RFC 2396. The tree's defining document may set
168	forth additional syntax and semantics requirements above and
169	beyond those specified in RFC 2396.
170
171	All new URL schemes SHOULD follow the Guidelines for URL Schemes,
172	set forth in RFC [URL-GUIDELINES] [2].
173
174	An analysis of the security issues inherent in the new URL scheme is
175	encouraged. Regardless of what security analysis is or is not
176	performed, all descriptions of security issues must be as accurate
177	as possible. In particular, a statement that there are "no security
178	issues associated with this scheme" must not be confused with "the
179	security issues associates with this scheme have not been assessed"
180	or "the security issues associated with this scheme cannot be
181	predicted because of <reason>".
182
183	There is absolutely no requirement that URL schemes created in an
184	alternative tree be secure or completely free from risks.
185	Nevertheless, the tree's defining document must set forth the
186	standard for security considerations, and in any event all known
187	security risks SHOULD be identified.
188
189	Change control must be defined for a new tree. Change control may
190	be vested in the IETF, or in an individual, group or other entity.
191	The change control standard for the tree must be approved by the
192	IESG.
193
194	The syntax for alternative trees shall be as follows: each tree will
195	be identified by a unique prefix, which must be established in the
196	same fashion as a URL scheme name in the IETF tree, except that the
197	prefix must be defined by a Standards Track document. Scheme names
198	in the new tree are then constructed by prepending the prefix to an
199	identifier unique to each scheme in that tree, as prescribed by that
200	tree's identifying document:
201
202	<prefix>'-'<tree-specific identifier>
203
204	For instance, the "foo" tree would allow creation of scheme names of
205	the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
206	an arbitrary USASCII string following the tree's unique prefix.
207
208	4.0 Registration Procedures
209
210	4.1 The IETF Tree
211
212	The first step in registering a new URL scheme in the IETF tree is
213	to publish an IETF Internet-Draft detailing the syntax and
214	semantics of the proposed scheme. The draft must, minimally,
215	address all of the items covered by the template provided in section
216	6 of this document.
217
218	After all issues raised during a review period of no less than 4
219	weeks have been addressed, submit the draft to the IESG for review.
220
221	The IESG will review the proposed new scheme and either refer the
222	scheme to a working group (existing or new) or directly present the
223	scheme to the IESG for a last call. In the former case, the working
224	group is responsible for submitting a final version of the draft to
225	the IESG for approval at such time as it has received adequate
226	review and deliberation.
227
228	4.2 Alternative Trees
229
230	Registration of URL schemes created in an alternative tree may be
231	formal, through IETF documents, IANA registration, or other
232	acknowledged organization; informal, through a mailing list or
233	other publication mechanism; or nonexistent. The registration
234	mechanism must be documented for each alternative tree, and must be
235	consistent for all URL scheme names created in that tree.
236
237	It is the responsibility of the creator of the tree's registration
238	requirements to establish that the registration mechanism is
239	workable as described; it is within the discretion of the IESG to
240	reject the document describing a tree if it determines the
241	registration mechanism is impractical or creates an undue burden on
242	a party who will not accept it. (For instance, if an IANA
243	registration mechanism is proposed, IESG might reject the tree if
244	its mechanism would create undue liability on the part of IANA.)
245
246	While the template in section 6 of this document is intended to
247	apply to URL scheme names in the IETF tree, it is also offered as a
248	guideline for those documenting alternative trees.
249
250	5.0 Change Control
251
252	5.1 Schemes in the IETF Tree
253
254	URL schemes created in the IETF tree are "owned" by the IETF itself
255	and may be changed, as needed, by updating the RFC that describes
256	them. Schemes described by Standards Track RFC but be replaced with
257	new Standards Track RFCs. Informational RFCs may be replaced by new
258	Informational RFCs or Standards Track RFCs.
259
260	5.2 Schemes in Alternative Trees
261
262	URL schemes in an alternative tree that are undocumented (as allowed
263	by that tree's rules) may be changed by their owner at any time
264	without notifying the IETF.
265
266	URL schemes created in an alternative tree that have been documented
267	by an Informational RFC, may be changed at any time by the owner,
268	however, an updated Informational RFC which details the changes
269	made, must be submitted to the IESG.
270
271	The owner of a URL scheme registered in an alternative tree and
272	documented by an Informational RFC may pass responsibility for the
273	registration to another person or agency by informing the IESG.
274
275	The IESG may reassign responsibility for a URL scheme registered in
276	an alternative tree and documented by an Informational RFC. The
277	most common case of this will be to enable changes to be made to
278	schemes where the scheme name is privately owned by the rules of its
279	tree, and the owner of the scheme name has died, moved out of
280	contact or is otherwise unable to make changes that are important to
281	the community.
282
283	The IESG may reclassify a URL scheme created in an alternative tree
284	and documented via an Informational RFC as "historic" if it
285	determines that the scheme is no longer in use.
286
287	6.0 Registration Template
288
289	The following issues should be addressed when documenting a new URL
290	scheme:
291
292	URL scheme name.
293
294	URL scheme syntax. This should be expressed in a clear and
295	concise manner. The use of ABNF is encouraged. Please refer to
296	RFC [URL-GUIDELINES] for guidance on designing and explaining
297	your scheme's syntax.
298
299	Character encoding considerations. It is important to identify
300	what your scheme supports in this regard. It is obvious that for
301	interoperability, it is best if there is a means to support
302	character sets beyond USASCII, but especially for private
303	schemes, this may not be the case.
304
305	Intended usage. What sort of resource is being identified? If
306	this is not a 'resource' type of URL (e.g. mailto:), explain the
307	action that should be initiated by the consumer of the URL. If
308	there is a MIME type associated with this resource, please
309	identify it.
310
311	Applications and/or protocols which use this URL scheme name.
312	Including references to documentation which defines the
313	applications and/or protocols cited is especially useful.
314
315	Interoperability considerations. If you are aware of any details
316	regarding your scheme which might impact interoperability, please
317	identify them here. For example: proprietary or uncommon
318	encoding method; inability to support multibyte character sets;
319	incompatibility with types or versions of underlying protocol
320	(if scheme is tunneled over another protocol).
321
322	Security considerations.
323
324	Relevant publications.
325
326	Person & email address to contact for further information.
327
328	Author/Change controller.
329
330	Applications and/or protocols which use this URL scheme name.
331
332	7.0 Security Considerations
333
334	Information that creates or updates a registration needs to be
335	authenticated.
336
337	Information concerning possible security vulnerabilities of a
338	protocol may change over time. Consequently, claims as to the
339	security properties of a registered URL scheme may change as well.
340	As new vulnerabilities are discovered, information about such
341	vulnerabilities may need to be attached to existing documentation,
342	so that users are not misled as to the true security properties of a
343	registered URL scheme.
344
345	If the IESG agrees to delegate the registration and change control
346	functions of an alternative tree to a group or individual outside of
347	the IETF, that group or individual should have sufficient security
348	procedures in place to authenticate registration changes.
349
350	8.0 References
351
352	[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
353	Identifiers (URI): Generic Syntax", RFC 2396, August 1998
354
355	[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
356	"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August
357	1998
358
359	[3] Postel, J., Reynolds, J., "Instructions to RFC Authors",
360	RFC 2223, October 1997.
361
362	9.0 Authors' Address
363
364	Rich Petke
365	UUNET Technologies
366	5000 Britton Road
367	P. O. Box 5000
368	Hilliard, OH 43026-5000
369	USA
370	Phone: +1 614 723 4157
371	Fax: +1 614 723 8407
372	Email: rpetke@wcom.net
373
374	Ian King
375	Microsoft Corporation
376	One Microsoft Way
377	Redmond, WA 98052-6399
378	USA
379	Phone: +1 425-703-2293
380	FAX: +1 425-936-7329
381	Email: iking@microsoft.com