>The IESG has received a request from the Extensions to FTP Working >Group to consider Extensions to FTP <draft-ietf-ftpext-mlst-13.txt> as >a Proposed Standard.
There are a couple of unclarities in the specification that should be cleaned up: Section 2.4 states that "unless stated to the contrary, any reply to any FTP command ... may be of the multi-line format". It doesn't say what counts as stating to the contrary, except to say that ABNF indicating a single-line response format is not sufficient to require a single-line response. This makes those parts of the specification that provide a more restricted syntax for certain replies ambiguous: it isn't clear where multi-line responses are permitted. This happens in section 3.1 (defining a successful MDTM reply) and 4.1 (SIZE): both give ABNF that on its face allows only for a single-line reply, and in neither case is the applicability of 2.4's implicit multi-line reply rule explicitly addressed. Neither section says what a valid multi-line success reply (to MDTM or SIZE) would look like. I guess that multi-line replies aren't intended to be permitted in this case, but in the light of section 2.4 it's unclear. Shouldn't we instead have an explicit note in cases where an ABNF rule is intended to be taken *non*-literally? Section 3.1, on the MDTM command, says "Attempts to query the modification time of files that are unable to be retrieved generate undefined responses.". The phrase "undefined responses" sounds like it permits what would otherwise be violations of the protocol, such that the client cannot correctly infer any information from what happens later in the session, and in fact that the client cannot determine whether this has happened. Sections 3.1 and 3.2 go on to provide perfectly sensible ways of handling error conditions within the protocol, so "undefined responses" seem unnecessary. Probably the "undefined responses" sentence should be removed or modified, perhaps to something like "Attempts ... may generate either errors or successful responses that might not be meaningful.". If "undefined responses" was intended to permit some other historical behaviour, the limits of such behaviour should be specified. -zefram
