Subject: Ftp-WG: HOST command and client upgrades

From: "Jan Mikkelsen" <[email-masked]>
Date: Mon, 25 Oct 1999 21:04:37 -0400

Alun Jones wrote:
>A thought struck me, that Americans would describe as a "Well, Duh!"
moment.
>
>user@host is just as acceptable as host@user.  You'll never see @ in host,
>and host is the last part before the <CR><LF> delimiter.

Very true. :-)

>Unfortunately, it still suffers the same problem - if you get
>"[email-masked]", is that a request under the new scheme, or is it an old
>username?  Perhaps it's not too difficult - it's almost certainly not going
>to resolve both ways, so try whichever works, if you're in the transition
>period.

I don't think it matters too much.

Let's look at the posibilities:

1. Server with a single virtual host, and a single username namespace.

No problem:  The host is a given.  If the hostname component matches a known
host, remove it, if that fails to match a username, try the whole thing.
However, see below.

2. Server with multiple virtual hosts, username namespace for each virtual
host.

The input format must always have a host component, which must be extracted
to determine which username namespace to check.  If it doesn't, the login is
a a failure before it's even started.

3. Server with multiple virtual hosts, single username namespace.

This is the same as case 2, as the server still needs the hostname component
(presumably) to decide what to serve.  If it doesn't need that, then it just
a different namespace based purely on the username, and is exactly the same
as case one.

In all cases, a username containing the delimiter is still a valid username,
it might just need to be fully qualified.  Eg. "[email-masked]@texis.com" to
have "[email-masked]" be the username on the FTP virtual host "texis.com".

The problem with case one is any sites which have this pattern:  Hostname
"domain.com", and users "[email-masked]" and "blah".  Site managers in this
case will need to choose a standard method, and inform their user base.

I must admit I prefer user@domain; it is a form more familiar to most users,
and may even happen to be equal a valid email address.

Jan Mikkelsen