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 |
|