- From: <Jared_Rhine@hmc.edu>
- Date: Tue, 7 Mar 1995 22:31:01 -0500
- To: ietf-lists@proper.com (Paul Hoffman)
- Cc: uri@bunyip.com
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
Received on Tuesday, 7 March 1995 22:31:27 UTC