Re: Last Call: Extensions to FTP to Proposed Standard
Zefram <zefram@FYSH.ORG> Tue, 27 November 2001 13:40 UTC
Received: by ietf.org (8.9.1a/8.9.1a) id IAA26544 for ietf-outbound.10@ietf.org; Tue, 27 Nov 2001 08:40:03 -0500 (EST)
Received: by ietf.org (8.9.1a/8.9.1a) id IAA25632 for ietf-mainout; Tue, 27 Nov 2001 08:24:18 -0500 (EST)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from bowl.fysh.org (mail@fysh.org [212.47.68.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20380 for <ietf@ietf.org>; Mon, 26 Nov 2001 21:32:59 -0500 (EST)
Received: from zefram by bowl.fysh.org with local (Exim 3.33 #1 (Debian)) id 168Y3M-0001Ff-00; Tue, 27 Nov 2001 02:32:56 +0000
Date: Tue, 27 Nov 2001 02:32:56 +0000
To: ietf@ietf.org
Subject: Re: Last Call: Extensions to FTP to Proposed Standard
Message-ID: <20011127023256.D8299@fysh.org>
References: <200111262100.QAA00874@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200111262100.QAA00874@ietf.org>
User-Agent: Mutt/1.3.23i
From: Zefram <zefram@FYSH.ORG>
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org
>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