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


INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-04.txt>     MCIWORLDCOM Advanced Networks
                                                       November 1, 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 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 April 30, 1999.

   Copyright Notice

   Copyright (C) The Internet Society (1998).  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, two different registration "trees"
   have been created.  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.

   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.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 The OID Tree

   The OID tree is intended for URL schemes which will be used in a
   proprietary manner.  The trees exists to provide a mechanism for
   ensuring that scheme names do not collide.  The syntax and semantics
   of URL schemes created in the OID tree do not have to be reviewed or
   publicly disclosed.

   Creating a URL scheme name in the OID tree does not imply
   endorsement, approval, or recommendation by the IETF or even
   certification that the specification is adequate, even if the scheme
   was published as an IETF Internet-Draft and/or reviewed by IETF
   participants.  To become Internet Standards, protocols, data
   objects, or whatever must go through the IETF standards process and
   registration in the IETF tree.


2.4 Additional Registration Trees

   From time to time and as required by the community, the IESG may
   create new top-level registration trees.  


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 The OID Tree

   While public exposure and review of a URL scheme created in the OID
   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 OID tree URL schemes is
   encouraged but not required.  Material may be published as an
   Informational RFC by sending it to the RFC Editor (please follow the
   instructions to RFC authors, RFC 2223 [3]).

   URL schemes created in the OID tree are encouraged to conform to the
   generic URL syntax, RFC 2396, but are not required to do so.

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

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

   There is absolutely no requirement that URL schemes created in the
   OID tree be secure or completely free from risks.  Nevertheless, all
   known security risks SHOULD be identified.

   The registration of a URL scheme created in the OID tree formally
   belongs to the entity to which the OID is assigned.  Changes to the
   specification of an OID tree URL scheme which is documented by an
   Informational RFC shall only be accepted from the owner of the OID
   or with the permission of the owner of the OID.

   The syntax of URL scheme names for schemes created in the OID tree
   is simply the text string "OID-" followed by the numeric OID
   including any embedded hyphens.  URL scheme names are case
   insensitive so the letters in the text string "OID-" need not be
   capitalized.  No variations on this formula are permitted.

   Examples of valid URL scheme names in the OID tree:

      OID-2-16-840-1-113779-2-1:
      Oid-2-16-840-1-113779-2-1-100:
      OiD-2-16-840-1-113779-3:
      oid-2-16-840-1-113779-123:


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 The OID Tree

   Registration of URL schemes created in the OID tree is automatic
   because the scheme name is based on a previously registered entity,
   an OID.  There is no requirement to publish any documentation for
   the URL scheme, however, doing so may be advantageous and is
   encouraged.

   The recommended form for documenting a URL scheme created in the OID
   tree is via an Informational RFC.  The RFC should address all of the
   items covered by the template provided in section 6 of this
   document.


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 the OID Tree

   Undocumented URL schemes created in the OID tree may be changed by
   their owner at any time without notifying the IETF.

   URL schemes created in the OID 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 the OID 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
   the OID tree and documented by an Informational RFC.  The most
   common case of this will be to enable changes to be made to schemes
   where the owner of the OID has died, moved out of contact or is
   otherwise unable to make changes that are important to the
   community.

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


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.


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  Author's Address

   Rich Petke
   MCIWORLDCOM 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


Appendix A -- Grandfathered URL Scheme Names

   A number of URL scheme names, in use prior to 1998, would, if
   registered under the procedures specified in this document, be
   placed into the OID tree.  Re-registration of those types to reflect
   the appropriate tree or documentation of the schemes in an
   Informational RFC 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 OID tree.


      ABOUT:  (No information available at this time.)

      AOL:  (No information available at this time.)

1
2	INTERNET-DRAFT R. Petke
3	<draft-ietf-urlreg-procedures-04.txt> MCIWORLDCOM Advanced Networks
4	November 1, 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 learn the current status of any Internet-Draft, please check the
25	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
26	Directories on ftp.ietf.org (US East Coast), nic.nordu.net
27	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
28	Rim).
29
30	Distribution of this memo is unlimited.
31
32	This Internet-Draft expires April 30, 1999.
33
34	Copyright Notice
35
36	Copyright (C) The Internet Society (1998). All Rights Reserved.
37
38	Abstract
39
40	This document defines the process by which new URL scheme names are
41	registered.
42
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
68	2.0 URL Scheme Name Registration Trees
69
70	2.1 General
71
72	In order to increase the efficiency and flexibility of the URL
73	scheme name registration process, two different registration "trees"
74	have been created. The registration requirements and specific
75	registration procedures for each tree differ, allowing the overall
76	registration procedure to accommodate the different natural
77	requirements for URL schemes. For example, a scheme that will be
78	recommended for wide support and implementation by the Internet
79	community requires a more complete review than a scheme intended to
80	be used for resources associated with proprietary software.
81
82	The first step in registering a new URL scheme name is to determine
83	which registration tree the scheme should be registered in.
84	Determination of the proper registration tree is based on the
85	intended use for the new scheme and the desired syntax for the
86	scheme name.
87
88	Note that some URL schemes defined prior to this document do not
89	conform to the naming conventions described below. See Appendix A
90	for a discussion of those schemes.
91
92
93	2.2 The IETF Tree
94
95	The IETF tree is intended for URL schemes of general interest to the
96	Internet community. The tree exists for URL schemes that require a
97	substantive review and approval process. It is expected that
98	applicability statements for particular applications will be
99	published from time to time that recommend implementation of, and
100	support for, URL schemes that have proven particularly useful in
101	those contexts.
102
103
104	2.3 The OID Tree
105
106	The OID tree is intended for URL schemes which will be used in a
107	proprietary manner. The trees exists to provide a mechanism for
108	ensuring that scheme names do not collide. The syntax and semantics
109	of URL schemes created in the OID tree do not have to be reviewed or
110	publicly disclosed.
111
112	Creating a URL scheme name in the OID tree does not imply
113	endorsement, approval, or recommendation by the IETF or even
114	certification that the specification is adequate, even if the scheme
115	was published as an IETF Internet-Draft and/or reviewed by IETF
116	participants. To become Internet Standards, protocols, data
117	objects, or whatever must go through the IETF standards process and
118	registration in the IETF tree.
119
120
121	2.4 Additional Registration Trees
122
123	From time to time and as required by the community, the IESG may
124	create new top-level registration trees.
125
126
127	3.0 Requirements for Scheme Name Registration
128
129	3.1 General Requirements
130
131	All new URL scheme NAMES, regardless of registration tree, MUST
132	conform to the syntax specified in RFC 2396 for scheme NAMES.
133
134
135	3.2 The IETF Tree
136
137	Registration in the IETF tree requires publication of the URL scheme
138	syntax and semantics in either an Informational or Standards Track
139	RFC.
140
141	In addition to having a conforming scheme NAME (see section 3.1),
142	all new URL schemes registered in the IETF tree, MUST conform to the
143	generic syntax for URLs as specified in RFC 2396.
144
145	An analysis of the security issues inherent in the new URL scheme is
146	REQUIRED. (This is in accordance with the basic requirements for
147	all IETF protocols.) There is absolutely no requirement that all
148	URL schemes registered in the IETF tree be secure or completely free
149	from risks. Nevertheless, all known security risks must be
150	identified.
151
152	The "owner" of a URL scheme name registered in the IETF tree is
153	assumed to be the IETF itself. Modification or alteration of the
154	specification requires the same level of processing (e.g.
155	Informational or Standards Track RFC) as used for the initial
156	registration. Schemes originally defined via an Informational RFC
157	may, however, be replaced with Standards Track documents.
158
159
160	3.3 The OID Tree
161
162	While public exposure and review of a URL scheme created in the OID
163	tree is not required, using the IETF Internet-Draft mechanism for
164	peer review is strongly encouraged to improve the quality of the
165	specification. RFC publication of OID tree URL schemes is
166	encouraged but not required. Material may be published as an
167	Informational RFC by sending it to the RFC Editor (please follow the
168	instructions to RFC authors, RFC 2223 [3]).
169
170	URL schemes created in the OID tree are encouraged to conform to the
171	generic URL syntax, RFC 2396, but are not required to do so.
172
173	All new URL schemes SHOULD follow the Guidelines for URL Schemes,
174	set forth in RFC [URL-GUIDELINES] [2].
175
176	While not required, an analysis of the security issues inherent in
177	the new URL scheme is encouraged. Regardless of what security
178	analysis is or is not performed, all descriptions of security issues
179	must be as accurate as possible. In particular, a statement that
180	there are "no security issues associated with this scheme" must not
181	be confused with "the security issues associates with this scheme
182	have not been assessed".
183
184	There is absolutely no requirement that URL schemes created in the
185	OID tree be secure or completely free from risks. Nevertheless, all
186	known security risks SHOULD be identified.
187
188	The registration of a URL scheme created in the OID tree formally
189	belongs to the entity to which the OID is assigned. Changes to the
190	specification of an OID tree URL scheme which is documented by an
191	Informational RFC shall only be accepted from the owner of the OID
192	or with the permission of the owner of the OID.
193
194	The syntax of URL scheme names for schemes created in the OID tree
195	is simply the text string "OID-" followed by the numeric OID
196	including any embedded hyphens. URL scheme names are case
197	insensitive so the letters in the text string "OID-" need not be
198	capitalized. No variations on this formula are permitted.
199
200	Examples of valid URL scheme names in the OID tree:
201
202	OID-2-16-840-1-113779-2-1:
203	Oid-2-16-840-1-113779-2-1-100:
204	OiD-2-16-840-1-113779-3:
205	oid-2-16-840-1-113779-123:
206
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
229	4.2 The OID Tree
230
231	Registration of URL schemes created in the OID tree is automatic
232	because the scheme name is based on a previously registered entity,
233	an OID. There is no requirement to publish any documentation for
234	the URL scheme, however, doing so may be advantageous and is
235	encouraged.
236
237	The recommended form for documenting a URL scheme created in the OID
238	tree is via an Informational RFC. The RFC should address all of the
239	items covered by the template provided in section 6 of this
240	document.
241
242
243	5.0 Change Control
244
245	5.1 Schemes in the IETF Tree
246
247	URL schemes created in the IETF tree are "owned" by the IETF itself
248	and may be changed, as needed, by updating the RFC that describes
249	them. Schemes described by Standards Track RFC but be replaced with
250	new Standards Track RFCs. Informational RFCs may be replaced by new
251	Informational RFCs or Standards Track RFCs.
252
253
254	5.2 Schemes in the OID Tree
255
256	Undocumented URL schemes created in the OID tree may be changed by
257	their owner at any time without notifying the IETF.
258
259	URL schemes created in the OID tree that have been documented by an
260	Informational RFC, may be changed at any time by the owner, however,
261	an updated Informational RFC which details the changes made, must be
262	submitted to the IESG.
263
264	The owner of a URL scheme registered in the OID tree and documented
265	by an Informational RFC may pass responsibility for the registration
266	to another person or agency by informing the IESG.
267
268	The IESG may reassign responsibility for a URL scheme registered in
269	the OID tree and documented by an Informational RFC. The most
270	common case of this will be to enable changes to be made to schemes
271	where the owner of the OID has died, moved out of contact or is
272	otherwise unable to make changes that are important to the
273	community.
274
275	The IESG may reclassify a URL scheme created in the OID tree and
276	documented via an Informational RFC as "historic" if it determines
277	that the scheme is no longer in use.
278
279
280	6.0 Registration Template
281
282	The following issues should be addressed when documenting a new URL
283	scheme:
284
285	URL scheme name.
286
287	URL scheme syntax. This should be expressed in a clear and
288	concise manner. The use of ABNF is encouraged. Please refer to
289	RFC [URL-GUIDELINES] for guidance on designing and explaining
290	your scheme's syntax.
291
292	Character encoding considerations. It is important to identify
293	what your scheme supports in this regard. It is obvious that for
294	interoperability, it is best if there is a means to support
295	character sets beyond USASCII, but especially for private
296	schemes, this may not be the case.
297
298	Intended usage. What sort of resource is being identified? If
299	this is not a 'resource' type of URL (e.g. mailto:), explain the
300	action that should be initiated by the consumer of the URL. If
301	there is a MIME type associated with this resource, please
302	identify it.
303
304	Applications and/or protocols which use this URL scheme name.
305
306	Interoperability considerations. If you are aware of any details
307	regarding your scheme which might impact interoperability, please
308	identify them here. For example: proprietary or uncommon
309	encoding method; inability to support multibyte character sets;
310	incompatibility with types or versions of underlying protocol
311	(if scheme is tunneled over another protocol).
312
313	Security considerations.
314
315	Relevant publications.
316
317	Person & email address to contact for further information.
318
319	Author/Change controller.
320
321
322	Applications and/or protocols which use this URL scheme name.
323
324
325
326	7.0 Security Considerations
327
328	Information that creates or updates a registration needs to be
329	authenticated.
330
331	Information concerning possible security vulnerabilities of a
332	protocol may change over time. Consequently, claims as to the
333	security properties of a registered URL scheme may change as well.
334	As new vulnerabilities are discovered, information about such
335	vulnerabilities may need to be attached to existing documentation,
336	so that users are not misled as to the true security properties of a
337	registered URL scheme.
338
339
340	8.0 References
341
342	[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
343	Identifiers (URI): Generic Syntax", RFC 2396, August 1998
344
345	[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
346	"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August
347	1998
348
349	[3] Postel, J., Reynolds, J., "Instructions to RFC Authors",
350	RFC 2223, October 1997.
351
352
353	9.0 Author's Address
354
355	Rich Petke
356	MCIWORLDCOM Advanced Networks
357	5000 Britton Road
358	P. O. Box 5000
359	Hilliard, OH 43026-5000
360	USA
361
362	Phone: +1 614 723 4157
363	Fax: +1 614 723 8407
364	EMail: rpetke@wcom.net
365
366
367	Appendix A -- Grandfathered URL Scheme Names
368
369	A number of URL scheme names, in use prior to 1998, would, if
370	registered under the procedures specified in this document, be
371	placed into the OID tree. Re-registration of those types to reflect
372	the appropriate tree or documentation of the schemes in an
373	Informational RFC is encouraged, but not required. Ownership and
374	change control principles outlined in this document apply to those
375	types as if they had been registered in the OID tree.
376
377
378	ABOUT: (No information available at this time.)
379
380	AOL: (No information available at this time.)
381