Date: Tue, 27 Nov 2001 02:32:56 +0000
From: Zefram <zefram(_at_)fysh(_dot_)org>
Message-ID: <20011127023256(_dot_)D8299(_at_)fysh(_dot_)org>
Thanks for the comments.
I'm quoting almost your entire message for the benefit of the ftpext
WG list ...
| 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?
I'm not sure about that, though SIZE and MDTM should both say that only
one line is permitted I think. After the last call has ended, and
working group permitting, I will fix that (along with anything else
discovered that needs fixing). I'll see if there are any others.
But in the general case, any ftp response, can be multi-line (which
certainly applies to all of the error responses) so I don't think that
changing the sense of the comment in 2.4 would be the right solution.
It might also be worth asking whether there is really any reason for the
SIZE, MDTM commands, etc, to actually be restricted to one line replies,
provided that however many lines are generated, just the required information
is returned.
| 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.
That wasn't the intent, perhaps this could be clarified. Clearly though,
I think, it is only the response generated that is undefined, nothing that
would affect the rest of the session (that is, it doesn't say it has an
undefined effect, just generates an undefined response). But more than
that, the intent is that the syntax would still be correctly generated, but
that the value returned might be rubbish - and yes, without the client
having any way to tell that it 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.
No, the expectation is that the server is not required to check whether
the object for which the mod time is requested has a sensible mod time
to return. If the underlying OS generates an error, then the server will
generally reply with an error code. If not, but simply returns some value
which isn't what would normally be considered as a modification time, then
the server is allowed to simply send that back to the client, it doesn't
have to test whether the value it obtained is rational or not.
| 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.".
That is more or less what "generate undefined responses" was intended to
convey. That is, you'll get a response, but what that response might
be isn't defined...
| If "undefined responses" was intended to permit some other historical
| behaviour, the limits of such behaviour should be specified.
Certainly, the MTDM (and SIZE) sections (and stream mode restart) are just
intended to document functions that have been in ftp servers for 15 years
or so now, both so their functionality can be reliably used, and so others
know exactly what is required to implement them. About the only limit that
I can see being reasonable here is that if a response that looks like a
success response is generated, then it should conform to the syntax.
kre