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	wakaba	1.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