1 |
|
2 |
INTERNET-DRAFT R. Petke |
3 |
<draft-ietf-urlreg-procedures-03.txt> WorldCom Advanced Networks |
4 |
August 7, 1998 |
5 |
|
6 |
|
7 |
|
8 |
Registration Procedures for URL Scheme Names |
9 |
|
10 |
|
11 |
|
12 |
Status of this Memo |
13 |
|
14 |
This document is an Internet-Draft. Internet-Drafts are working |
15 |
documents of the Internet Engineering Task Force (IETF), its areas, |
16 |
and its working groups. Note that other groups may also distribute |
17 |
working documents as Internet-Drafts. |
18 |
|
19 |
Internet-Drafts are draft documents valid for a maximum of six |
20 |
months and may be updated, replaced, or obsoleted by other documents |
21 |
at any time. It is inappropriate to use Internet-Drafts as |
22 |
reference material or to cite them other than as "work in progress." |
23 |
|
24 |
To view the entire list of current Internet-Drafts, please check |
25 |
the "1id-abstracts.txt" listing contained in the Internet-Drafts |
26 |
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net |
27 |
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au |
28 |
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu |
29 |
(US West Coast). |
30 |
|
31 |
Distribution of this memo is unlimited. |
32 |
|
33 |
This Internet Draft expires February 7, 1999. |
34 |
|
35 |
Copyright Notice |
36 |
|
37 |
Copyright (C) The Internet Society (1998). All Rights Reserved. |
38 |
|
39 |
Abstract |
40 |
|
41 |
This document defines the process by which new URL schemes are |
42 |
registered. |
43 |
|
44 |
|
45 |
1.0 Introduction |
46 |
|
47 |
A Uniform Resource Locator (URL) is a compact string representation |
48 |
of the location for a resource that is available via the Internet. |
49 |
RFC [URI-SYNTAX] [1] defines the general syntax and semantics of |
50 |
URIs, and, by inclusion, URLs. URLs are designated by including a |
51 |
"<scheme>:" and then a "<scheme-specific-part>". Many URL schemes |
52 |
are already defined, however, new schemes may need to be defined in |
53 |
the future in order to accommodate new Internet protocols and/or |
54 |
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 registration procedures which use the Internet |
63 |
Assigned Numbers Authority (IANA) as a central registry for such URL |
64 |
scheme names and the IETF RFC mechanism for scheme review, where |
65 |
appropriate. |
66 |
|
67 |
|
68 |
2.0 URL Scheme Name Registration |
69 |
|
70 |
In order to increase the efficiency and flexibility of the URL |
71 |
scheme name registration process, several different registration |
72 |
"trees" have been created. The registration requirements and |
73 |
specific registration procedures for each tree differ, allowing the |
74 |
overall registration procedure to accommodate the different natural |
75 |
requirements for URL schemes. For example, a scheme that will be |
76 |
recommended for wide support and implementation by the Internet |
77 |
Community requires a more complete review, prior to registration, |
78 |
than a scheme intended to be used for resources associated with |
79 |
proprietary software. |
80 |
|
81 |
Each of the URL scheme name registration trees also imparts a |
82 |
specific syntax to the scheme name being registered. |
83 |
|
84 |
Registration of a new URL scheme name may occur in any ONE of the |
85 |
established registration trees. |
86 |
|
87 |
The first step in registering a new URL scheme name is to determine |
88 |
which registration tree the scheme should be registered in. |
89 |
Determination of the proper registration tree is based on the |
90 |
intended use for the new scheme, the desired syntax for the scheme |
91 |
name, and the ability to meet the registration requirements for the |
92 |
desired tree. |
93 |
|
94 |
Note that some URL schemes defined prior to this document do not |
95 |
conform to the naming conventions described below. See Appendix A |
96 |
for a discussion of those schemes. |
97 |
|
98 |
The following subsections define the registration trees available at |
99 |
this time, the purpose of each tree, the requirements for |
100 |
registration in each tree, and the associated URL scheme name |
101 |
formats that are applied to names registered in each tree. |
102 |
|
103 |
|
104 |
2.1 General Requirements |
105 |
|
106 |
All new URL scheme NAMES, regardless of registration tree, MUST |
107 |
conform to the syntax specified in RFC [URI-SYNTAX] for scheme |
108 |
names. |
109 |
|
110 |
|
111 |
2.2 The IETF Tree |
112 |
|
113 |
2.2.1 Purpose |
114 |
|
115 |
The IETF tree is intended for URL schemes of general interest to the |
116 |
Internet Community. The tree exists for URL schemes that require a |
117 |
substantive review and approval process; the vendor and personal |
118 |
trees exist for those that do not. It is expected that |
119 |
applicability statements for particular applications will be |
120 |
published from time to time that recommend implementation of, and |
121 |
support for, URL schemes that have proven particularly useful in |
122 |
those contexts. |
123 |
|
124 |
2.2.2 Registration Requirements |
125 |
|
126 |
Registration in the IETF tree requires approval by the IESG and |
127 |
publication of the URL scheme syntax and semantics as some form of |
128 |
RFC, usually a standards track RFC. |
129 |
|
130 |
All new URL schemes registered in the IETF tree, MUST conform to the |
131 |
generic syntax for URLs as specified in RFC [URI-SYNTAX]. |
132 |
|
133 |
An analysis of the security issues inherent in the new URL scheme is |
134 |
REQUIRED. (This is in accordance with the basic requirements for |
135 |
all IETF protocols.) There is absolutely no requirement that all |
136 |
URL schemes registered in the IETF tree be secure or completely free |
137 |
from risks. Nevertheless, all known security risks must be |
138 |
identified. |
139 |
|
140 |
The security considerations section of all registrations is subject |
141 |
to continuing evaluation and modification, and in particular may be |
142 |
extended by use of the "comments on URL scheme names" mechanism |
143 |
described in section 4.0. |
144 |
|
145 |
2.2.3 Ownership |
146 |
|
147 |
The "owner" of a URL scheme name registration in the IETF tree is |
148 |
assumed to be the IETF itself. Modification or alteration of the |
149 |
specification requires the same level of processing (e.g. standards |
150 |
track) as required for the initial registration. |
151 |
|
152 |
2.2.4 Syntax of URL Scheme Names |
153 |
|
154 |
URL scheme names in the IETF tree are normally denoted by names that |
155 |
are not explicitly faceted, i.e., do not contain period (".") |
156 |
characters. For example, "http", "ftp", "mailto", etc. |
157 |
|
158 |
|
159 |
2.3 The Vendor Tree |
160 |
|
161 |
2.3.1 Purpose |
162 |
|
163 |
The vendor tree is used for URL schemes associated with commercially |
164 |
available products. "Vendor" or "producer" are construed as |
165 |
equivalent and very broadly in this context. |
166 |
|
167 |
A registration may be placed in the vendor tree by anyone who needs |
168 |
to identify a scheme for (1) specifying the location of a resource |
169 |
available via the Internet (2) which may be accessed using a |
170 |
protocol (or mechanism) for which there is not currently a URL |
171 |
scheme registered in the IETF tree. |
172 |
|
173 |
The registration of a URL scheme name in the vendor tree does not |
174 |
imply endorsement, approval, or recommendation by IANA or IETF or |
175 |
even certification that the specification is adequate. To become |
176 |
Internet Standards, protocol, data objects, or whatever must go |
177 |
through the IETF standards process and the registration in the IETF |
178 |
tree. |
179 |
|
180 |
2.3.2 Registration Requirements |
181 |
|
182 |
RFC publication of vendor URL schemes is encouraged but not |
183 |
required. Material may be published as an Informational RFC by |
184 |
sending it to the RFC Editor (please follow the instructions to RFC |
185 |
authors, RFC-2223 [3]). |
186 |
|
187 |
While public exposure and review of URL scheme names to be |
188 |
registered in the vendor tree is not required, using the |
189 |
ietf-url-schemes list for review is strongly encouraged to improve |
190 |
the quality of those specifications. |
191 |
|
192 |
URL schemes registered in the vendor tree are encouraged to conform |
193 |
to the generic URL syntax but are not required to do so in order to |
194 |
be registered. |
195 |
|
196 |
All new URL schemes SHOULD follow the Guidelines for URL Schemes, |
197 |
set forth in RFC [URL-GUIDELINES] [2]. |
198 |
|
199 |
While not required, an analysis of the security issues inherent in |
200 |
the new URL scheme is encouraged. Regardless of what security |
201 |
analysis is or is not performed, all descriptions of security issues |
202 |
must be as accurate as possible. In particular, a statement that |
203 |
there are "no security issues associated with this scheme" must not |
204 |
be confused with "the security issues associates with this scheme |
205 |
have not been assessed". |
206 |
|
207 |
There is absolutely no requirement that URL schemes registered in |
208 |
the vendor tree be secure or completely free from risks. |
209 |
Nevertheless, all known security risks SHOULD be identified in the |
210 |
registration. |
211 |
|
212 |
The security considerations section of all registrations is subject |
213 |
to continuing evaluation and modification, and in particular may be |
214 |
extended by use of the "comments on URL scheme name" mechanism |
215 |
described in section 4.0. |
216 |
|
217 |
2.3.3 Ownership of Registration |
218 |
|
219 |
The registration formally belongs to the vendor or organization |
220 |
registering the scheme name. Changes to the specification will be |
221 |
made at their request, as discussed in subsequent sections. |
222 |
|
223 |
2.3.4 Syntax of URL Scheme Names |
224 |
|
225 |
Registrations in the vendor tree will be distinguished by the |
226 |
leading facet "vnd.". That must be followed by an IANA-approved |
227 |
designation of the producer's name, which is then followed by a URL |
228 |
scheme name or product designation (e.g. vnd.bigcompany.telepathic). |
229 |
|
230 |
IANA will assign unique designations for producer names, |
231 |
("bigcompany" in the example above). Accordingly, once a producer |
232 |
has successfully registered a scheme name, |
233 |
(e.g. "vnd.bigcompany.telepathic"), only registrations for new |
234 |
scheme names that originate from "bigcompany" will begin with |
235 |
"vnd.bigcompany.". |
236 |
|
237 |
|
238 |
2.4 The Personal or Private Tree |
239 |
|
240 |
2.4.1 Purpose |
241 |
|
242 |
Registrations for URL schemes created experimentally or as part of |
243 |
products that are not distributed commercially may be registered in |
244 |
the personal tree. Unlike the IETF and vendor trees which guarantee |
245 |
the uniqueness of registered scheme names, registrations in the |
246 |
personal tree are NOT guaranteed to be unique. Multiple sites may |
247 |
register the same scheme name but use it in different (and |
248 |
incompatible) ways. |
249 |
|
250 |
The registration of a URL scheme name in the personal tree does not |
251 |
imply endorsement, approval, or recommendation by IANA or IETF or |
252 |
even certification that the specification is adequate. To become |
253 |
Internet Standards, protocol, data objects, or whatever must go |
254 |
through the IETF standards process and the registration in the IETF |
255 |
tree. |
256 |
|
257 |
2.4.2 Registration Requirements |
258 |
|
259 |
RFC publication of personal URL schemes is encouraged but not |
260 |
required. Materials may be published as an Informational RFC by |
261 |
sending it to the RFC Editor (please follow the instructions to RFC |
262 |
authors, RFC-2223 [3]). |
263 |
|
264 |
While public exposure and review of URL scheme names to be |
265 |
registered in the personal tree is not required, using the |
266 |
ietf-url-schemes list for review is strongly encouraged to improve |
267 |
the quality of those specifications. |
268 |
|
269 |
URL schemes registered in the personal tree are encouraged to |
270 |
conform to the generic URL syntax but are not required to do so in |
271 |
order to be registered. |
272 |
|
273 |
All new URL schemes SHOULD follow the Guidelines for URL Schemes, |
274 |
set forth in RFC [URL-GUIDELINES] [2]. |
275 |
|
276 |
While not required, an analysis of the security issues inherent in |
277 |
the new URL scheme is encouraged. Regardless of what security |
278 |
analysis is or is not performed, all descriptions of security issues |
279 |
must be as accurate as possible. In particular, a statement that |
280 |
there are "no security issues associated with this scheme" must not |
281 |
be confused with "the security issues associates with this scheme |
282 |
have not been assessed". |
283 |
|
284 |
There is absolutely no requirement that URL schemes registered in |
285 |
the personal tree be secure or completely free from risks. |
286 |
Nevertheless, all known security risks SHOULD be identified in the |
287 |
registration. |
288 |
|
289 |
The security considerations section of all registrations is subject |
290 |
to continuing evaluation and modification, and in particular may be |
291 |
extended by use of the "comments on URL scheme name" mechanism |
292 |
described in section 4.0. |
293 |
|
294 |
2.4.3 Ownership of Registration |
295 |
|
296 |
The owner of "personal" registrations and associated specifications |
297 |
is the person or entity making the registration, or one to whom |
298 |
responsibility has been transferred as described below. |
299 |
|
300 |
2.4.4 Syntax of URL Scheme Names |
301 |
|
302 |
Registrations in the personal tree are distinguished by the leading |
303 |
facet "prs.". For example, "prs.fiberreflection". |
304 |
|
305 |
2.5 Additional Registration Trees |
306 |
|
307 |
From time to time and as required by the community, the IANA may, |
308 |
with the advice and consent of the IESG, create new top-level |
309 |
registration trees. It is explicitly assumed that these trees may |
310 |
be created for external registration and management by well-known |
311 |
permanent bodies, such as scientific societies, for URL schemes |
312 |
specific to the sciences they cover. In general, the quality of |
313 |
review of specifications for one of these additional registration |
314 |
trees is expected to be equivalent to that which IETF would give to |
315 |
registrations in its own tree. Establishment of these new trees |
316 |
will be announced through RFC publication approved by the IESG. |
317 |
|
318 |
|
319 |
3.0 Registration Procedures |
320 |
|
321 |
The following sections detail the procedures to follow to register a |
322 |
new URL scheme name in a specific registration tree. With the |
323 |
exception of registration in the IETF tree, these procedures are not |
324 |
a formal standards process, but rather an administrative procedure |
325 |
intended to allow community comment and sanity checking without |
326 |
excessive time delay. |
327 |
|
328 |
3.1 The IETF Tree |
329 |
|
330 |
Complete the registration template (section 7.0 of this document) |
331 |
and submit it to the IESG for review. Generally the details of |
332 |
the proposed new URL scheme should already be documented in an |
333 |
Internet-Draft and the registration template should reference this |
334 |
draft. |
335 |
|
336 |
The IESG will review the proposed new scheme and either refer the |
337 |
scheme to a working group (existing or new) or directly present the |
338 |
registration and associated documentation to the IESG for a last |
339 |
call. In the former case, the working group is responsible for |
340 |
re-submitting it to the IESG for approval at such time as it has |
341 |
received adequate review and deliberation. |
342 |
|
343 |
After the IESG has approved the registration, it will forward the |
344 |
registration paperwork and documentation to IANA for publication on |
345 |
the ietf-url-schemes list and official registration in the IETF |
346 |
tree. |
347 |
|
348 |
Authors proposing new URL schemes for the IETF tree are encouraged |
349 |
to present the proposed schemes to the IETF as a whole, via the |
350 |
Internet-Drafts mechanism, well in advance of submission to the |
351 |
IESG. |
352 |
|
353 |
|
354 |
3.2 The Vendor Tree |
355 |
|
356 |
Complete the registration template (section 7.0 of this document) as |
357 |
completely as possible. |
358 |
|
359 |
While not required, it is recommended and encouraged that vendors |
360 |
submit a copy of the completed registration template (which includes |
361 |
references to any additional documentation), to the ietf-url-schemes |
362 |
list for peer review and comment. The quality of URL schemes can |
363 |
usually be improved through such a process. The amount of feedback |
364 |
received regarding the proposed scheme should serve as an indication |
365 |
of how long to keep the proposal in peer review before proceeding |
366 |
with the registration. |
367 |
|
368 |
Forward the completed registration template to IANA (iana@iana.org). |
369 |
|
370 |
IANA will review the registration template to ensure that it meets |
371 |
the requirements necessary for registration. If it does not meet |
372 |
the necessary requirements, the application will be rejected and |
373 |
returned to the submitter and the registration process will be |
374 |
terminated. Authors may choose to amend the information presented |
375 |
in the registration template and re-submit it to IANA who will treat |
376 |
the re-submission as a new registration request. |
377 |
|
378 |
IANA will assign the unique designation for the producer's name at |
379 |
this time if one has not already been assigned to the producer |
380 |
making the registration request. |
381 |
|
382 |
Regardless of whether or not the accepted registration template has |
383 |
previously been posted to the ietf-url-schemes list for review, IANA |
384 |
will post the template to the list along with an indication that the |
385 |
template has been officially received by IANA for registration. |
386 |
IANA will then wait for two (2) weeks for comments on and community |
387 |
review of the registration request. |
388 |
|
389 |
The intent of the public posting is to solicit comments and feedback |
390 |
on the choice of scheme name, the syntax and semantics of the |
391 |
scheme, and a review of any interoperability or security |
392 |
considerations (if such information is disclosed in the application |
393 |
or associated documentation). |
394 |
|
395 |
IANA will forward all comments received during this review period to |
396 |
the person designated as the contact person in the registration |
397 |
template. |
398 |
|
399 |
The submitter may submit a revised registration, or withdraw the |
400 |
registration completely, at any time. |
401 |
|
402 |
After the two week review period has expired, IANA shall register |
403 |
the URL scheme name in the vendor tree. |
404 |
|
405 |
URL scheme names proposed to this mailing list are not formally |
406 |
registered and should not be used until the registration procedure |
407 |
is completed by IANA. |
408 |
|
409 |
3.3 The Personal Tree |
410 |
|
411 |
The registration procedure for URL scheme names in the personal tree |
412 |
is identical as that specified for the vendor tree with the |
413 |
exception of IANA assigning the vendor a unique name. |
414 |
|
415 |
|
416 |
4.0 Comments on URL Scheme Name Registrations |
417 |
|
418 |
Comments on registered URL scheme names may be submitted by members |
419 |
of the community to IANA. These comments will be passed on to the |
420 |
"owner" of the URL scheme name if possible. Submitters of comments |
421 |
may request that their comment be attached to the URL scheme name |
422 |
registration itself, and if IANA approves of this the comment will |
423 |
be made accessible in conjunction with the scheme name registration |
424 |
itself. |
425 |
|
426 |
|
427 |
5.0 Change Control |
428 |
|
429 |
Once a URL scheme name has been published by IANA, the owner of the |
430 |
scheme name may request a change to its definition. The descriptions |
431 |
of the different registration trees above designate the owners of |
432 |
each type of registration. The change request follows the same |
433 |
procedure as the registration request: |
434 |
|
435 |
(1) Complete the registration template. |
436 |
|
437 |
(2) Publish the revised scheme syntax and semantics on the |
438 |
ietf-url-schemes list if peer review is requested. |
439 |
|
440 |
(3) Submit the revised registration to IANA. |
441 |
|
442 |
Changes should be requested only when there are serious omission or |
443 |
errors in the published specification. When review is required, a |
444 |
change request may be denied if it renders entities that were valid |
445 |
under the previous definition invalid under the new definition. |
446 |
|
447 |
The owner of a URL scheme registration may pass responsibility for |
448 |
the registration to another person or agency by informing IANA and |
449 |
the ietf-url-schemes list; this can be done without discussion or |
450 |
review. |
451 |
|
452 |
The IESG may reassign responsibility for a URL scheme name. The |
453 |
most common case of this will be to enable changes to be made to |
454 |
schemes where the author of the registration has died, moved out of |
455 |
contact or is otherwise unable to make changes that are important to |
456 |
the community. |
457 |
|
458 |
URL scheme name registrations may not be deleted; URL scheme names |
459 |
which are no longer believed appropriate for use can be declared |
460 |
OBSOLETE by a change to their "intended use" field; such URL scheme |
461 |
names will be clearly marked in the lists published by IANA. |
462 |
|
463 |
|
464 |
6.0 IANA Considerations |
465 |
|
466 |
6.1 Discussion List |
467 |
|
468 |
A discussion list named "ietf-url-schemes" needs to be created and |
469 |
maintained at "iana.org". The list MUST be open and MUST NOT |
470 |
require the submitter to be subscribed to the list in order to |
471 |
process a post. |
472 |
|
473 |
6.2 Location of Registered URL Scheme Name List |
474 |
|
475 |
URL scheme name registrations need to be posted in the anonymous |
476 |
FTP directory |
477 |
"ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/". |
478 |
|
479 |
6.3 Procedures for Registering URL Scheme Names |
480 |
|
481 |
Scheme names in the IETF tree will only be registered in response |
482 |
to a communication from the IESG stating that a given registration |
483 |
has been approved. |
484 |
|
485 |
Scheme names in the vendor tree will be registered automatically |
486 |
provided that the registration template contains at least the |
487 |
information specified below. Assignment of unique scheme names |
488 |
shall be on a first come, first served basis. |
489 |
|
490 |
Scheme names in the personal tree will be registered automatically |
491 |
provided that the registration template contains at least the |
492 |
information specified below. No attempt shall be made to prevent |
493 |
multiple applications from registering the same scheme name even if |
494 |
the use of the schemes are different and incompatible. |
495 |
|
496 |
The following minimal information must be specified for a |
497 |
registration in the vendor or personal tree: |
498 |
|
499 |
Scheme Name Syntax: The syntax of the requested scheme name |
500 |
(including the assigned producer designation in the case of vendor |
501 |
tree registrations), MUST conform to the syntax for such as |
502 |
specified in RFC [URI-SYNTAX]. While encouraged to do so, the |
503 |
syntax for the actual scheme does not have to conform to the |
504 |
general syntax specified in RFC [URI-SYNTAX]. |
505 |
|
506 |
Security Considerations: The application for registration of a |
507 |
scheme name MUST include a discussion of the security considerations |
508 |
inherent in the scheme. |
509 |
|
510 |
Contact Person: The application MUST include accurate information |
511 |
regarding a person to contact about the registration. |
512 |
|
513 |
Author/Change Controller: The application MUST specify the author |
514 |
and/or entity responsible for change control of the proposed scheme. |
515 |
|
516 |
|
517 |
7.0 Registration Template |
518 |
|
519 |
To: iana@iana.org |
520 |
Subject: Registration of URL Scheme Name <name> |
521 |
|
522 |
URL Scheme Name: |
523 |
|
524 |
Character encoding considerations: |
525 |
|
526 |
Security considerations: |
527 |
|
528 |
Interoperability considerations: |
529 |
|
530 |
Published specification: |
531 |
|
532 |
Applications which use this URL scheme name: |
533 |
|
534 |
Additional information: |
535 |
|
536 |
Person & email address to contact for further information: |
537 |
|
538 |
Intended usage: |
539 |
|
540 |
(One of COMMON, LIMITED USE or OBSOLETE) |
541 |
|
542 |
Author/Change controller: |
543 |
|
544 |
(Any other information that the author deems interesting may be |
545 |
added below this line.) |
546 |
|
547 |
|
548 |
8.0 Security Considerations |
549 |
|
550 |
Information that creates or updates a registration needs to be |
551 |
authenticated. |
552 |
|
553 |
Information concerning possible security vulnerabilities of a |
554 |
protocol may change over time. Consequently, claims as to the |
555 |
security properties of a registered URL scheme may change as well. |
556 |
As new vulnerabilities are discovered, information about such |
557 |
vulnerabilities may need to be attached to existing registrations, |
558 |
so that users are not misled as to the true security properties of a |
559 |
registered URL scheme. |
560 |
|
561 |
Delegations of a name space should only be assigned to someone with |
562 |
adequate security. |
563 |
|
564 |
|
565 |
9.0 References |
566 |
|
567 |
[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource |
568 |
Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998 |
569 |
|
570 |
[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., |
571 |
"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998 |
572 |
|
573 |
[3] Postel, J., Reynolds, J., "Instructions to RFC Authors", |
574 |
RFC 2223, October 1997. |
575 |
|
576 |
|
577 |
10.0 Author's Address |
578 |
|
579 |
Rich Petke |
580 |
WorldCom Advanced Networks |
581 |
5000 Britton Road |
582 |
P. O. Box 5000 |
583 |
Hilliard, OH 43026-5000 |
584 |
USA |
585 |
|
586 |
Phone: +1 614 723 4157 |
587 |
Fax: +1 614 723 1333 |
588 |
EMail: rpetke@compuserve.net |
589 |
|
590 |
|
591 |
Appendix A -- Grandfathered URL Scheme Names |
592 |
|
593 |
A number of URL scheme names, in use prior to 1998, would, if |
594 |
registered under the procedures specified in this document, be |
595 |
placed into either the vendor or personal trees. Re-registration |
596 |
of those types to reflect the appropriate trees is encouraged, but |
597 |
not required. Ownership and change control principles outlined in |
598 |
this document apply to those types as if they had been registered in |
599 |
the trees described above. |
600 |
|
601 |
ABOUT: |
602 |
|
603 |
AOL: |
604 |
|