Subject: Ftp-WG: MLST-07

From: Robert Elz <[email-masked]>
Date: Mon, 2 Aug 1999 08:47:00 -0400

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

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

Do you think something needs to be said about that?   Undefined means
"do whatever you like", so generating a 550 would be fine, as would
returning a mod time of Jan 1 1970, or some other meaningless gibberish.

  | 4.4 - The example uses a file called "A",

Point taken, will fix.

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

It is supposed to return an error.   Doesn't it say that?   If not, I will
fix it.   (That is, the server isn't supposed to open the data connection for
a MLSD until after it has verified that it will have a listing to send).

I'll also make sure there's an example of this actually ocurring.

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

Could be done.    My server does, when it can (when it has permission to
read back through the directory path and find a path name - it doesn't 
attempt to calculate from the CWD commands issued) but I didn't want to
require that of others necessarily.

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

That I guess is for the WG.   What the examples say is (mostly) what my
server (and Marty Gleeson's server for some) happened to return, that
shouldn't be taken as an implication fo anything.   My intent was to allow
the server to return any case that happens to be convenient for its author,
but perhaps others would prefer that we recommend something?

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

Oops - bug in my server.   Will fix, and fix the example 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.

I simply did that which was suggested on the list.   I see no problem with
reversing it (also little advantage, but that little consistency probably
wouldn't hurt).

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

I guess that could be done, and would have some advantages.   I'm not really
a client author, and this would tend to affect clients more than servers,

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

I don't know, should it?    Is it really right to read this as "An ef tee pee
implementation..." or as "A File Transfer Protocol implementation..." ?

I've never known.   As well as this posing of the question here, I'll ask a
known grammar pedant, and see what he suggests...

kre