1 |
|
2 |
IETF URI Working Group |
3 |
Internet-Draft |
4 |
draft-ietf-uri-url-finger-03 |
5 |
Expires January 11, 1996 |
6 |
|
7 |
finger URL Specification |
8 |
|
9 |
Status of This Memo |
10 |
|
11 |
This document is an Internet-Draft. Internet-Drafts are working |
12 |
documents of the Internet Engineering Task Force (IETF), its |
13 |
areas, and its working groups. Note that other groups may also |
14 |
distribute working documents as Internet-Drafts. |
15 |
|
16 |
Internet-Drafts are draft documents valid for a maximum of six |
17 |
months and may be updated, replaced, or obsoleted by other |
18 |
documents at any time. It is inappropriate to use Internet- |
19 |
Drafts as reference material or to cite them other than as |
20 |
``work in progress.'' |
21 |
|
22 |
To learn the current status of any Internet-Draft, please check |
23 |
the ``1id-abstracts.txt'' listing contained in the Internet- |
24 |
Drafts Shadow Directories on ftp.is.co.za (Africa), |
25 |
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), |
26 |
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). |
27 |
|
28 |
Abstract |
29 |
|
30 |
A new URL scheme, "finger", is defined. It allows client software to |
31 |
request information from finger servers that conform to RFC 1288. |
32 |
|
33 |
1. Description |
34 |
|
35 |
Many Internet hosts publish information through the finger protocol, as |
36 |
described in RFC 1288. In order to allow that information to be located |
37 |
in a standard fashion, a "finger" URL is needed. |
38 |
|
39 |
The "finger" URL has the form: |
40 |
|
41 |
finger://host[:port][/<request>] |
42 |
|
43 |
The <request> must conform with the RFC 1288 request format. |
44 |
|
45 |
A finger client could simply send the <request> followed by a <CRLF> to |
46 |
the host designated in the first part of the URL at the specified port after |
47 |
decoding any escaped characters. The default port is 79. Client software |
48 |
that resolves "finger" URLs may choose to ignore the optional port |
49 |
number in order to increase security. |
50 |
|
51 |
2. Encoding |
52 |
|
53 |
RFC1738 requires that many characters in URLs be encoded. This affects |
54 |
the finger scheme in that some requests may contain space (" ", ASCII |
55 |
hex 20) and forward slash ("/", ASCII hex 2F). These characters must be |
56 |
encoded in the URL following the rules in RFC 1738. |
57 |
|
58 |
Clients should not decode CR and LF characters in a URL. |
59 |
|
60 |
3. Examples |
61 |
|
62 |
Typically, a finger URL will be something like: |
63 |
|
64 |
finger://space.mit.edu/nasanews |
65 |
|
66 |
RFC 1288 allows null requests. The URL for such a request might look |
67 |
like: |
68 |
|
69 |
finger://status.nlak.net |
70 |
|
71 |
However, note that some requests might look like: |
72 |
|
73 |
finger://host2.bigstate.edu/someuser@host1.bigstate.edu |
74 |
|
75 |
and: |
76 |
|
77 |
finger://host1.bigstate.edu/%2FW%20someuser |
78 |
|
79 |
4. Security |
80 |
|
81 |
RFC 1288 contains a detailed section on both client and host security that |
82 |
should be read by anyone implementing clients that allow the finger URL. |
83 |
Specifically, client software should check for any unsafe characters and |
84 |
character strings received before displaying the results of a query. Further, |
85 |
since each URL is for a single request, the client software should be careful |
86 |
not to decode CR and LF characters in a URL. |
87 |
|
88 |
As explained in RFC 1738, URLs that use non-standard port numbers pose a |
89 |
potential security risk for users of those URLs. If a port other than 79 is |
90 |
specified in a finger URL, the finger client might warn the user or reject |
91 |
the URL altogether. |
92 |
|
93 |
5. Author contact information: |
94 |
|
95 |
Paul E. Hoffman |
96 |
Proper Publishing |
97 |
127 Segre Place |
98 |
Santa Cruz, CA 95060 USA |
99 |
Tel: 408-426-6222 |
100 |
phoffman@proper.com |
101 |
|
102 |
|