Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST

[Ángel González <[e-mail]>]

On 03/02/13 22:05, Tim Kosse wrote:
> Hi,
>
> here's my review of the LOCK draft:

> In other words, the additional problems with firewalls and NAT devices
> caused by LOCK completely defeat its intended purpose.
>
> There is a good solution for this problem though, namely FTP over TLS.
> Following the AUTH TLS command, most firewalls and NAT routers stop
> interfering with the control connection. Perhaps mandate FTP over TLS
> for LOCK?
Worth suggesting as a note, but I don't think it should be required.


> 2. What about Telnet signals (e.g. IP and Synch) on the NVT during a
> transfer?
>
> Suggestion: Not allowed during a running transfer.
>
>
> 3. How is the STAT command to be handled?
>
> From RFC959: The command may be sent during a file transfer (along with
> the Telnet IP and Synch signals--see the Section on FTP Commands) in
> which case the server will respond with the status of the operation in
> progress
>
> There's no way to send the STAT reply during an ongoing download (e.g.
> RETR) if LOCK is being used.
>
> During an ongoing upload (e.g. STOR), how should STAT be handled?
>
> Suggestion: No STAT during a running transfer allowed.

I think the LOCK command should be changed (and probably renamed)
into a command multiplexing the connection.
The current LOCK command would be equivalent to multiplexing one
channel with the control connection. But it would add support to
send commands/signals/replies between chunks, plus doing several
transmissions in parallel.