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

From: Anthony Bryan <[email-masked]>
Date: Mon, 4 Jun 2012 19:53:56 -0400

FYI, any comments?

http://tools.ietf.org/html/draft-bryan-ftp-range

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, May 24, 2012 at 7:36 PM
Subject: New Version Notification for draft-bryan-ftp-range-06.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

A new version of I-D, draft-bryan-ftp-range-06.txt has been
successfully submitted by Anthony Bryan and posted to the IETF
repository.

Filename:        draft-bryan-ftp-range
Revision:        06
Title:           File Transfer Protocol RANG Command for Octet Ranges
Creation date:   2012-05-24
WG ID:           Individual Submission
Number of pages: 12

Abstract:
  The File Transfer Protocol offers the REST command to designate a
  starting point for a transfer, but does not currently offer any
  method to specify an end point.  This document specifies a new FTP
  RANG command to be used by clients to designate a start and end point
  to permit restarts and repairs of interrupted data transfers in
  STREAM mode.

The IETF Secretariat

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: Tim Kosse <[email-masked]>
Date: Sun, 17 Jun 2012 11:07:12 +0200

> 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

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 28 Jun 2012 21:10:08 -0400

thanks, Tim!

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

Yes.

> the end of the file with RETR if the end point is larger than the actual

Yes, changed.

> possible to selectively modify parts of a file on the server.

that sounds good to me and like a nice bonus.

what do others think?