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