--On Monday, 12 April, 2010 12:44 -0700 The IESG
<iesg-secretary@xxxxxxxx> wrote:
> The IESG has received a request from an individual submitter
> to consider the following document:
>
> - 'File Transfer Protocol HOST Command '
> <draft-hethmon-mcmurray-ftp-hosts-11.txt> as a Proposed
> Standard
>...
IESG,
This draft is much improved from prior versions, and the
explanations of why adding a new, pre-authentication, command
is needed are appreciated. There are other possibilities,
however, that do not increase the number of turnarounds or add
to the complexity of the command. For example, one could
either create some syntax within the USER command if the
extension were advertised so that one would have
USER userid virtual-host-id
PASS ...
ACCT ...
(possibly with some other delimiter) or one could, with such
an option, replace USER entirely, e.g.,
UHST userid virtual-host-id
etc.
This leads to a more general point, which I think is the main
issue with this and the other FTP proposals that are at various
points in the pipe. FTP is our oldest applications protocol
that is still in active use. It was rather carefully designed.
It is not HTTP and retrofitting HTTP syntax and concepts into
it is not obviously the right thing to do.
If we are going to start adding features to FTP, it seems to me
that we need a strategy and to make design decisions: lots of
little commands with four-letter names and single-token syntax
versus a smaller number of more complex commands versus
extending (or, in the words of the authors, "overloading")
existing commands. Those decisions should not -- cannot -- be
made by processing one command extension at a time, with each
one reflecting the taste and assumptions of its authors in
different ways.
It seems to me that we need a WG or some other mechanism for
establishing and determining community consensus around basic
design principles for FTP extensions. If the IESG then wants
to process individual extensions as individual submissions,
that would be fine, but let's first at least establish a
framework for evaluating them.
thanks,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf