Ftp-WG: FTP Data Connection Assurance

> Looking at chapters "3. PASSIVE ESTABLISH (ESTP)" and
> "D.2 Automatically Finding the Specified Connection",
> there are two distinct operation modes for ESTP:
>
> Either
> - the server ignores the argument and accepts the first
>   connection
> or
> - the server honors the argument and accepts the matching
>   connection
>
> That behavior should to some extent be controllable by the
> client.

My original vision was that the server ignore the argument because it really
is not needed.

I added the argument because I realized the server _could_ make use of it.
I don't however, see that the client need be aware of that or have any input
into it.

> How about a slightly changed definition for ESTP
> that makes the argument optional? E.g.:
>
>   If the argument to ESTP is omitted, the server should
>   accept the first connection from the listen queue and
>   reply with a suitable 225 code (or 4xx/5xx on error).
>
>   If the argument is present, the server may either
>   - search the listen queue for the matching connection,
>     accept it and reply with a 225 code (or 4xx/5xx on
>     error/not found),
>   or
>   - ignore the argument, accept the first connection
>     and return 225 (4xx/5xx on error).

I don't have a problem with making the ESTP argument optional.

> For ESTP error recovery, I don't agree with making ABOR
> dependant on the session context. I'd very much prefer:
>
>   If the client detects a mismatch it may send an ABOR,
>   followed by PASV/LPSV/EPSV to establish a new connection.
>   It should not be expected that any socket related to the
>   data connection survives ABOR.

I don't see ABOR as being state dependant.  Except for the unnecessary and
misleading discussion of ABOR relative to EPSV in RFC 2428, the workings of
the ABOR command in the FTP have to do with the established data connection.
All I'm suggesting is, in this case, a natural use of the ABOR command with
respect to the ESTA/ESTP commands.

> "D.3 Using a Common Passive Socket" will obviously work
> if all clients are ESTP compliant (and the server enforces
> ESTP). In a mixed environment (ESTP clients and legacy
> clients) however, an ESTP capable client would have to
> announce that capability ("OPTS ESTA ...") to the server
> before any PASV command is issued, and the server would
> have to enforce usage of ESTP by this client. And from
> a NAT/firewalling point of view, a common data socket in
> a mixed environment doesn't give any advantage.

Well, I'm not sure the user could or should be expected to announce the
support of ESTA/ESTP, but you're correct that in a mixed environment, it
does not help the firewall rules.

The fact of the matter, though, is that I put D.3 in because it's the
logical end-point of the reasoning. I honestly do not expect it will ever
prove workable, but unless someone puts the idea out, nobody will look at it
and prove me wrong.