Ftp-WG: Re: draft-ietf-ftpext-mlst (fwd)

Finally I manage to get all information from IESG members _and_ time to
summaarize them.

Here they are (many I think are minor and can be done just because I think
a new version is needed anyways):

(A) 

Section 3 talks about comparing the server's file modification time to the
client's. But 2.3 says that the times aren't synchronized.

I asked what the issue was and got the following dialogue:

>> The key sentence is in 2.3 before the one talking about time not being
>> synchronized:
>> 
>>     A server-FTP process should always use the same
>>     time reference, so the times it returns will be consistent.
> 
> Right.  But it's easy to read "file modification time" as "local file 
> modification time".  I think the document should suggest asking for the 
> modification time before a transfer, so that that can be compared with
> the modification time retrieved before a restart.

>> 
>>> Servers should ensure that the unique identifier fact is not security 
>>> sensitive, e.g., it should not be the NFS handle for the file.
>> 
>> Is this something you want to the Security Considerations Section?
>> 
> It probably should be there.

(B)

Should this doc say that it updates STD 9, see sec 8?

(C)

Section 3.4 starts:

      If we assume the existence of three files, A B and C, and a directory
      D, and no other files at all

but later it assumes the existence of files named "file6" and
"19990929043300 File6".

(D)

Section 7.1:

            For these purposes, the contents of a directory are whatever
      file names (not pathnames) the server-PI will allow to be referenced
      when the current working directory is the directory named, and which
      the server-PI desires to reveal to the user-PI.

Earlier text refers to both "file names" and "directory names", implying
that they are seperate things, so this text seems to preclude including
directory names in MLSx responses. Should this say "file or directory
names"?

(E)

In the last paragraph of 7.2:

        Facts
      should be provided in each output line only if they both provide
      relevant information about the file named on the same line, and they
      are in the set requested by the user-PI.

Should this refer to section 7.9, since this is a forward reference
to the fact that the set is requestable?


(F)

Section 7.5.1:

...
                file -- a file entry
...

                type-val = "File" / "cdir" / "pdir" / "dir" /
                                                    os-type

Fact values are case-sensitive, right, so the ABNF should probably
use "file".

(G)

Relevant to section 7.5.1.2 and 7.5.1.4:

All the examples in section 7.7 show listings where, if present,
"type=cdir" and "type=pdir" are at the beginning, despite the warnings
that they may be anywhere. Even if it means modifying an example from
what was actually returned by an implementation, I think it'd be worth
having an example that has these entries elsewhere, since examples are
commonly heavily used during implementation.

(H)

Section 7.7.9:

This server seems to use uppercase when fully-qualifying the type=cdir
entry on MLSD responses, and lowercase when fully-qualifying responses
to MSLT. This is a little confusing, so although the explanation does
mention that it is a case-independent NVFS, perhaps it could explicitly
say "and that's why it uses different case for the fully-qualified path
in different responses".

(I)

The last example in section 7.8.1:

  S> MLST Type*;Size*;Modify*;Perm;Unique*;

      ... All of the facts supported by
      this server are enabled by default.

In the example response, Perm is not enabled by default.

(J)

7 says that all 256 octet values are permitted. Must telnet NVT characters
be escaped here? Or, should it be said that all 256 octet values are
allowed after NVT processing? Clarify.

(K)

Servers should ensure that the unique identifier fact is not security
sensitive, e.g., it should not be the NFS handle for the file.

This can be handled by explicit sentence in Security Consideration Section.






===================END FORWARDED MESSAGE===================

Paul Hethmon
[email protected]
http://www.hethmon.com