Subject: Ftp-WG: HOST command and client upgrades

From: Dave Cridland <[email-masked]>
Date: Mon, 25 Oct 1999 11:51:47 -0400

> I disagree.  A poorly-designed HOST command slipped into a much-wanted
MLST
> draft might make it to RFC status simply because we want to see MLST that
> much sooner.  Separated into its own document, it will need to stand on
its
> own to make it to RFC status.  As others have pointed out, the HOST
command
> has not yet been completely discussed here, and it is perhaps immature or
> incomplete.  As such, I would hate to see a poorer version implemented
> because of a wish to get MLST out.

I agree totally. As Dan has commented, exactly the same issues ought to be
held against HOST as are held against EPLF - that it's an upgrade dependant
on the majority of clients upgrading - something that probably won't happen
with FTP clients, I believe.

MLST is needed, because the sooner servers implement it, the sooner clients
will.

HOST is not so essential - it's a good idea that we have it, and no doubt
the likes of RIPE will be very glad once it's done, but I, too, feel that
there's been perhaps too little thought gone into it, but equally there's
been quite heavy pressure to get the draft out of the door.

> >That was suggested to me in private mail as well (wondering why the text
> >in the draft is so demeaning of other virtual host schemes...).   That
> >suggestion was to use user@host as the USER command data.

> To address a couple of comments heard elsewhere on this list, the HOST
> command is not useless on older clients - FTP requires that all clients be
> given a "QUOTE" capability, to send any command.  This allows HOST to work

... and there are plenty of graphical ones that don't appear to think that
this particular part of the stanard applies to them, as I've found out -
usually when discovering that they also don't have SITE, nor any intereface
to the popular non-standard SITE CHMOD, which is handy for the likes of
UNIX-based virtual HTTP servers with CGI.

USER user@host sounds like a possible good workaround - I realise that there
almost certainly are servers using email-address style logins out there,
though, so there are problems. Another good reason why we need to seperate
this issue from the rest, and get the rest of the draft (IMHO, quite ready
for RFC publication) out of the door.

As an aside this has reminded me that an additional draft would mean we
might devote some time to other features, such as the SETF that some of us
talked about some months ago. (Another good point about MLST over EPLF, in
fact - since there's a known set of facts for which we can handle with a
SETFact style command, which suggests that further features in the FTP
protocol - making it more useful - could be easier with MLST).

> >The HOST method kind of permits virtual hosts to be implemented using
> >a wrapper process, but I am not sure that there will ever actually be
> >an implementation done that way.   Perhaps.

> Who knows?  Maybe there'll be some kind of NAT developed that uses a
future
> defined HOST command?  Hey, I can dream, right?

I agree that it'll never be a wrapper, simply because it'll end up being
easier to update the server rather than the precarious sysadmin task of
applying a wrapper to it.

As for dreaming, if we're dreaming, I'd like to go for a world in which NAT
doesn't happen, and ISPs stop being quite so anal about charging different
prices for different numbers of IP addresses. Oh, and one in which the only
problem with numbers of IP addresses is how we will ever use them all... Oh,
and one in which I get free doughnuts, too.

Dave.

---

From: Alun Jones <[email-masked]>
Date: Mon, 25 Oct 1999 17:02:10 -0400

At 11:51 AM 10/25/99 -0400, you wrote: 
USER user@host sounds like a possible good workaround - I realise that
there almost certainly are servers using email-address style logins out
there, though, so there are problems. Another good reason why we need to
seperate this issue from the rest, and get the rest of the draft (IMHO,
quite ready for RFC publication) out of the door.
<<<<

I was just reminded of another issue with using the '@' sign - that is what
to represent it as in a URL.  Granted, the spec suggests we should be able
to say "ftp://user%40host:pass@host", since 40 is the ASCII hex equivalent
of '@'.  However, it adds another possibility for confusion.

I do, however, like the idea of a separator, in that it allows the use of
current ftp clients.  Unfortunately, it's going to be hard to find one that
doesn't occur naturally in the wild in existing user names, and yet which
can be entered into an old FTP client.

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [email-masked].  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*

---

From: Stephen Tihor <[email-masked]>
Date: Mon, 25 Oct 1999 18:44:46 -0400

user@host is used by Lyris for most of its authentications.