Extensions to FTP
draft-ietf-ftpext-mlst-16

[Ballot discuss]
Several suggestions, all relatively minor:

--

Should the reference to RFC 2119 follow the form suggested in RFC 2119?

--

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

--

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

--

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?

--

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

--

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.

--

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

--

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.

[Ballot discuss]
The second paragraph of section 2.2 says, in part:

  Implementations are advised against converting a UTF-8 pathname to a local
  encoding, and then attempting to invert the encoding later.

I think this incorrectly confuses encodings with charsets. In particular,
I don't want an implementation that uses UTF-16 internally to refrain
from converting UTF-16 to UTF-8 on the wire. I do want, however to
discourage _charset_ conversions. I suggest this be changed to read:

  Implementations are advised against converting a UTF-8 pathname to a local
  charset, and then attempting to invert the transformation later.

I also note that even with the changed wording this is slightly in
conflct with the recommendations in section 7.5.9, but I guess this is OK.

[Ballot discuss]
Bill: Several suggestions, all relatively minor:

--

Should the reference to RFC 2119 follow the form suggested in RFC 2119?

--

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

--

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

--

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?

--

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

--

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.

--

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

--

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.

[Ballot discuss]
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.

(How many FTP clients and servers implement Block and Compressed?)

7 says that all 256 octet values are permitted. Must telnet NVT
characters be escaped here? Clarify.

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

And I don't think I particularly want to discuss the copyright notice...

State Changes to New Version Needed (WG/Author)                    from Evaluation: Discuss                              by paf

State Changes to Evaluation: Discuss                              from Ready for Telechat                                by scoya

State Changes to Ready for Telechat                                from New Version Needed (WG/Author)                    by scoya