2004/id/draft-ietf-uri-url-finger-01.txt


IETF URI Working Group
Internet-Draft
draft-ietf-uri-url-finger-01.txt
Expires August 24, 1995

                             finger URL Specification

Status of This Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

A new URL scheme, "finger", is defined. It allows client software to
request information from finger servers that conform to RFC 1288.

Description

Many Internet hosts publish information through the finger protocol, as
described in RFC 1288. In order to allow that information to be located
in a standard fashion, a "finger" URL is needed.

The "finger" URL has the form:

     finger:<request>

where <request> is of the form:

     [%2FW[*<%20>]][username]@hostname[*@hostname]

All requests must be sent to the standard TCP finger port, 79 (decimal).
A finger URL that does not include a host name, such as:

     finger:someuser

should be rejected by the client software.

The request send by a finger client should follow the rules in RFC 1288
for stripping host names. For example, the URL:

     finger:someuser@host1.bigstate.edu

would cause a finger client to send the request "someuser<CRLF>" to
port 79 at host1.bigstate.edu.

Encoding

RFC1738 requires that many characters in URLs be encoded. This affects
the finger scheme in that some requests may contain space (" ", ASCII
hex 20) and forward slash ("/", ASCII hex 2F). These characters must be
encoded in the URL following the rules in RFC 1738. Clients should not
decode CR and LF characters in a URL.

Examples

Typically, a finger URL will be something like:

     finger:nasanews@space.mit.edu

However, note that some requests might look like:

     finger:someuser@host1.bigstate.edu@host2.bigstate.edu

and:

     finger:%2FW%20someuser@host1.bigstate.edu

Security

RFC 1288 contains a detailed section on both client and host security that
should be read by anyone implementing clients that allow the finger URL.
Specifically, client software should check for any unsafe characters and
character strings received before displaying the results of a query.

Author contact information:

Paul E. Hoffman
Proper Publishing
127 Segre Place
Santa Cruz, CA  95060 USA
Tel: 408-426-6222
phoffman@proper.com


1	wakaba	1.1
2			IETF URI Working Group
3			Internet-Draft
4			draft-ietf-uri-url-finger-01.txt
5			Expires August 24, 1995
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			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:<request>
42
43			where <request> is of the form:
44
45			[%2FW[<%20>]][username]@hostname[@hostname]
46
47			All requests must be sent to the standard TCP finger port, 79 (decimal).
48			A finger URL that does not include a host name, such as:
49
50			finger:someuser
51
52			should be rejected by the client software.
53
54			The request send by a finger client should follow the rules in RFC 1288
55			for stripping host names. For example, the URL:
56
57			finger:someuser@host1.bigstate.edu
58
59			would cause a finger client to send the request "someuser<CRLF>" to
60			port 79 at host1.bigstate.edu.
61
62			Encoding
63
64			RFC1738 requires that many characters in URLs be encoded. This affects
65			the finger scheme in that some requests may contain space (" ", ASCII
66			hex 20) and forward slash ("/", ASCII hex 2F). These characters must be
67			encoded in the URL following the rules in RFC 1738. Clients should not
68			decode CR and LF characters in a URL.
69
70			Examples
71
72			Typically, a finger URL will be something like:
73
74			finger:nasanews@space.mit.edu
75
76			However, note that some requests might look like:
77
78			finger:someuser@host1.bigstate.edu@host2.bigstate.edu
79
80			and:
81
82			finger:%2FW%20someuser@host1.bigstate.edu
83
84			Security
85
86			RFC 1288 contains a detailed section on both client and host security that
87			should be read by anyone implementing clients that allow the finger URL.
88			Specifically, client software should check for any unsafe characters and
89			character strings received before displaying the results of a query.
90
91			Author contact information:
92
93			Paul E. Hoffman
94			Proper Publishing
95			127 Segre Place
96			Santa Cruz, CA 95060 USA
97			Tel: 408-426-6222
98			phoffman@proper.com
99
100