Subject: Ftp-WG: HOST command and I18N Draft

From: Alun Jones <[email-masked]>
Date: Fri, 19 Mar 1999 13:34:22 -0500

At 01:08 PM 3/19/99 -0500, Curtin, William wrote:
>  I'm trying to spit out the next (and hopefully the last) version of the
>I18N draft. I've told my boss this is the only thing I can work on until its
>done. I have a question about the use of the HOST command.

I guess as the guy that initially proposed it, I get to defend my views on
it :-(

>1. Presumably a virtual host could be set up to define a given language
>(i.e. myserver.com, english.myserver.com and german.myserver.com all
>associated with the same IP address) so that a "LANG" command would not
>always be necessary. I'm saying in the draft that language support can be
>achieved by a virtual host, if so configured, or by the use of a new LANG
>command.

Since my idea was initially that a 'wrapper' could be placed around an
existing FTP server by a "HOST" command interpreter, there should
essentially be no state preserved after the HOST command - in fact, if such
a 'wrapper' is in place, then the server has no knowledge of _anything_
transmitted before the HOST command is accepted - that's why I wanted the
HOST response to be a 220, not a 234.  If you want it put another way, have
your standard Unix inetd respond to port 21 by feeding it to 'ftphostd',
which waits for _only_ a HOST command, and then passes further commands on
to a real 'ftpd' (but with different configuration parameters depending on
the HOST chosen).

>       That is, has the HOST command overridden the LANG command preceding 
>       it because support of German was part of the virtual host?>

Yes - as far as I see it, since there should be, ideally, no use of (or
meaning ascribed to) the FEAT or LANG command before the HOST command.

>3. Perhaps the HOST command was not intended to be used to support language,
>in which case all I need to say is use LANG command to negotiate language
>prior to a HOST command. 

A LANG command could certainly be used by a more advanced server to either
provide a different listing of hosts that are accepted (we accept hosts
Albert through Zachary if LANG is English, and Albrecht through Zimmerman
if LANG is German), but the language provided after a HOST command might
not be the language requested before the HOST command - I'm not sure how
this would be dealt with, since it's been a while since I even glanced at
I18N.

>4. Given that HOST is a mandatory command I intend to use it to tell if a
>new server is talking to an old client (because the server will see the USER
>command after connection vice a HOST command prior to authentication) or if
>an old server is talking to a new client (because the client will receive a
>550 response to the HOST command). Sound reasonable?

Yes - the old client talking to the new server will either be told "no host
selected", or perhaps provide an instruction on encoding the host in, say,
the username, or simply connect to a 'default' host.

The old server talking to the new client will receive a command it doesn't
understand, followed by a USER command that works.

>5. The draft, as I have it written only addresses language support for
>greeting messages and command responses from the server.

It's perhaps tricky to call, since my initial aim for this (as with so many
modifications) was to allow for a 'quick patch' to support the new command
on old servers - the inetd wrapper, for instance - and there are reasons
both to suggest that a LANG command should be passed through to the new
host, and to suggest that you shouldn't expect to be greeted in German even
if you ask for it.  Obviously, if the wrapper can be told that a HOST
command after requesting German should lead to a different server, or a
server with parameters specifying German, then this can be done, but in the
absence of such an ability, perhaps it should not be required of a
HOST-compliant server.

Much like the EPLF proposal, it's nice to have an extension that can be
implemented through external modifications to existing software, as well as
integrated into new software.  Unlike the EPLF proposal, this is designed
so that existing servers and clients essentially don't notice that there's
anything different.

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: Gregory A Lundberg <[email-masked]>
Date: Fri, 19 Mar 1999 14:06:30 -0500

I like Alun's model.

Scope the FEAT stuff.  The host you're talking to prior to HOST is
conceptually different than the host you're talking to once HOST has been
negotiated.

The server MAY honor FEAT negotiations, such as LANG, prior to the HOST
command.

The client SHOULD NOT presume any FEAT discoveries or negotiations prior
to HOST will have any effect whatsoever after HOST has been selected.

The server SHOULD continue to honor those FEAT negotiations after HOST
selection.

The client SHOULD rediscover and renogitiate all FEAT options after HOST
selection.

The well-written client, therefore, SHOULD NOT issue FEAT until after HOST
selection.

As I see it, the correct sequence is

  HOST
  FEAT
  LANG...etc
  USER

while the following sequence is allowed, the FEAT/LANG has no effect after
HOST

  FEAT
  LANG...etc
  HOST
  USER

so, why even allow this last one if we ignore the FEAT/LANG?  so we can
allow the case where thre is no HOST:

  FEAT
  LANG...etc
  USER

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Stephen Tihor <[email-masked]>
Date: Fri, 19 Mar 1999 20:43:28 -0500

Don't we want to permit the case of:

    FEAT
    HOST
    USER
    FEAT 
    LANG
    USER

where the client uses the FEAT command to determine that HOST is available and
meaningful?  Or are we going to link the features so that HOST is mandatory if
we are using FEAT or LANG?

---

From: Alun Jones <[email-masked]>
Date: Fri, 19 Mar 1999 21:15:17 -0500

>we are using FEAT or LANG?

My personal feeling is to link the various commands as little as possible.
For instance, the FEAT command is, I believe, already out in an RFC.  We
can't (or shouldn't try to) change that definition, and perhaps the I18N
stuff should be left relatively apart from the other definitions also.  I'd
say that if the client knows about HOST, it should not send a FEAT to
discover the presence of that command - since the FEAT list may change on
applying the HOST command, it is enough to send the HOST command and look
for the 500 response, then send the FEAT after.

For LANG, there is an argument to be made that it might be sent before the
HOST command, although as has been noted, an I18N client without the HOST
command will already receive the initial 220 greeting in a default language
- hence, the client should send the HOST command first, followed by LANG
(which should then repeat the greeting in the appropriate language), and
then the USER / PASS / ACCT sequence as normal.

For FEAT and LANG, it doesn't much matter which goes first, although
applying FEAT will tell you whether the LANG command will be accepted.

Does this make any sense?  This means the sequence should be:

HOST
FEAT
LANG
USER
PASS
etc...

None of the first three commands should be treated by the server as
required of the client (except that a lack of HOST command to a server with
no default host can cause a rejection of the connection)

That sounds about appropriate - anyone got any different interpretations on
the ordering and mandatoriness of the commands in relation to one another?
I can see that FEAT is required for both the other commands, since they are
extensions to 959/1123, but there are those who would write an I18N server
that serves only one host, and there are those who would write a multi-host
server that doesn't use multiple languages.  I don't think HOST or LANG
should require the other to be implemented.

But that's just my opinion.

Alun.
~~~~

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 19 Mar 1999 23:52:36 -0500

> required of the client (except that a lack of HOST command to a server
> with no default host can cause a rejection of the connection)
> 
> That sounds about appropriate - anyone got any different
> interpretations on the ordering and mandatoriness of the commands in
> relation to one another? I can see that FEAT is required for both the
> other commands, since they are extensions to 959/1123, but there are
> those who would write an I18N server that serves only one host, and
> there are those who would write a multi-host server that doesn't use
> multiple languages.  I don't think HOST or LANG should require the
> other to be implemented.

As I see it, there are two, possibly three states.  In each state, the
FEAT response and the effect of LANG or any other feature negotiation
should carry forward at least through the transition to the next state.
During that transition, if any currently selected feature is no longer
permissible, the server should select a new default value.

The states I see are:
  - Initial connection to the default server, not logged in
  - Connected to a 'virtual host' server, by HOST, not logged in
  - Logged in on a server.

This last state is where I have a question.  I'm not sure it makes sense
to have different feature sets simply because we're logged in.

Features negotiated prior to HOST should effect the greeting sent in
response to HOST.  For instance, initially the default server might select
a default language of French.  Due to a FEAT/LANG negotiation, the client
has determined that German is available and selected that language.  All
subsequent responses should be in German.

If, during the processing of HOST, it is found that German is not allowed
for this virtual server, the language should be reset to a (possibly
HOST-specific) default language, say Russian.  The response to HOST would
be in the resulting language (German or, if that's not allowed, Russian),
as should all subsequent responses until a new language is negotiated by
another FEAT/LANG cycle.

I say 'FEAT/LANG' because I see FEAT as the way to determine which
languages are available and LANG as the way to select one of them.  The
client could simply issue LANG commands running down a list of preferences
until it receives a positive response.

If it makes sense, the processing of the USER command could also force a
reset of negotiated features.  Perhaps the user 'juan' has a language
selection of Spanish.  During processing of USER, the language would be
reset to Spanish (overriding the earlier choices of French, German, then
Russian); the response to USER .. probably the password challenge ..
should be in Spanish.  If 'juan' has additional languages available (none
of which were the language in effect prior to USER), those languages could
be selected via a subsequent FEAT/LANG negotiation.

So, we could see a sequence such as

                (Default language for default host is French)
  (French)      Greeting
           LANG english
  (French)      Negative response
           LANG spanish
  (French)      Negative response
           LANG german
  (German)      Positive response
           HOST (German not available on this host, Russian is default)
  (Russian)     Greeting
           FEAT
  (Russian)     Feature list
           LANG greek
  (Greek)       Positive response
           USER (Greek not available to this user, Spanish is default)
  (Spanish)     Password challenge
           PASS
  (Spanish)     Greeting
           FEAT
  (Spanish)     Feature list
           LANG english
  (English)     Positive response
           LIST
  (English)     Directory listing
           QUIT
  (English)     Farewell

--