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

Ángel González <keisial@gmail.com> Sun, 03 February 2013 22:11 UTC

Return-Path: <keisial@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DD221F88CF for <ftpext@ietfa.amsl.com>; Sun, 3 Feb 2013 14:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dDn4JHeCkMF for <ftpext@ietfa.amsl.com>; Sun, 3 Feb 2013 14:11:17 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0317521F853C for <ftpext@ietf.org>; Sun, 3 Feb 2013 14:11:16 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hm6so1021274wib.8 for <ftpext@ietf.org>; Sun, 03 Feb 2013 14:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CpZMOTHHC79f0hRqmO5pH0t44l7WwFF2uXh+xiUSmec=; b=jA626UHDqv8wBjGKz5dqlB/jiHjvrniPsAeLQIkzDesLJZPBAsgusUhpLnTqUosm+V WELjvIi/BVAedsmTDoEQ5BtXAtihrfa5nCS0JKiBjcJhDi+Yh8W/W3LLlfI9CUDW9jQ6 ymji2puBZ5yA83vTS/JF+hJtp0bMmvPPDfHYUzcJDMZe0eDDGcHX0aTfZaXHyeWAGvp8 gGBunaWO5CFIVpHC/Uw8eyMitKRizX6+P1pcAWSIW3yKQmurmzYA0/AncDFn7VXjo4aC U+00vJv+Rcb5y7DQCxeJljrN7tq/QkJq3McAC8FXp0HzE2hJhORHRHYSwxJ4E6cg1ap4 svjw==
X-Received: by 10.180.85.97 with SMTP id g1mr7172764wiz.29.1359929475997; Sun, 03 Feb 2013 14:11:15 -0800 (PST)
Received: from [192.168.1.26] (210.Red-193-153-87.dynamicIP.rima-tde.net. [193.153.87.210]) by mx.google.com with ESMTPS id ec3sm11662137wib.1.2013.02.03.14.11.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 14:11:15 -0800 (PST)
Message-ID: <510EE013.7010505@gmail.com>
Date: Sun, 03 Feb 2013 23:09:23 +0100
From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
User-Agent: Thunderbird
MIME-Version: 1.0
To: Tim Kosse <tim.kosse@filezilla-project.org>
References: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com> <510ED0FF.5070100@filezilla-project.org>
In-Reply-To: <510ED0FF.5070100@filezilla-project.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Feb 2013 22:11:23 -0000

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.