From anthonybryan@gmail.com Mon Jun 4 16:53:57 2012 Return-Path: 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 CC63321F8792 for ; Mon, 4 Jun 2012 16:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 83vHuxKndnKE for ; Mon, 4 Jun 2012 16:53:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1B521F878E for ; Mon, 4 Jun 2012 16:53:57 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9265738obb.31 for ; Mon, 04 Jun 2012 16:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=4xao74FuGF8G0WvsCiqEDLyjUMG5BkWG1mFBQdSs6BE=; b=J7pJd7Jae9AEsRl+toZ6fBTm7EJtFLLf1SU4Z1M9F8aVZ7GDdE4nBFZDp3G3TRn9eY BkZFduzm1YnRU/8BzuxtS7vrkHynBMCvecE3iwXywXjbQrIRogaQtLYOo6aqslaQP+4t RtdNK2ox+oydJuKRHVYMXCXgLPQhgR+iymjf3t69nJVqitnsZm5zSgwaRF6hiSBvksOn vF5m+cnEqKqtlH+fheClFH/edHZHA/uVeQ48cLbZ5lU/IILVLCxRWluCKjlDs3oU4g3x 5GDgUMjreS5HROlUuJAiuGbr2rqnmy9P0tJwb3i4kD69cMcy0OqYZKI2lfP8eInWqbFz q6KA== MIME-Version: 1.0 Received: by 10.60.23.193 with SMTP id o1mr13660803oef.7.1338854036584; Mon, 04 Jun 2012 16:53:56 -0700 (PDT) Received: by 10.182.50.199 with HTTP; Mon, 4 Jun 2012 16:53:56 -0700 (PDT) In-Reply-To: <20120524233616.22194.91919.idtracker@ietfa.amsl.com> References: <20120524233616.22194.91919.idtracker@ietfa.amsl.com> Date: Mon, 4 Jun 2012 19:53:56 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 23:53:57 -0000 FYI, any comments? http://tools.ietf.org/html/draft-bryan-ftp-range ---------- Forwarded message ---------- From: Date: Thu, May 24, 2012 at 7:36 PM Subject: New Version Notification for draft-bryan-ftp-range-06.txt To: anthonybryan@gmail.com Cc: daniel@haxx.se, tatsuhiro.t@gmail.com 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: =A0 =A0 =A0 =A0draft-bryan-ftp-range Revision: =A0 =A0 =A0 =A006 Title: =A0 =A0 =A0 =A0 =A0 File Transfer Protocol RANG Command for Octet Ra= nges Creation date: =A0 2012-05-24 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 12 Abstract: =A0 The File Transfer Protocol offers the REST command to designate a =A0 starting point for a transfer, but does not currently offer any =A0 method to specify an end point. =A0This document specifies a new FTP =A0 RANG command to be used by clients to designate a start and end point =A0 to permit restarts and repairs of interrupted data transfers in =A0 STREAM mode. The IETF Secretariat --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From tim.kosse@filezilla-project.org Sun Jun 17 02:07:18 2012 Return-Path: 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 ; Sun, 17 Jun 2012 02:07:18 -0700 (PDT) X-Quarantine-ID: 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 ; 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 ; 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 ) 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 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 References: <20120524233616.22194.91919.idtracker@ietfa.amsl.com> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 09:07:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00DA8B6ED5A0A9FBB1BD7F37 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 t= o > 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 --------------enig00DA8B6ED5A0A9FBB1BD7F37 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/dnkAACgkQ8N9+lcqiUkWibACfYgYOb7vKfDIb5N6xJy0wRfYE lAEAoMpBol5hsroxv3yynwhCzTBlKvk4 =cB8I -----END PGP SIGNATURE----- --------------enig00DA8B6ED5A0A9FBB1BD7F37-- From anthonybryan@gmail.com Sun Jun 17 08:56:43 2012 Return-Path: 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 2A65921F8525 for ; Sun, 17 Jun 2012 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y2FekbjSMxyg for ; Sun, 17 Jun 2012 08:56:42 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 805CC21F851C for ; Sun, 17 Jun 2012 08:56:42 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3518058ggn.31 for ; Sun, 17 Jun 2012 08:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Ag8+gDJkFkF8OGGJWQXjj5fyN7oXk6LtJevCjBUXgbA=; b=iHD/BmZQVkciJoVZUi64ZpDtCdSa9MtXRNE5DkzrtExA8MBijLuktHlDSjxhRPrxqN oeiUNcMA7QpmUgSI00jgJPiyMQQU9ZeVjkT2md+7C7rbrf8HZU8Yr1wBJ7hW0guLQJLS qhyMlvCQF64S4pZwf+q+xOfrCqH2cYsZbU4sLvFSWu01byHcNdszeta6HMZRyIw8TXgr RQT3HRT8eQbngIUoB+GjHZAdTocqYlLybTfmawughpUDNKbFTv87bEwfhxLnl+YQtIaV l/pC93DVoL2PI25zvv6ODIEVQA9cd9BaETJws5tEmK9Yju15ZVn9DwX/xs2N4GFzN/Kn qRwA== MIME-Version: 1.0 Received: by 10.236.153.8 with SMTP id e8mr15260929yhk.80.1339948601983; Sun, 17 Jun 2012 08:56:41 -0700 (PDT) Received: by 10.146.107.1 with HTTP; Sun, 17 Jun 2012 08:56:41 -0700 (PDT) Date: Sun, 17 Jun 2012 11:56:41 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ftpext] FYI: FTP Application Layer Gateway (ALG) for IPv6/IPv4 Translation X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 15:56:43 -0000 RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation http://tools.ietf.org/html/rfc6384 and shortly after, draft-tsou-behave-ftp46 An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation http://tools.ietf.org/html/draft-tsou-behave-ftp46 Abstract An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo updates RFC 6384 with the case of an IPv4 client connecting to an IPv6 server. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Thu Jun 28 18:10:10 2012 Return-Path: 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 0A33C11E80FF for ; Thu, 28 Jun 2012 18:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] 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 OP0fo4iRehYX for ; Thu, 28 Jun 2012 18:10:08 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (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; d=gmail.com; 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 10.236.154.193 with SMTP id h41mr37021yhk.58.1340932208145; Thu, 28 Jun 2012 18:10:08 -0700 (PDT) Received: by 10.146.107.1 with HTTP; Thu, 28 Jun 2012 18:10:08 -0700 (PDT) In-Reply-To: <4FDD9E40.8060900@filezilla-project.org> References: <20120524233616.22194.91919.idtracker@ietfa.amsl.com> <4FDD9E40.8060900@filezilla-project.org> 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 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: 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? >> 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. >> =A0 =A0The server-PI SHOULD transfer the whole range from the start poin= t to >> =A0 =A0the end point with RETR if the end point is larger than the actua= l >> =A0 =A0file. > > 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 >> =A0 =A0insert the data into the file named. =A0The results are undefined= if a >> =A0 =A0client uses RANG to do other than restart to complete a transfer = of a >> =A0 =A0file that had previously failed to completely transfer. =A0In >> =A0 =A0particular, if the restart marker set with a RANG command is not = at >> =A0 =A0the end of the data currently stored at the server, as reported b= y >> =A0 =A0the server, or if insufficient data are provided in a STOR that >> =A0 =A0follows a RANG to extend the destination file to at least its >> =A0 =A0previous 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? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads