Subject: Ftp-WG: size and mdtm - Internet Draft Extensions to FTP draft-ietf

From: [email-masked]
Date: Thu, 15 Apr 1999 16:58:43 -0400

I and my colleages have read your Internet Draft, Extensions to FTP,
draft-ietf-ftpext-mlst-06.txt, February 1999.  We are considering whether
an appropriate state diagram for the SIZE and MDTM command should be as is
shown
in RFC 959, section 6, page 54, for the

commands ABOR, ALLOC, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, QUIT,

SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE,

or whether the state diagram in RFC 959, section 6, page 55, for the

page 55, for the APPE, LIST, NLST, REIN, RETR, STOR, and STOU commands

is more appropriate.   Or perhaps,  a new state diagram would model SIZE
and MDTM?

On the one hand, Extensions to FTP lists only a
limited number of acceptable replies which would seem to be very
restrictive.
The page 55 state diagram seems to be appropriate for those commands that

require a data connection, which the SIZE command would not require.

On the other hand, the draft uses the terminology should and not must
when describing acceptable responses, suggesting some leeway in replies
returned to the client.    Perhaps additional replies are to be tolerated
by the client and we can
envision circumstances where use of additional replies would provide
function to the FTP client.
Here's some examples we thought of:
      530 Not logged in.
   125-Waiting for volume mount for %s

Our FTP server in general provides that you provide a login and password
before issuing certain commands.  It seems resonable to us to put SIZE
andMDTM in that category, hence 530.

Our FTP server provides an interface to files which reside on devices which
must be physically mounted by an operator.
We'd like to suggest to the client that it might be awhile before the
response can be returned, hence the reply 125.

Can you provide us with some advice on an appropriate state diagram model
for SIZE and MDTM?

Thanks!

Janet C. Wolf
CS/390 Development