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

[Anthony Bryan <[e-mail]>]

thanks, Tim!

On Sun, Jun 17, 2012 at 5:07 AM, Tim Kosse
<[e-mail]> wrote:
> 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.

Yes.


>>    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.

Yes, changed.

>> 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.

that sounds good to me and like a nice bonus.

what do others think?

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