1 |
INTERNET-DRAFT Larry Masinter |
2 |
<draft-ietf-urlreg-guide-00.txt> Harald T. Alvestrand |
3 |
October 24, 1997 Dan Zigmond |
4 |
|
5 |
Guidelines for new URL Schemes |
6 |
|
7 |
Status of this Memo |
8 |
|
9 |
This document is an Internet-Draft. Internet-Drafts are working |
10 |
documents of the Internet Engineering Task Force (IETF), its areas, |
11 |
and its working groups. Note that other groups may also distribute |
12 |
working documents as Internet-Drafts. |
13 |
|
14 |
Internet-Drafts are draft documents valid for a maximum of six |
15 |
months and may be updated, replaced, or obsoleted by other |
16 |
documents at any time. It is inappropriate to use Internet-Drafts |
17 |
as reference material or to cite them other than as ``work in |
18 |
progress.'' |
19 |
|
20 |
To learn the current status of any Internet-Draft, please check the |
21 |
``1id-abstracts.txt'' listing contained in the Internet-Drafts |
22 |
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net |
23 |
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East |
24 |
Coast), or ftp.isi.edu (US West Coast). |
25 |
|
26 |
Issues: |
27 |
Registration process isn't really there. |
28 |
registration is important |
29 |
standardization |
30 |
standards track |
31 |
local URL schemes about: "let them" |
32 |
|
33 |
Abstract |
34 |
|
35 |
A Uniform Resource Locator (URL) is a compact string representation |
36 |
of the location for a resource that is available via the Internet. |
37 |
[RFC URL-SYNTAX] defines the general syntax and semantics of URLs. |
38 |
This document provides guidelines for the definition of new URL |
39 |
schemes and describes the process by which they are registered. |
40 |
|
41 |
1. Introduction |
42 |
|
43 |
In addition to specifying the general syntax for Uniform Resource |
44 |
Locators, RFC 1738 defined a number of generally useful URL schemes |
45 |
and promised that a mechanism for registering new schemes would be |
46 |
established. Several new URLs have been proposed since that time, |
47 |
but the procedure for standardizing these schemes has never been |
48 |
fully defined. This document describes the current practice and |
49 |
offers some guidance for authors of new schemes. |
50 |
|
51 |
One process for defining URL schemes is via the Internet standards |
52 |
process: new URL schemes should be described in standards-track |
53 |
RFCs. The Internet Assigned Numbers Authority (IANA) maintains a |
54 |
registry of all URL schemes defined in this way. |
55 |
|
56 |
2. Guildelines for new URL schemes |
57 |
|
58 |
Because new URL schemes potentially complicate client software, new |
59 |
schemes must have demonstrable utility and operability, as well as |
60 |
compatibility with existing URL schemes. This section elaborates |
61 |
these criteria. |
62 |
|
63 |
2.1 Syntactic compatibility |
64 |
|
65 |
New URL schemes should follow the same syntactic conventions of |
66 |
existing schemes when appropriate. |
67 |
|
68 |
2.1.1 Use of initial "//" for top level |
69 |
|
70 |
Many proposed new URL schemes seem to use "://" as a kind of |
71 |
indicator that what follows is a URL. However, the use of "//" |
72 |
indicates a "top level" for schemes that support relative |
73 |
URLs, and is not necessary (and just confusing) for schemes |
74 |
that have no relative forms. URL schemes without relative |
75 |
forms (such as mailto, cid, mid) do not use an initial "//". |
76 |
|
77 |
2.1.2 Compatibility with relative URLs |
78 |
|
79 |
URL schemes should use the generic-URL syntax if they are intended |
80 |
to be used with relative URLs. A description of the allowed |
81 |
relative forms should be included in the scheme's definition. |
82 |
Many applications use relative URLs extensively. |
83 |
|
84 |
o Can it be parsed according to RFC URL-SYNTAX - that is, if the |
85 |
tokens "//", "/", ";", "?" and "#" are used, do they have the |
86 |
meaning given in RFC URL-SYNTAX? |
87 |
|
88 |
o Does it make sense to use it in relative URLs like those RFC |
89 |
URL-SYNTAX specifies? |
90 |
|
91 |
o If something is designed to be broken into pieces, does it |
92 |
document what those pieces are, why it should be broken in this |
93 |
way, and why the breaks aren't where URL-SYNTAX says that they |
94 |
usually should be? |
95 |
|
96 |
o If it has a hierarchy, does it go left-to-right and with slash |
97 |
separators like RFC URL-SYNTAX? If not, why not? |
98 |
|
99 |
2.2 Is the scheme well defined? |
100 |
|
101 |
It is important that the semantics of the "resource" that a URL |
102 |
"locates" be well defined. This might mean different things |
103 |
depending on the nature of the URL scheme. |
104 |
|
105 |
2.2.1 Clear mapping from other name spaces |
106 |
|
107 |
In many cases, new URL schemes are defined as ways to translate |
108 |
other protocols and name spaces into the general framework of |
109 |
URLs. The "ftp" URL scheme translates from the FTP protocol, while |
110 |
the "mid" URL scheme translates from the Message-ID field of |
111 |
messages. |
112 |
|
113 |
In either case, the description of the mapping must be complete, |
114 |
must describe how character sets get encoded or not in URLs, must |
115 |
describe exactly how all legal values of the base standard can be |
116 |
represented using the URL scheme, and exactly which modifiers, |
117 |
alternate forms and other artifacts from the base standards are |
118 |
included or not included. These requirements are elaborated |
119 |
below. |
120 |
|
121 |
2.2.2 URL schemes associated with network protocols |
122 |
|
123 |
Most new URL schemes are associated with network resources that |
124 |
have one or several network protocols that can access them. The |
125 |
'ftp', 'news', and 'http' schemes are of this nature. For such |
126 |
schemes, the specification should completely describe how URLs are |
127 |
translated into protocol actions in sufficient detail to make the |
128 |
access of the network resource unambiguous. If an implementation |
129 |
of of the URL scheme requires some configuration, the configuration |
130 |
elements must be clearly identified. (For example, the 'news' |
131 |
scheme, if implemented using NTTP, requires configuration of the |
132 |
NTTP server.) |
133 |
|
134 |
2.2.3 Character encoding |
135 |
|
136 |
When describing URL schemes in which (some of) the elements of |
137 |
the URL are actually representations of sequences of characters, |
138 |
care should be taken not to introduce unnecessary variety in the |
139 |
ways in which characters are encoded into octets and then into |
140 |
URL characters. Unless there is some compelling reason for a |
141 |
particular scheme to do otherwise, translating character sequences |
142 |
into UTF-8 [RFC2044] and then subsequently using the %HH encoding |
143 |
for unsafe octets is recommended. |
144 |
|
145 |
2.2.4 Definition of non-protocol URL schemes |
146 |
|
147 |
In some cases, URL schemes do not have particular network protocols |
148 |
associated with them, because their use is limited to contexts |
149 |
where the access method is understood. This is the case, for |
150 |
example, with the "cid" and "mid" URL schemes. For these URL |
151 |
schemes, the specification should describe the notation of the |
152 |
scheme and a complete mapping of the locator from its source. |
153 |
|
154 |
2.2.5 Definition of URL schemes not associated with data resources |
155 |
|
156 |
Most URL schemes locate Internet resources that correspond |
157 |
to data objects that can be retrieved or modified. This is the |
158 |
case with "ftp" and "http", for example. However, some URL schemes |
159 |
do not; for example, the "mailto" URL scheme corresponds to an |
160 |
Internet mail address. |
161 |
|
162 |
If a new URL scheme does not locate resources that are data |
163 |
objects, the properties of names in the new space must be clearly |
164 |
defined. |
165 |
|
166 |
2.2.6 Definition of operations |
167 |
|
168 |
In some contexts (for example, HTML forms) it is possible to |
169 |
specify any one of a list of operations to be performed on a |
170 |
specifc URL. (Outside forms, it is generally assumed to be |
171 |
something you GET.) |
172 |
|
173 |
The URL scheme definition should describe all well-defined |
174 |
operations on the URL identifier, and what they are supposed to |
175 |
do. |
176 |
|
177 |
Some URL schemes (for example, "telnet") provide location |
178 |
information for hooking onto bidirectional data streams, and don't |
179 |
fit the "infoaccess" paradigm of most URLs very well; this should |
180 |
be documented. |
181 |
|
182 |
NOTE: It is perfectly valid to say that "no operation apart from |
183 |
GET is defined for this URL". It is also valid to say that "there's |
184 |
only one operation defined for this URL, and it's not very |
185 |
GET-like". The important point is that what is defined on this type |
186 |
is described. |
187 |
|
188 |
2.3 Demonstrated utility |
189 |
|
190 |
URL schemes should have demonstrated utility. New URL schemes are |
191 |
expensive things to support. Often they require special code in |
192 |
browsers, proxies, and/or servers. Having a lot of ways to say the |
193 |
same thing needless complicates these programs without adding value |
194 |
to the Internet. |
195 |
|
196 |
The kinds of things that are useful include: |
197 |
|
198 |
o Things that cannot be referred to in any other way. |
199 |
|
200 |
o Things where it is much easier to get at them using this |
201 |
scheme than (for instance) a proxy gateway. |
202 |
|
203 |
|
204 |
2.3.1 Proxy into HTTP/HTML |
205 |
|
206 |
One way to provide a demonstration of utility is via a gateway |
207 |
which provides objects in the new scheme for clients using an |
208 |
existing protocol. It is much easier to deploy gateways to a new |
209 |
service than it is to deploy browsers that understand the new URL |
210 |
object. |
211 |
|
212 |
Things to look for when thinking about a proxy are: |
213 |
|
214 |
o Is there a single global resolution mechanism whereby any proxy can |
215 |
find the referenced object? |
216 |
o If not, is there a way in which the user can find any object of |
217 |
this type, and "run his own proxy"? |
218 |
o Are the operations mappable one-to-one (or possibly using |
219 |
modifiers) to HTTP operations? |
220 |
o Is the type of returned objects well defined? |
221 |
* as MIME content-types? |
222 |
* as something that can be translated to HTML? |
223 |
o Is there running code for a proxy? |
224 |
|
225 |
2.4 Are there security considerations? |
226 |
|
227 |
Above and beyond the security considerations of the base mechanism |
228 |
a scheme builds upon, one must think of things that can happen in |
229 |
the normal course of URL usage. |
230 |
|
231 |
In particular: |
232 |
|
233 |
o Does the user need to be warned that such a thing is happening |
234 |
without an explicit request (GET for the source of an IMG tag, |
235 |
for instance)? This has implications for the design of a proxy |
236 |
gateway, of course. |
237 |
|
238 |
o Is it possible to fake URLs of this type that point to different |
239 |
things in a dangerous way? |
240 |
|
241 |
o Are there mechanisms for identifying the requester that can be |
242 |
used or need to be used with this mechanism (the From: field in a |
243 |
mailto: URL, or the Kerberos login required for AFS access in the |
244 |
AFS: url, for instance)? |
245 |
|
246 |
o Does the mechanism contain passwords or other security |
247 |
information that are passed inside the referring document in the |
248 |
clear (as in the "ftp" URL, for instance)? |
249 |
|
250 |
2.5 Does it start with UR? |
251 |
|
252 |
Any scheme starting with the letters "U" and "R", in particular if |
253 |
it attaches any of the meanings "uniform", "universal" or |
254 |
"unifying" to the first letter, is going to cause intense debate, |
255 |
and generate much heat (but maybe little light). |
256 |
|
257 |
Any such proposal should either make sure that there is a large |
258 |
consensus behind it that it will be the only scheme of its type, or |
259 |
pick another name. |
260 |
|
261 |
2.6 Non-considerations |
262 |
|
263 |
Some issues that are often raised but are not relevent to new URL |
264 |
schemes include the following. |
265 |
|
266 |
2.6.1 Are all objects acessible? |
267 |
|
268 |
Can all objects in the world that are validly identified by a |
269 |
scheme be accessed by any UA implementing it? |
270 |
|
271 |
Sometimes the answer will be yes and sometimes no; often it will |
272 |
depend on factors (like firewalls or client configuration) not |
273 |
directly related to the scheme itself. |
274 |
|
275 |
3. Revision process |
276 |
|
277 |
NOTE: THIS SECTION IS ENTIRELY TBD. REVIEW COMMITTEE? PRIVATE URLS? |
278 |
|
279 |
URL schemes will have either a standards track RFC, or else they |
280 |
will be a registration at IANA. where include the whole draft. URL |
281 |
schemes will have a review panel, appointed by IETF AD, who may not |
282 |
reject a URL scheme but who may provide a 2 sentence recommendation |
283 |
about the use of the URL scheme. Conflicting registrations are |
284 |
possible for non-standard URL schemes, and the order in the IANA |
285 |
list of conflicting registrations will be determined by a random |
286 |
number generator. |
287 |
|
288 |
4. Security considerations |
289 |
|
290 |
New URL schemes are required to address all security considerations |
291 |
in their definitions. |
292 |
|
293 |
5. IANA considerations |
294 |
|
295 |
This document requires IANA to register URL schemes according to |
296 |
the process outlined in section 3. |
297 |
|
298 |
6. References |
299 |
|
300 |
[RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode |
301 |
and ISO 10646", Alis Technologies, October 1996. |
302 |
|
303 |
[URL-SYNTAX] |
304 |
Berners-Lee, Fielding, Masinter, "Uniform Resource Locators: |
305 |
Generic Syntax and Semantics", <draft-fielding-url-syntax-04>. |
306 |
|
307 |
7. Author's Addresses |
308 |
|
309 |
Larry Masinter |
310 |
Xerox Corporation |
311 |
Palo Alto Research Center |
312 |
3333 Coyote Hill Road |
313 |
Palo Alto, CA 94304 |
314 |
Fax: +1-415-812-4333 |
315 |
EMail: masinter@parc.xerox.com |
316 |
|
317 |
Harald T. Alvestrand |
318 |
UNINETT A/S |
319 |
Postboks 6683 Elgeseter 7002 |
320 |
Trondheim, Norway |
321 |
Tel: +47 73 59 70 94 |
322 |
EMail: Harald.T.Alvestrand@uninett.no |
323 |
|
324 |
Dan Zigmond |
325 |
Wink Communications |
326 |
1001 Marina Village Parkway |
327 |
Alameda CA 94610 |
328 |
Fax: +1-510-337-2960 |
329 |
Phone: +1-510-337-6359 |
330 |
Email: dan.zigmond@wink.com |