Subject: Ftp-WG: HOST command and I18N Draft

From: "Curtin, William" <[email-masked]>
Date: Fri, 19 Mar 1999 16:59:24 -0500

Alun,

  Thanks. Some comments below.

> -----Original Message-----
> From: Alun Jones [mailto:[email-masked]]
> Sent: Friday, March 19, 1999 1:34 PM
> To: FTPEXT Working Group
> Subject: Ftp-WG: HOST command and I18N Draft
<snip>

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

I thought I recalled some discussion about HOST preserving the language set
via
a LANG command and the LANG command being issued before the HOST command. If
HOST does not preserve any state that actually makes things easier for me.
I can simply give a caveat that language support may be part of a "virtual
host" and that a LANG 
command may not be needed in all cases to support language negotiation. I'll
also state that 
the LANG command, if needed, should be issued after a HOST command and prior
to authentication. 

I can suggest that "welcome messages" be issued after the LANG command
(shouldn't hurt to say it for LANG as well as HOST commands). I've been
thinking about what to do with login information for support of old clients.
That is, if a server waits until after a HOST or LANG command to send login
information, old clients will never see it and the next command will have to
be USER. I'm going to say that servers may wish to return login information,
in their default language, as part of a 220 reply but may wish to retransmit
if a new language (different than the default) is negotiated prior to
authentication.

Also note that if I use the HOST command to determine if an new server is
talking to an old client or a new client is talking to an old server, that
it will couple this draft to the "Extensions to FTP" draft (this draft is
already coupled to the I18N draft). Does anyone have a problem with that? In
my working draft, that I'm working on now, I mandate support of the HOST
command. Another way might be to MANDATE the LANG command and use it
instead. 

<snip>

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

Presumably though if the HOST command is via a wrapper to an old server then
the LANG command will fail so this shouldn't be a problem right? 

> Alun.
> ~~~~

					thanks
					  bill