Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftp-range-06.txt

Tim Kosse <tim.kosse@filezilla-project.org> Sun, 17 June 2012 09:07 UTC

Return-Path: <tim.kosse@filezilla-project.org>
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 C983221F8622 for <ftpext@ietfa.amsl.com>; Sun, 17 Jun 2012 02:07:18 -0700 (PDT)
X-Quarantine-ID: <IDXdxVb8FYV3>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ... [score: 0.0000]\n \n autolearn: ha[...]
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDXdxVb8FYV3 for <ftpext@ietfa.amsl.com>; Sun, 17 Jun 2012 02:07:18 -0700 (PDT)
Received: from filezilla-project.org (filezilla-project.org [IPv6:2a01:4f8:61:61a3::2]) by ietfa.amsl.com (Postfix) with ESMTP id C41AF21F859E for <ftpext@ietf.org>; Sun, 17 Jun 2012 02:07:13 -0700 (PDT)
Received: from p4fc1d095.dip.t-dialin.net ([79.193.208.149] helo=[10.0.0.59]) by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <tim.kosse@filezilla-project.org>) id 1SgBRu-0003Yj-Qy; Sun, 17 Jun 2012 11:07:12 +0200
Message-ID: <4FDD9E40.8060900@filezilla-project.org>
Date: Sun, 17 Jun 2012 11:07:12 +0200
From: Tim Kosse <tim.kosse@filezilla-project.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Anthony Bryan <anthonybryan@gmail.com>
References: <20120524233616.22194.91919.idtracker@ietfa.amsl.com> <CANqTPejvDbHT5ysCksB+GdxjODVrU9BGkFfvwjMZymAeJiyjYg@mail.gmail.com>
In-Reply-To: <CANqTPejvDbHT5ysCksB+GdxjODVrU9BGkFfvwjMZymAeJiyjYg@mail.gmail.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig00DA8B6ED5A0A9FBB1BD7F37"
Cc: ftpext@ietf.org
Subject: Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftp-range-06.txt
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, 17 Jun 2012 09:07:19 -0000

On 2012-06-05 01:53, Anthony Bryan wrote:
> FYI, any comments?
> http://tools.ietf.org/html/draft-bryan-ftp-range

> 3. octet Ranges in STREAM Mode

The title of section 3 should probably start a capital letter.

>    The server-PI SHOULD transfer the whole range from the start point to
>    the end point with RETR if the end point is larger than the actual
>    file.

Seems unclear, in particular what to send between the end of the file
and the end point. I suppose you meant the following?

The server-PI SHOULD transfer the whole range from the start point to
the end of the file with RETR if the end point is larger than the actual
file.

> With STOR, however, the server must
>    insert the data into the file named.  The results are undefined if a
>    client uses RANG to do other than restart to complete a transfer of a
>    file that had previously failed to completely transfer.  In
>    particular, if the restart marker set with a RANG command is not at
>    the end of the data currently stored at the server, as reported by
>    the server, or if insufficient data are provided in a STOR that
>    follows a RANG to extend the destination file to at least its
>    previous size, then the effects are undefined.

The requirement of the start point to be at the end of the file if used
with STOR is problematic.

If a transfer is interrupted due to a network error, it can happen that
the for the client the transfer has failed already whereas the server
things it is still ongoing. If there is data still in-flight or
otherwise pending, the file size can change between the call to SIZE and
the subsequent RANG/STOR. Only workaround would be for the client to
wait an unspecified time before resuming until it can be reasonably sure
that there is no pending data still in-flight.

I would change the semantics as follows:

- The RANG start point must never exceed the file size
- If it is less than the file size, continue writing at that position in
the file, overwriting existing data between start-point and end-point.
- RANG must not cause files on the server to be truncated
- Implementation note: Some servers currently open the file with
O_APPEND if using STOR, they should not do this anymore.

Apart from solving the timing issue, this change would also makes it
possible to selectively modify parts of a file on the server.

Regards,
Tim