From ftp-wg-owner@hethmon.com Sun Feb 3 12:45:40 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28097 for ; Sun, 3 Feb 2002 12:45:39 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020203125123-12768-9 ; Sun, 03 Feb 2002 12:51:23 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020203125112-62985-8 ; Sun, 03 Feb 2002 12:51:17 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g13HhDS04000; Mon, 4 Feb 2002 00:43:14 +0700 (ICT) In-Reply-To: <5922228.1011896065@localhost> References: <5922228.1011896065@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <3998.1012758192@brandenburg.cs.mu.OZ.AU> Date: Sun, 3 Feb 2002 12:51:19 -0500 X-OldDate: Mon, 04 Feb 2002 00:43:12 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Ftp-WG: Re: Comments from IESG on draft-ietf-ftpext-mlst Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28097 Date: Thu, 24 Jan 2002 18:14:25 +0100 From: Patrik Fältström 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 From ftp-wg-owner@hethmon.com Fri Feb 8 04:58:47 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02257 for ; Fri, 8 Feb 2002 04:58:46 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020208050353-9475-10 ; Fri, 08 Feb 2002 05:03:53 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020208050037-47976-8 ; Fri, 08 Feb 2002 05:03:50 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g189lPJ01516; Fri, 8 Feb 2002 16:47:25 +0700 (ICT) In-Reply-To: <8557370.1013162576@localhost> References: <8557370.1013162576@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1514.1013161645@brandenburg.cs.mu.OZ.AU> Date: Fri, 8 Feb 2002 05:03:50 -0500 X-OldDate: Fri, 08 Feb 2002 16:47:25 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Ftp-WG: Re: More ABNF issues with draft-ietf-ftpext-mlst-14.txt (fwd) Date: Fri, 08 Feb 2002 10:02:56 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Message-ID: <8557370.1013162576@localhost> [Quotes from Bill Fenner] | Earlier I wondered about case-sensitive type facts, and suggested that | the "File" should read "file" in the definition of the type-val | rule. That was before I realized that strings are case-insensitive | in ABNF; the only way to make a case-sensitive string is to specify it | in hex, e.g. %x66.69.6C.65 Yes, that was (the essence of) my reply when this was first mentioned. | -- so, the easier thing would be to explicitly | define that type-vals are case-insensitive. That will be in the updated draft. It was always the intention. Note: The "os-name" indicates the specific system type which supports the particular localtype. OS specific types are registered by the IANA using the procedures specified in section 10. The "os-type" provides the system dependent information as to the type of the file listed. The os-name and os-type strings in an os-type are case independent. from the top of page 30 of the -14 draft (section 7.5.1.5). The updated draft has this more clearly specified for all type-vals (so the ones that were case independent by virtue of being specified as ABNF strings are not quite as magic now - ie: you don't have to be as much an ABNF expert to get this right). | (Section 2.1's line of | reasoning that claims that "token" is case sensitive would seem to | apply to "value" as well, the value of a fact.) Yes, it would, and in general it does. But anywhere a specific set of values is allowed, and they are listed as ABNF strings, then those strings must be treated case-independently. So, for the strings like "file", any representation (FILE file File FiLe) must be treated the same. Where some value is possible that isn't specified as an ABNF string, then without anything stating the contrary, case dependent comparisons would be required. Having a value which was case dependent sometimes, and independent others, would be a nightmare - which is why 7.5.1.5 made the OS dependent stuff be explicitly case independent. So, I think that all of this was actually consistent all the time - but certainly having the rules more explicit is a good idea. | In 7.5.1.5, the "os-type" rule is defined twice: Oops - thanks for spotting that one! | One or the other should probably be renamed; perhaps the second one | could become "os-specific-type" or something. Too long (screws the doc formatting). I'll probably rename the first, there are more (short) reasonable choices available... | A type fact where the type is an os-type does not match the | grammar for facts. Hmm. Yes. | I don't know if the right answer is to redefine [value] | or to say that it's OK that an os-type is not a value since there's | an explicitly seperate grammar for it, or what. I will ponder this one for a few more days, and listen to WG suggestions. There isn't going to be a new draft submitted for (at least) several days anyway (I am too bust with other work to work on the FTP server so I can generate the requested example without cdir/pdir at the head of MLSD output). kre ps: I'm impressed by any effort to actually verify the grammar fragments in this doc - it was never really complete enough (being just an add-on to an existing protocol) to allow a complete grammar for anything to be written, just the isolated pieces. From ftp-wg-owner@hethmon.com Fri Feb 8 05:07:57 2002 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02365 for ; Fri, 8 Feb 2002 05:07:56 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020208051356-13701-9 ; Fri, 08 Feb 2002 05:13:56 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20020208050833-59638-9 ; Fri, 08 Feb 2002 05:13:53 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g189xCJ01571; Fri, 8 Feb 2002 16:59:12 +0700 (ICT) In-Reply-To: <8557370.1013162576@localhost> References: <8557370.1013162576@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <1569.1013162352@brandenburg.cs.mu.OZ.AU> Date: Fri, 8 Feb 2002 05:13:54 -0500 X-OldDate: Fri, 08 Feb 2002 16:59:12 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Ftp-WG: Re: More ABNF issues with draft-ietf-ftpext-mlst-14.txt (fwd) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02365 Date: Fri, 08 Feb 2002 10:02:56 +0100 From: Patrik Fältström Message-ID: <8557370.1013162576@localhost> [Quoting Bill Fenner] | One or the other should probably be renamed; perhaps the second one | could become "os-specific-type" or something. I actually (unless there are other suggestions from the WG of course) decided on making the second one be "os-kind" - the 4 character word keeps the formatting looking nice... (and so the first one stays as "os-type"). kre