draft-ietf-ftpext-mlst-16.txt

[Robert Elz <kre@munnari.OZ.AU>]

Thanks for finally noticing that draft-ietf-ftpext-mlst-16.txt
has been waiting for attention for a long time.

I see 4 comments in the "draft status tracker" page.   I'm not sure
of the exact status of those (since they claim to be talking about
version 0) but just to save some time, I will make some comments
about those comments, so perhaps we can get this draft cleared up
a little quicker.

Taking the comments in the order they were added to the page (ie:
bottom up).

	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.

Yes, it does.   That's all true.   The MDTM command has been defined
(in practice) like this for more than 10 years.   This is just documenting
existing practice, at this stage there's no rational way to change that.

In practice, the times are synchronised well enough (ie: the systems have
the correct date) for all of this to work well enough.  That is, people
do it like this.

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

Probably none any more, but what does this have to do with anything?
The only relevance of those to this draft (the REST command, which is
the only even half way relevant part) is that the draft explicitly
doesn't have anything to do with those modes of transfer.

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

On the control connection, yes, they must.   On a data connection, no,
they must not.   And I can't believe that any more clarification of this
can possibly be wanted, the doc is full of clarification of this.
See section 2.2 (and most likely a zillion other places).

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

Section 11, the security considerations already says ...

   Server FTP should take care not to reveal sensitive information about
   files to unauthorised parties.  In particular, some underlying
   filesystems provide a file identifier which, if known, can allow many
   of the filesystem protection mechanisms to be by-passed.  That
   identifier would not be a suitable choice to use as the basis of the
   value of the unique fact. 

What more can possibly be said?

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

Good, just don't go there.   When it gets published as an RFC, the RFC
editor can stick in whatever copyright notice the RFC editor wants to use.
What is there now is pretty much exactly what the IESG said it should
contain the last time this issue came up (2 years ago?)


Next:

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

No.

	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

No it doesn't, that was an earlier version, it was corrected the last
time this was pointed out.

	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.

Again, already corrected.

      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?

Again, already corrected.

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

No.   Strings in ABNF are case independent.   So, any of File file FILE fIlE
(and more) are possible here.   They all mean the same thing.   That is,
when ABNF uses "A" (or "a") it means (in something similar to ABNF which is
case dependent) ("A" / "a").

What's more, just in case the reader of this doc is ignorant of ABNF, and
can't be bothered reading its specification, section 2.1 says ...

   Note that in ABNF, string literals are case insensitive.  That
   convention is preserved in this document, and implies that FTP
   commands added by this specification have names that can be
   represented in any case.

(and goes on ad nauseum to explain what that means).

Furthermore, section 7.5.1 even says (now anyway - this was probably added
for re-inforcement after this comment was made previously)

   The value of the type fact (the "type-val") is a case independent
   string.

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

Already fixed.  See 7.7.11

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

Already fixed, see the end of 7.9

	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.

Already fixed, it now says "All but one of ..."


Next:

	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.

Already fixed.

	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.

I have no idea at all what that means.   Those words from 2.2 are about what
the implementation does internally.   7.5.9 is about how a server says
what charset it is using over the wire.   ???


Next:
The 4th comment is a duplicate of the 2nd.


Hopefully this will help speed your deliberations.   It has been (within
a few days of) 6 months now since the last activity on this doc, which was

	Version -16 addresses my concerns.

It would be nice if all the "concerns" were gone now.

kre