From dwing@cisco.com Mon Jan 3 12:36:44 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A553A3A6BAA; Mon, 3 Jan 2011 12:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxFup5SaOUZh; Mon, 3 Jan 2011 12:36:43 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 990C53A6B15; Mon, 3 Jan 2011 12:36:43 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL3CIU2rRN+J/2dsb2JhbACXPYx4c6JvmRKFSgSCen1u X-IronPort-AV: E=Sophos;i="4.60,268,1291593600"; d="scan'208";a="253975600" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2011 20:38:50 +0000 Received: from dwingWS (sjc-vpn6-1124.cisco.com [10.21.124.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p03KcoQ0001358; Mon, 3 Jan 2011 20:38:50 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> In-Reply-To: Date: Mon, 3 Jan 2011 12:38:50 -0800 Message-ID: <015d01cbab86$3aa832a0$aff897e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acui6l3NHck6gDWLR/+iYfvxNL8tqwImxCtA Content-Language: en-us Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: [ftpext] FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:36:44 -0000 > Maybe at this point in the discussion it would be good to hear from > implementers. There are already tons of NAT44 FTP ALGs out there, I > wonder how those solve this. For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's IOS, and it does nothing special with LANG (it doesn't block the command nor parse the FEAT response). We have other ALGs in other products (e.g., Linksys, ASA), but I did not check those. Our bug database (which spans all Cisco-branded products) has no customer complaints about FTP's LANG support. -d From anthonybryan@gmail.com Mon Jan 3 14:14:37 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FBF3A6C99 for ; Mon, 3 Jan 2011 14:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYQEHkXhesud for ; Mon, 3 Jan 2011 14:14:36 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 591083A693B for ; Mon, 3 Jan 2011 14:14:36 -0800 (PST) Received: by ewy8 with SMTP id 8so6300138ewy.31 for ; Mon, 03 Jan 2011 14:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kk9+2CTaR6guGSKrjHwWwH9o0WmVw9zufSwiTkKLIVQ=; b=RV1MhRk/oXm407ewp/6+rkdykgWnXSbe1CYJ7LqAGNZ1aIAlRBgs0Vklggwd/5YxHW q+X2miJL97ceU2Ezvv5cnXwrTxsiXcPNgitkQ1UoKHBv3Gb4Zd85Kb3T7La6Dr3ZYtVR 7190AGO2uWhDjb6Mne2dHmqzHIhp/ts9qi8S4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rzjm9vmj0Q6Q1iGNTYZ8TDrAvxJB4we4x191TUCZfsxiD4Y6yHr+AYjvTORGVRLlQX ymBEHxYs9AB2FElj0QVqqGgF8e9pCq1hMAgPt8FTMfUBGUuYRCqmvfEW7bu8I2AesoTY yrEilq6CwSy2yzF+ylA+5Edp58RuPGPg8Wvzk= MIME-Version: 1.0 Received: by 10.213.23.12 with SMTP id p12mr4477366ebb.50.1294093002189; Mon, 03 Jan 2011 14:16:42 -0800 (PST) Received: by 10.213.9.208 with HTTP; Mon, 3 Jan 2011 14:16:42 -0800 (PST) In-Reply-To: References: <20101124224501.31531.96663.idtracker@localhost> <4CEDAA9A.8030303@kimmeringer.de> <4CEF00C0.5050200@gmail.com> <4CEFDCB9.6010203@gmail.com> Date: Mon, 3 Jan 2011 17:16:42 -0500 Message-ID: From: Anthony Bryan To: Tatsuhiro Tsujikawa , Daniel Stenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 22:14:37 -0000 2010/11/29 Anthony Bryan : > > so, people seem to be interested in partial file hashing. I think it > is worth considering, even though it makes things more complicated and > there are potential security issues. > > any suggestions how to add this to the current draft? so, we have a new RANGe command [1] ID for specifying byte ranges. used with RETR: C> RANG 802816 1000000 S> 350 Restarting at 802816. End Byte range at 1000000. Send RETRIEVE C> RETR cap60.pl198.tar what does everyone think of using RANGe with HASH to specify the byte range for the optional partial file hashing? C> RANG 802816 1000000 S> 350 Byte range starting at 802816, ending at 1000000. C> HASH filename.ext S> 213 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext 802816 1000000 --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads [1] http://tools.ietf.org/html/draft-bryan-ftp-range From iljitsch@muada.com Wed Jan 5 06:17:32 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFAE3A6C18; Wed, 5 Jan 2011 06:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSHB4a84UTnd; Wed, 5 Jan 2011 06:17:31 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 0F04A3A6C05; Wed, 5 Jan 2011 06:17:30 -0800 (PST) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p05EJIMa061521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jan 2011 15:19:18 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <015d01cbab86$3aa832a0$aff897e0$@com> Date: Wed, 5 Jan 2011 15:19:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: Re: [ftpext] FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:17:32 -0000 On 3 jan 2011, at 21:38, Dan Wing wrote: > For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's > IOS, and it does nothing special with LANG (it doesn't block the > command nor parse the FEAT response). We have other ALGs in other > products (e.g., Linksys, ASA), but I did not check those. Our bug=20 > database (which spans all Cisco-branded products) has no customer=20 > complaints about FTP's LANG support. Apparently nobody else can muster up the energy to care about this. I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a = server and client negotiate a non-default language the ALG also = participates. This assumes the ALG supports the negotiated language, but = I'm thinking that if the server and client support a non-default = language, there's a good chance that the ALG vendor either added this = language too, or allowed sufficient customization for the user to do = this. The ALG only has 10 or so responses that it can generate, after = all. But for the reasons I outlined earlier, I'm still very reluctant to make = this a MUST. Seeing as the FTP44 ALG people apparently managed to do = without this, such a requirement runs a big risk of becoming a dead = letter, anyway. There's enough of that when it comes to FTP = specifications... Iljitsch= From lothar@kimmeringer.de Wed Jan 5 06:57:37 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5660C3A6E3F for ; Wed, 5 Jan 2011 06:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnR6lPw10HaL for ; Wed, 5 Jan 2011 06:57:36 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 1ABA13A6E37 for ; Wed, 5 Jan 2011 06:57:36 -0800 (PST) Received: from [192.168.1.20] (mnch-5d86ff90.pool.mediaWays.net [93.134.255.144]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MV0vp-1PpC4W32pp-00YFRj; Wed, 05 Jan 2011 15:59:41 +0100 Message-ID: <4D24875D.2070601@kimmeringer.de> Date: Wed, 05 Jan 2011 15:59:41 +0100 From: Lothar Kimmeringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 CC: ftpext@ietf.org References: <20101124224501.31531.96663.idtracker@localhost> <4CEDAA9A.8030303@kimmeringer.de> <4CEF00C0.5050200@gmail.com> <4CEFDCB9.6010203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:egAjP17S9SBgUPy6wwd6dnV1wwA3dDSfhrFbHzhH+RK RGnxA/OdWl0WLY2GYNP/x4Aots3dWR5aLPSCa+kzsLvrQ3WS+5 TXLWBq94O/dSiaK1d404B6/lfT5XCW8tBaBb0vNj8vEEizfsUl 8IoUft+BqmmcXCftXKUCWUrTSM+kOLRpCU/cLdY3EmqcOrmRrK B7PK/2j7hfheZKW2uHZIg== Subject: Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:57:37 -0000 Am 03.01.2011 23:16, schrieb Anthony Bryan: > 2010/11/29 Anthony Bryan: >> >> so, people seem to be interested in partial file hashing. I think it >> is worth considering, even though it makes things more complicated and >> there are potential security issues. I don't see security issues that might come up with that. Can you be a bit more specific with that? >> any suggestions how to add this to the current draft? > > so, we have a new RANGe command [1] ID for specifying byte ranges. > > used with RETR: > > C> RANG 802816 1000000 > S> 350 Restarting at 802816. End Byte range at 1000000. Send RETRIEVE > C> RETR cap60.pl198.tar > > what does everyone think of using RANGe with HASH to specify the byte > range for the optional partial file hashing? IMHO a good thing since it's addressing the same issue. > C> RANG 802816 1000000 > S> 350 Byte range starting at 802816, ending at 1000000. > C> HASH filename.ext > S> 213 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext > 802816 1000000 Do you need an additional RANG 802816 1000000 to finally retrieve that part of data or is that setting after the call of HASH still "active" and the client can continue with RETR immedately? That should be speci- fied as well. In addition to that I think adding hashing to the transfer of files using APPE, RETR and STOR would be a good thing as well and allows to get immediate feedback for a transfer of data if it has been succeeded without transfer error. The capability of the server to do so should be announced as additional FEAT-element: C> FEAT S> 211-Extensions supported: S> ... S> HASH SHA-256;SHA-512;SHA-1*;MD5 S> THSH NONE*;SHA-256;SHA-512;SHA-1;MD5 S> ... S> 211 END Rules are the same as for HASH with the additional option "NONE" which will result into the old behavior i.e. no hash digest cal- culation during transfers. NONE MUST be the default value being set when initiating an FTP-session to ensure backward compatibility. If a hash-calculation is active the return-message of RETR, STOR and APPE will contain the output similar to HASH in addition to the transfer complete message: S> 226 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext\ 802816 1000000 ASCII transfer complete The data being used for calculating the hash MUST be the original data before any transformations take place (e.g. when transfering in ASCII mode) I see a couple of advantages for this approach: - The caluclation of a hash while already handling the data- transfer can easily be done in most implementing languages I'm aware of. E.g. in Java it's simply a DigestInputStream/ DigestOutputStream being added to the already existing chain of streams being used. The calculation happens "on the fly". - Returning the hash as response to the transfer itself allows the client to check the resulting hash with the hash being calculated locally (e.g. by using above chain of streams as well) No need to call RANG and HASH specifically reducing the number of commands being exchanged between server and client. As well the file IO on the server-side is reduced since the data doesn't need to be processed twice (transfer and hash-calculation). - The correct transfer of data using other modes than "I" can be checked that way since it's operated on the data as it is received during transfer before conversions take place. A later call of RANG/HASH on a file being transfered in ASCII-mode most likely will produce a different hash than the one being calculated on the client side. I hope this will not complicate things too much. Best regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From Richard.Koenning@ts.fujitsu.com Wed Jan 5 07:24:50 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1453A6C69 for ; Wed, 5 Jan 2011 07:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvA3xC-nnKYJ for ; Wed, 5 Jan 2011 07:24:49 -0800 (PST) Received: from dgate20.ts.fujitsu.com (dgate20.ts.fujitsu.com [80.70.172.51]) by core3.amsl.com (Postfix) with ESMTP id B985E3A6E36 for ; Wed, 5 Jan 2011 07:24:48 -0800 (PST) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=LWPZDlnEXsQEBHRsCMgtWLZbS1ybiwrQ0Zq7hWXQPRPtv85Mpk+w6tpH H2F9yl6lhxQRU8RaaK/yOEPpc+fPF+653zHYlRn3iSuOSiB1NuGpSRr24 K7AwFHlIL9nBwUkVzy064m1QWAl/aSkjp3ZSrMowDVOg0MleKhNErg/wQ sUPgOiN4WOxaGbESoSFXszm7ZeHuOKprnieJ43bD/MM5BdNTL9XihbcZu ssBhzQeXKf16JKJRZl/eQvebmAZDy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1294241216; x=1325777216; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4D248DBD.8020905@ts.fujitsu.com>|Date:=20 Wed,=2005=20Jan=202011=2016:26:53=20+0100|From:=20Richard =20Koenning=20|Reply-To: =20=20Richard.Koenning@ts.fujitsu.com|MIME-Version:=201.0 |To:=20"ftpext@ietf.org"=20|CC:=20Lothar =20Kimmeringer=20|Subject:=20Re: =20[ftpext]=20I-D=20Action:draft-ietf-ftpext2-hash-00.txt |References:=20<20101124224501.31531.96663.idtracker@loca lhost>=09<4CEDAA9A.8030303@kimmeringer.de>=09=09<4CE F00C0.5050200@gmail.com>=09=09<4CEFDCB9.6010203@g mail.com>=09=09=20<4D24875D.2070601@kimmering er.de>|In-Reply-To:=20<4D24875D.2070601@kimmeringer.de> |Content-Transfer-Encoding:=20quoted-printable; bh=7m+N1TEFfUkegt1b1fp6dg5fDJzmnnebjCqJUN7B4yM=; b=l941ZCQCu6xaqd73aR4ODY/P39ObFVhunOWkBHVEu/K3kxl0oILQjGdg 89vwwCVTculO2fbamPq/Sc5muR7oF1FYLlKQW40PnJAcpgcKqGb4K+Nm4 MfjhBhmgqzXZZAdWYWHZOlyvavi0vExWzQbJOLr2dKH6qkFeNfCtp8G+9 QZQbepzGx3q0XhBZjO39qvvcuk/rLpKlUIWomtdjr3JoF6plduYzDisRs jJQ7Q7VWoyMsXaDUJy80Qjr8DelN1; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.60,278,1291590000"; d="scan'208";a="55824730" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate20u.abg.fsc.net with ESMTP; 05 Jan 2011 16:26:54 +0100 X-IronPort-AV: E=Sophos;i="4.60,278,1291590000"; d="scan'208";a="107801036" Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate40u.abg.fsc.net with ESMTP; 05 Jan 2011 16:26:54 +0100 Message-ID: <4D248DBD.8020905@ts.fujitsu.com> Date: Wed, 05 Jan 2011 16:26:53 +0100 From: Richard Koenning Organization: Fujitsu Technology Solutions GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, de-nds, en, en-US, it MIME-Version: 1.0 To: "ftpext@ietf.org" References: <20101124224501.31531.96663.idtracker@localhost> <4CEDAA9A.8030303@kimmeringer.de> <4CEF00C0.5050200@gmail.com> <4CEFDCB9.6010203@gmail.com> <4D24875D.2070601@kimmeringer.de> In-Reply-To: <4D24875D.2070601@kimmeringer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Richard.Koenning@ts.fujitsu.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 15:24:50 -0000 Lothar Kimmeringer wrote: > The data being used for calculating the hash MUST be the original > data before any transformations take place (e.g. when transfering > in ASCII mode) The data on the server before the transformation isn't necessarily the=20 same as the data on the client after undoing the transformation. E.g.=20 regard systems with different EOL conventions (LF on Unix systems, CR on = Mac OS (afaik), CR LF on Windows systems and even more complicated=20 conventions on mainframe systems), the common denominator of the FTP=20 partners is the data on the wire, therefore the data being used for=20 calculating the hash MUST be the data after the transformations take=20 place on the sending side and before the transformations take place on=20 the receiving side (with the SIZE command we have already a similar=20 situation with the same rule). Best regards, Richard --=20 Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH From dthaler@microsoft.com Wed Jan 5 08:09:36 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BA23A6B89; Wed, 5 Jan 2011 08:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.54 X-Spam-Level: X-Spam-Status: No, score=-111.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAFtwB7+93I8; Wed, 5 Jan 2011 08:09:36 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id F08503A6B78; Wed, 5 Jan 2011 08:09:35 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 5 Jan 2011 08:11:43 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 5 Jan 2011 08:11:43 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 5 Jan 2011 08:11:44 -0800 From: Dave Thaler To: "ftpext@ietf.org" Thread-Topic: FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] Thread-Index: AQHLq4ZCd3oh0GiYREyEEa+YCsrCvZPC9jCA//+XuqA= Date: Wed, 5 Jan 2011 16:11:40 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> In-Reply-To: <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , 'Behave WG' Subject: Re: [ftpext] FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 16:09:37 -0000 Question to FTPEXT: Given that many NAT44's that have FTP ALG don't allow LANG to work correctl= y, and we haven't seen any responses from FTPEXT folks arguing that it's important, should the Behave WG consider LANG support in RFC 2640 to be=20 unimportant? Is it basically dead? If so, I'm fine with a SHOULD in the FTP64 doc. And I agree with Iljitsch= 's implication that the recommendation for FTP64 ALGs should be the same as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is. -Dave > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, January 05, 2011 6:19 AM > To: Dan Wing > Cc: Dave Thaler; draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; > 'Behave WG' > Subject: Re: FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf- > behave-ftp64-05] >=20 > On 3 jan 2011, at 21:38, Dan Wing wrote: >=20 > > For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's > > IOS, and it does nothing special with LANG (it doesn't block the > > command nor parse the FEAT response). We have other ALGs in other > > products (e.g., Linksys, ASA), but I did not check those. Our bug > > database (which spans all Cisco-branded products) has no customer > > complaints about FTP's LANG support. >=20 > Apparently nobody else can muster up the energy to care about this. >=20 > I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a s= erver > and client negotiate a non-default language the ALG also participates. Th= is > assumes the ALG supports the negotiated language, but I'm thinking that i= f the > server and client support a non-default language, there's a good chance t= hat the > ALG vendor either added this language too, or allowed sufficient customiz= ation > for the user to do this. The ALG only has 10 or so responses that it can = generate, > after all. >=20 > But for the reasons I outlined earlier, I'm still very reluctant to make = this a > MUST. Seeing as the FTP44 ALG people apparently managed to do without thi= s, > such a requirement runs a big risk of becoming a dead letter, anyway. The= re's > enough of that when it comes to FTP specifications... >=20 > Iljitsch From fred@cisco.com Wed Jan 5 11:30:30 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7898B3A6C74; Wed, 5 Jan 2011 11:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl0pjo4Na55j; Wed, 5 Jan 2011 11:30:29 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F2EF13A6AB5; Wed, 5 Jan 2011 11:30:28 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,278,1291593600"; d="scan'208";a="310715506" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2011 19:32:36 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p05JWVsC021966; Wed, 5 Jan 2011 19:32:35 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 05 Jan 2011 11:32:36 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 05 Jan 2011 11:32:36 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 5 Jan 2011 11:32:19 -0800 Message-Id: References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 05 Jan 2011 11:31:51 -0800 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , 'Behave WG' Subject: Re: [ftpext] [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:30:30 -0000 On Jan 5, 2011, at 8:11 AM, Dave Thaler wrote: > I agree with Iljitsch's implication that the recommendation for FTP64 = ALGs should be the same as whatever the recommendation for other FTP = ALGs (e.g. in NAT44's) is. Yes.= From iljitsch@muada.com Wed Jan 5 13:39:50 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C943A6CD9; Wed, 5 Jan 2011 13:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GecR3pK1KizS; Wed, 5 Jan 2011 13:39:14 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id EEE9A3A67D6; Wed, 5 Jan 2011 13:39:13 -0800 (PST) Received: from [192.168.1.5] (176.Red-83-33-119.dynamicIP.rima-tde.net [83.33.119.176]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p05Lewv1064526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jan 2011 22:40:59 +0100 (CET) (envelope-from iljitsch@muada.com) References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2-276357164 Message-Id: <1BF1B9D6-B649-48A5-BB4A-F31F2BCC4E72@muada.com> X-Mailer: iPhone Mail (8C148) From: Iljitsch van Beijnum Date: Wed, 5 Jan 2011 22:40:45 +0100 To: Dave Thaler Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , Behave WG Subject: Re: [ftpext] FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:39:50 -0000 --Apple-Mail-2-276357164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 jan. 2011, at 17:11, Dave Thaler wrote: > And I agree with Iljitsch's > implication that the recommendation for FTP64 ALGs should be the same > as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is. Failing to quit while I'm ahead... Are there any FTP44 ALG recommendations? --Apple-Mail-2-276357164 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8

On 5 jan. 2011, at 17:11, Dave Thaler <dthaler@microsoft.com> wrote:

And I agree with Iljitsch's
implication that the recommendation for FTP64 ALGs should be the same
as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is.

Failing to quit while I'm ahead...

Are there any FTP44 ALG recommendations?

--Apple-Mail-2-276357164-- From dwing@cisco.com Wed Jan 5 15:40:36 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384173A6E23; Wed, 5 Jan 2011 15:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9W8H-IUB5qU; Wed, 5 Jan 2011 15:40:35 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7F23D3A6D0E; Wed, 5 Jan 2011 15:40:35 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANOQJE2rR7Hu/2dsb2JhbACDd5M3jG5zplGKU41PgSGDN3QEhGg X-IronPort-AV: E=Sophos;i="4.60,280,1291593600"; d="scan'208";a="396523978" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 05 Jan 2011 23:42:42 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p05Nggew006185; Wed, 5 Jan 2011 23:42:42 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Dave Thaler'" References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1BF1B9D6-B649-48A5-B B4A-F31F2BCC4E72@muada.com> In-Reply-To: <1BF1B9D6-B649-48A5-BB4A-F31F2BCC4E72@muada.com> Date: Wed, 5 Jan 2011 15:42:41 -0800 Message-ID: <097701cbad32$3e8bf200$bba3d600$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutIUtb5iuicnTUQjqT4jyoTusjawAEKWaA Content-Language: en-us Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' Subject: Re: [ftpext] FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:40:36 -0000 > On 5 jan. 2011, at 17:11, Dave Thaler wrote: > > > And I agree with Iljitsch's > implication that the recommendation for FTP64 ALGs should be the > same > as whatever the recommendation for other FTP ALGs (e.g. in > NAT44's) is. > > > > Failing to quit while I'm ahead... > > Are there any FTP44 ALG recommendations? I am only aware of http://tools.ietf.org/html/rfc3027#section-4.1 -d From sob@nvnet.cz Wed Jan 5 17:03:32 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFA63A6D79 for ; Wed, 5 Jan 2011 17:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_CZ=0.445, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+ytaLP6ln6F for ; Wed, 5 Jan 2011 17:03:32 -0800 (PST) Received: from mail.nvnet.cz (mail.nvnet.cz [IPv6:2002:d5d3:2ff6:80::3]) by core3.amsl.com (Postfix) with ESMTP id 63CD63A6D1C for ; Wed, 5 Jan 2011 17:03:30 -0800 (PST) X-AuthUser: sob@nvnet.cz Received: from Sob-PC.nvnet.cz ([213.211.47.246]:58578) by mail.nvnet.cz with [XMail 1.25 ESMTP Server] id for from ; Thu, 6 Jan 2011 02:05:36 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Jan 2011 02:01:58 +0100 To: Anthony Bryan From: Sob In-Reply-To: References: <20101124224501.31531.96663.idtracker@localhost> <4CEDAA9A.8030303@kimmeringer.de> <4CEF00C0.5050200@gmail.com> <4CEFDCB9.6010203@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20110106010331.63CD63A6D1C@core3.amsl.com> Cc: ftpext@ietf.org Subject: Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:03:33 -0000 At 23:16 3.1.2011, anthonybryan@gmail.com wrote: > S> 213 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext >802816 1000000 Range information after filename doesn't seem to be the best idea. If optional, then it's wrong, because it can't be told if it's there or if it's part of filename. If mandatory, then it would work and only doesn't look nice. Rather than inventing new custom reply format, wouldn't it be better to adopt MLSx style? It's simple, readable, extensible, ... E.g.: S> 213 Hash.SHA-256=f0ad929cd...;Range=802816-1000000; filename.ext And the relation between HASH and MLSx doesn't necessarily have to end with this. Hash as optional MLSx fact would be nice answer to already requested hashes for multiple files at the same time. -- From dthaler@microsoft.com Wed Jan 5 17:55:12 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39DE3A6E52; Wed, 5 Jan 2011 17:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZGiOrDs+R2v; Wed, 5 Jan 2011 17:55:11 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B281B3A6E55; Wed, 5 Jan 2011 17:55:11 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 5 Jan 2011 17:57:19 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 5 Jan 2011 17:57:18 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 5 Jan 2011 17:57:17 -0800 From: Dave Thaler To: Dan Wing , 'Iljitsch van Beijnum' Thread-Topic: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] Thread-Index: AQHLrTJEjnmEF06JX0uY7W1jdnOAoJPDLGvw Date: Thu, 6 Jan 2011 01:57:17 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653448AC5B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> <015d01cbab86$3aa832a0$aff897e0$@com> <4AFCA9F5-CA3A-48EF-87AB-7ADC165956B2@muada.com> <9B57C850BB53634CACEC56EF4853FF6534487CCF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1BF1B9D6-B649-48A5-B B4A-F31F2BCC4E72@muada.com> <097701cbad32$3e8bf200$bba3d600$@com> In-Reply-To: <097701cbad32$3e8bf200$bba3d600$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , 'Behave WG' Subject: Re: [ftpext] [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05] X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:55:12 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Dan Wing > Sent: Wednesday, January 05, 2011 3:43 PM > To: 'Iljitsch van Beijnum'; Dave Thaler > Cc: draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; 'Behave WG' > Subject: Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, draft-ietf- > behave-ftp64-05] >=20 > > On 5 jan. 2011, at 17:11, Dave Thaler wrote: > > > > > > And I agree with Iljitsch's > > implication that the recommendation for FTP64 ALGs should be the > same > > as whatever the recommendation for other FTP ALGs (e.g. in > > NAT44's) is. > > > > Failing to quit while I'm ahead... > > > > Are there any FTP44 ALG recommendations? >=20 > I am only aware of > http://tools.ietf.org/html/rfc3027#section-4.1 In the interest of making progress on FTP64... Given that the LANG/FEAT problem is not specific to FTP64 but applies to 44 ALGs (or any other type of FTP ALG for that matter), I think this proble= m is probably best addressed outside of the FTP64 spec itself, and if an answ= er existed in another doc, the FTP64 spec would just refer to it. As such, I think I am ok with not solving the problem in the FTP64 spec, and leaving it for future work. However, I would like to see a note=20 to that effect added to FTP64. In other words, I can live with it being unspecified in FTP64 as long as FTP64 calls out the issue and says it's lef= t for future work and points out that it's not specific to a 64 case. While that may result in bad behavior, it's no worse than the situation we're already in today where LANG behavior is somewhere between=20 broken and "unexpected". In my opinion, the FTPEXT group should=20 then decide what it wants to do about LANG (rev RFC 2640 or ignore=20 the problem or whatever else). -Dave From lothar@kimmeringer.de Sat Jan 8 09:27:39 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3EF28C13B for ; Sat, 8 Jan 2011 09:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKZ+dXlbNr-7 for ; Sat, 8 Jan 2011 09:27:38 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 3AC9428C136 for ; Sat, 8 Jan 2011 09:27:35 -0800 (PST) Received: from [192.168.1.20] (mnch-4d0425fb.pool.mediaWays.net [77.4.37.251]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MAAX7-1PQvF90EvZ-00BJVX; Sat, 08 Jan 2011 18:29:42 +0100 Message-ID: <4D289F05.8000100@kimmeringer.de> Date: Sat, 08 Jan 2011 18:29:41 +0100 From: Lothar Kimmeringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ftpext@ietf.org" References: <20101124224501.31531.96663.idtracker@localhost> <4CEDAA9A.8030303@kimmeringer.de> <4CEF00C0.5050200@gmail.com> <4CEFDCB9.6010203@gmail.com> <4D24875D.2070601@kimmeringer.de> <4D248DBD.8020905@ts.fujitsu.com> In-Reply-To: <4D248DBD.8020905@ts.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:X4y1LWbJRe69hwlDnilcL0DzOHwV90sKDCBHosRqpxa 1uzGAujHDUer7F4squSE3euJotC2M+LU9uYPlTISbCN+ja6j5m oM0vOri+jFRcRqciyT+1o78zXfcI40NdtDJtUJa+NeWkoAkUZl fgd1djPP/y4xx616xncgbtDpsRmk0fjSCf8JxUnJ/0ssMqYG4y 6lIGCX2AuiS59Gj4P1yrA== Subject: Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:27:41 -0000 Am 05.01.2011 16:26, schrieb Richard Koenning: > Lothar Kimmeringer wrote: > >> The data being used for calculating the hash MUST be the original >> data before any transformations take place (e.g. when transfering >> in ASCII mode) > > The data on the server before the transformation isn't necessarily > the same as the data on the client after undoing the transformation. > E.g. regard systems with different EOL conventions (LF on Unix > systems, CR on Mac OS (afaik), CR LF on Windows systems and even more > complicated conventions on mainframe systems), the common denominator > of the FTP partners is the data on the wire, therefore the data being > used for calculating the hash MUST be the data after the > transformations take place on the sending side and before the > transformations take place on the receiving side (with the SIZE > command we have already a similar situation with the same rule). We thought of the same, your description is more common than mine, where I only regarded the server side when data is being sent from client to sever. Best regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! From robmcm@microsoft.com Wed Jan 12 00:56:52 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F663A69E5 for ; Wed, 12 Jan 2011 00:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIw1olbiMuXd for ; Wed, 12 Jan 2011 00:56:51 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 3670A3A681B for ; Wed, 12 Jan 2011 00:56:51 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Jan 2011 00:59:10 -0800 Received: from TK5EX14MBXC131.redmond.corp.microsoft.com ([169.254.10.208]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Wed, 12 Jan 2011 00:59:09 -0800 From: Robert McMurray To: 'Daniel Stenberg' , "ftpext@ietf.org" Thread-Topic: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-01.txt Thread-Index: AQHLl9v5Wdrp1+tqOk6u0+E2XrsuiJPNHmng Date: Wed, 12 Jan 2011 08:59:09 +0000 Message-ID: References: <20101208181502.13334.10373.idtracker@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-01.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 08:56:53 -0000 Daniel, Thanks for the great feedback. Sorry for the delayed response, I've been on= vacation. The reason that there are two possible responses for an out-of-sequence is = because I didn't think that it was absolutely necessary to mandate one or t= he other in this situation. Of the two possibilities I personally favor the= first option, which is to treat the late HOST command as an erroneous sequ= ence of commands and return a 503 reply. This is because the general idea i= s that the HOST command is part of a login sequence, like the USER, PASS, a= nd ACCT commands - and you can't use those commands out-of-order. But that = being said, I could see where an implementer might want to choose the REIN = behavior, and I think that a client and server could negotiate this conditi= on pretty easily. But if there was a consensus to drop one or the other, I'= d side with the 503 reply so the client always knows that it should send a = REIN command. As far as sending a port goes, there was a discussion about that concept a = year and a half ago with the old HOST draft before the Working Group was fo= rmed, and it took me a little while to find my notes on that. The basic out= come of that discussion is that it doesn't sense to pass a port - and I'm p= araphrasing some of my notes from that discussion. When the client has already connected to the server on the control port, th= e connection has already been made and therefore specifying a port as part = of the HOST command has no real meaning. Once a connection has been establi= shed, the PORT and PASV commands control any secondary (data) connections, = but control is still over the existing command connection. To me specifying= a port seemed analogous to issuing an HTTP request like http://example.com= :p1:p2, where p1 is the first port to connect to and p2 is the second port.= So the port is superfluous in this scenario, and might actually cause unne= cessary problems in a NAT or firewall scenario, which I explain later. I had mentioned in the previous discussion that I had thought about an exam= ple NAT/firewall situation like the following: a. The site ftp.example.com is behind a NAT/firewall b. Client wants to connect to ftp.example.com on port 2112 c. Client looks up ftp.example.com in DNS, sees that it's 10.0.0.1 (which i= s NAT/firewall's address) d. Client connects to 10.0.0.1 on port 2112 e. NAT/firewall looks up the FTP mapping for 10.0.0.1 on port 2112, sees th= at it's routed to the FTP server at 192.168.0.1 on port 2112, and routes th= e connection traffic accordingly f. Client sends HOST ftp.example.com:2112 In this last step - both connections have already been made; the client has= connected to the NAT/firewall on the control channel over port 2112, and t= he NAT/firewall has connected to the intended FTP server on the control cha= nnel over port 2112. So once again the addition of the port is unnecessary. I had also considered changing ports through the HOST command with regard t= o a NAT/firewall situation, which you had mentioned in your email, but that= doesn't make sense, either. Pardon my anthropomorphizing this a little, bu= t I spent some time thinking through this scenario with the mindset of a cl= ient saying to a NAT/firewall: "I want to talk to you (ServerA) on port 111= 1, but I want to talk to someone that's hiding behind you (ServerB) on port= 2222." So the client connects to ServerA on port 1111, then sends HOST Ser= verB:2222. This seemed to me like a scenario that might be feasible. That said, my argument in favor of that scenario fell apart rather quickly = when considering it from a client perspective. If I have an FTP client and = I want to use a front-end NAT/firewall and back-end FTP server with differi= ng ports, I would now need to start configuring two ports for every FTP con= nection: the first port for my communication with the front-end and the sec= ond port for the back-end. That just didn't make sense. In the end, the arguments that won out in my considerations was the way tha= t I currently configure an FTP server behind a NAT server - I configure ext= ernal-facing DNS names (admin.example.com and author.example.com) and I con= figure routing rules to different ports on my back-end FTP server. So the N= AT server performs the port translation, and adding a port in the HOST comm= and would just mess things up. All that being said, for most clients, they are never aware that they are d= ealing with a firewall or NAT server, so trying to force the client to beco= me aware of special syntax to communicate through the NAT/firewall to a bac= k-end seemed to defeat some of the justification for having the NAT/firewal= l in the first place. Also, it seemed a bad idea to be exposing the remote = server information to clients through the NAT/firewall. Considering a two-port configuration just didn't work for any of the scenar= ios that I considered because that was simply not the way that the HOST com= mand was intended, and there would be way too many barriers to finding a wa= y to make that work. I think that for the NAT/firewall situations you would= need to have a different command that specifically addressed those scenari= os, something like a "RTCN 192.168.0.1:3333" command for a Remote Connectio= n to a back-end server, although personally I still think that it's a bad i= dea to expose the remote connection information through the NAT/firewall. Thanks again! --Robert -----Original Message----- From: Daniel Stenberg [mailto:daniel@haxx.se]=20 Sent: Wednesday, December 08, 2010 2:22 PM To: ftpext@ietf.org Subject: Re: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-01.txt On Wed, 8 Dec 2010, Internet-Drafts@ietf.org wrote: > This document defines a new FTP command that provides a mechanism for FTP= =20 > clients and servers to identify individual virtual hosts on an FTP server= . This is a very well written document and I really like it. Two=20 comments/remarks: Section 3 (and 3.3) mentions that the server can respond to a late HOST in = one=20 of two ways (a or b). Why two? Why not just specify one specific way which will make it easier fo= r=20 both client and server authors to behave? (I would personally prefer b but = it=20 is not a strong preference). Section 3.1 details that HOST only specify host name or IP address, not por= t=20 number. The HTTP Host: header can (optionally) include a port number. The t= ext=20 says that the port number is pointless but I'm not sure that it always is a= nd=20 will be. In a time when we use NATs and port forwarders and so on, I can=20 imagine a case when you have a front end port (port A) open for clients to= =20 connect to, but once connected you forward the traffic to an internal site = on=20 port B (or C or D perhaps when load ballancing for example) and thus the=20 internal receiver of the traffic doesn't know which port the client origina= lly=20 connected to unless it mentions that. It's just so easy to also support the port number as I think it would be a= =20 shame to forbid it since there may actually be usecases for it! --=20 / daniel.haxx.se From rto@globalscape.com Fri Jan 14 14:52:02 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A914E3A67E1 for ; Fri, 14 Jan 2011 14:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.422 X-Spam-Level: ** X-Spam-Status: No, score=2.422 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCZl8vU0Sh7W for ; Fri, 14 Jan 2011 14:52:00 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id 39F053A6BCC for ; Fri, 14 Jan 2011 14:52:00 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Fri, 14 Jan 2011 16:54:26 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Fri, 14 Jan 2011 16:54:20 -0600 Thread-Topic: test post - feel free to delete Thread-Index: Acu0PfqncwZ+x5LfRj6zc+BKIbLHWw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [ftpext] test post - feel free to delete X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 22:52:02 -0000 --_004_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_ Content-Type: multipart/alternative; boundary="_000_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_" --_000_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a test post =3D) Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com [cid:image001.gif@01CBB40B.B00AD150] (NYSE Amex:GSB) *This communication, including attachments, is for the exclusive use of the= addressee and may contain proprietary, confidential or privileged informat= ion. If you are not the intended recipient, any use, copying, disclosure, d= issemination or distribution is strictly prohibited. If you are not the int= ended recipient, please notify the sender immediately by return email and d= elete this communication and destroy all copies. --_000_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a test p= ost =3D)

 

Robert Oslin
Director of Product Management
= Tel: 1 (210) 293-7902
Fax: 1 (210) 690-8824

Send = me large files securely

www.globalscape.com=

3D"Globalscape_150=

   (NYSE Amex:GS= B)

*This c= ommunication, including attachments, is for the exclusive use of the addres= see and may contain proprietary, confidential or privileged information. If= you are not the intended recipient, any use, copying, disclosure, dissemin= ation or distribution is strictly prohibited. If you are not the intended r= ecipient, please notify the sender immediately by return email and delete t= his communication and destroy all copies.

<= p class=3DMsoNormal> 

= --_000_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_-- --_004_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1415; creation-date="Fri, 14 Jan 2011 16:54:21 GMT"; modification-date="Fri, 14 Jan 2011 16:54:21 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhlgAfANUAAL+/v0BAQMvY6mSKvxAQEGBgYJ+fn5ex1M/Pz3BwcCAgIK+vr+/v79/f34+P j1BQUNji7zAwMPL1+j1tr0p3tX6eyuXr9FeAurHE36S62nGUxb7O5Iuoz8LFyjY8RX9/fzBjqgAA AP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACWAB8AAAb/QJFw SCwaj8ikcslsOp/QqDQpqEKm2Kx2y3VKKhOQGETBdM/otLooCIMGmOqmcpGs7/i8CAHo+xFCEGIT G0YQFR1+AF0Mig16kEMCV08FIZeYIQEiEhQgE5RGEh6ZXQCZH5GQGZ6FRw2Ke5mZmwdiGUoNBJim qKp6BxoaB0UIBbuzCpcFH7QinhRMzZd7H9YOgEWw1twL2SKnmKm/eBAXAxZEBrPsCgwitBa3TA2Y AewB2QbK7JcKBuB8iRBAZ4yYARxCicBQcMwEhOmISHAjhhiRAQYNnuOQDmPGj0YQZCJgAMCCe+Lg 2RMgRkATfgQSfLCEiQCDaZcCfDCQANkl/z6+KjgcQNQgBxEQPI0hqlSMmSEeDSqMSoHoAIogMkT9 OMYIzhAAhTDwuYkWSxAumaBcMOSrAwPcHAxB8CBTH18GD1CScODAJAsU6wyxNYZShjFNL1wcY1GI 0KWMnXwNK8RnBJU5z6ZdEoHakHA5RTRw8KBzvxB3U17gSlSvCA4GXQnhe2CDgHQQ3GgAHFlI1ApV BBygWFRMVatEFX7OpGBRg7qYCmDWJMEpEwa8lttzMPLBTpqXUl9KJQGDBqwGB2gwuBnJ6k/pDhf2 zdVgBQlbP7YnAv60gkfOrFYBE+uE11Ym/bkzBErhgRZCKlVkYAcEAjCkkUG4DCGBBlYJV//fGIL9 FlxwUPXmRH8jffDOdJtgIEZESDDATwgEMNNfBA6GkAAADjDYICrvkeFXhY/BVyQIFcRxQGJnkYHc VkdF1ZgRUQ3Q15VXhgTTAjx+AMA3QjgjAkYDKJHAeGeyU8A7BviEiQJpXlISKnw19ZEGlGwQZEYU HGCBUhPAKARhLUmZRH5cGQFdCAomoUg2EyFpxxF8LCIaXNYssKJYAMQFSCN+NABqH48IYYEAGVxZ xRESVKhqRK1accSIEFBYhaBF2DrirvtNd0kEAQSr0weaJoEfGU/NRs6yqix62iUkKWHeJwNU4Cez 2ObBgI/PopatFACUyiwDYGYRJ7ABuCn/EBoIBFsuFAlQJoID0ULRQAMLsGVmsPoW8cEDXHD36xEO joNGAMz0K0UACluzMDbvFhGBAwBsSoTDW+BEEpgIfGUpGgVE8MgCD8hlzAcIJNBAPg8UkLLLQzSX QAE7EuDOzIsEkECPOxeg6cwPtBlBAnzQ3EjLH+uIcj4BjPbASQg3YEwCTSMMkAEtf9DAzOIKsUC3 s0i3xgcEnNITvQ7sHAAAAexDcgSlDRECdh8osMDELbcpkgH7JKBAAQg/HcLXBkSwzgIFeBfBB5uE 2YcIdRWwT6c6L66ANWUTwN3kiwfwgOdG0Au23WsAkICMzcx0CgM37aRTAiJ4ngDsooUApI8IZYfQ gN3YnSTCTMBTbUA9tw8+twE6WwPwHpeJwEBnC8wkGgHtft0A8sgDcLl0JdcoORJdMh6sNQZEzEhn EWxrcwPHMHzJAjKJ0Ga9AOCoQPHyExBTj79zI9MC+kMNAW5XAAUQ4CSYEkI4PMcw6hmQOyJoDtk0 8YEdNU0BBuyUzRT2rQ56UAgOcAB2uvbBEnoQAcqgnQlXyMIWuvCFMIyhKoIAADs= --_004_F15941D3C8A2D54D92B341C20CACDF2311976FEB77exchange_-- From rto@globalscape.com Fri Jan 14 15:30:50 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1419B3A6CA5 for ; Fri, 14 Jan 2011 15:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=2.511, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRPGfnlqAKSA for ; Fri, 14 Jan 2011 15:30:49 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id D9C353A6C14 for ; Fri, 14 Jan 2011 15:30:48 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Fri, 14 Jan 2011 17:33:15 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Fri, 14 Jan 2011 17:32:58 -0600 Thread-Topic: draft-ietf-ftpext2-hash - partial hashes Thread-Index: Acu0Q2BCbIG45I28QRe5qMdFqet68Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ftpext] draft-ietf-ftpext2-hash - partial hashes X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 23:30:50 -0000 draft-ietf-ftpext2-hash open issues indicates: "Current version of the draf= t defines full file hashes, but not partial file hashes." Partial hashes are valuable and applicable to re-world scenarios and should= be considered for inclusion in the HASH specification. Use Case:=20 User initiates download of multi-gigabyte file, such as ISO or similar. Transaction is interrupted [Later] User re-initiates download of same (supposedly) file At this point the client software must make a decision as to whether to res= ume the transfer or not. Filename is the first criteria observed, followed = by size. However, these do not take into consideration a corrupted partial = file (even with identical byte count), or that the remote file could have c= hanged, especially given the difficulty in assessing time differences betwe= en client and host systems. By requesting the hash for the portion of the remote file matching the byte= s for the partial local file, the client could determine whether the local = file is indeed valid and partial and subsequently resume the transfer from = the appropriate byte offset. A similar need occurs when the client has no prior knowledge of the transfe= r (no queue or cache mechanism) and a same name file is identified and the = client must determine whether the local file is just a segment/part of the = larger file located on the remote.=20 Below is an example of overwrite logic performed today by our FTP client us= ing hashes and size comparisons:=A0 If a user requests to download a file and a file with the same name exists = locally, the client will determine if the file sizes are the same or if the= destination (local) size is smaller (indicating a possible partially trans= ferred file). If file sizes are the same then the client will compute the h= ash for the entire file and ask the server for to provide the hash for the = corresponding remote file. The client will then skip the transfer if the ha= shes are identical or overwrite the file if the hashes do not match. If=A0 = the remote (source) file is larger the client will ask the server for a par= tial hash, up to the bytes that match the local (destination) file size. If= the partial hash matches then the client will resume the transfer from the= byte offset. If the hashes are different then the client will overwrite th= e file. (e.g. local partial file was corrupted or is not same file). Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com From anthonybryan@gmail.com Mon Jan 17 00:56:52 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585393A6EC8 for ; Mon, 17 Jan 2011 00:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+oK5xeyBBD6 for ; Mon, 17 Jan 2011 00:56:50 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 4B1BC3A6EC5 for ; Mon, 17 Jan 2011 00:56:50 -0800 (PST) Received: by eyd10 with SMTP id 10so2522478eyd.31 for ; Mon, 17 Jan 2011 00:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CcJunfN3C8XDzoiYEKApnq7gpmw7Gb5pAEtmoRgj1Wc=; b=BlsVJs3b0hhnWfZ/RH/oXoO5e0R2UX8zbKU/sKqb4w0s53BkawD1AOrtFVhieIwplK 3+J2OaxPaXz9i90oC1qaXP0IdQL48angJ3mrxk+ZpKcmeqrys0qhqwZgRzoBL+QTbewu cHTMcnVauvCH4ixrmz5bnZVfS47deOuRDzT7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n8r3kbpuqYz/3U7l23M55BZwGAgE70WsLPBP+TFO1jLGd6iNdeYSwpF6VWIBl6zvYj YIQhYvRwwM1LUvpJw8qYnlPgN+vw9dn/Q4DQD8iBqigcsy8jchBpAJryotgXtl1B863W kbVjssJgaw/LZfdTnvkL40dRdXfVFANlsho0w= MIME-Version: 1.0 Received: by 10.213.23.12 with SMTP id p12mr3419859ebb.50.1295254763341; Mon, 17 Jan 2011 00:59:23 -0800 (PST) Received: by 10.213.9.208 with HTTP; Mon, 17 Jan 2011 00:59:23 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Jan 2011 03:59:23 -0500 Message-ID: From: Anthony Bryan To: Robert Oslin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:56:52 -0000 On Fri, Jan 14, 2011 at 6:32 PM, Robert Oslin wrote: > draft-ietf-ftpext2-hash open issues indicates: "Current version of the dr= aft defines full file hashes, but not partial file hashes." > > Partial hashes are valuable and applicable to re-world scenarios and shou= ld be considered for inclusion in the HASH specification. > > Use Case: > > =A0 =A0 =A0 =A0User initiates download of multi-gigabyte file, such as IS= O or similar. > =A0 =A0 =A0 =A0Transaction is interrupted > =A0 =A0 =A0 =A0[Later] User re-initiates download of same (supposedly) fi= le > > At this point the client software must make a decision as to whether to r= esume the transfer or not. Filename is the first criteria observed, followe= d by size. However, these do not take into consideration a corrupted partia= l file (even with identical byte count), or that the remote file could have= changed, especially given the difficulty in assessing time differences bet= ween client and host systems. > > By requesting the hash for the portion of the remote file matching the by= tes for the partial local file, the client could determine whether the loca= l file is indeed valid and partial and subsequently resume the transfer fro= m the appropriate byte offset. > > A similar need occurs when the client has no prior knowledge of the trans= fer (no queue or cache mechanism) and a same name file is identified and th= e client must determine whether the local file is just a segment/part of th= e larger file located on the remote. > > Below is an example of overwrite logic performed today by our FTP client = using hashes and size comparisons: > > If a user requests to download a file and a file with the same name exist= s locally, the client will determine if the file sizes are the same or if t= he destination (local) size is smaller (indicating a possible partially tra= nsferred file). If file sizes are the same then the client will compute the= hash for the entire file and ask the server for to provide the hash for th= e corresponding remote file. The client will then skip the transfer if the = hashes are identical or overwrite the file if the hashes do not match. If= =A0 the remote (source) file is larger the client will ask the server for a= partial hash, up to the bytes that match the local (destination) file size= . If the partial hash matches then the client will resume the transfer from= the byte offset. If the hashes are different then the client will overwrit= e the file. (e.g. local partial file was corrupted or is not same file). Robert, thanks for joining us & for posting. a very quick introduction for Robert would mention that he works on CuteFTP and is the originator of the XCRC command. I think everyone's been unanimous in that we want HASH to support partial file hashes. I think there are a few things to iron out. 1) how to (optionally) select the byte range to be hashed. we proposed a new byte RANGe selection command, http://tools.ietf.org/html/draft-bryan-ftp-range , which needed to be fleshed out of course but would look something like this: C> RANG 802816 1000000 S> 350 Byte range starting at 802816, ending at 1000000. 2) how to show that partial hashes are supported, or if that's even needed? add a "p" to the FEAT? or just use an error code if someone tries to do a partial file hash and & it's not allowed or unsupported on the server? C> FEAT S> 211-Extensions supported: S> ... S> HASH SHA-256p;SHA-512p;SHA-1p*;MD5p S> ... S> 211 END 3) the server response which shows it's a partial file hash and not a full file hash. it would probably be good to have the range in there, and it could be mandatory, where if it was a full file hash it would list the start & end of the file C> HASH filename.ext S> 213 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext -802816 1000000 from Lothar: S> 226 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext\ 802816 1000000 ASCII transfer complete from Sob: Rather than inventing new custom reply format, wouldn't it be better to adopt MLSx style? It's simple, readable, extensible, ... E.g.: S> 213 Hash.SHA-256=3Df0ad929cd...;Range=3D802816-1000000; filename.ext (I intend to reply to the other hash messages backlog shortly) --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From mb@smartftp.com Mon Jan 17 01:29:08 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977F528C1AA for ; Mon, 17 Jan 2011 01:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpoJXF5hykfK for ; Mon, 17 Jan 2011 01:29:07 -0800 (PST) Received: from mail.smartftp.com (mail.smartftp.com [75.126.59.172]) by core3.amsl.com (Postfix) with ESMTP id 1F02C28C1C0 for ; Mon, 17 Jan 2011 01:29:07 -0800 (PST) Received: from M.smartsoft.local ([fe80::fd57:1201:8518:71bc]) by m.smartsoft.local ([fe80::fd57:1201:8518:71bc%12]) with mapi id 14.01.0270.001; Mon, 17 Jan 2011 01:31:41 -0800 From: Mat Berchtold To: Anthony Bryan , Robert Oslin Thread-Topic: [ftpext] draft-ietf-ftpext2-hash - partial hashes Thread-Index: Acu0Q2BCbIG45I28QRe5qMdFqet68QCJIOKAABAlE3A= Date: Mon, 17 Jan 2011 09:31:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.205] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 09:29:08 -0000 Hello Anthony .. >RANG for HASH I understand that RANG is a replacement for REST. Using the newly introduce= d command now to extend other commands as HASH might not be what RANG has b= een originally intended for. My concerns: - FEAT Reply One concern is how to announce the feature in the FEAT reply. Right now the= RANG draft proposed to use RANG STREAM. Assuming that the server now suppo= rts RANG for HASH as well, how does the FEAT line look like? RANG STREAM;HA= SH? What if another command that might be introduced in the future wants to= use the RANG concept as well?=20 - Multiple commands for one function=20 The use of multiple commands for one function makes it more complex than it= needs to be.=20 >Anthony's proposed FEAT reply for partial hashes I think partial hashes should be a MUST and not optional. Hence there is no= need for a special FEAT response. >MLST style reply I'm also in favor of the MLST style reply for commands with more than one r= eturn value. For the HASH output, everything beside the "Value" fact should= be optional. Maybe MFF style arguments should be considered as well: C>HASH Range=3D0-1000; File.ext S>213 Value=3Df0ad929cd...;Algorithm=3Dsha-256;Range=3D0-1000; And my favorite would be to pass the algorithm the same way to the HASH com= mand: C>HASH Algorithm=3Dsha-256;Range=3D0-1000; File.ext S>213 Value=3Df0ad929cd...;Algorithm=3Dsha-256;Range=3D0-1000; Regards, Mat -----Original Message----- From: ftpext-bounces@ietf.org [mailto:ftpext-bounces@ietf.org] On Behalf Of= Anthony Bryan Sent: Monday, 17 January, 2011 09:59 To: Robert Oslin Cc: ftpext@ietf.org Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes On Fri, Jan 14, 2011 at 6:32 PM, Robert Oslin wrote: > draft-ietf-ftpext2-hash open issues indicates: "Current version of the dr= aft defines full file hashes, but not partial file hashes." > > Partial hashes are valuable and applicable to re-world scenarios and shou= ld be considered for inclusion in the HASH specification. > > Use Case: > > =A0 =A0 =A0 =A0User initiates download of multi-gigabyte file, such as IS= O or similar. > =A0 =A0 =A0 =A0Transaction is interrupted > =A0 =A0 =A0 =A0[Later] User re-initiates download of same (supposedly) fi= le > > At this point the client software must make a decision as to whether to r= esume the transfer or not. Filename is the first criteria observed, followe= d by size. However, these do not take into consideration a corrupted partia= l file (even with identical byte count), or that the remote file could have= changed, especially given the difficulty in assessing time differences bet= ween client and host systems. > > By requesting the hash for the portion of the remote file matching the by= tes for the partial local file, the client could determine whether the loca= l file is indeed valid and partial and subsequently resume the transfer fro= m the appropriate byte offset. > > A similar need occurs when the client has no prior knowledge of the trans= fer (no queue or cache mechanism) and a same name file is identified and th= e client must determine whether the local file is just a segment/part of th= e larger file located on the remote. > > Below is an example of overwrite logic performed today by our FTP client = using hashes and size comparisons: > > If a user requests to download a file and a file with the same name exist= s locally, the client will determine if the file sizes are the same or if t= he destination (local) size is smaller (indicating a possible partially tra= nsferred file). If file sizes are the same then the client will compute the= hash for the entire file and ask the server for to provide the hash for th= e corresponding remote file. The client will then skip the transfer if the = hashes are identical or overwrite the file if the hashes do not match. If= =A0 the remote (source) file is larger the client will ask the server for a= partial hash, up to the bytes that match the local (destination) file size= . If the partial hash matches then the client will resume the transfer from= the byte offset. If the hashes are different then the client will overwrit= e the file. (e.g. local partial file was corrupted or is not same file). Robert, thanks for joining us & for posting. a very quick introduction for Robert would mention that he works on CuteFTP= and is the originator of the XCRC command. I think everyone's been unanimous in that we want HASH to support partial f= ile hashes. I think there are a few things to iron out. 1) how to (optionally) select the byte range to be hashed. we proposed a new byte RANGe selection command, http://tools.ietf.org/html/= draft-bryan-ftp-range , which needed to be fleshed out of course but would = look something like this: C> RANG 802816 1000000 S> 350 Byte range starting at 802816, ending at 1000000. 2) how to show that partial hashes are supported, or if that's even needed?= add a "p" to the FEAT? or just use an error code if someone tries to do a = partial file hash and & it's not allowed or unsupported on the server? C> FEAT S> 211-Extensions supported: S> ... S> HASH SHA-256p;SHA-512p;SHA-1p*;MD5p S> ... S> 211 END 3) the server response which shows it's a partial file hash and not a full = file hash. it would probably be good to have the range in there, and it cou= ld be mandatory, where if it was a full file hash it would list the start &= end of the file C> HASH filename.ext S> 213 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext -802816 1000000 from Lothar: S> 226 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext\ 802816 1000000 ASCII transfer complete from Sob: Rather than inventing new custom reply format, wouldn't it be better to ado= pt MLSx style? It's simple, readable, extensible, ... E.g.: S> 213 Hash.SHA-256=3Df0ad929cd...;Range=3D802816-1000000; filename.ext (I intend to reply to the other hash messages backlog shortly) -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads ______________________= _________________________ ftpext mailing list ftpext@ietf.org https://www.ietf.org/mailman/listinfo/ftpext From rto@globalscape.com Mon Jan 17 07:55:44 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA3B3A6BD8 for ; Mon, 17 Jan 2011 07:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOjDlAVgYFye for ; Mon, 17 Jan 2011 07:55:43 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id A29CF3A6BD7 for ; Mon, 17 Jan 2011 07:55:43 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Mon, 17 Jan 2011 09:58:17 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Mon, 17 Jan 2011 09:58:12 -0600 Thread-Topic: [ftpext] draft-ietf-ftpext2-hash - partial hashes Thread-Index: Acu0Q2BCbIG45I28QRe5qMdFqet68QCJIOKAABAlE3AAE+4kwA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:55:45 -0000 >>[Anthony]- Multiple commands for one function=20 >>[Mat] The use of multiple commands for one function makes it more complex= than it needs to be. I agree with Mat regarding unnecessary complexity. I agree with both of you= regarding proposed MLSx style request/reply. If the optional parameters we= re left out then defaults would apply (i.e. default algorithm, all bytes, e= tc.).=20 Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com =A0=A0=A0(NYSE Amex:GSB) *This communication, including attachments, is for the exclusive use of the= addressee and may contain proprietary, confidential or privileged informat= ion. If you are not the intended recipient, any use, copying, disclosure, d= issemination or distribution is strictly prohibited. If you are not the int= ended recipient, please notify the sender immediately by return email and d= elete this communication and destroy all copies. From rto@globalscape.com Mon Jan 17 08:02:21 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FA93A6BD8 for ; Mon, 17 Jan 2011 08:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsKPHV75eCmH for ; Mon, 17 Jan 2011 08:02:13 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id 7AE1F3A6D4E for ; Mon, 17 Jan 2011 08:02:13 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Mon, 17 Jan 2011 10:04:48 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Mon, 17 Jan 2011 10:04:45 -0600 Thread-Topic: draft-ietf-ftpext2-hash command name and default algorithm Thread-Index: Acu2YEHTH+sjQcC6SLm33aTYd7G1+Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:02:21 -0000 --_004_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_ Content-Type: multipart/alternative; boundary="_000_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_" --_000_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ftpext2-hash documents over 40 (and I'm certain this not a compr= ehensive list) implementations of XCRC, the non-formalized/ratified file in= tegrity command that has been the de facto standard over the past decade. A= s some on this list know well, it can be extremely time consuming and costl= y for vendors to implement new standards in their products (I could write p= ages on the soup-to-nuts process involved). I believe it would make life ea= sier on developers and speed the adoption of your RFC if you considered cha= nging the following: 1. Keep the command XCRC vs. HASH. XCRC standards for "Transfer (xfer) Cycl= ical Integrity Check", not "eXperimental Cyclical Integrity Check" as some = have supposed. Personally I like "HASH" better, but keeping the command the= same would mean that possibly hundreds of vendors wouldn't have to change = anything to start supporting it today (exception is #2 below). 2. Keep the default hash CRC32 (maybe if no opts shown in FEAT response), b= ut recommend MD5, SHA1, or higher. Now, I understand this is a big red flag= : "What about potential for collisions!" and "What about malicious users?".= Yes, those are both [remote] possibilities; I grant you that. I would not = advocate for CRC32 unless it were already in use by hundreds of FTP clients= /servers across the world, with great success, and zero reports (that I kno= w of) of problems. Now before you reply, consider that it would be the defa= ult, for legacy support sakes, but the RFC would strongly urge/recommend th= at new implementations or existing ones use SHA-1 or higher. By defaulting = to CRC32 and XCRC you would avoid disenfranchising hundreds of vendors from= the new standard, while encouraging new and existing vendors/developers to= switch to stronger algorithms to mitigate data integrity security risks. There is one more reason to consider using CRC32 as the default aside from = grandfathering in existing XCRC vendors. CRC32 is fast! It is 2-4X faster than geekdom approved algorithms such as SHA-256. This is a big= deal when it comes to FTP sessions, with the typical 30-60 second client i= mposed timeout between client request and server replies. According to a cr= ypto++ API benchmark, CRC32 can process 253 MiB/Second vs. SHA-256's 111MiB= /Second. That is a difference between 15 seconds for CRC32 vs. 36 seconds f= or SHA-256 to hash a 4 GB file (not counting disk i/o time!). Therefore you= run a greater risk of timing out the socket connection when using stronger= hashing algorithms. We should also consider the problem we are trying to solve with HASH/XCRC. = Are we simply trying to detect modifications due to random transmission err= ors, as was the original intent of XCRC? Or are we trying to detect malicio= us tampering or mitigate risk of collisions? If the former, then I would ar= gue that CRC32 as the default (for legacy support and performance) is the p= referred approach. If the latter, then perhaps we should enforce SHA-1 or h= igher as the default and force vendors to bite the bullet. Final thoughts. Changing the command name to XCRC but not changing the defa= ult algorithm to CRC32 would make no sense. Its neither or or both. I do un= derstand if everyone votes for a stronger (default) hashing algorithm, and = I do see the benefits going forward; I just want everyone to consider the i= mpact to existing vendors/developers and impact to performance, which could= lead to more timeouts - hence failed transfers, which could adversely impa= ct business processes. Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com [cid:image001.gif@01CBB62D.8A2A1B70] (NYSE Amex:GSB) *This communication, including attachments, is for the exclusive use of the= addressee and may contain proprietary, confidential or privileged informat= ion. If you are not the intended recipient, any use, copying, disclosure, d= issemination or distribution is strictly prohibited. If you are not the int= ended recipient, please notify the sender immediately by return email and d= elete this communication and destroy all copies. --_000_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-ft= pext2-hash documents over 40 (and I'm certain this not a comprehensive list= ) implementations of XCRC, the non-formalized/ratified file integrity comma= nd that has been the de facto standard over the past decade. As some on thi= s list know well, it can be extremely time consuming and costly for vendors= to implement new standards in their products (I could write pages on the s= oup-to-nuts process involved). I believe it would make life easier on devel= opers and speed the adoption of your RFC if you considered changing the fol= lowing:

 

1. Keep the command XCRC vs. HASH. XCRC standards for "= ;Transfer (xfer) Cyclical Integrity Check", not "eXperimental Cyc= lical Integrity Check" as some have supposed. Personally I like "= HASH" better, but keeping the command the same would mean that possibl= y hundreds of vendors wouldn't have to change anything to start supporting = it today (exception is #2 below).

 

2. Keep the default hash CRC32 (m= aybe if no opts shown in FEAT response), but recommend MD5, SHA1, or higher= . Now, I understand this is a big red flag: "What about potential for = collisions!" and "What about malicious users?”. Yes, those = are both [remote] possibilities; I grant you that. I would not advocate for= CRC32 unless it were already in use by hundreds of FTP clients/servers acr= oss the world, with great success, and zero reports (that I know of) of pro= blems. Now before you reply, consider that it would be the default, for leg= acy support sakes, but the RFC would strongly urge/recommend that new imple= mentations or existing ones use SHA-1 or higher. By defaulting to CRC32 and= XCRC you would avoid disenfranchising hundreds of vendors from the new sta= ndard, while encouraging new and existing vendors/developers to switch to s= tronger algorithms to mitigate data integrity security risks.

 

Ther= e is one more reason to consider using CRC32 as the default aside from gran= dfathering in existing XCRC vendors. CRC32 is fast! It is

2-4X faster than geekdom approved algorithms such as = SHA-256. This is a big deal when it comes to FTP sessions, with the typical= 30-60 second client imposed timeout between client request and server repl= ies. According to a crypto++ API benchmark, CRC32 can process 253 MiB/Secon= d vs. SHA-256's 111MiB/Second. That is a difference between 15 seconds for = CRC32 vs. 36 seconds for SHA-256 to hash a 4 GB file (not counting disk i/o= time!). Therefore you run a greater risk of timing out the socket connecti= on when using stronger hashing algorithms.

 

We should also consider = the problem we are trying to solve with HASH/XCRC. Are we simply trying to = detect modifications due to random transmission errors, as was the original= intent of XCRC? Or are we trying to detect malicious tampering or mitigate= risk of collisions? If the former, then I would argue that CRC32 as the de= fault (for legacy support and performance) is the preferred approach. If th= e latter, then perhaps we should enforce SHA-1 or higher as the default and= force vendors to bite the bullet.

 

Final thoughts. Changing the com= mand name to XCRC but not changing the default algorithm to CRC32 would mak= e no sense. Its neither or or both. I do understand if everyone votes for a= stronger (default) hashing algorithm, and I do see the benefits going forw= ard; I just want everyone to consider the impact to existing vendors/develo= pers and impact to performance, which could lead to more timeouts - hence f= ailed transfers, which could adversely impact business processes.

 

&n= bsp;

Robert Osl= in
Director of Product Manage= ment
Tel: 1 (210) 293-7902
Fax: 1 (210) 690-8824

Send me large files securely

www.globalscape.com<= /span>

*This communication, including attachments, is for the exclus= ive use of the addressee and may contain proprietary, confidential or privi= leged information. If you are not the intended recipient, any use, copying,= disclosure, dissemination or distribution is strictly prohibited. If you a= re not the intended recipient, please notify the sender immediately by retu= rn email and delete this communication and destroy all copies.

 

= = --_000_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_-- --_004_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1415; creation-date="Mon, 17 Jan 2011 10:04:46 GMT"; modification-date="Mon, 17 Jan 2011 10:04:46 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhlgAfANUAAL+/v0BAQMvY6mSKvxAQEGBgYJ+fn5ex1M/Pz3BwcCAgIK+vr+/v79/f34+P j1BQUNji7zAwMPL1+j1tr0p3tX6eyuXr9FeAurHE36S62nGUxb7O5Iuoz8LFyjY8RX9/fzBjqgAA AP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACWAB8AAAb/QJFw SCwaj8ikcslsOp/QqDQpqEKm2Kx2y3VKKhOQGETBdM/otLooCIMGmOqmcpGs7/i8CAHo+xFCEGIT G0YQFR1+AF0Mig16kEMCV08FIZeYIQEiEhQgE5RGEh6ZXQCZH5GQGZ6FRw2Ke5mZmwdiGUoNBJim qKp6BxoaB0UIBbuzCpcFH7QinhRMzZd7H9YOgEWw1twL2SKnmKm/eBAXAxZEBrPsCgwitBa3TA2Y AewB2QbK7JcKBuB8iRBAZ4yYARxCicBQcMwEhOmISHAjhhiRAQYNnuOQDmPGj0YQZCJgAMCCe+Lg 2RMgRkATfgQSfLCEiQCDaZcCfDCQANkl/z6+KjgcQNQgBxEQPI0hqlSMmSEeDSqMSoHoAIogMkT9 OMYIzhAAhTDwuYkWSxAumaBcMOSrAwPcHAxB8CBTH18GD1CScODAJAsU6wyxNYZShjFNL1wcY1GI 0KWMnXwNK8RnBJU5z6ZdEoHakHA5RTRw8KBzvxB3U17gSlSvCA4GXQnhe2CDgHQQ3GgAHFlI1ApV BBygWFRMVatEFX7OpGBRg7qYCmDWJMEpEwa8lttzMPLBTpqXUl9KJQGDBqwGB2gwuBnJ6k/pDhf2 zdVgBQlbP7YnAv60gkfOrFYBE+uE11Ym/bkzBErhgRZCKlVkYAcEAjCkkUG4DCGBBlYJV//fGIL9 FlxwUPXmRH8jffDOdJtgIEZESDDATwgEMNNfBA6GkAAADjDYICrvkeFXhY/BVyQIFcRxQGJnkYHc VkdF1ZgRUQ3Q15VXhgTTAjx+AMA3QjgjAkYDKJHAeGeyU8A7BviEiQJpXlISKnw19ZEGlGwQZEYU HGCBUhPAKARhLUmZRH5cGQFdCAomoUg2EyFpxxF8LCIaXNYssKJYAMQFSCN+NABqH48IYYEAGVxZ xRESVKhqRK1accSIEFBYhaBF2DrirvtNd0kEAQSr0weaJoEfGU/NRs6yqix62iUkKWHeJwNU4Cez 2ObBgI/PopatFACUyiwDYGYRJ7ABuCn/EBoIBFsuFAlQJoID0ULRQAMLsGVmsPoW8cEDXHD36xEO joNGAMz0K0UACluzMDbvFhGBAwBsSoTDW+BEEpgIfGUpGgVE8MgCD8hlzAcIJNBAPg8UkLLLQzSX QAE7EuDOzIsEkECPOxeg6cwPtBlBAnzQ3EjLH+uIcj4BjPbASQg3YEwCTSMMkAEtf9DAzOIKsUC3 s0i3xgcEnNITvQ7sHAAAAexDcgSlDRECdh8osMDELbcpkgH7JKBAAQg/HcLXBkSwzgIFeBfBB5uE 2YcIdRWwT6c6L66ANWUTwN3kiwfwgOdG0Au23WsAkICMzcx0CgM37aRTAiJ4ngDsooUApI8IZYfQ gN3YnSTCTMBTbUA9tw8+twE6WwPwHpeJwEBnC8wkGgHtft0A8sgDcLl0JdcoORJdMh6sNQZEzEhn EWxrcwPHMHzJAjKJ0Ga9AOCoQPHyExBTj79zI9MC+kMNAW5XAAUQ4CSYEkI4PMcw6hmQOyJoDtk0 8YEdNU0BBuyUzRT2rQ56UAgOcAB2uvbBEnoQAcqgnQlXyMIWuvCFMIyhKoIAADs= --_004_F15941D3C8A2D54D92B341C20CACDF2311976FECC9exchange_-- From rto@globalscape.com Mon Jan 17 08:40:41 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974663A6BFC for ; Mon, 17 Jan 2011 08:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf9Q1VTxl319 for ; Mon, 17 Jan 2011 08:40:40 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id 7829C3A6B94 for ; Mon, 17 Jan 2011 08:40:40 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Mon, 17 Jan 2011 10:43:15 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Mon, 17 Jan 2011 10:43:10 -0600 Thread-Topic: draft-ietf-ftpext2-ftp64-00 translation scenario Thread-Index: Acu2ZZ/c55xqKk71TX2R++NZHeH5cw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ftpext] draft-ietf-ftpext2-ftp64-00 translation scenario X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:40:41 -0000 This draft makes the case for how an IPv6 FTP client should behave when pro= cessing an IPv4 FTP Server PASV/PORT reply when going from an IPv6 network = through a translation device.=20 In general I'm in favor of "client intelligence"*, and I don't see that it = explicitly violates RFC959 in terms of handling the PASV response, although= it does so implicitly since the client should be using the IP and port pro= vided in the server reply.=20 My point of contention is this: Why an RFC at all? Unless I'm mistaken, tra= nslation, such as NAT-PT, BIS, BIA, etc. has been moved to experimental sta= tus, as translation should be considered a "last resort" when other IPv6 tr= ansition options are unavailable (dual stack, tunneling, etc.).=20 ~~~ *Clients should do this today in an IPv4 world if for example a PASV reply = contains network address prefix, e.g. 192.168.0.0/16, which can happen if u= sing encrypted communications and going though NAT and the server hasn't co= nfigured the "external" facing IP (And since the session is encrypted, NAT = can't see the address to change it). The client should identify this (and s= imilar) wrong IPs and reuse the control connection's IP. Robert Oslin Director of Product Management Tel: 1 (210) 293-7902 Fax: 1 (210) 690-8824 Send me large files securely www.globalscape.com =A0=A0=A0(NYSE Amex:GSB) *This communication, including attachments, is for the exclusive use of the= addressee and may contain proprietary, confidential or privileged informat= ion. If you are not the intended recipient, any use, copying, disclosure, d= issemination or distribution is strictly prohibited. If you are not the int= ended recipient, please notify the sender immediately by return email and d= elete this communication and destroy all copies. From sob@nvnet.cz Mon Jan 17 09:56:01 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A46028C1E3 for ; Mon, 17 Jan 2011 09:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_CZ=0.445, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfkqArUy5mWf for ; Mon, 17 Jan 2011 09:56:01 -0800 (PST) Received: from mail.nvnet.cz (mail.nvnet.cz [IPv6:2002:d5d3:2ff6:80::3]) by core3.amsl.com (Postfix) with ESMTP id 2F89028C1A2 for ; Mon, 17 Jan 2011 09:55:59 -0800 (PST) X-AuthUser: sob@nvnet.cz Received: from Sob-PC.nvnet.cz ([213.211.47.246]:56522) by mail.nvnet.cz with [XMail 1.25 ESMTP Server] id for from ; Mon, 17 Jan 2011 18:58:32 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Jan 2011 18:58:12 +0100 To: "ftpext@ietf.org" From: Sob In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20110117175600.2F89028C1A2@core3.amsl.com> Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:56:01 -0000 At 17:04 17.1.2011, Robert Oslin wrote: >I believe it would make life easier on developers and speed the >adoption of your RFC if you considered changing the following: > >1. Keep the command XCRC ... >2. Keep the default hash CRC32 ... You would have to keep one more thing, "250 " as default (or only) reply format, otherwise old clients with knowledge of only the old XCRC wouldn't know what to do with it. So you can either: a) scratch all new reply format ideas and stick with the old one; after all, it shouldn't be that hard for client to remember what it asked for (filename, range, hash type) b) force new clients to support two completely different reply formats, otherwise they wouldn't understand old servers and the "instant success" would not happen; again, it's probably doable, developers are clever people and the two formats should be different enough to get properly recognized But essentially it would still be two different commands, only with the same name, no real advantage. Old client wouldn't benefit from new server and the other way around. -- From rto@globalscape.com Tue Jan 18 06:37:32 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD34728C119 for ; Tue, 18 Jan 2011 06:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JxfKLKOTiLk for ; Tue, 18 Jan 2011 06:37:31 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id AAA4728C117 for ; Tue, 18 Jan 2011 06:37:31 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Tue, 18 Jan 2011 08:40:08 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Tue, 18 Jan 2011 08:40:05 -0600 Thread-Topic: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm Thread-Index: Acu2gYMhqyjOZJzlR9qBH5ePdgO7QAAm1byQ Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> In-Reply-To: <20110117175600.2F89028C1A2@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:37:32 -0000 I don't see why we need a reply that includes information the client alread= y knows (hash used, filename, etc.). Only the hash is needed, hence option = (a) below.=20 Again, I'm not insisting on XCRC over HASH and CRC32 over SHA-1 as the defa= ult algorithm; I'm simply make the case that doing so will ease the path fo= r adopting the new standard for most FTP server client/server vendors. Robert Oslin -----Original Message----- From: Sob [mailto:sob@nvnet.cz]=20 Sent: Monday, January 17, 2011 11:58 AM To: ftpext@ietf.org Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algo= rithm At 17:04 17.1.2011, Robert Oslin wrote: >I believe it would make life easier on developers and speed the=20 >adoption of your RFC if you considered changing the following: > >1. Keep the command XCRC ... >2. Keep the default hash CRC32 ... You would have to keep one more thing, "250 " as default (or=20 only) reply format, otherwise old clients with knowledge of only the=20 old XCRC wouldn't know what to do with it. So you can either: a) scratch all new reply format ideas and stick with the old one;=20 after all, it shouldn't be that hard for client to remember what it=20 asked for (filename, range, hash type) b) force new clients to support two completely different reply=20 formats, otherwise they wouldn't understand old servers and the=20 "instant success" would not happen; again, it's probably doable,=20 developers are clever people and the two formats should be different=20 enough to get properly recognized But essentially it would still be two different commands, only with=20 the same name, no real advantage. Old client wouldn't benefit from=20 new server and the other way around. -- From daniel@haxx.se Tue Jan 18 06:43:55 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625E628C140 for ; Tue, 18 Jan 2011 06:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhDcEqjeDHbg for ; Tue, 18 Jan 2011 06:43:54 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 932DA28C131 for ; Tue, 18 Jan 2011 06:43:44 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id p0IEkJQo009941; Tue, 18 Jan 2011 15:46:19 +0100 Date: Tue, 18 Jan 2011 15:46:19 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Robert Oslin In-Reply-To: Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:43:55 -0000 On Tue, 18 Jan 2011, Robert Oslin wrote: > Again, I'm not insisting on XCRC over HASH and CRC32 over SHA-1 as the > default algorithm; I'm simply make the case that doing so will ease the path > for adopting the new standard for most FTP server client/server vendors. Sure, if we want to standardize XCRC using CRC32 I personally think CRC32 is too weak for multi-gigabyte files. -- / daniel.haxx.se From rto@globalscape.com Tue Jan 18 07:49:32 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD25C3A7027 for ; Tue, 18 Jan 2011 07:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aHTv40UGIMD for ; Tue, 18 Jan 2011 07:49:31 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id 46AAA3A7005 for ; Tue, 18 Jan 2011 07:49:31 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Tue, 18 Jan 2011 09:52:08 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Tue, 18 Jan 2011 09:52:06 -0600 Thread-Topic: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm Thread-Index: Acu3HnjtSqH1wO6gQ8Sa0b3WVqCmugAABK+A Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:49:32 -0000 >> I personally think CRC32 is too weak for multi-gigabyte files. Do you mean that CRC32 is weak period? I don't see how file size would make= a difference other than the time needed to calculate the hash. One may arg= ue that the "weaker" the hash the faster it will compute, making it ideal f= or use with larger files (in order to mitigate the chance of client timeout= s). I know that I'm arguing from a losing position. If academics frown on MD5 t= hen how much more will they frown on CRC32? For enterprise level mission cr= itical transfers you want as close to zero chance of collisions, whether by= malicious intent or otherwise, and CRC32 is relatively weak in this regard= . However the current draft states:=20 "Implementations SHOULD NOT make any algorithm the default that is known to= be weaker than SHA-1. Support for any additional algorithms is OPTIONAL" SHA-1 at 153 MiB/Second is only marginally faster than SHA-256 at 111 MiB/S= econd while still being susceptible to collisions (http://en.wikipedia.org/= wiki/SHA-1). If performance is the goal then changing from SHA-1 to CRC32 a= s the default algorithm will result in 2X performance gain while remaining = just as susceptible to collisions. If security is the overriding goal then = SHA-256 should be the minimum recommended, with less (and more) secure algo= rithms optional. I.e. "Implementations SHOULD NOT make any algorithm the default that is kno= wn to be weaker than SHA-256. Support for any additional algorithms is OPTI= ONAL" I don't know how else to balance the need for performance (avoiding timeout= s) while minimizing the chance of collisions. CRC32 and MD5 are fast but co= llision prone. SHA-1 is slow and still collision prone. SHA-256 is slower b= ut almost zero chance for collisions. Note that performance will become les= s of a problem in future as CPU speeds increase. Sorry for the rant, but even the smallest decision can often result in huge= repercussions for vendors and users later on.=20 Robert Oslin -----Original Message----- From: Daniel Stenberg [mailto:daniel@haxx.se]=20 Sent: Tuesday, January 18, 2011 8:46 AM To: Robert Oslin Cc: ftpext@ietf.org Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algo= rithm On Tue, 18 Jan 2011, Robert Oslin wrote: > Again, I'm not insisting on XCRC over HASH and CRC32 over SHA-1 as the=20 > default algorithm; I'm simply make the case that doing so will ease the p= ath=20 > for adopting the new standard for most FTP server client/server vendors. Sure, if we want to standardize XCRC using CRC32 I personally think CRC32 is too weak for multi-gigabyte files. --=20 / daniel.haxx.se From daniel@haxx.se Tue Jan 18 07:58:40 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F7D28C1AA for ; Tue, 18 Jan 2011 07:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeizKleQI2dt for ; Tue, 18 Jan 2011 07:58:39 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id F1EC628C102 for ; Tue, 18 Jan 2011 07:58:38 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id p0IG1EQC030449; Tue, 18 Jan 2011 17:01:14 +0100 Date: Tue, 18 Jan 2011 17:01:14 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Robert Oslin In-Reply-To: Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:58:40 -0000 On Tue, 18 Jan 2011, Robert Oslin wrote: >>> I personally think CRC32 is too weak for multi-gigabyte files. > > Do you mean that CRC32 is weak period? CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets weaker the more data to try to check with it. Having a CRC32 field for a sufficiently small amount of data will be fine IMO - but that's not what we design for here. > One may argue that the "weaker" the hash the faster it will compute, making > it ideal for use with larger files (in order to mitigate the chance of > client timeouts). Clients don't have to timeout. The server can easily send "213-" lines every 5-10 seconds or so while calculating the hash. Or is there a reason why not? -- / daniel.haxx.se From rto@globalscape.com Tue Jan 18 08:14:16 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB7D3A6F49 for ; Tue, 18 Jan 2011 08:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqkXuj0rgC5P for ; Tue, 18 Jan 2011 08:14:15 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id 68D593A7021 for ; Tue, 18 Jan 2011 08:14:15 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Tue, 18 Jan 2011 10:16:52 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Tue, 18 Jan 2011 10:16:51 -0600 Thread-Topic: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm Thread-Index: Acu3KO+aObgaEJCkSFKA/1nDXARWvAAAUL0g Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:14:16 -0000 I like the idea of an intermittent 213 reply that would effectively ask the= client to hang in there (maybe reset its timeout counter, perhaps with a c= lient defined hard limit to the number of resets in order to prevent malici= ous use). This seems in accord with RFC959 section 5.4: Certain commands require a se= cond reply for which the user should also wait. These replies may, for exa= mple, report on the progress or completion of file transfer or the closing = of the data connection. They are secondary replies to file transfer comman= ds. Anthony, could a provision be made such that a server MAY return a 213 repl= y every N seconds (5, 15, other) for long running hash operations? I think = that would be especially useful if SHA-256 ends up being the default recomm= ended and implemented hash algorithm. Alternatively client logic could be made to auto-extend the internal timeou= t when making a hash request for a large file. The draft could recommend ei= ther/or approach. Robert Oslin -----Original Message----- From: Daniel Stenberg [mailto:daniel@haxx.se]=20 Sent: Tuesday, January 18, 2011 10:01 AM To: Robert Oslin Cc: ftpext@ietf.org Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algo= rithm On Tue, 18 Jan 2011, Robert Oslin wrote: >>> I personally think CRC32 is too weak for multi-gigabyte files. > > Do you mean that CRC32 is weak period? CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets wea= ker=20 the more data to try to check with it. Having a CRC32 field for a sufficien= tly=20 small amount of data will be fine IMO - but that's not what we design for=20 here. > One may argue that the "weaker" the hash the faster it will compute, maki= ng=20 > it ideal for use with larger files (in order to mitigate the chance of=20 > client timeouts). Clients don't have to timeout. The server can easily send "213-" lines ever= y=20 5-10 seconds or so while calculating the hash. Or is there a reason why not= ? --=20 / daniel.haxx.se From sob@nvnet.cz Tue Jan 18 08:18:51 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D774E3A7021 for ; Tue, 18 Jan 2011 08:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_CZ=0.445, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUIJ15zGRJp0 for ; Tue, 18 Jan 2011 08:18:51 -0800 (PST) Received: from mail.nvnet.cz (mail.nvnet.cz [IPv6:2002:d5d3:2ff6:80::3]) by core3.amsl.com (Postfix) with ESMTP id 609B53A7036 for ; Tue, 18 Jan 2011 08:18:50 -0800 (PST) X-AuthUser: sob@nvnet.cz Received: from Sob-PC.nvnet.cz ([213.211.47.246]:53940) by mail.nvnet.cz with [XMail 1.25 ESMTP Server] id for from ; Tue, 18 Jan 2011 17:21:24 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Jan 2011 17:21:01 +0100 To: "ftpext@ietf.org" From: Sob In-Reply-To: References: <20110117175600.2F89028C1A2@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20110118161850.609B53A7036@core3.amsl.com> Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:18:51 -0000 At 15:40 18.1.2011, Robert Oslin wrote: >I don't see why we need a reply that includes information the client >already knows (hash used, filename, etc.). Only the hash is needed, >hence option (a) below. I have no strong opinion on this. While bare hash should be enough, including additional info might be good for something. >Again, I'm not insisting on XCRC over HASH and CRC32 over SHA-1 as >the default algorithm; I'm simply make the case that doing so will >ease the path for adopting the new standard for most FTP server >client/server vendors. Sure, "new, improved and backward compatible version of good old trusted XCRC command" sounds better than "unknown new HASH command". On the other hand, if someone advertises support for XCRC and it turns out that it means only very small subset of the specification (i.e. old XCRC), it wouldn't be so great. And it shows another problem on the horizon, what about FEAT? What's the correct line for current XCRC anyway? I saw: XCRC filename;start;end XCRC "filename" SP EP Even others maybe? Whichever we choose, we instantly get millions of servers violation the specification. Unless the XCRC line for FEAT is defined as "XCRC". When you think about it, new and independent HASH command is not such bad idea. -- From Richard.Koenning@ts.fujitsu.com Tue Jan 18 11:12:20 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0AD3A7030 for ; Tue, 18 Jan 2011 11:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWhfonw2xDOz for ; Tue, 18 Jan 2011 11:12:19 -0800 (PST) Received: from dgate10.ts.fujitsu.com (dgate10.ts.fujitsu.com [80.70.172.49]) by core3.amsl.com (Postfix) with ESMTP id 07E5C3A7023 for ; Tue, 18 Jan 2011 11:12:18 -0800 (PST) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=bGHfJSCm8yQvMrHZTrXH7Ooml5bDw7IMsjY7l8d2vKLpPp/3Eme54usp tHJc6a3DdmDQ5Byh5wZZyQjpkhJK32DBZ9gemz6lPeEg7ANifTBB9EulO uqCFmTMAydAL+6WnxN9WGn3qebELCO1yN/rGo0MUkrDZekl/KTz+St4ZO eBWM3z0By/fH0Ztky5j/eRE4MtGIXdM9b/OAwakGpTckrhP8v0QOHhXo+ T+zhd52VVWo4w76TdqZ3sxXtchJcG; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1295378097; x=1326914097; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4D35E6AE.7040108@ts.fujitsu.com>|Date:=20 Tue,=2018=20Jan=202011=2020:14:54=20+0100|From:=20Richard =20Koenning=20|Reply-To: =20=20Richard.Koenning@ts.fujitsu.com|MIME-Version:=201.0 |To:=20"ftpext@ietf.org"=20|Subject:=20R e:=20[ftpext]=20draft-ietf-ftpext2-hash=20command=20name =20and=20default=20algorithm|References:=20=09<20110117175600 .2F89028C1A2@core3.amsl.com>=09=09=09=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quo ted-printable; bh=gdb/1BspEe63/S4OM6tLzCQBvbx8+uTuCPIdlm0985E=; b=GMCbSOL9eRcz4oBjrHr0ZqST0NCN7pIhVRqYEaPMRMpFoyqb1VIlbRzP m/PYKMdXX/gP5IgKvVaG8Eddj7MKai5NZQK5y7eVasmx2pGpj9kOUG+8P fv9p+oFLNMemygePjy3yQCB4dqQeO26JE20q/Bk/Hr6e1RZVVvV3eMbgQ WWLwDsRVnFv9QA8ZBxrmqvUPJrwRzXAfSWjq3/qJ9SyuRN4ElGDKXjkme B7CfS2NnkAoMA4YV2ErckOqZTMcmp; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.60,339,1291590000"; d="scan'208";a="66360206" Received: from abgdgate30u.abg.fsc.net ([172.25.138.66]) by dgate10u.abg.fsc.net with ESMTP; 18 Jan 2011 20:14:55 +0100 X-IronPort-AV: E=Sophos;i="4.60,339,1291590000"; d="scan'208";a="107123086" Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate30u.abg.fsc.net with ESMTP; 18 Jan 2011 20:14:55 +0100 Message-ID: <4D35E6AE.7040108@ts.fujitsu.com> Date: Tue, 18 Jan 2011 20:14:54 +0100 From: Richard Koenning Organization: Fujitsu Technology Solutions GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, de-nds, en, en-US, it MIME-Version: 1.0 To: "ftpext@ietf.org" References: <20110117175600.2F89028C1A2@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Richard.Koenning@ts.fujitsu.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:12:20 -0000 Daniel Stenberg wrote: > On Tue, 18 Jan 2011, Robert Oslin wrote: >=20 >>>>I personally think CRC32 is too weak for multi-gigabyte files. >> >>Do you mean that CRC32 is weak period? >=20 > CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets= weaker=20 > the more data to try to check with it. Having a CRC32 field for a suffi= ciently=20 > small amount of data will be fine IMO - but that's not what we design f= or=20 > here. From the draft it is still unclear to me whether the hash shall be used = only for detecting "normal" transmission problems or also for detecting=20 active attacks on the data channel. For the latter CRC32 is out of discussion not only for the size of the=20 hash value but for its linear properties: it is even easy to change the=20 data while keeping the CRC unchanged. Regarding MD5: Since long time cryptologists warn against using MD5 for=20 new protocols/applications. As an application of this policy there are=20 no newer TLS cipher suites using MD5. Regarding SHA1: Despite showing some weakness too it is imho still in=20 wide usage e.g. in the TLS area. On the other hand the search for new=20 long-term hash functions is still ongoing=20 (http://csrc.nist.gov/groups/ST/hash/timeline.html). Therefore it seems=20 to me still acceptable to use SHA1 as default hash function. When the hash function is only used for detecting transmission errors=20 than the collision probability is one of the main points, this=20 probability is approximately the inverse of the square root of the hash=20 value space. So with CRC32 one has to expect collisions already with a=20 set of some ten thousand files. With MD5 the corresponding number has 19 = figures, which probably suffices already for most applications. --=20 Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH From anthonybryan@gmail.com Wed Jan 19 01:42:22 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CEA3A6FB5 for ; Wed, 19 Jan 2011 01:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtR+Zia-x6Gl for ; Wed, 19 Jan 2011 01:42:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 988633A7031 for ; Wed, 19 Jan 2011 01:42:19 -0800 (PST) Received: by eyd10 with SMTP id 10so302789eyd.31 for ; Wed, 19 Jan 2011 01:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QHYfGRS0Jwbq8K+xplPewnQdUMPYfJXHq8712LolylM=; b=WE0e6DwDyRNfyDtpm/lQA6MQmNRQAjs2SrV5d2sYr0lyFE5WgvqvqTcBMK04wM6Tsp u+qzea+m/KkLPbPT/3jH+yi1CVXaZxjbD5T9M0b5994V1fO3l3ZkgM0bhZyKU2r6Q3UX RffNxbNMx6EaHWik+/CBaRAm1j61TlTDnRhHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RF+vP9TRiOPjHjMYKJOX1xCJYmTsi/u3e/6oQxfb4rCWpbhjuhOWqegytE1KnrjQcF 74fU5b9EQVz8oh0SMn6IJHLyQSGyugsdk57yjVDqC0Cfz7EX/f7u09EYebOOaYwN0n7n JXhwkI22nIBTJw5qTRwID/8zmhTikqXfmOvbA= MIME-Version: 1.0 Received: by 10.213.28.14 with SMTP id k14mr698780ebc.24.1295430298024; Wed, 19 Jan 2011 01:44:58 -0800 (PST) Received: by 10.213.9.208 with HTTP; Wed, 19 Jan 2011 01:44:57 -0800 (PST) In-Reply-To: References: <20110117175600.2F89028C1A2@core3.amsl.com> Date: Wed, 19 Jan 2011 04:44:57 -0500 Message-ID: From: Anthony Bryan To: Robert Oslin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 09:42:22 -0000 On Tue, Jan 18, 2011 at 11:16 AM, Robert Oslin wrote: > I like the idea of an intermittent 213 reply that would effectively ask t= he client to hang in there (maybe reset its timeout counter, perhaps with a= client defined hard limit to the number of resets in order to prevent mali= cious use). > > This seems in accord with RFC959 section 5.4: Certain commands require a = second reply for which the user should also wait. =A0These replies may, for= example, report on the progress or completion of file transfer or the clos= ing of the data connection. =A0They are secondary replies to file transfer = commands. > > Anthony, could a provision be made such that a server MAY return a 213 re= ply every N seconds (5, 15, other) for long running hash operations? I thin= k that would be especially useful if SHA-256 ends up being the default reco= mmended and implemented hash algorithm. I think we can do anything that is internally consistent within the FTP universe and seems logical for the published FTP RFCs. :) > Alternatively client logic could be made to auto-extend the internal time= out when making a hash request for a large file. The draft could recommend = either/or approach. > > Robert Oslin > > > > > -----Original Message----- > From: Daniel Stenberg [mailto:daniel@haxx.se] > Sent: Tuesday, January 18, 2011 10:01 AM > To: Robert Oslin > Cc: ftpext@ietf.org > Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default al= gorithm > > On Tue, 18 Jan 2011, Robert Oslin wrote: > >>>> I personally think CRC32 is too weak for multi-gigabyte files. >> >> Do you mean that CRC32 is weak period? > > CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets w= eaker > the more data to try to check with it. Having a CRC32 field for a suffici= ently > small amount of data will be fine IMO - but that's not what we design for > here. > >> One may argue that the "weaker" the hash the faster it will compute, mak= ing >> it ideal for use with larger files (in order to mitigate the chance of >> client timeouts). > > Clients don't have to timeout. The server can easily send "213-" lines ev= ery > 5-10 seconds or so while calculating the hash. Or is there a reason why n= ot? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From daniel@haxx.se Wed Jan 19 02:13:43 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E4B3A6FC2 for ; Wed, 19 Jan 2011 02:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-GJG3h8w9My for ; Wed, 19 Jan 2011 02:13:42 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id D015F3A6FB5 for ; Wed, 19 Jan 2011 02:13:41 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id p0JAGG6m030276; Wed, 19 Jan 2011 11:16:16 +0100 Date: Wed, 19 Jan 2011 11:16:16 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Anthony Bryan In-Reply-To: Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" , Robert Oslin Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 10:13:43 -0000 On Wed, 19 Jan 2011, Anthony Bryan wrote: >> Anthony, could a provision be made such that a server MAY return a 213 >> reply every N seconds (5, 15, other) for long running hash operations? I >> think that would be especially useful if SHA-256 ends up being the default >> recommended and implemented hash algorithm. > > I think we can do anything that is internally consistent within the FTP > universe and seems logical for the published FTP RFCs. :) Right. I was only suggesting a "213-" response line, which isn't the final line of a 213 so I don't think we'd have to write anything in particular to allow a server to do that. It would be following standard FTP behavior. We could of course still add something in the spec to make it more obvious that this might be a good idea for servers to do. -- / daniel.haxx.se From rto@globalscape.com Wed Jan 19 06:17:34 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037EC3A713D for ; Wed, 19 Jan 2011 06:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7BT0b9NpQUF for ; Wed, 19 Jan 2011 06:17:32 -0800 (PST) Received: from webmail.globalscape.com (exchange.globalscape.com [208.89.186.61]) by core3.amsl.com (Postfix) with ESMTP id E8A193A7139 for ; Wed, 19 Jan 2011 06:17:31 -0800 (PST) Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange ([127.0.0.1]) with mapi; Wed, 19 Jan 2011 08:20:11 -0600 From: Robert Oslin To: "ftpext@ietf.org" Date: Wed, 19 Jan 2011 08:19:54 -0600 Thread-Topic: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm Thread-Index: Acu3weqY+pNcBnWMQ7ywBOrGhi5l+wAIdyuA Message-ID: References: <20110117175600.2F89028C1A2@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:17:34 -0000 Correct. I meant "SHOULD" return an intermediate (213) reply for long-runni= ng... -----Original Message----- From: Daniel Stenberg [mailto:daniel@haxx.se]=20 Sent: Wednesday, January 19, 2011 4:16 AM To: Anthony Bryan Cc: Robert Oslin; ftpext@ietf.org Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algo= rithm On Wed, 19 Jan 2011, Anthony Bryan wrote: >> Anthony, could a provision be made such that a server MAY return a 213=20 >> reply every N seconds (5, 15, other) for long running hash operations? I= =20 >> think that would be especially useful if SHA-256 ends up being the defau= lt=20 >> recommended and implemented hash algorithm. > > I think we can do anything that is internally consistent within the FTP=20 > universe and seems logical for the published FTP RFCs. :) Right. I was only suggesting a "213-" response line, which isn't the final= =20 line of a 213 so I don't think we'd have to write anything in particular to= =20 allow a server to do that. It would be following standard FTP behavior. We could of course still add something in the spec to make it more obvious= =20 that this might be a good idea for servers to do. --=20 / daniel.haxx.se From tony@att.com Thu Jan 20 11:11:27 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBB33A67CF for ; Thu, 20 Jan 2011 11:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi+wLYMqmbPT for ; Thu, 20 Jan 2011 11:11:26 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id D51173A67B7 for ; Thu, 20 Jan 2011 11:11:26 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-9.tower-129.messagelabs.com!1295550849!48789927!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 1300 invoked from network); 20 Jan 2011 19:14:09 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jan 2011 19:14:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0KJEUg5029971 for ; Thu, 20 Jan 2011 14:14:30 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0KJENiu029811 for ; Thu, 20 Jan 2011 14:14:24 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0KJE1EJ003664 for ; Thu, 20 Jan 2011 14:14:01 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0KJDsEr003419 for ; Thu, 20 Jan 2011 14:13:54 -0500 Received: from [135.70.213.81] (vpn-135-70-213-81.vpn.east.att.com[135.70.213.81]) by maillennium.att.com (mailgw1) with ESMTP id <20110120191354gw1004lko0e> (Authid: tony); Thu, 20 Jan 2011 19:13:54 +0000 X-Originating-IP: [135.70.213.81] Message-ID: <4D388971.5070608@att.com> Date: Thu, 20 Jan 2011 14:13:53 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] Subject: WGLC starting now for draft-ietf-ftpext2-hosts-01 (File Transfer Protocol HOST Command for Virtual Hosts) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 19:11:27 -0000 Working Group Last Call for draft-ietf-ftpext2-hosts-01 (File Transfer Protocol HOST Command for Virtual Hosts) is now in effect, lasting for two weeks and will end on Friday, February 4th, 2011. https://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/ or http://tools.ietf.org/html/draft-ietf-ftpext2-hosts Please review it and submit comments by then. A new revision will be produced (if needed) and then we will submit it to the IESG for IETF-wide last call and evaluation. Anthony Bryan and Tony Hansen co-chairs, FTPext2 WG From daniel@haxx.se Tue Jan 25 13:02:49 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004473A689E for ; Tue, 25 Jan 2011 13:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqFUDdZBOiAS for ; Tue, 25 Jan 2011 13:02:47 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id E820E3A6838 for ; Tue, 25 Jan 2011 13:02:46 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id p0PL5eiZ011442; Tue, 25 Jan 2011 22:05:41 +0100 Date: Tue, 25 Jan 2011 22:05:40 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mat Berchtold In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" , Robert Oslin Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:02:49 -0000 On Mon, 17 Jan 2011, Mat Berchtold wrote: > I understand that RANG is a replacement for REST. Using the newly introduced > command now to extend other commands as HASH might not be what RANG has been > originally intended for. It actually is. We just wanted to start slowly and gently and specified it for RETR only to start with, as that is certainly a major use case. > One concern is how to announce the feature in the FEAT reply. Right now the > RANG draft proposed to use RANG STREAM. Assuming that the server now > supports RANG for HASH as well, how does the FEAT line look like? RANG > STREAM;HASH? What if another command that might be introduced in the future > wants to use the RANG concept as well? I think we shouldn't try to look too far ahead and guess what the future might and might not bring for this. As RANG and HASH aren't even yet very far taken, I suggest we simply say that FEAT resports RANG when the server supports it, and then it expect that to mean for the commands we include in the RANG spec: RETR and HASH so far. > The use of multiple commands for one function makes it more complex than it > needs to be. (I assume you here talk about having to do both RANG and HASH to get a ranged hash output.) Perhaps, but in my view RANG goes very well in hand with how RETR works already and that's a long established concept in FTP so I don't think this is a stretch. Also, it could be seen as odd to have multiple commands allow a range instead of having a single command that sets a range... > I think partial hashes should be a MUST and not optional. Hence there is no > need for a special FEAT response. I quite agree. Also, since HASH allows a server to reject to respond with a hash at will, it can select to do that on ranges if it thinks that is cool. -- / daniel.haxx.se From daniel@haxx.se Tue Jan 25 13:05:25 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7AA3A6838 for ; Tue, 25 Jan 2011 13:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fNNtoKFC6gg for ; Tue, 25 Jan 2011 13:05:24 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 26BA23A689E for ; Tue, 25 Jan 2011 13:05:23 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id p0PL8Njo012205; Tue, 25 Jan 2011 22:08:23 +0100 Date: Tue, 25 Jan 2011 22:08:23 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mat Berchtold In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" , Robert Oslin Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:05:25 -0000 On Tue, 25 Jan 2011, Daniel Stenberg wrote: > Perhaps, but in my view RANG goes very well in hand with how RETR works > already and that's a long established concept in FTP so I don't think this is > a stretch. Ouch, I meant that to be s/RETR/REST ... -- / daniel.haxx.se From tatsuhiro.t@gmail.com Thu Jan 27 04:08:25 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D41328C133 for ; Thu, 27 Jan 2011 04:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddAcstZGsajY for ; Thu, 27 Jan 2011 04:08:20 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E0B7228C13E for ; Thu, 27 Jan 2011 04:08:19 -0800 (PST) Received: by fxm9 with SMTP id 9so2247490fxm.31 for ; Thu, 27 Jan 2011 04:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=FZT8T9vQs6pAMfDiZ7STmsW3eoyCuts7BAiO5WBHvXk=; b=v6CsFuCUtNSxRWrnEwPcV29EBQKDpKgy0CAy5u640pr8ym5U2BHjH5ysyEPdfQJ/c9 oREjMTo4PbL76uSrIzdBMOjTwY3sZQhHoeKB+HDsPYJbGnF68kkWGhJ+VaniPE1yMDAU THi1j7a+f2dg8hRQbzkKnrOnU7maRw4HY4UG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ssi+rks2gp+CBpUTFVlIaCS5uiKCxCJB85PhQG9baQTzWag2BJKWiXzIOUIpLav5Wk 68PGr0ukrtRu0s41SEaPwPkVZtefKMs4xtCmKQB2oUZ8L6W3ef96f4xg2HpY3XhrDZj+ /lxpJQhdA59pqA+kCIdEo1chxouA+IwZv0IM0= Received: by 10.223.97.8 with SMTP id j8mr806426fan.141.1296130281412; Thu, 27 Jan 2011 04:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.78.194 with HTTP; Thu, 27 Jan 2011 04:11:01 -0800 (PST) From: Tatsuhiro Tsujikawa Date: Thu, 27 Jan 2011 21:11:01 +0900 Message-ID: To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] draft-bryan-ftp-range-01 - reset X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:08:25 -0000 Hi, draft-bryan-ftp-range-01 changed the way to reset the range command previously issued. 4. The RANGe Command (RANG) To reset the range command, "RANG 1 0" should be issued. Invalid RANG requests where 'start-point' is larger than 'end-point' automatically reset the byte selection to the default, which is the whole file. But currently, it states that server should respond with a 5yz reply with "RANG 1 0". 4.3. RANG Command Errors ... The server-PI SHOULD reply with a 5yz reply if the specified end point is larger than the actual file or the end point is before the start point. I think "RANG 1 0" is a recommended way of reseting range, I think server must reply with 200 reply. So I propose to add following sentence to the above paragraph: But the server-PI MUST reply with a 200 reply if "RANG 1 0" is issued by client-PI because it is a valid way of reseting range. Best regards, Tatsuhiro Tsujikawa From anthonybryan@gmail.com Thu Jan 27 20:51:46 2011 Return-Path: X-Original-To: ftpext@core3.amsl.com Delivered-To: ftpext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0CC3A6BDF for ; Thu, 27 Jan 2011 20:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS4+oW2HhDv7 for ; Thu, 27 Jan 2011 20:51:45 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 031BD3A6BCB for ; Thu, 27 Jan 2011 20:51:38 -0800 (PST) Received: by ewy8 with SMTP id 8so1430033ewy.31 for ; Thu, 27 Jan 2011 20:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f72Xyz3i4rWZvvx3Bm/43jKZDsF8u7pE0r+dzC4H8zo=; b=kr1qShlgpiDF5CNNlrh2hTcBN4qP4PVbyJVVFjISriVBzawBFRVRJb6um9NXCtCk+e euAdZsRDQ4dDubR5uO8gmzByAQhg3d606ipHOyI3wets+m/O9WEpKWmJqihSSFUONUb1 12EZVWVknl62ikEc+ez/QCsExb1qtfOJjBY+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rue6NxXHu46RFHNO+kGiHK8ZcC4VJ4UoSytp8CgITaXnLFkzgIlh9APeJZ4VHBa8VH tmMZoKeMZTWrven15DKmxg1jpK31QelA1k/G23PQv0de4KIza2d0kxgbB7zbh8FuQZqs KkFt9J97unb+iM+wdTJH5X/JFXiqK42JQWPbk= MIME-Version: 1.0 Received: by 10.213.104.143 with SMTP id p15mr4135755ebo.92.1296190483271; Thu, 27 Jan 2011 20:54:43 -0800 (PST) Received: by 10.213.112.209 with HTTP; Thu, 27 Jan 2011 20:54:43 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Jan 2011 23:54:43 -0500 Message-ID: From: Anthony Bryan To: Tatsuhiro Tsujikawa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] draft-bryan-ftp-range-01 - reset X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 04:51:47 -0000 On Thu, Jan 27, 2011 at 7:11 AM, Tatsuhiro Tsujikawa wrote: > Hi, > > draft-bryan-ftp-range-01 changed the way to reset the range command > previously issued. > > 4. =A0The RANGe Command (RANG) > > =A0To reset the range command, "RANG 1 0" should be issued. =A0Invalid > =A0 RANG requests where 'start-point' is larger than 'end-point' > =A0 automatically reset the byte selection to the default, which is the > =A0 whole file. > > But currently, it states that server should respond with a 5yz reply > with "RANG 1 0". > > 4.3. =A0RANG Command Errors > =A0 ... > =A0 The server-PI SHOULD reply with a 5yz reply if the specified end > =A0 point is larger than the actual file or the end point is before the > =A0 start point. > > I think "RANG 1 0" is a recommended way of reseting range, I think server= must > reply with 200 reply. So I propose to add following sentence to the > above paragraph: > > =A0 But the server-PI MUST reply with a 200 reply if "RANG 1 0" is issued > =A0 by client-PI because it is a valid way of reseting range. yes sir, good catch. I added the text: The server-PI MUST reply with a 350 reply if "RANG 1 0" is issued by client-PI because it is a valid way of resetting range. (The range would also be reset if the session is reinitialized with REIN but this terminates the user and resets all parameters). and also a short section 5. RANG Command Use with Other Commands This specification defines the use of RANG in a certain way. Other commands could decide to use RANG in a similar way, to select a byte range, and their specification would define how they operate with RANG. The HASH command [draft-ietf-ftpext2-hash] uses RANG to select a byte range for partial file hashing. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads

   (NYSE Amex:GSB)