# Revised Internet-Draft: finger URL

Jared_Rhine@hmc.edu
Tue, 7 Mar 1995 22:31:01 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: David G. Durand: "Re: URNs don't provide permanence"
- Previous message: Paul Hoffman: "Revised Internet-Draft: finger URL"
- Next in thread: Jared_Rhine@hmc.edu: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Jared_Rhine@hmc.edu: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Michael A. Dolan: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Jared_Rhine@hmc.edu: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Paul Hoffman: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: David Robinson: "Re: Revised Internet-Draft: finger URL"

    Date: Tue, 7 Mar 1995 22:31:01 -0500

    Message-Id: <199503080331.WAA04543@aslan.math.hmc.edu>

    From: Jared_Rhine@hmc.edu

    To: ietf-lists@proper.com (Paul Hoffman)

    Subject: Revised Internet-Draft: finger URL

PH == Paul Hoffman <ietf-lists@proper.com>

PH> draft-ietf-uri-url-finger-02.txt

PH> In order to allow that information to be located in a standard
PH> fashion, a "finger" URL is needed.

I would prefer the word "retrieved" instead of "located".

PH> The "finger" URL has the form:
PH>
PH> finger://host[:port][/<request>]
PH>
PH> The <request> must conform with the RFC 1288 request format.

Not exactly. <request> must conform to a RFC 1288 request format after
standard URL encoding.

If this document is intended for publication, some mention of the syntax of
"host" and "port" must be made. That mention should just be a pointer to
the URL RFC, but this specification in incomplete without it.

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

A better word than "could" should be chosen.

PH> Clients should not decode CR and LF characters in a URL.

As I mentioned before, I object to this language because it requires
implementors to special-case their decoding algorithms. The request should
be decoded and then rejected if it contains either of these characters. Or
better yet, merely declare such URLs as illegal, and then it is up to the
implementor how they want to detect it and what they want to do about it.

As a final note, you need a references section, as at least two external
documents are needed to implement this specification.

    --
    Jared_Rhine@hmc.edu | Harvey Mudd College | http://www.hmc.edu/~jared/home.html

    "The universe is made of stories, not atoms." - Muriel Rukeyser

- Next message: David G. Durand: "Re: URNs don't provide permanence"
- Previous message: Paul Hoffman: "Revised Internet-Draft: finger URL"
- Next in thread: Jared_Rhine@hmc.edu: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Jared_Rhine@hmc.edu: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Michael A. Dolan: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Jared_Rhine@hmc.edu: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: Paul Hoffman: "Re: Revised Internet-Draft: finger URL"
- Maybe reply: David Robinson: "Re: Revised Internet-Draft: finger URL"