Subject: Ftp-WG: MLST-07

From: Alun Jones <[email-masked]>
Date: Thu, 29 Jul 1999 17:32:26 -0400

At 06:00 PM 6/16/99 -0400, Robert Elz wrote:
>I guess you have all seen the announcement that a new version of the mlst
>draft is now available.   draft-ietf-ftpext-mlst-07.txt

Here's a couple of thoughts from MLST-07:

3.1 - "Attempts to query the modification time of files that are unable to
be retrieved generate undefined responses" - for good security, of course,
the 550 return should be generated.

4.4 - The example uses a file called "A", leading to the commands being
listed as:
TYPE I
SIZE A
TYPE A
SIZE A
While it's likely that anyone reading this text will be mostly familiar
with RFC 959 and its offshoots, it might be wise to choose a file name that
isn't already an argument of one of the other commands in the example.
Just for clarity's sake.

8.2 - In LIST or NLST, there is no good standard as to what to do when the
user has no permissions to list a requested directory; most servers follow
the de-facto standard from Unix of providing an empty listing.  What is
MLST or MLSD supposed to do in such a situation?

8.3.1 - MLSD; on the 'type=cdir' line, should we suggest that TVFS servers
display a full path, to match the output from MLST?

8.5 - Standard facts; It's implied by the examples, but maybe it should be
stated - is there a specific case that servers _should_ use in outputting
facts in listings and/or FEAT/OPTS responses?

8.8.1 - Examples - FEAT here returns 201, whereas the RFC (2389) says it
should return 211.  This is an issue in the example for 8.9.2 as well.

8.9.1 - OPTS MLST response.  Any reason why the message shouldn't better be
"OPTS MLST" [ SP 1*( factname [ "*" ] ";" ) ]?  In other words, combine a
couple of things:
a) Reverse the OPTS and MLST, so that the output looks very much like the
command that created it.
b) Make the facts list output be exactly the same format as that displayed
by FEAT - thus allowing servers to use the same function to create it, and
clients to use the same function to evaluate it.

General note on implementation:
As is perhaps widely known, Windows has two names for every file - the long
name, and the shorter, 8.3 format short name.  Is it advised that an
MLSD/MLST implementation list all [reasonable] names by which a file is
known, or is it better to stick to the one format all the time?  If all
names are to be listed, maybe some consideration can be given to the
doubling of size of transported, redundant information.  In my own case,
under Windows, I don't have, AFAIK, anything to use as the 'unique' fact to
allow a client to tie the two entries together, but maybe there could be a
"ditto" fact, to mean that this line's file name is to refer to the same
file [and with the same facts] as the previous line's.  Comments?

Minor spelling / grammar mistake:

8.3 - "A FTP implementation"?  Should that be "An FTP implementation" instead?

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: Stephen Tihor <[email-masked]>
Date: Fri, 30 Jul 1999 00:37:50 -0400

Wouldn't a suitably qualified MS-DOS short name path be useful as 
a unqiue fact for short and long named files in the windows version.

---

From: Alun Jones <[email-masked]>
Date: Fri, 30 Jul 1999 08:03:42 -0400

>a unqiue fact for short and long named files in the windows version. 

You mean the whole path?  Up to 256 characters of it, possibly including
semicolons [and the escaping thereof]?  I'm sorry, I missed out the
adjective "reasonable" from my posting. :-)

It'd be interesting, however, to note what other people are using on other
platforms to generate their 'unique' fact - for instance, those using
inodes, how does your solution cope with more than one drive, in which case
any number of files would share the same inode, just on different mounts,
right?  [It's been a while since I was seriously into Unix, sorry]

Alun.
~~~~

---

From: Stephen Tihor <[email-masked]>
Date: Fri, 30 Jul 1999 14:00:50 -0400

That was what I was thinking. After all a unique id is an opaque object of 
no interest to any one else.   for example on VMS you would use a device name
and a fileid of:  _AXP3$DRA0:(123879,1238,3)  possible encoding it to taste
as axp3$dra0fid123879a1238v3 to avoid most funny characters.   I suppose a 
serve could generate hashes and cache the translations for the duration of the reasonable like of a unique fact. 
Or take the full path composed of short names, then encode it as base-36 since 
that uses only a-z and 0-9.  Or base 62 or 64 if you are willing to use upper and lower case.  
giive the path is generally monocase you should come up with a decent compression
ratio.