Subject: Ftp-WG: HOST command and client upgrades

From: "Jan Mikkelsen" <[email-masked]>
Date: Mon, 25 Oct 1999 08:20:07 -0400

Robert Elz wrote:

>  | In order for a client to use HOST, MLST, whatever new feature, it must
send
>  | (say): "VER RFC-nnnn" or "VER FTP-n".
>
>I don't think that is needed. [...]

I don't think I explained myself very well in my original post;  I was in a
bit of a hurry.  I understand that FEAT lets a client see what a server can
do, and not send spurious commands.  That is a good thing.

My original suggestion was to force servers to fail any "new" command,
unless the client sent HOST first, in a similar way to HTTP/1.1, and for
similar reasons.  I suggested using FEAT to determine whether the HOST
command should be required of a client.  It was quite correctly pointed out
that FEAT was specified in an earlier RFC, and so using it as an indicator
might not be such a great idea.  Clients which implemented RFC 2389 in good
faith should not suddenly break.  The "VER" suggestion was an (admittedly
not very well thought out) attempt to give the server a way to determine the
claimed conformance level of the client.

The purpose of this is not to force all clients to suddenly support HOST,
but to have new clients support HOST, so that sites that need host have some
change of pointing users to clients which also support HOST.

It may well be that all this isn't necessary, and a simple "MUST" in the
specification will do.  But the mind of a client developer gets focused when
a server tells his client to go away.

>wrt HOST - Dan is quite right, it will be basically useless until
>clients support it.

Absolutely.  It a simple thing for clients to support, but, at least
initially, will not provide much benefit.  The benefit of HOST is really to
operators of virtual FTP sites, not to clients at all.

>It may be that with the number of ftp client implementations already
>in the field, and perhaps never to be updated, adding virtual FTP hosts
>may simply be impossible now, however desireable it might be.   It was
>possible with HTTP, given that there were only a few browsers around,
>and essentially no other tools at the time, and the browsers were still
>in such a state of flux that almost everyone updated them monthly.
>None of that is true with FTP.

The operator of an FTP site can make a decision about his user base, just as
HTTP operators have.  There was a point where it became practical to operate
an HTTP site using the HOST header to determine what to serve, and that
point might have varied from operator to operator.

However, if no attempt is made to have new clients support HOST, that point
will never come, or it will require other kludges.

There are still HTTP clients installed which do not generate the HOST
header, but they form such a small part of the traffic that they just plain
do not matter.

>If we are going to continue to discuss HOST, I'd suggest that we decide
>to move it out of the MLST draft (and let that get smaller), and make
>it a draft of its own, that we can then decide what to do with.  It is
>certainly the least mature part of what is currently in MLST.  If we
>do that, and someone else would prefer to be the editor of the HOST draft,
>that's fine with me...

I'm much more interested in virtual hosts than MLST, but if others are
desperate for MLST to be published in an RFC, I don't want to stand in their
way.  But I must admit I do see it as a convenient way to force client
implementors to support virtual hosts.

In any case, to continue the virtual host discussion:

An alternative way of implementing virtual hosts might be not to have a
separate command at all, but rather to overload the user command.  If a
server responds with a particular attribute in the FEAT response (say,
something like "USERHOST"), the client can, optionally, preceed the username
with the virtual host name.  Users of old clients can manually enter the
hostname before the username to access a particular virtual host.

This provides a way for old clients to work with virtual hosts, and for new
clients to automate the process.

The drawback of this is that putting a virtual hosting front end onto an an
old server is a little more work, and it still suffers from the REIN issues.
But I'd question how many sites that actually depend on virtual hosting
would implement it that way.

Jan Mikkelsen

---

From: Robert Elz <[email-masked]>
Date: Mon, 25 Oct 1999 08:58:28 -0400

Date:        Mon, 25 Oct 1999 08:20:07 -0400
    From:        "Jan Mikkelsen" <[email-masked]>
    Message-ID:  <[email-masked]>

  | My original suggestion was to force servers to fail any "new" command,
  | unless the client sent HOST first,

That's certainly an option for servers that are running virtual hosts.

  | I suggested using FEAT to determine whether the HOST
  | command should be required of a client.  It was quite correctly pointed out
  | that FEAT was specified in an earlier RFC, and so using it as an indicator
  | might not be such a great idea.

Who said that?    For a client that has any idea at all about any of this
(virtual host stuff I mean) then if the server says HOST in its FEAT output,
the client should certainly be sending a HOST command.   If the server
doesn't say HOST in its FEAT output, then the client can still send a HOST
command, but it ought be expecting a 500 type reply from the server (unknown
command).

Clients that don't understand virtual hosts aren't going to bs sending
HOST commands whatever the server's FEAT output says, or doesn't say.

Why was using this considered to be not a reasonable thing to do?

  | But the mind of a client developer gets focused when
  | a server tells his client to go away.

Yes, and if that is what is needed at some server, that is what should
be done.   If you want to support many different virtual hosts, and your
clients aren't telling you which one they want, you really have no other
choice (and looking to try to determine that it is a new client, and so
really ought to have implemented HOST, but just didn't, rather than it
being an old client which hasn't been touched in decades, doesn't really
make any difference at all).

  | I'm much more interested in virtual hosts than MLST, but if others are
  | desperate for MLST to be published in an RFC, I don't want to stand in their
  | way.

So far there has been almost zero opinion expressed on this matter
(just Alun really).   It would be nice to hear from others in this group.
I know there are more of you out there...

  | But I must admit I do see it as a convenient way to force client
  | implementors to support virtual hosts.

I doubt that which doc it appears in will make much difference there.

  | An alternative way of implementing virtual hosts might be not to have a
  | separate command at all, but rather to overload the user command.

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.

Any of those schemes are fine - there's no defined syntax for a user name,
it can be anything that your server wants it to be (or allows it to be).
The NVFS that is presented clearly depends upon the user that connects,
it always has - so whether you break apart the user name and use some of
that to choose the NFVS root, and another part the initial directory
within the NVFS, or whether the whole string is used to access a database
giving that info, or anything else at all like that, is entirely up to
the server - and none of that is going to change.

The difference between any scheme like that and the HOST command, is that
the user cannot get any "you have connected to xxx" type messages that
reference the virtual host name before they have logged in using the
overloaded user command.   The HOST command is intended to be part of the
initial connect sequence, allowing the welcome message to appear after it
has been given instead of before.

Apart from that there isn't really a lot of difference I can see.

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.

kre

---

From: Alun Jones <[email-masked]>
Date: Mon, 25 Oct 1999 09:34:49 -0400

>I know there are more of you out there...

That's because I like hearing the sound of my own ... or rather, seeing the
look of my own typing :-)  Actually, it's because I want to make sure that
my views are heard - if they're rejected, that's fine, but if I don't
express them, I can hardly complain later.

>I doubt that which doc it appears in will make much difference there.

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.

>suggestion was to use user@host as the USER command data.

Ideal would be some means whereby either a client could send the host to
all servers, and have it discarded by those that don't care, or where the
client could tell up front whether or not to send the HOST command.  Each
time I try to tell customers they can't use space, or quotes, or some other
character in their user names, I've been told that these customers used
those characters - and I'd be surprised if there wasn't a server somewhere
that used email addresses as user names.

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
on older clients - simply refuse a bland login with a message indicating to
quote the HOST command before logging in.  Unfortunately, this doesn't
confer the same backward-compatibility to either MLSD or EPLF - but since
MLSD uses a new command, that backward-compatibility is not at issue; for
EPLF, where the output from the existing LIST command is codified to be
something other than what those old clients expect, that loss of
compatibility is very much at issue.

>has been given instead of before.

I would say "as well as" rather than "instead of" here - there is option
for a greeting message prior to the HOST command, in particular this could
warn users either to use the HOST command, or to use some other means of
selecting host names.  Microsoft's instance of putting "USER domain\user"
to allow logins to be authorised by different domains is one example of the
kind of instruction that could be given to old client users.

>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?

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: "D. J. Bernstein" <[email-masked]>
Date: Mon, 25 Oct 1999 10:26:26 -0400

Jan Mikkelsen writes:
> There was a point where it became practical to operate

Right. The same will be true for FTP HOST, if more and more clients
start supporting it. Server implementors and individual sysadmins will
_eventually_ find it practical to cut off service to non-HOST clients.

Of course, it would be suicidal for a server to stop providing files to
non-HOST clients _today_. But this is a red herring. The HOST transition
plan is for clients to upgrade _first_.

Similarly, the EPLF transition plan is for clients to upgrade _first_.
Most servers don't want to cut off listings to non-EPLF clients _today_,
but this is a red herring. Server implementors and individual sysadmins
will _eventually_ find it practical to use EPLF.

Jones says he'll get hundreds of complaints if his listings don't work
with non-EPLF clients. Well, he'll lose _all_ his users if his files
can't be retrieved by non-HOST clients. But this is a specious argument
against EPLF, and it's a specious argument against HOST.

There's a big difference between ``servers do this now'' and ``servers
do this later, when it's an improvement.'' Jones is ignoring the
difference. He's incorrectly criticizing proposals for costs that are
not actually incurred by those proposals. Why?

---Dan

---

From: Alun Jones <[email-masked]>
Date: Mon, 25 Oct 1999 11:28:12 -0400

>against EPLF, and it's a specious argument against HOST.

The big difference which you are apparently missing is that a server can
tell when the majority of its clients send the HOST command, yet it is
impossible to tell when clients are able to parse EPLF.  Hence a server
implementor/author has adequate information on when to make the switch to
denying any non-HOST clients, but zero information on when to provide EPLF
as the only listing format.

Further, as I pointed out before, and yet you so conveniently ignore, the
HOST command can be sent by a user even on old clients, without requiring
any additional code [RFC 1123 requires a 'quote' command or capability].
One cannot, however, persuade an old client to parse EPLF without adding
new code.

I don't know why I bother arguing with you - we're in a working group here,
and I don't think anyone's stupid enough to be fooled by your tactics.

Alun.
~~~~

---

From: "D. J. Bernstein" <[email-masked]>
Date: Mon, 25 Oct 1999 12:39:12 -0400

Alun Jones writes:
> impossible to tell when clients are able to parse EPLF.

Did you also claim that /./ in FTP URLs was ``unimplementable'' because
you weren't sure whether it was safe to start using it? Frankly, Jones,
you've chosen an asinine way to argue against protocol extensions.

In the real world, we collect browser version statistics through HTTP,
and so we can easily see that (for example) the vast majority of users
discarded Netscape 2.* within a year after Netscape 3.0 was released.
Browsers account for the bulk of FTP use.

> any additional code [RFC 1123 requires a 'quote' command or capability].

QUOTE has no relevance to what I said, which is that you'd lose all your
users if your files couldn't be retrieved by non-HOST clients.

If you don't believe me, go ahead and require HOST, and tell your users
to use QUOTE HOST, and see what happens. Otherwise you're a hypocrite.

You had it right when you argued the opposite side of this issue in
1997: ``How many clients, especially the GUI ones, would make it easy
(or possible) to QUOTE the HOST command to the server and then log in?''

---Dan

---

From: Alun Jones <[email-masked]>
Date: Mon, 25 Oct 1999 13:29:50 -0400

>you've chosen an asinine way to argue against protocol extensions.

I doubt that I claimed that, but if you're willing to show the reference,
I'll read what I actually said and say whether I still agree with it.
Certainly I've found notes where I've asked whether "/./" was dealt with by
the client or the server, and I can't imagine that I'd claim it was
unimplementable when it's clearly already been implemented on clients
without impact on servers.

>Browsers account for the bulk of FTP use.

Okay, so we're going to collect statistics from one protocol to assign to
another protocol?  Sounds a little loopy to me.

>to use QUOTE HOST, and see what happens. Otherwise you're a hypocrite.

Dan, that makes no sense at all.  I've stated already that HOST hasn't had
nearly enough thought or discussion behind it to even contemplate its
implementation at the present time.  All discussion of it is hypothetical
at the moment - note that while the words may appear close in the
dictionary, that does not mean the same as "hypocritical".  Part of the
discussion that needs to come about is not merely whether a solution is
technically possible, but also whether it will survive in the marketplace.
I've pretty much ignored the latter, preferring to suggest merely that HOST
may be technically feasible, whereas EPLF provides no clue as to when
implementation is technically acceptable.

>(or possible) to QUOTE the HOST command to the server and then log in?''

Anyone bothering to find that in the archives will note that I was not
actually arguing the opposite side of the issue in that email; I was
putting forward pros and cons for various solutions to multiple virtual
hosts.  Even if it were the case that my email of two years ago was on an
opposing side, what kind of a man doesn't change his mind about one thing
or another in two years and after learning more?  This is perhaps part of
my problem with you, Dan - you assume a position and then refuse to deviate
from that, regardless of changing circumstance, information or discussion.

The only reason I bother to answer your posts is to correct inaccuracies,
out-of-context quotes, and downright lies, for others that might assume
that you are correct merely because you speak with an assured air.

Alun.
~~~~