Subject: Ftp-WG: Lang command

From: "Curtin, William" <[email-masked]>
Date: Tue, 12 Jan 1999 16:03:49 -0500

I've been trying to think through the addition of a "LANG" command and
associated FEAT response and OPTS request, for the I18N draft (as
recommended from the last call).

Here is my plan:

1. Create a LANG command with parameters associated with the primary
language tag defined in RFC 1766 (i.e. ISO 639 tags). 

2. Recommend that clients, prior to authentication, issue a FEAT command to
discover what languages the server can support.

3. State that servers must support "Welcome banners" and command
responses/errors in a given language to claim support for that language. The
draft would of course state that FTP commands included in responses (e.g.
USER, PORT, etc.) should not be translated into the language being
supported. The server must wait until after receiving a LANG command before
issuing the "welcome message".

4. Require the client issue OPTS for the LANG command with the requested
language prior to authentication.

5. If the server cannot support the language being requested by the client,
it must use the default language. The default language (i-default) is
defined in 1766. Now RFC 2277 states that the default language must be
understandable by english speaking people. Will the recommendation that
servers must support "en" as a default start a flame war?

This will all work fine for new clients and servers but I'm having some
problems figuring out when the welcome message can be sent.

For new clients and servers: MLST recommends the server wait until after a
HOST command is issued to send the "welcome". What if a HOST command is not
sent? Should the I18N draft require MLST be supported and therefore HOST
will be supported (presumably after the LANG command and before the USER
command). Also some discussion has recommended defining a new command for
displaying the "welcome" message. Should a command be defined to do this and
relieve the dependence on HOST? That latter approach seems cleaner to me.
The requirement would be that the client issue a new "MESS" command just
prior to authentication.

For old clients and new servers: How should the server recognize that it is
talking to an old client and that it should probably issue the "Welcome"
after the TCP connection?? If it waits for the LANG, HOST, MESS commands to
first send the "welcome" message it will receive the USER command and the
human associated with the user-PI may miss login information from the
server.

For new clients and old servers: It probably doesn't make a difference as
the old servers will not recognize the LANG command and the client get
responses and messages in the language supported by the server. No
difference than what is happening today.

Guidance from the group would be greatly appreciated.

							bill

---

From: Alex Belits <[email-masked]>
Date: Tue, 12 Jan 1999 17:52:53 -0500

> language tag defined in RFC 1766 (i.e. ISO 639 tags). 

  While I don't think that such functionality is important, if it will be
considered to be useful, I have several comments about implementation.

> supported.

  Text part of the response to FTP commands in most of cases is not
supposed to be parsed by the client that uses numerical part only, and in
existing implementations text part sometimes is translated into the
locally configured language (say, AIX ftpd). While this practice is often
counterproductive (remote human user may be unable to read the
local language), it's harmless.

> The server must wait until after receiving a LANG command before

  Unlikely. However it may be necessary to send a language/charset pair
instead of language only -- some languages have multiple charsets, and
even though some people propose the total ban on all charsets other than
Unicode and on all encodings other than UTF-8 (or at lease cripple the
charsets support to make the use of anything but UTF-8 as much painful as
possible), users of other charsets strongly disagree with it. However if
multiple charsets and languages are supported, there must be no
requirement that all servers must support all charsets of the same
language if even only one charset for this language is supported --
computer may lack the resources to do such conversion, or data necessary,
or available conversion may be ambiguous.

> problems figuring out when the welcome message can be sent.

  "Welcome message" is an optional multiline part of the successful login
message ("230 User logged in, proceed."). Nothing can prevent the issue of
the login message without breaking the protocol and compatibility with
existing software, and disabling it merely because of lack of "LANG" will
confuse users -- FTP, as opposed to HTTP, is a very old protocol, and it
has no place for a version number in the request. So existing clients that
never send any additional commands will simply be left without any
possibility to see "welcome message". Enabling this feature only of FEAT
is requested may seem to be more reasonable, but it will give FEAT a
rather ugly side effect.

  Along with "welcome messages" it's common for FTP servers to display
help, various multiline information in response to CWD, etc., so
implementation should affect either all content-dependent responses over
control socket (in the cases when translation of those particular messages
is available), or none, to be consistent.

> The requirement would be that the client issue a new "MESS" command just

  I don't understand how proposed HOST command complies with the
requirement of backward compatibility at all. It is made as an imitation
of HTTP "Host" header, however in HTTP it became mandatory in HTTP 1.1.
Not being mandatory the possibility of HOST provides no means of reliably
identifying the virtual host if multiple hosts share the same IP address
for clients that are not aware of it, except by sending some kind of 
"welcome message" that tells the user to enter HOST manually, immediately
after his login.

  My personal opinion is that FTP should not imitate HTTP in areas where
HTTP implements its features in a way, significantly different from FTP.
If such features are necessary, HTTP should be used instead of FTP in the
first place. While it's true that FTP "competes" with HTTP, there are a
lot of situations where the use of HTTP is completely justified, and there
are absolutely no benefits that FTP provides over HTTP. In those cases
it's just more reasonable to use HTTP and leave FTP alone.

  FTP is a protocol, not a product, and increasing its use at the expense
of other protocol in the manner that will not benefit efficiency and
usability of the Internet is not what the development of Internet
standards is about. One can use FTP instead of SMTP or NNTP, too, however
currently it's clearly visible that it will be pointless to "improve" FTP
into the direction that will allow to replace those protocols because SMTP
and NNTP serve their purposes better than any "improved" FTP ever will be,
unless it will incorporate them. I propose to leave HTTP alone with its
use, incorporate into FTP the best ideas that fit (this is why long ago I
proposed to define operations to be byte-transparent by default, and to
add optional language/charset labels to MLST), and make something useful
from it. The goal of making FTP into better HTTP than HTTP is childish,
and unlikely even to benefit FTP servers and clients' developers, not to
mention users.

  There is a possibility that in the future the improvements in HTTP will
make HTTP match every piece of FTP functionality, and will make FTP
obsolete. If that will happen, nothing will be lost because functionality
will be still there. Currently this is not the case, and FTP use is
justified. I see the goal of FTP improvement not to compete with anything
or provide a possibility of unusual uses for FTP that are already served
by other protocols -- the goal is to improve FTP to allow its use in
existing situations where FTP, for good or bad reasons, is used, and will
be used for a long time, and in areas where nothing serves the purpose
well, but FTP can fit if improved. Non-ASCII filenames and directory lists
formats are among cases where FTP standards need improvements because of
the nature of data and operations, commonly performed over FTP. Virtual
hosting of web sites and file archives is the area where HTTP fits very
well, and needs no replacement -- people who want their file archive to be
on some virtual host shared with other archives, have no need in
"nice-looking" FTP URL if the price is any decrease in compatibility with
existing FTP clients. It's not HTTP where the URL became a symbol of the
identity and status of its owner.

  Anyone who wants to answer to this and argue that HTTP is bad,
inefficient, etc., should read relevant standards carefully first -- I
did, and I expect others to do the same if they want to discuss it. The
flaws of existing implementations of HTTP are well known, and I will not
argue that poor implementation of HTTP, or the enormous size of some
specifications, associated with HTTP, do not cause damage. However it's a
poor justification for extending FTP (thus bloating the standard and
creating possible incompatibilities, too) into that area.

> after the TCP connection??

  The message after TCP connection is "220 Service ready for new user." It
must be sent by the server without any expected input, and protocol that
does not implement this is by definition not FTP.

> If it waits for the LANG, HOST, MESS commands to

  Only commands, sent between the initial connection and USER can affect
the login message.

-- 
Alex

----------------------------------------------------------------------
 Excellent.. now give users the option to cut your hair you hippie!
                                                  -- Anonymous Coward

---

From: Alun Jones <[email-masked]>
Date: Thu, 14 Jan 1999 08:07:10 -0500

>"welcome message" that tells the user to enter HOST manually, immediately

That is correct.  The intent is that sites in future will be of the
following kinds:

1. RFC-959 compliant: no HOST command is accepted, and either FEAT is
unrecognised, or does not return HOST as an option.  The client is not
expected (or allowed) to send a HOST command.
2. HOST command accepted, FEAT reports that HOST is allowed, yet there is
some 'default' environment/host that is entered by those clients with no
HOST command implemented.  Here, the greeting message could make it clear
that the "QUOTE HOST" command can be used to enter other hosts.
3. HOST command required - FEAT reports that HOST is allowed, no other
action is allowed until the HOST command is entered.

The FTP server will still send a 220 message in greeting, and a 230 message
once the user and password have been verified on that host.  No difference
there.  I've suggested, I believe, that the response to HOST be 220, so
that a HOST command could be implemented by a wrapper that passes the
client on to a standard server.

>it's just more reasonable to use HTTP and leave FTP alone.

The HOST command was suggested from the simple standpoint that many people
have been asking for it.  Yes, it derives in some sense from the perception
among users that if HTTP can distinguish between hosts on the same IP
address, surely FTP should also.  No, it isn't an attempt to compete with
or supplant FTP - it is merely an attempt to allow co-location of servers
without further depleting the IP address space by requiring a different IP
address for each FTP server.  To some extent, it is necessitated by the
fact that multiple HTTP servers can run on the same IP address and be
distinguished from one another, and that FTP servers may be dropped if they
cannot do so.  To lose FTP's numerous advantages over HTTP for this reason
would seem petty.

>and unlikely even to benefit FTP servers and clients' developers, not to

This is not even remotely what this is about.  You've got the wrong
impression entirely.  We are not attempting to supplant HTTP - although
your same accusation might be thrown at HTTP (after all, FTP had a
persistent connection for multiple transfers _long_ before HTTP did it, and
for HTTP to do it just because FTP has it "is childish", etc, right?)

>will be still there.

You sound like you're saying that HTTP should continue to improve to
subsume FTP, and that FTP should remain static?  I don't accept that.
There is still a place for FTP, and there is still room for improvement to
FTP.  A protocol that refuses to improve to match bona fide requirements is
doomed.

>  Virtual

Excuse me?  You're now saying that a file archive is the perfect use of
HTTP, and somewhere that FTP shouldn't stick its nose in, for the sole
reason that the archive is 'virtual'?  This same effect can be achieved
right now, through FTP as it exists, with the major downside that it uses
one more IP address, and requires each server that is co-located on a
machine to have its own IP address.  The addition of the HOST command
serves solely to remove that requirement of multiple IP addresses per
machine (which is often difficult to achieve in some OSes).

>does not implement this is by definition not FTP.

This remains true with the HOST command, as for the LANG command.  A 220
greeting message is _always_ to be issued to the client on connection.

>  Only commands, sent between the initial connection and USER can affect

My original idea is for the HOST command to send a fresh greeting, based on
the server's newly selected identity.  If HOST and LANG are both supported,
and both generate a greeting message, this could be an issue that needs
fixing - either allowing a language argument on the HOST command, for
instance, or by stating that one should precede the other.

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*