Subject: Ftp-WG: MLST Draft Comments

From: Robert Elz <[email-masked]>
Date: Wed, 2 Jun 1999 11:02:53 -0400

Date:        Wed, 26 May 1999 07:54:10 -0400
    From:        Alun Jones <[email-masked]>
    Message-ID:  <[email-masked]>

I have been updating the draft, and I came acorss a problem with
other text in the draft, and this method ...

  | "The rationale behind this is that implementations of the HOST command
  | should be free to work as 'wrappers' - as a separate process

The problem is with the REIN command.   As I recall it, earlier discussions
(and certainly the current text in the draft) had settled upon the REIN
command resetting everything - including the selected hostname, such that
another HOST command needs to be done after a REIN.   That is in conformance
with what 959 says about REIN ...

	    This is identical
            to the state in which a user finds himself immediately after
            the control connection is opened.

If HOST is implemented via wrappers to old FTP servers, can this possibly
be handled correctly?   Wouldn't an old FTP server just see the REIN
command, and reset itself to the state just after it gained control - that
is, after the HOST command had been processed?

To me this means that either we re-open the REIN discussion (as brief as it
was), and allow REIN to re-initialise to the state after the HOST command,
or we give up on the idea of unchanged ftp servers being invoked to handle
HOST handoffs.

Which?

[Personal aside - I don't think much of changing REIN from the 959 definition,
even though I regard the pair <tcp-open, HOST> as pretty much a unit.  I'm
also not sure that I see many instances where someone is going to be 
implementing the HOST command in a server, without having the ability to
make any changes in the server - if that (old) server can be told that it
is coming from a HOST wrapper, then it can easily handle REIN the way it is
currently defined, and also trivially generate whichever 2xy code we pick].

  | [If this gets included, do I get an author credit?]

Sure, if you want, I don't mind who is listed as an author.

  | It may be nice to use:
  |     mlst-opts-ok = "200 MLST OPTS " *(factname ';')

Fine.

kre

---

From: Alun Jones <[email-masked]>
Date: Wed, 2 Jun 1999 14:45:27 -0400

>with what 959 says about REIN ...

Maybe a further note to the effect that implementing a wrapper for HOST on
an otherwise unchanged server means that REIN will not reset to the state
immediately following connection, but the state immediately following the
HOST command - this will be out of compliance with the MLST draft.
Further, the issuance of a HOST command after REIN will produce an error,
indicating that HOST is not supported by the server.  The client must take
this as a sign that the way to REINitialise this session is to close and
re-open it, issuing the HOST command again after the new session is open.

Since REIN is very rarely used (I had no problems reported before I
implemented it), I'd say it's not _drastically_ important, but that a
server supporting HOST explicitly (i.e. not through a wrapper) should treat
REIN as an invitation to wait for a new HOST command, and that a client
supporting HOST should deal properly with a 5xx response to the HOST
command after REIN.

This has the advantage of essentially leaving the definition of RFC959
alone as much as possible, and placing all the work on new platforms,
rather than essentially requiring retrofitting to old servers.

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*