Message-Id: <199408071919.MAA18705@nic.cerf.net>
Date: Sun, 07 Aug 1994 12:14:38 -0700
To: Larry Masinter <masinter@parc.xerox.com>
From: miked@CERF.NET (Michael A. Dolan)
Subject: Re: URL Algorithm Specification
At 08:12 PM 8/6/94 PDT, Larry Masinter wrote:
>The specification is careful to map the FTP URLs into
>a series of commands that are in the FTP protocol, independent of what
>is on the other side of your FTP server.
>I'm not sure what you think
>might be ambiguous. Perhaps you could elaborate.
It only refers to some commands and in no particular order. There is also
no mention of how to POST or obtain information such as HEAD. There is
no mention of USER and PASS and how *really* to negotiate the authentication.
The algorithm does not define what operation it is performing (although one
would presume GET).
I wasn't questioning the accuracy of the spec. I was trying (perhaps poorly)
to point out that reading it left me, as an implementor, in doubt as to
exactly what to do. Hence the need in my opinion for a (more) exact
algorithm specification.
>> ... an algorithm for accessing of resources within that scheme ...
>> a. Do such algorithms exist for the currently-defined URLs ? If so,
>> where (other than libwww source) ?
>
>I think this is a legitimate question, and I don't want to give a flip
>answer. I think the answer is:
> yes, in this specification, for ftp, telnet, gopher, mailto, file
> not really for http, news, nntp, wais, prospero
I addressed FTP above, but the same applies to gopher. Without how to
handle each type (2 is interesting) it is difficult to implement, even
with RFC 1436 in hand.
The telnet and mailto URLs are completely unspecified as to what to do with
TELNET and SMTP protocols. Existing implementations simply permit execing
external clients to do whatever they wish, or in some cases did a crude
SMTP access.
File doesn't take Einstein to figure out what to do, but nevertheless is
left unspecified. For example, it should "open(), read(), read().....close()"
to implement GET, but what about POST and HEAD ?
We agree in regard to http, news, nntp, wais, and prospero. :-)
>>b. Any specification of an algorithm implies a set of functions or
>> what could be called "virtual methods" that operate on the URL.
>> Are such functions defined ? If not, then I would propose GET, POST,
>> and HEAD as a start.
>
>I think this is an interesting request, and quite possible to do,
>although I don't think it's required in this RFC, which primarily
>attempts to describe the syntax of URLs.
I would agree except that section 4 requires future protocols to include
such an algorithm. Hence it should either be part of this RFC or not. If
it is part, then you should define the purpose of the algorithm. For example,
in current implementations, http supports GET and POST, but not HEAD; FTP
only supports GET; mailto supports only POST; and news supports only GET
(but not POST !).
You can choose whatever scope you want for this RFC, but either it should
have algorithms or not. If it does, then the operators, or "virtual methods"
or whatever you want to call them should be defined for each.
-----------------------------------------------
Michael A. Dolan - <mailto:miked@cerfnet.com>
TerraByte Technology (619) 445-9070, FAX -8864