Subject: Ftp-WG: Re: Comments from IESG on draft-ietf-ftpext-mlst

From: Robert Elz <[email-masked]>
Date: Fri, 25 Jan 2002 04:55:11 -0500

Date:        Thu, 24 Jan 2002 18:14:25 +0100
    From:        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
    Message-ID:  <5922228.1011896065@localhost>

  | IESG today discussed the document, and have the following comments. I
  | presume you have to come out with a new version of the document.

Yes, it looks like it...

  | Regardless, let me get comments on these comments.

So, let's (WG) decide what should be done about each of these (some are
no brainers and easy fixes).

  | (a)
  | 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.

Yes, probably, this is outside my area of expertise (whatever that
might be).

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

No, certainly don't want that.

  | I do want, however to
  | discourage _charset_ conversions. I suggest this be changed to read:

Fine by me.

  | 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'll look at that.

  | (b)
  | Should the reference to RFC 2119 follow the form suggested in RFC 2119?

I don't know, should it?   Does anyone really care?

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

Yes, I had noticed that one myself, but didn't think it really worthy of
a fix, but I guess it should be done.   I'll figure out a suitable fix to
the "and no other files at all" so it doesn't have to say "and 
19990929043300 File6" in the previous clause, and post that to the list
later.

  | (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,

That's not intended, and I think the right fix should be to delete that
notion from wherever it might be springing.   They might be different, they
might be interchangeable, that's up to the implementation.

But ...
 
  | so this text seems to preclude including
  | directory names in MLSx responses.  Should this say "file or directory
  | names"?

that can certainly be done to handle any cases where files and directories
are different beasts.

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

Sure, can do that easily.

  | (f)
  | 
  | Section 7.5.1:
  | 
  | ...
  |         file         -- a file entry
  | ...
  | 
  |         type-val        = "File" / "cdir" / "pdir" / "dir" /
  |                           os-type
  | 
  | Fact values are case-sensitive, right,

Most are, but any ABNF strings are case insensitive (see the ABNF spec),
so those strings should be case insensitive, so it really shouldn't matter
whether it is "File" or "file".

But I'm not sure that the WG ever truly considered this (the os-type would
be case sensitive...) so now would be a good time - avoid things slipping by
without proper consideration.

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

Hmmm - I really don't want to fake any examples, so doing this would mean
finding (more likely, producing) a server that generates the listing in a
different order.   I'll see how easy it is to make my server do that - unless
someone else has a server that generates MLSD output with cdir/pdir somewhere
other than at the top (perhaps if the output is sorted by name...)

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

Can do that I guess - certainly can't do any harm, but I'd have thought it
really ought to be obvious enough...

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

Oops ... and I thought my eyesight was better than that.   That one I
didn't notice.  Thanks, will fix.

After a couple of days (waiting for suggestions) I'll submit yet another
draft...

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Jan 2002 22:19:47 -0500

Date:        Tue, 29 Jan 2002 08:30:09 -0800 (PST)
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | I'm OK with this -- in fact your wording is better than mine.

OK, none of these bother me, and they don't seem to be bothering the
rest of the WG, so that's what I'll do...

kre