Re: protocol vs. UI

--On Saturday, May 25, 2002 6:50 PM -0700 Dave Crocker
<[email protected]> wrote:

>...
> (FTP was expected to be a direct UI.  Didn't work, very well,
> did it?)
>...

Dave,

Regardless of how I might feel about the rest of your analysis
(I'll let you and Erik debate that), the above is just not
correct.  While FTP apparently lends itself to "direct UI", it
was never intended that way.   Indeed, features of the protocol,
especially some that are not widely implemented of late,
_require_ some machinery in the server and client, rather than
being "direct" protocol features.

For example, use of "TYPE ASCII" transfers requires translation
between the character set of the sender and network ASCII and
translation by the receiver from network ASCII to local
character set and formats.  Even when those hosts use ASCII, the
translations must accomodate, e.g., conversion of end of line
conventions.

Better FTP implementations also support asynchronous command
operation, reformatting of other external data types, and so on.
But the protocol is no more designed as a "direct UI" than SMTP
or POP3 (which are at least synchronous) or IMAP (which is still
a text-based protocol).  And, for whatever it is worth, the
first FTP implementations I remember (Tenex, Multics, ITS) all
used user interfaces that were different in style from the
protocol and, generally, even in the names of some of the verbs
(where a command sequence was used, rather than a single command
with several qualifiers, as was the normal usage on Tenex).

Of course, Whois or Finger might be better examples of your
point, but those protocols did not specify the details of either
the input or output formats.

     john