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

Anthony Bryan <> Fri, 29 June 2012 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A33C11E80FF for <>; Thu, 28 Jun 2012 18:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OP0fo4iRehYX for <>; Thu, 28 Jun 2012 18:10:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D04B11E80A2 for <>; Thu, 28 Jun 2012 18:10:08 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2619547ghb.31 for <>; Thu, 28 Jun 2012 18:10:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zsREXTDJYYq0Gh520XqBpwFKcLjr0XD5PWWHvcT8vBw=; b=AVEV9hQTASEIZDuRI8KXah7bJ7yNCoW2fdqpK3OWDiHQZEYfsVxo2647RdNHdJzgS+ uxzDcwzFCUDlAdG6kAaZ2z35kaVIrrEXl8KAtYe+H4eBwwxKYjokPs4hG8DEgh8JQexI dG8y//ZOaWrVRBnAOzxgf4Mxv/u7ydmb8nbnkli7DRDkZO+hVlfAvynT2CbRyqpAK/+R YGgzYv/Gm6vhTMTmj9NwkVOfEcbqjzlB2gHb57TjGk/Rk5Uc3NWb2hrM3QW+7dOmC/Hz uFC2BsE+xDY7hy2n0JNrlSoMpK4UidylhboRmdYBSoBVlfaE0N6v8tWTImokw5qHt+XS /J9w==
MIME-Version: 1.0
Received: by with SMTP id h41mr37021yhk.58.1340932208145; Thu, 28 Jun 2012 18:10:08 -0700 (PDT)
Received: by with HTTP; Thu, 28 Jun 2012 18:10:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 28 Jun 2012 21:10:08 -0400
Message-ID: <>
From: Anthony Bryan <>
To: Tim Kosse <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftp-range-06.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jun 2012 01:10:10 -0000

thanks, Tim!

On Sun, Jun 17, 2012 at 5:07 AM, Tim Kosse
<> wrote:
> On 2012-06-05 01:53, Anthony Bryan wrote:
>> FYI, any comments?
>> 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.

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 [ ]
  )) Easier, More Reliable, Self Healing Downloads