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