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

IETF URI Working Group
Internet-Draft
draft-ietf-uri-url-finger-02.txt
Expires September 7, 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://host[:port][/<request>]

The <request> must conform with the RFC 1288 request format.

A finger client could simply send the <request> followed by a <CRLF> to
the host designated in the first part of the URL at the specified port after
decoding any escaped characters. The default port is 79.

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://space.mit.edu/nasanews

RFC 1288 allows null requests. The URL for such a request might look
like:

     finger://status.nlak.net

However, note that some requests might look like:

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

and:

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

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. Further,
since each URL is for a single request, the client software should be careful
not to decode CR and LF characters in a URL.

As explained in RFC 1738, URLs that use non-standard port numbers pose a
potential security risk for users of those URLs. If a port other than 79 is
specified in a finger URL, the finger client might warn the user or reject
the URL altogether.

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