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


INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-05.txt>    MCI WorldCom Advanced Networks
                                                                I. King
                                                  Microsoft Corporation
                                                       January 25, 1999


             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 learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.ietf.org (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet-Draft expires July 25, 1999.

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.


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 an existing tree can be shown to
   fail in providing for a clear and specific need of some sector of
   the community.  


3.0 Requirements for Scheme Name Registration

3.1 General Requirements

   All new URL scheme NAMES, regardless of registration tree, MUST
   conform to the syntax specified in RFC 2396 for scheme NAMES.


3.2 The IETF Tree

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

   In addition to having a conforming scheme NAME (see section 3.1),
   all new URL schemes registered in the IETF tree, MUST conform to the
   generic syntax for URLs as specified in RFC 2396.

   An analysis of the security issues inherent in the new URL scheme is
   REQUIRED.  (This is in accordance with the basic requirements for
   all IETF protocols.)  There is absolutely no requirement that all
   URL schemes registered in the IETF tree be secure or completely free
   from risks.  Nevertheless, all known security risks must be
   identified.

   The "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 are encouraged to conform
   to the generic URL syntax, RFC 2396, but are not required to do so.
   However, the tree's defining document must set forth the strength of
   this requirement.  

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

   While not required, an analysis of the security issues inherent in
   the new URL scheme is encouraged.  Regardless of what security
   analysis is or is not performed, all descriptions of security issues
   must be as accurate as possible.  In particular, a statement that
   there are "no security issues associated with this scheme" must not
   be confused with "the security issues associates with this scheme
   have not been assessed" 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

   Undocumented URL schemes created in an alternative tree 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.

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