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

From: Robert Elz <[email-masked]>
Date: Sun, 3 Feb 2002 12:51:19 -0500

Date:        Thu, 24 Jan 2002 18:14:25 +0100
    From:        Patrik Fältström <[email-masked]>
    Message-ID:  <5922228.1011896065@localhost>

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

I have currently got this section containing the sentence you sent last
Tuesday.   But upon reflection, I'm not sure that is correct either.

This is all in the context of what the client does, the intent was that
the client gets the names from the listing, does whatever it likes with
them for the purposes of display to the user, but retains a copy of the
actual octet string that the server sent, and when the user picks one of
the files to act upon, the client sends to the server the exact same octet
string that the server sent to the client.

No transformations at all - not into UCS4 or wchar_t's or anything of the
kind.

The reason for this is that there's no way that the client can know for
certain just what those octets represent.   UTF-8 is recommended, but not
required.   They could be absolutely anything.

Of course, as long as the client sends back the same string it received,
what it does internally is irrelevant to anyone - all that matters is that
it sends back the correct string.   The idea behind the implementor advice
was to prevent things like implementations deciding to store all the
path names in UCS4 (or something), getting the name from the server,
attempting to convert it from UTF-8 into UCS4, and failing, because what
it obtained wasn't UTF-8 - and then having no way left to store the name,
other than whatever gets left behind in the UCS4 when the conversion bombs
out.

So, are there any other suggestions for text that better embodies this
advice (it is only implementor advice - a suggestion on what to do to
avoid breaking the protocol) without standing all over people's notions
of what are charsets, and so on, and what can be done to them safely?

Obviously no-one is ever going to care if the octects of the file name are
stored in bigger than 8 bit storage units, and that's the only transformation
that's made, nor will anyone care if the implementor is really careful to
get things right even in the hard cases.   I think I'd kind of prefer 
discouraging any kind of fiddling with the names (as retained to be returned
to the server) though.

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

Since no-one seems to care, I haven't altered anything there.   If anyone
does care, suggested text (yes, if appropriate, that means someone else
does the cut from 2119...) and what it should replace will be needed.

  | (c)
  | Section 3.4 starts:

It now starts ...

   If we assume the existence of three files, A B and C, a directory D,
   two files with names that end with the string "ile6", and no other
   files at all, then the MDTM command may behave as indicated.  The

which is not very nice, but will do I think.   Otherwise, suggested text
please...   (the incorrect "21" later in the section is now "20").

  | (d)
  | Section 7.1:

  | Should this say "file or directory names"?

It is now ...

   For these purposes, the contents of a directory are whatever
   file or directory names (not pathnames) the server-PI will allow to
   be referenced when the current working directory is the directory
   named, [...]

  | (e)

  | In the last paragraph of 7.2:

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

That section now ends ...

   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.  See section 7.9 (page 48).
   There is no requirement that the same set of facts be provided for
   each file, or that the facts presented occur in the same order for
   each file.

  | (f)

  | Section 7.5.1:

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

Actually, many fact values are case insensitive, and the type fact
certainly is one of those (all the ones with defined fixed strings are
by virtue of the definitions of ABNF, the one remaining, the os dependent
type, is explicitly case independent - see section 7.5.1.5

I have made it clear(er) that everything here is case independent (as is the
perm fact, most of the ones that refer to IANA registries probably are
as well - depends on the definition of the registry) by adding ...

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

at the end of section 7..5.1 (just before 7.5.1.1).

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

Still working on that one (as it needs code mods to generate a new
example...)

  | (h)
  | Section 7.7.9:
  | 
  | perhaps it could explicitly
  | say "and that's why it uses different case for the fully-qualified path
  | in different responses".

What I added was (after noting it is case independent) ...

   The server seems to return
   files using the case in which they were requested, when the name was
   sent by the client, and otherwise uses an algorithm known only to
   itself to select the case of the names it returns. 

Is that good enough?

I also fixed a typo just before that, s/contract/contrast/ ... (why did
no-one pick up that one?)

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

It now says ...

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

kre