Revised Internet-Draft: finger URL

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


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)
Cc: uri@bunyip.com
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