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