From anthonybryan@gmail.com Fri Feb 1 20:26:07 2013 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 B67481F0D00 for ; Fri, 1 Feb 2013 20:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bwCdXgGTP5a for ; Fri, 1 Feb 2013 20:26:07 -0800 (PST) Received: from mail-ia0-x232.google.com (ia-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id AE1171F0CFE for ; Fri, 1 Feb 2013 20:26:06 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so6140126iab.23 for ; Fri, 01 Feb 2013 20:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=uLtYMUqekd4aJ86Rkva3Ji7m8bV6RrAxfehbRztEhR8=; b=PjgWhcCR2bN243ZesezoceHTSe8tkJFFejXCCE/EduL8aq4NiXm3ffHOn6Fa+ej4hU qYG55B8lVgSpk+LcmlqIlkBSK+HzuMX7/ZkeVzi3HofVBBgeUOUKShb7eRD3w6wNVRuY r+q0V9Gh1WA50Y36bSSlLW2Oe6WAQdIiES7mPTC1sSkzocOSBS90bD4QczcNlxyMWFfk V7p1DeUrwH+S2Gdi49nKjrCvAxwPXGF9eSNeTFu7X/llJwk4EKP58zr6/5eT/k6c/HwI fZoBaEP6VCqJnRLBbsBUsphsqk/aOzKf37UvKRrw1PjKSTjwhFwhgWcIAJiCe+YeH4Wj KTEA== MIME-Version: 1.0 X-Received: by 10.50.217.167 with SMTP id oz7mr682487igc.26.1359779166016; Fri, 01 Feb 2013 20:26:06 -0800 (PST) Received: by 10.50.191.231 with HTTP; Fri, 1 Feb 2013 20:26:05 -0800 (PST) In-Reply-To: <5105BDA8.7000006@gmail.com> References: <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> <5105BDA8.7000006@gmail.com> Date: Fri, 1 Feb 2013 23:26:05 -0500 Message-ID: From: Anthony Bryan To: bblackshaw@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST 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: Sat, 02 Feb 2013 04:26:08 -0000 right, we could leave the boundary REQUIRED but have an OPTIONAL size that would be used (probably the majority of the time?) btw, we are working on some of the issues that have been brought up w/ RANG & LOCK so we put new versions out. we'll continue on this & should have more updates soon. the RANG text has been re-organized to reflect that it is not transfer specific, but just about selecting a range, that can be used with transfers, HASH, etc, as it always has been. fancy diffs: http://tools.ietf.org/html/draft-bryan-ftp-range http://tools.ietf.org/html/draft-bryan-ftp-lock On Sun, Jan 27, 2013 at 6:52 PM, Bruce Blackshaw wro= te: > It's true that you don't always know the size at the start. > > Nonetheless, it could be be specified that iff the size of the raw data i= s > known, then "size" could be used. In the many cases that this is possible= , > performance should be faster (although I can't quantify by how much). > > regards > > Bruce Blackshaw > > > On 28/01/2013 4:32 AM, Alun Jones wrote: >>> >>> Of =C1ngel Gonz=E1lez >>> >>> Bruce Blackshaw wrote: >>>> >>>> Re LOCK, I think it would be useful to have an alternative to >>>> "boundary" called "size", that could provide the size of the raw data >>>> for binary transfers. That might provide quite a performance >>>> advantage compared to having to search for the boundary. >>>> >>>> regards >>> >>> Good point. I think it would be much more useful than the boundary >>> method. >>> The value of such size parameter should be the amount of data sent on t= he >>> wire. >> >> This has an obvious problem - what if the size of the file changes durin= g >> the transfer? >> >> There are many uses of FTP (webcam being the one that comes immediately = to >> mind) where a "file" is retrieved, and is handled as if it is a >> potentially-infinite stream. We have a webcam at work that encodes video >> as >> an animated GIF that never ends. Doesn't display in Internet Explorer, >> because IE is paranoid, but it's a use-case that should be considered. T= he >> boundary method works for this use, where the size method doesn't. >> >> Alun. >> ~~~~ >> >> > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From hans@enterprisedt.com Fri Feb 1 21:59:37 2013 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 CDB1721F8E0A for ; Fri, 1 Feb 2013 21:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLcSC1O+2Tvs for ; Fri, 1 Feb 2013 21:59:37 -0800 (PST) Received: from enterprisedt.com (mail.enterprisedt.com [67.225.246.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0921F8E03 for ; Fri, 1 Feb 2013 21:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=enterprisedt.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=GhEHCVDmpVuH7P4J1PFyiOWJCDRrzqAuMRn5xC8/RUU=; b=DXvKUBI72yFR7G7Hl085uqPAYiChdNcavTXPwULCRcDdXktAKlIDC2AYy+TPs31YEDciNNJ/2cWmTV7AjijKQ4iKsqr2WwMdFP+xkqSBpJjw2eoy1ihMShLWqGJ1jOdj; Received: from mail-ia0-f173.google.com ([209.85.210.173]:46590) by host.enterprisedt.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U1W8W-0007rm-KL for ftpext@ietf.org; Sat, 02 Feb 2013 15:59:36 +1000 Received: by mail-ia0-f173.google.com with SMTP id h37so1934814iak.4 for ; Fri, 01 Feb 2013 21:59:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.151.176 with SMTP id ur16mr791443igb.30.1359784775932; Fri, 01 Feb 2013 21:59:35 -0800 (PST) Received: by 10.64.137.39 with HTTP; Fri, 1 Feb 2013 21:59:35 -0800 (PST) In-Reply-To: References: <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> <5105BDA8.7000006@gmail.com> Date: Sat, 2 Feb 2013 15:59:35 +1000 Message-ID: From: Hans Andersen To: "ftpext@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3b9f3b8a5b9e04d4b79040 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.enterprisedt.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - enterprisedt.com Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST 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: Sat, 02 Feb 2013 05:59:37 -0000 --e89a8f3b9f3b8a5b9e04d4b79040 Content-Type: text/plain; charset=ISO-8859-1 I just wanted to back my colleague, Bruce, on the performance issue related to detecting boundaries. A few weeks ago I wrote code that detects MIME boundaries in HTTP-POSTs while piping the data to a file. The best I managed to achieve was significantly slower than simple piping. I therefore think that optionally including the size is important for performance. On 2 February 2013 14:26, Anthony Bryan wrote: > right, we could leave the boundary REQUIRED but have an OPTIONAL size > that would be used (probably the majority of the time?) --e89a8f3b9f3b8a5b9e04d4b79040 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just wanted to back my colleague, Bruce, on the performance issue related= to detecting boundaries. =A0A few weeks ago I wrote code that detects MIME= boundaries in HTTP-POSTs while piping the data to a file. =A0The best I ma= naged to achieve was significantly slower than simple piping. =A0I therefor= e think that optionally including the size is important for performance.
On 2 February 2013 14:26, An= thony Bryan <anthonybryan@gmail.com> wrote:
right, we could leave the boundary REQUIRED but have an OPTIONAL size
that would be used (probably the majority of the time?)
--e89a8f3b9f3b8a5b9e04d4b79040-- From tim.kosse@filezilla-project.org Sun Feb 3 13:05:12 2013 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 02B7721F8868 for ; Sun, 3 Feb 2013 13:05:12 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgvkpKl94TdC for ; Sun, 3 Feb 2013 13:05:11 -0800 (PST) Received: from filezilla-project.org (filezilla-project.org [IPv6:2a01:4f8:160:7342::2]) by ietfa.amsl.com (Postfix) with ESMTP id 58A0F21F8867 for ; Sun, 3 Feb 2013 13:05:11 -0800 (PST) Received: from p4fc1d5f3.dip.t-dialin.net ([79.193.213.243] 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 1U26kP-0005dl-CF; Sun, 03 Feb 2013 22:05:10 +0100 Message-ID: <510ED0FF.5070100@filezilla-project.org> Date: Sun, 03 Feb 2013 22:05:03 +0100 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "ftpext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AASQWRFAEIJUAAHKAWOO" Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST 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, 03 Feb 2013 21:05:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AASQWRFAEIJUAAHKAWOO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, here's my review of the LOCK draft: 1. From the draft: "As mentioned, the use of two ports with FTP became problematic with the advent of firewalls and NATs. By using a single port, like many other protocols, these problems are eliminated." For plain FTP, transmitting arbitrary data over the control connection will cause massive problems. There are plenty of firewalls and NAT devices that close the FTP connection if there's strange data on the control connection. Worse, many NAT devices act as transparent FTP proxy. They have the nasty habit of not filtering out FEAT responses they do not know about, so once a client uses an advertised feature the proxy doesn't support, the connection will fail. In other words, the additional problems with firewalls and NAT devices caused by LOCK completely defeat its intended purpose. There is a good solution for this problem though, namely FTP over TLS. Following the AUTH TLS command, most firewalls and NAT routers stop interfering with the control connection. Perhaps mandate FTP over TLS for LOCK? 2. What about Telnet signals (e.g. IP and Synch) on the NVT during a transfer? Suggestion: Not allowed during a running transfer. 3. How is the STAT command to be handled? =46rom RFC959: The command may be sent during a file transfer (along with= the Telnet IP and Synch signals--see the Section on FTP Commands) in which case the server will respond with the status of the operation in progress There's no way to send the STAT reply during an ongoing download (e.g. RETR) if LOCK is being used. During an ongoing upload (e.g. STOR), how should STAT be handled? Suggestion: No STAT during a running transfer allowed. 4. SIZE command =46rom RFC3659: The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer size of a file from the server-FTP process. This is the exact number of octets (8 bit bytes) that would be transmitted over the data connection should that file be transmitted. I suggest that if LOCK is being used, it refers to the amount of octets that would be enclosed in the boundary start end end, excluding the boundary markers. 5. From the draft: "To turn off LOCK and return to the previous behavior, a client can issue a PORT, PASV, or similar command." Not precise enough. What is similar? PASS is similar to PASV, only one different letter. I suggest explicitly naming all commands. 6. REST command. Same problem as with SIZE. I propose the restart offset refers to the actual data payload excluding the boundary. 7. Transfer modes other than MODE S aren't mentioned. Explicitly state that LOCK with other transfer modes is undefined. Regards, Tim Kosse ------enig2AASQWRFAEIJUAAHKAWOO 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEO0QUACgkQ8N9+lcqiUkWtdACfRnIUOq4XBB6oOwppSzZ51eT/ F7sAnRoE/gVV00YcUresB2Jn8N0V+/6p =70So -----END PGP SIGNATURE----- ------enig2AASQWRFAEIJUAAHKAWOO-- From keisial@gmail.com Sun Feb 3 14:11:23 2013 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 75DD221F88CF for ; Sun, 3 Feb 2013 14:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dDn4JHeCkMF for ; Sun, 3 Feb 2013 14:11:17 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0317521F853C for ; Sun, 3 Feb 2013 14:11:16 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so1021274wib.8 for ; Sun, 03 Feb 2013 14:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CpZMOTHHC79f0hRqmO5pH0t44l7WwFF2uXh+xiUSmec=; b=jA626UHDqv8wBjGKz5dqlB/jiHjvrniPsAeLQIkzDesLJZPBAsgusUhpLnTqUosm+V WELjvIi/BVAedsmTDoEQ5BtXAtihrfa5nCS0JKiBjcJhDi+Yh8W/W3LLlfI9CUDW9jQ6 ymji2puBZ5yA83vTS/JF+hJtp0bMmvPPDfHYUzcJDMZe0eDDGcHX0aTfZaXHyeWAGvp8 gGBunaWO5CFIVpHC/Uw8eyMitKRizX6+P1pcAWSIW3yKQmurmzYA0/AncDFn7VXjo4aC U+00vJv+Rcb5y7DQCxeJljrN7tq/QkJq3McAC8FXp0HzE2hJhORHRHYSwxJ4E6cg1ap4 svjw== X-Received: by 10.180.85.97 with SMTP id g1mr7172764wiz.29.1359929475997; Sun, 03 Feb 2013 14:11:15 -0800 (PST) Received: from [192.168.1.26] (210.Red-193-153-87.dynamicIP.rima-tde.net. [193.153.87.210]) by mx.google.com with ESMTPS id ec3sm11662137wib.1.2013.02.03.14.11.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 14:11:15 -0800 (PST) Message-ID: <510EE013.7010505@gmail.com> Date: Sun, 03 Feb 2013 23:09:23 +0100 From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= User-Agent: Thunderbird MIME-Version: 1.0 To: Tim Kosse References: <510ED0FF.5070100@filezilla-project.org> In-Reply-To: <510ED0FF.5070100@filezilla-project.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ftpext@ietf.org" Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST 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, 03 Feb 2013 22:11:23 -0000 On 03/02/13 22:05, Tim Kosse wrote: > Hi, > > here's my review of the LOCK draft: > In other words, the additional problems with firewalls and NAT devices > caused by LOCK completely defeat its intended purpose. > > There is a good solution for this problem though, namely FTP over TLS. > Following the AUTH TLS command, most firewalls and NAT routers stop > interfering with the control connection. Perhaps mandate FTP over TLS > for LOCK? Worth suggesting as a note, but I don't think it should be required. > 2. What about Telnet signals (e.g. IP and Synch) on the NVT during a > transfer? > > Suggestion: Not allowed during a running transfer. > > > 3. How is the STAT command to be handled? > > From RFC959: The command may be sent during a file transfer (along with > the Telnet IP and Synch signals--see the Section on FTP Commands) in > which case the server will respond with the status of the operation in > progress > > There's no way to send the STAT reply during an ongoing download (e.g. > RETR) if LOCK is being used. > > During an ongoing upload (e.g. STOR), how should STAT be handled? > > Suggestion: No STAT during a running transfer allowed. I think the LOCK command should be changed (and probably renamed) into a command multiplexing the connection. The current LOCK command would be equivalent to multiplexing one channel with the control connection. But it would add support to send commands/signals/replies between chunks, plus doing several transmissions in parallel. From anthonybryan@gmail.com Tue Feb 5 06:30:59 2013 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 5EB3C21F88FB for ; Tue, 5 Feb 2013 06:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThRIkzXbYop0 for ; Tue, 5 Feb 2013 06:30:57 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8BE21F88E1 for ; Tue, 5 Feb 2013 06:30:57 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id bv4so1805931qab.17 for ; Tue, 05 Feb 2013 06:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ySqcDojibQTDfT3dY3AAIodyTTsRjrcHypLvjPdCxSs=; b=09HBR/zjcxWEd0gm9jBeZvhwvhN7MBIs6mlA4lVombGLw+8W2IGFQCJ4ExnNySqX21 CFTD4SZPfaqhQyo91IrAhDe/1PjYl3hnyNrpvSyToTkQkR9ynM17cOTWiO7fRqtE767a KRfwUy743tlkKKTHtjKa8E7M6MhAU214SxWFf2uZBoYtqTRfAA+QR8eZV86+oy++b4cv EHtdVUmxeLMg8ezUv76G8Z7mSCwhDxue/b/suY1UWQgA07I81l1rK5V+yd0PltTy2xk+ 7c7Z5gA7YQf7S1TMfQWk8Asc3aZCYB3QTKVCcC7wxZUOlyGsctw/0xTRHrTPkXz3dj9S Zu7Q== MIME-Version: 1.0 X-Received: by 10.229.198.132 with SMTP id eo4mr507624qcb.86.1360074657040; Tue, 05 Feb 2013 06:30:57 -0800 (PST) Received: by 10.49.12.36 with HTTP; Tue, 5 Feb 2013 06:30:56 -0800 (PST) In-Reply-To: <510ED0FF.5070100@filezilla-project.org> References: <510ED0FF.5070100@filezilla-project.org> Date: Tue, 5 Feb 2013 09:30:56 -0500 Message-ID: From: Anthony Bryan To: Tim Kosse Content-Type: text/plain; charset=ISO-8859-1 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST 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: Tue, 05 Feb 2013 14:30:59 -0000 Tim, thanks so much for the review! here's the text I've used to address your comments. let me know what you think, if we can refine it more. On Sun, Feb 3, 2013 at 4:05 PM, Tim Kosse wrote: > Hi, > > here's my review of the LOCK draft: > > 1. From the draft: "As mentioned, the use of two ports with FTP became > problematic with the advent of firewalls and NATs. By using a single > port, like many other protocols, these problems are eliminated." > > For plain FTP, transmitting arbitrary data over the control connection > will cause massive problems. There are plenty of firewalls and NAT > devices that close the FTP connection if there's strange data on the > control connection. > > Worse, many NAT devices act as transparent FTP proxy. They have the > nasty habit of not filtering out FEAT responses they do not know about, > so once a client uses an advertised feature the proxy doesn't support, > the connection will fail. > > In other words, the additional problems with firewalls and NAT devices > caused by LOCK completely defeat its intended purpose. > > There is a good solution for this problem though, namely FTP over TLS. > Following the AUTH TLS command, most firewalls and NAT routers stop > interfering with the control connection. Perhaps mandate FTP over TLS > for LOCK? FTP secured with TLS [RFC4217] is RECOMMENDED when LOCK is in use as most firewalls and NATs will stop interfering with the control connection following the AUTH TLS command. > 2. What about Telnet signals (e.g. IP and Synch) on the NVT during a > transfer? > > Suggestion: Not allowed during a running transfer. The STAT command and Telnet IP and Synch signals are not allowed during a running transfer. > 3. How is the STAT command to be handled? > > From RFC959: The command may be sent during a file transfer (along with > the Telnet IP and Synch signals--see the Section on FTP Commands) in > which case the server will respond with the status of the operation in > progress > > There's no way to send the STAT reply during an ongoing download (e.g. > RETR) if LOCK is being used. > > During an ongoing upload (e.g. STOR), how should STAT be handled? > > Suggestion: No STAT during a running transfer allowed. The STAT command and Telnet IP and Synch signals are not allowed during a running transfer. > 4. SIZE command > > From RFC3659: The FTP command, SIZE OF FILE (SIZE), is used to obtain > the transfer size of a file from the server-FTP process. This is the > exact number of octets (8 bit bytes) that would be transmitted over the > data connection should that file be transmitted. > > I suggest that if LOCK is being used, it refers to the amount of octets > that would be enclosed in the boundary start end end, excluding the > boundary markers. When LOCK is in use, the response to a SIZE command refers to the amount of octets that would be enclosed in the boundary start and end, excluding the boundary markers. > 5. From the draft: "To turn off LOCK and return to the previous > behavior, a client can > issue a PORT, PASV, or similar command." > > Not precise enough. What is similar? PASS is similar to PASV, only one > different letter. I suggest explicitly naming all commands. To turn off LOCK and return to the previous behavior, a client can issue a EPRT, EPSV, PASV, or PORT command. > 6. REST command. Same problem as with SIZE. I propose the restart offset > refers to the actual data payload excluding the boundary. When LOCK is in use, the restart offset of the REST command refers to the actual data payload excluding the boundary. > 7. Transfer modes other than MODE S aren't mentioned. Explicitly state > that LOCK with other transfer modes is undefined. LOCK is undefined with other transfer modes, besides STREAM. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads