From anthonybryan@gmail.com Fri Jun 11 09:24:12 2010 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 41B4A3A68DA for ; Fri, 11 Jun 2010 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 L0RLH-tscbFQ for ; Fri, 11 Jun 2010 09:24:10 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 424323A6933 for ; Fri, 11 Jun 2010 09:24:07 -0700 (PDT) Received: by iwn42 with SMTP id 42so1336574iwn.31 for ; Fri, 11 Jun 2010 09:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=pvj5kg6LOLs4sFYg340h7FBOX27WC+1SRi3OSBtUAQo=; b=gnvFAYf3vMtoMayx1rvVhpFnQFwVTZFCvH5WKc4Eddd3yPpHv/JHdswh+W6FIPF2ge JcB1smWq4x9eTu7Grvohq9Akb3IchlTgxokDL1viuXmHu/1r8Kr5HTw4qt0uF5+utR5a H2trmXimXqO16WdQxmIOSPNV6oq2t+V9J+d1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UNqCEekcu2I8/fs4vRcDJ+n5ozBMa9/8+UYVf+ZJlJqeALiqR7GKEGezTUr1R2uHfh fkh9n1p/vtj1SC0jTsxDbo2zSOBeF6/DBCX7MmRvZX2LZrtmISiJVI9mV/madpdkQQpo uBU3u2UCjBpwAooJ5F5nGmJBZlq0A1n0ipQjk= MIME-Version: 1.0 Received: by 10.231.140.69 with SMTP id h5mr2119788ibu.153.1276273446515; Fri, 11 Jun 2010 09:24:06 -0700 (PDT) Received: by 10.231.152.65 with HTTP; Fri, 11 Jun 2010 09:24:06 -0700 (PDT) Date: Fri, 11 Jun 2010 12:24:06 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] draft-bryan-ftp-hash 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, 11 Jun 2010 16:24:12 -0000 It's nice to see this new list for FTP extension discussion! We're working on an FTP HASH command: The File Transfer Protocol [RFC0959] does not offer any method to verify the integrity of a transferred file, nor can two files be compared against each other without actually transferring them first. Cryptographic hashes are a possible solution to this problem. In the past, several attempts have been made to add commands to obtain checksums and hashes, however none have been formally specified, leading to non-interoperability and confusion. To solve these issues, this document specifies a new FTP command to be used by clients to request cryptographic hashes of files. HTTP has a similar feature named Instance Digests [RFC3230] which allows a client to request the cryptographic hash of a file. We have a couple issues we'd like to discuss: Should HASH support partial file hashes, similar to the Content-MD5 HTTP Header? (Some of the non-standard hash commands allow this). Should the server response include the algorithm? i.e. "S> 213 SHA-256 xxxxxxxxxxxxxxx" -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From dwing@cisco.com Sat Jun 12 09:08:46 2010 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 18C9C3A6974 for ; Sat, 12 Jun 2010 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 v4OkLRo5c8Xd for ; Sat, 12 Jun 2010 09:08:45 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 278103A68E7 for ; Sat, 12 Jun 2010 09:08:42 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqANAPtNE0xAZnwN/2dsb2JhbACHY4EUiXeMFXGkeZlEhRoEg00 X-IronPort-AV: E=Sophos;i="4.53,408,1272844800"; d="scan'208";a="121015175" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2010 16:08:44 +0000 Received: from dwingwxp01 ([10.32.240.194]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5CG8hfc006539; Sat, 12 Jun 2010 16:08:44 GMT From: "Dan Wing" To: Date: Sat, 12 Jun 2010 09:08:40 -0700 Message-ID: <01e201cb0a49$86552b10$7844150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsKSTb69V8Z7cQbTM6G8YqOYTAVtw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: draft-ietf-behave-ftp64@tools.ietf.org, 'Behave Chairs' Subject: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03 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, 12 Jun 2010 16:08:46 -0000 FTPEXT2, BEHAVE has working group last called draft-ietf-behave-ftp64-03 and is soliciting reviews of the document. Please send reviews to behave@ietf.org or the authors at draft-ietf-behave-ftp64@tools.ietf.org. Abstract: The File Transfer Protocol has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers are IPv6-only while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document describes server, client and middlebox (if any) behavior that minimizes this problem. Thanks, -d From anthonybryan@gmail.com Sat Jun 12 22:02:31 2010 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 CD2AD3A6875 for ; Sat, 12 Jun 2010 22:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.816 X-Spam-Level: X-Spam-Status: No, score=0.816 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_50=0.001, SARE_PROLOSTOCK_SYM3=1.63] 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 SuE7WJ5fMx4O for ; Sat, 12 Jun 2010 22:02:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9F7ED3A686E for ; Sat, 12 Jun 2010 22:02:30 -0700 (PDT) Received: by gyh4 with SMTP id 4so1858323gyh.31 for ; Sat, 12 Jun 2010 22:02:31 -0700 (PDT) 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=YwvXQiELBqRzEGOCf9fq3ZV/zubBHSOxLyJ3pqJ/ERg=; b=hEvLQfeXkIAg41H5z7peQAap6+fNtysp1JzQABNbUp6rCWDP1Orhjm8FIR8kCXkdPV i0t2ulnE86ZP0eThc6MPMy51SY3hUNtby6AveB52UzCxYFLQcrZjYwolRQab9crd8hsd yoqGGBaQuRlcrAjR+rtBCBxL46+9k5KGLFvFs= 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=MLtuYbTPhAHvsj7S/koOZ0QBG7GXwluT5RBfAWZJIR+2d3jabs8OesMmV5Xko6Hc/h X9j14uXrAXuauQzO/d4gDsn7Lv36d5gLg7s0OSahFP/HKv0AWdGAULFW3AVq7GgZR9jm 2Z+5qw//LqTp4lLUG7p2shAMI+o3Q5ZlnalvY= MIME-Version: 1.0 Received: by 10.101.131.40 with SMTP id i40mr3543135ann.49.1276405350810; Sat, 12 Jun 2010 22:02:30 -0700 (PDT) Received: by 10.100.214.17 with HTTP; Sat, 12 Jun 2010 22:02:30 -0700 (PDT) In-Reply-To: <01e201cb0a49$86552b10$7844150a@cisco.com> References: <01e201cb0a49$86552b10$7844150a@cisco.com> Date: Sun, 13 Jun 2010 01:02:30 -0400 Message-ID: From: Anthony Bryan To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, Behave Chairs Subject: Re: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03 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: Sun, 13 Jun 2010 05:02:32 -0000 On Sat, Jun 12, 2010 at 12:08 PM, Dan Wing wrote: > FTPEXT2, > > BEHAVE has working group last called draft-ietf-behave-ftp64-03 and is > soliciting reviews of the document. =A0Please send reviews to behave@ietf= .org or > the authors at draft-ietf-behave-ftp64@tools.ietf.org. > > Abstract: > > =A0 The File Transfer Protocol has a very long history, and despite the > =A0 fact that today, other options exist to perform file transfers, FTP > =A0 is still in common use. =A0As such, it is important that in the > =A0 situation where some client computers are IPv6-only while many > =A0 servers are still IPv4-only and IPv6-to-IPv4 translators are used to > =A0 bridge that gap, FTP is made to work through these translators as > =A0 best it can. > > =A0 FTP has an active and a passive mode, both as original commands that > =A0 are IPv4-specific, and as extended, IP version agnostic commands. > =A0 The only FTP mode that works without changes through an IPv6-to-IPv4 > =A0 translator is extended passive. =A0However, many existing FTP servers > =A0 do not support this mode, and some clients do not ask for it. =A0This > =A0 document describes server, client and middlebox (if any) behavior > =A0 that minimizes this problem. Hi, Some suggestions for readability. The first time you use ALG, you want to be clear what it stands for. OLD Additionally, the document standardizes behavior for application layer gateway functionality to provide connectivity between unupdated servers and/or clients. NEW Additionally, the document standardizes behavior for application layer gateway (ALG) functionality to provide connectivity between unupdated servers and/or clients. The following sentence sounds weird. Should "so in EPRT translation is supported" be "so if EPRT translation is supported"? OLD However, in the case of EPRT translation, the ALG and translator functions need to be tightly coupled, so in EPRT translation is supported, it is assumed that the ALG and IPv6-to-IPv4 translation functions are integrated within a single device. OLD If the client issues the AUTH command the client is attempting to negotiate [RFC2228] security mechanisms which are likely to be incompatible with the FTP ALG function. NEW If the client issues the AUTH command, then the client is attempting to negotiate [RFC2228] security mechanisms which are likely to be incompatible with the FTP ALG function. OLD "Note that if multiple clients are using the IPv6-to-IPv4 to..." The IPv6-to-IPv4 what? OLD The main rationale for ignoring the IPv4 address in the 227 response, even if the client has IPv4 connectivity, most servers will only allow a data connection from the same client address as seen in the control channel connection, see [Bernstein]. NEW? The main rationale for ignoring the IPv4 address in the 227 response, even if the client has IPv4 connectivity, is that most servers will only allow a data connection from the same client address as seen in the control channel connection. (See [Bernstein]). --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Sun Jun 13 13:21:25 2010 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 720B23A6A5A for ; Sun, 13 Jun 2010 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.273 X-Spam-Level: X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_50=0.001] 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 w6k0gdgAeRS1 for ; Sun, 13 Jun 2010 13:21:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 573B03A6A57 for ; Sun, 13 Jun 2010 13:21:24 -0700 (PDT) Received: by iwn41 with SMTP id 41so473309iwn.31 for ; Sun, 13 Jun 2010 13:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=jq0vdfyhmTkhJ1SyG4n8DLSOc0KwMEhJPmH+MMZNlkU=; b=otxSpSxdXqyj+TpbCCsJtlFZ5E0/65wFuSFCNMSftVHhAGGjWmqw+46YziOpO03Jyr eL2DBCpIkn9rVAyn8mQvbr7ZIZ7/hfVkctZcEcPHF9Z25YWTZn7xt0y8q7TpP4JBchG3 4NhVFONdW2NrSnyrS4FiJwYWd4fylAQjGKqNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=s5lwcTf7juy9SbCT8uYiLA4UQmTBOg6v62DkUgsRSsg3TQxEMHNJDvArmCNWU5YAXM qhCwna/NpLsTTs1Pk5kSf44+8VOL0o/D+JUJAl6z1/qQQPweIm64n8mQeKy6gGSQmUzH HI0TnsJAKAwxErt7zuXn7D4NVMFYziauGPzLI= MIME-Version: 1.0 Received: by 10.231.148.73 with SMTP id o9mr5105817ibv.21.1276460484393; Sun, 13 Jun 2010 13:21:24 -0700 (PDT) Received: by 10.231.152.65 with HTTP; Sun, 13 Jun 2010 13:21:24 -0700 (PDT) Date: Sun, 13 Jun 2010 16:21:24 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] Expired FTP ID review: draft-twine-ftpmd5-00 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: Sun, 13 Jun 2010 20:21:25 -0000 I found out about this ID after working on draft-bryan-ftp-hash. I contacted the author and he said he did not plan to continue work on it, which stopped in 2002. The ideas are similar, a command to request the hash of a file, but it is tied to one algorithm (MD5) and there is another command (MMD5) to request the hashes of multiple files in a single command. My draft defines a HASH command which can be used to request any accepted algorithm (from an IANA registry name "Hash Function Textual Names"). draft-twine-ftpmd5-00 is one of at least ten non-standard FTP hash or checksum commands. It is supported by at least two servers: Apache FTP Server and Cross FTP Server. The fragmentation in support of all these different but similar commands led to my draft. I reference this draft in the Informative References section of mine. John Klensin suggested that draft-twine-ftpmd5-00 be marked as superseded by my draft. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From dwing@cisco.com Mon Jun 14 14:05:57 2010 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 6FA463A688E for ; Mon, 14 Jun 2010 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.741 X-Spam-Level: X-Spam-Status: No, score=-7.741 tagged_above=-999 required=5 tests=[AWL=-1.372, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, SARE_PROLOSTOCK_SYM3=1.63] 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 I827WPBzXc28 for ; Mon, 14 Jun 2010 14:05:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 034F23A69E3 for ; Mon, 14 Jun 2010 14:05:55 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMJAB42FkxAZnwM/2dsb2JhbACHY4EUlXVxpkWaFYUaBINN X-IronPort-AV: E=Sophos;i="4.53,416,1272844800"; d="scan'208";a="121655835" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2010 21:05:59 +0000 Received: from dwingwxp01 (sjc-vpn2-998.cisco.com [10.21.115.230]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5EL5wmE021469; Mon, 14 Jun 2010 21:05:58 GMT From: "Dan Wing" To: "'Anthony Bryan'" References: <01e201cb0a49$86552b10$7844150a@cisco.com> Date: Mon, 14 Jun 2010 14:05:57 -0700 Message-ID: <05f401cb0c05$63461c20$7844150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsKtaHLLutnsYb6Rpia6CvWpWKCEgBT7ykA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave Chairs' Subject: Re: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03 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, 14 Jun 2010 21:05:57 -0000 Thanks! -d =20 > -----Original Message----- > From: Anthony Bryan [mailto:anthonybryan@gmail.com]=20 > Sent: Saturday, June 12, 2010 10:03 PM > To: Dan Wing > Cc: ftpext@ietf.org; draft-ietf-behave-ftp64@tools.ietf.org;=20 > Behave Chairs > Subject: Re: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03 >=20 > On Sat, Jun 12, 2010 at 12:08 PM, Dan Wing wrote: > > FTPEXT2, > > > > BEHAVE has working group last called=20 > draft-ietf-behave-ftp64-03 and is > > soliciting reviews of the document. =A0Please send reviews to=20 > behave@ietf.org or > > the authors at draft-ietf-behave-ftp64@tools.ietf.org. > > > > Abstract: > > > > =A0 The File Transfer Protocol has a very long history, and=20 > despite the > > =A0 fact that today, other options exist to perform file=20 > transfers, FTP > > =A0 is still in common use. =A0As such, it is important that in the > > =A0 situation where some client computers are IPv6-only while many > > =A0 servers are still IPv4-only and IPv6-to-IPv4 translators=20 > are used to > > =A0 bridge that gap, FTP is made to work through these translators = as > > =A0 best it can. > > > > =A0 FTP has an active and a passive mode, both as original=20 > commands that > > =A0 are IPv4-specific, and as extended, IP version agnostic = commands. > > =A0 The only FTP mode that works without changes through an=20 > IPv6-to-IPv4 > > =A0 translator is extended passive. =A0However, many existing=20 > FTP servers > > =A0 do not support this mode, and some clients do not ask for=20 > it. =A0This > > =A0 document describes server, client and middlebox (if any) = behavior > > =A0 that minimizes this problem. >=20 > Hi, >=20 > Some suggestions for readability. >=20 > The first time you use ALG, you want to be clear what it stands for. >=20 > OLD > Additionally, the document standardizes behavior for application layer > gateway functionality to provide connectivity between unupdated > servers and/or clients. >=20 > NEW > Additionally, the document standardizes behavior for application layer > gateway (ALG) functionality to provide connectivity between unupdated > servers and/or clients. >=20 >=20 > The following sentence sounds weird. Should "so in EPRT translation is > supported" be "so if EPRT translation is supported"? > OLD > However, in the case of EPRT translation, the ALG and translator > functions need to be tightly coupled, so in EPRT translation is > supported, it is assumed that the ALG and IPv6-to-IPv4 translation > functions are integrated within a single device. >=20 >=20 > OLD > If the client issues the AUTH command the client is attempting to > negotiate [RFC2228] security mechanisms which are likely to be > incompatible with the FTP ALG function. >=20 > NEW > If the client issues the AUTH command, then the client is attempting > to negotiate [RFC2228] security mechanisms which are likely to be > incompatible with the FTP ALG function. >=20 >=20 > OLD > "Note that if multiple clients are using the IPv6-to-IPv4 to..." >=20 > The IPv6-to-IPv4 what? >=20 >=20 > OLD > The main rationale for ignoring the IPv4 address in the 227 response, > even if the client has IPv4 connectivity, most servers will only allow > a data connection from the same client address as seen in the control > channel connection, see [Bernstein]. >=20 > NEW? > The main rationale for ignoring the IPv4 address in the 227 response, > even if the client has IPv4 connectivity, is that most servers will > only allow a data connection from the same client address as seen in > the control channel connection. (See [Bernstein]). >=20 > --=20 > (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] > )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Mon Jun 21 13:04:17 2010 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 8552C28C126 for ; Mon, 21 Jun 2010 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_50=0.001] 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 Ggjmd7psvBTg for ; Mon, 21 Jun 2010 13:04:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C7E8A3A6AE9 for ; Mon, 21 Jun 2010 13:04:15 -0700 (PDT) Received: by iwn9 with SMTP id 9so838797iwn.31 for ; Mon, 21 Jun 2010 13:04:19 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=lA4a3j5oeaBkPgA2nmF/iDmu+pk5WO20JAQpqPlCor4=; b=wuoL+n+DRXOuRrBRkvNQt4tK/b4zROi+uhf/60YynP/SoqrF3noGcmOa9KYBgL4o6s IkLyKkYxfq8GSgap4vpapfILVlWtzOiE9RUrRWBekiUnwwiOBR8kktROuXcl8MlgeqRf Wl1wLnH+jw/NeCm/K2tc+pyTnmJyuw6vp6p4w= 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 :content-type:content-transfer-encoding; b=jndHPFb+azaJ4KkTvkbmIv3Gl2xxlqGyHjhDI++gQGsPOq2m2eOPWdxj2CQfV/MZEG JcBIXXA+Q+hqqiWOJQMWOikWzUiAwcNUINUaQEzUVKnk25RyzijTi9meM6pH5pFV2Y30 B7/v+PXssiXGYvU73qngMGJ6F+YCmQsxf2/qM= MIME-Version: 1.0 Received: by 10.231.207.155 with SMTP id fy27mr6393841ibb.177.1277150659157; Mon, 21 Jun 2010 13:04:19 -0700 (PDT) Received: by 10.231.152.65 with HTTP; Mon, 21 Jun 2010 13:04:19 -0700 (PDT) In-Reply-To: <4C1127A0.5090503@isode.com> References: <4C1127A0.5090503@isode.com> Date: Mon, 21 Jun 2010 16:04:19 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ftpext] Fwd: FTPEXT BOF 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, 21 Jun 2010 20:04:17 -0000 I haven't seen this here yet, & the IETF meeting in Maastricht is about a month away so I figured I'd post it. I won't be able to attend but I plan to help as much as I can otherwise. I'm more fitted to outreach or administrative type work. I've already reviewed 1 of the previous 20 or so abandoned drafts. can some of the implementers voice their opinion? I know at least one person was thinking of submitting a totally new draft..= . ---------- Forwarded message ---------- From: Alexey Melnikov Date: Thu, Jun 10, 2010 at 1:57 PM Subject: [apps-discuss] FTPEXT BOF To: Apps-Discuss@ietf.org Peter and I received a request to hold FTPEXT BOF in Maastricht. I am the sponsoring AD for it: BOF Chairs: Barry Leiba Length of session: 1 hour Goal: See if there is enough interest and energy to form a WG Draft Charter, Goals: Mailing list: =A0ftpext@ietf.org To subscribe: or Mailing list archive: Related Drafts: and (others might follow) _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -------------------- [Tentative] BOF Proposal: FTP Extensions, 2nd edition (ftpext2) Chair: TBD (see "Conditions" note at end) Application Area Directors: Alexey and Peter Description and Background The Standard File Transfer Protocol specification in RFC 959 has been updated several times with command extensions of one sort or another, including those based on the extension mechanism of RFCs 2389 (a complete list appears in RFC 5797 and the corresponding IANA registry). In the last several years, a series of additional Internet Drafts (listed below) have been posted and suggested for processing as individual submissions; of those, only draft-hethmon-mcmurray-ftp-hosts has made it to IETF Last Call although several others have been discussed extensively. A registry now exists for command extensions (RFC 5797). Those Internet-Drafts are: Active drafts: draft-bryan-ftp-hash draft-hethmon-mcmurray-ftp-hosts Expired individual submission drafts. This list is derived from a quick search of the I-D database. Some of them have been superceded by other work; others were abandoned long ago by the authors. Posting dates are listed from the index; expiration dates six months later. draft-bonachea-sftp-00 Protocol Negotiation Extensions to Secure FTP 1999-06-18 draft-casey-url-ftp-00 A FTP URL Format 1997-01-09 (presumably superceded by draft-hoffman-ftp-uri) draft-chin-dnftp-01 Distributed New File Transfer Protocol 2006-05-02 draft-dilip-ftpext-safe-transfer-00 Safe GET & Safe PUT options for FTP 2006-01-17 draft-fordh-ftp-ssl-firewall-07 FTP/TLS Friendly Firewalls 2005-10-21 draft-hoffman-ftp-uri-04 The ftp URI Scheme 2005-01-03 draft-klensin-ftp-typeu-00 FTP Extension for Internationalized Text 2008-07-27 draft-metz-spasv-00 Short Passive (SPASV) Command for FTP 1998-01-13 draft-mityok-macbin1-01 Adopt MacBinary II Mac File Encoding for FTP Transfers 1996-07-30 draft-peterson-streamlined-ftp-command-extensions-06 Streamlined FTP Command Extensions 2008-08-29 draft-preston-ftpext-deflate-03 Deflate transmission mode for FTP 2005-= 01-14 draft-rajeshs-ftpext-rec-arch-transfer-01 FTP Extensions for recursive and archived file transfers 2005-04-29 draft-rosenau-ftp-single-port-05 FTP EXTENSION ALLOWING IP FORWARDING (NATs) 2008-09-18 draft-saul-ftp-plus-00 FTP Plus 2000-08-29 draft-somers-ftp-mfxx-03 The 'MFMT', 'MFCT', and 'MFF' Command Extensions for FTP 2008-07-28 draft-stewart-ftp-client-mib-00 FTP Client MIB 1998-11-17 draft-twine-ftpmd5-00 The 'MD5' and 'MMD5' FTP Command Extensions 2002-= 05-14 The following additional drafts were work products of the old FTPEXT WG that do not appear to have been replaced by RFCs: draft-ietf-ftpext-data-connection-assurance-00 FTP Data Connection Assurance 2002-05-24 draft-ietf-ftpext-restart-00 REST Command and Extensions to FTP 1997-03= -21 draft-ietf-ftpext-utf-8-option-00 UTF-8 Option for FTP 2002-05-24 In addition, draft-ietf-behave-ftp64 may need additional review from an FTP-focused group. BOF Purpose/Charter This BOF has three purposes: (1) To triage the lists above and determine which of the drafts have been, or should be, permanently abandoned and which ones need further attention. It is expected that those who are interested in this work will go through that list and post opinions prior to the BOF session. Additional drafts may be added to the list if they were accidentally overlooked. (2) To identify additional areas in which FTP may be in need of extension. (3) To make a plan about how to proceed. Such a plan might be the formation of a WG, some FTP-specific directorate or review team for oversight of drafts related to FTP, or a conclusion that handling FTP drafts as uncoordinated individual submissions is appropriate. The BOF's purposes do not include a discussion of why FTP is obsolete and no one should be using it. Those who hold that position should hope that the BOF concludes that there is no interest in the IETF; if there is interest, work should proceed in some form if only to maximize interoperability with extensions that will be made anyway. The BOF leadership is expected to rule those out of order anyone who wants to argue that FTP should be abandoned or deprecated (without letting them get started if they have already taken that position on the obvious mailing lists). ----------------- Conditions: While it would be good to schedule this BOF, it is time to make a determination as to whether there is actually critical mass in the IETF to progress work on FTP. If no one cares enough to review drafts carefully other than their authors, we should just encourage the ISE to publish descriptions of implemented protocol extensions as Informational, make sure the extension keywords and parameters are in the registry, and move on. On the other hand, if people do care (and the recent responses on the IETF and Apps-Discuss lists to the hethmon-mcmurray and bryan drafts indicates that there might be), then we ought to be able to organize a systematic IETF review process and possibly even some strategic work on what is needed. Evidence of "someone cares" would be reflected by pre-IETF postings of proposed evaluations of I-Ds from the lists above and volunteers, from the FTP development and/or deployment communities, to lead the BOF or otherwise convince the ADs of intent to actively participate. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From tj@castaglia.org Tue Jun 22 07:44:40 2010 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 EB93D3A682D for ; Tue, 22 Jun 2010 07:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 Q-yrFgku-d1R for ; Tue, 22 Jun 2010 07:44:39 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 1CE1A3A681C for ; Tue, 22 Jun 2010 07:44:39 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BVW37213 (AUTH via LOGINBEFORESMTP); Tue, 22 Jun 2010 07:44:44 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Tue, 22 Jun 2010 07:43:40 -0700 (PDT) From: TJ Saunders To: Anthony Bryan In-Reply-To: Message-ID: References: <4C1127A0.5090503@isode.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] Fwd: FTPEXT BOF 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, 22 Jun 2010 14:44:40 -0000 > I haven't seen this here yet, & the IETF meeting in Maastricht is > about a month away so I figured I'd post it. I won't be able to attend > but I plan to help as much as I can otherwise. I'm more fitted to > outreach or administrative type work. > > I've already reviewed 1 of the previous 20 or so abandoned drafts. can > some of the implementers voice their opinion? I've started work on implementing the HOST command in proftpd, and have submitted some of my feedback directly to the Draft authors. I do have some continuing questions about how HOST would interact with e.g AUTH TLS, and/or SSL/TLS's Server Name Indication (SNI) mechanism. I would also like to revive interest in the MODE Z draft, and see if it can get to RFC status, given that there now multiple implementations of it: http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Had I the heavens' embroidered cloths, Enwrought with golden and silver light, The blue and the dim and the dark cloths Of night and light and half-light, I would spread the cloths under your feet. But I, being poor, have only my dreams; I have spread my dreams under your feet; Tread softly because you tread on my dreams. -William Butler Yeats ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From anthonybryan@gmail.com Tue Jun 22 13:37:29 2010 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 CBA303A6A02 for ; Tue, 22 Jun 2010 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_05=-1.11] 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 3pHE5rJCw6sX for ; Tue, 22 Jun 2010 13:37:28 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AB2373A68B8 for ; Tue, 22 Jun 2010 13:37:23 -0700 (PDT) Received: by iwn9 with SMTP id 9so2050970iwn.31 for ; Tue, 22 Jun 2010 13:37:28 -0700 (PDT) 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=MMX+WMlts888IkIglT/MC6MjqzccW5CKhPJ1EWD0k5U=; b=UbmMGp3vC3t3cfJCpp4K0czOICzIJe8RmhHrk7OJpg/gR1QvTqg73uy4MpzkYtsCyy h8I6sR4grxxC/gaNCsuynCQMBiY+mhTshwrb7jc/TjDPeZzM5BDZZM+XWjOgPgX8+QOh XwgFb7BMKQ9a+UOR/JhMR8b9NCfKvO57yKvPM= 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=FxHAHC1HwKDA6BY1j1jxlgHwnTPXXadjIy6TBkHnj1uJXG8Z9fN5OzwcnBWKzUhvyf v+Q85HIwkXHu5kccGEChE55UbexxdAc46qSQ+pHxwOUTzD0PygfTDwQPE+IW6rr+f6PN 0x/LZDB5tDFlAoUII8sK9NBUfoHjhZWSxnhBo= MIME-Version: 1.0 Received: by 10.42.7.68 with SMTP id d4mr2536207icd.34.1277239048057; Tue, 22 Jun 2010 13:37:28 -0700 (PDT) Received: by 10.231.152.65 with HTTP; Tue, 22 Jun 2010 13:37:27 -0700 (PDT) In-Reply-To: References: <4C1127A0.5090503@isode.com> Date: Tue, 22 Jun 2010 16:37:27 -0400 Message-ID: From: Anthony Bryan To: TJ Saunders Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] Fwd: FTPEXT BOF 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, 22 Jun 2010 20:37:29 -0000 On Tue, Jun 22, 2010 at 10:43 AM, TJ Saunders wrote: > > I would also like to revive interest in the MODE Z draft, and see if it > can get to RFC status, given that there now multiple implementations of > it: > > =A0http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 how widespread is it implemented? from a quick glance, this needs an "Updates: 959". and possibly update MODE in "FTP Commands and Extensions" (see IANA considerations section of ftp-hosts or ftp-hash). http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extens= ions.xhtml --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From iljitsch@muada.com Wed Jun 23 03:55:48 2010 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 B6C393A69D4 for ; Wed, 23 Jun 2010 03:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_20=-0.74, NO_RELAYS=-0.001] 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 GqXtbj3KC40f for ; Wed, 23 Jun 2010 03:55:48 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id A30883A689F for ; Wed, 23 Jun 2010 03:55:47 -0700 (PDT) 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 o5NAtdX9037410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Jun 2010 12:55:40 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2010 12:55:50 +0200 Message-Id: To: ftpext@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [ftpext] FTP password protection? 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, 23 Jun 2010 10:55:48 -0000 I could easily have missed this, but as far as I know, FTP has no = provisions to protect passwords used for logging in against = interception. In my opinion, this is the main reason non-anonymous FTP is problematic, = and I think defining a login mechanism that doesn't expose cleartext = passwords would be a good addition to FTP.= From daniel@haxx.se Wed Jun 23 04:10:15 2010 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 5194B3A6990 for ; Wed, 23 Jun 2010 04:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[AWL=-1.980, 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 45AO1x2-TCOt for ; Wed, 23 Jun 2010 04:10:12 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id A94C93A699E for ; Wed, 23 Jun 2010 04:10:10 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o5NBAHNE032344; Wed, 23 Jun 2010 13:10:17 +0200 Date: Wed, 23 Jun 2010 13:10:17 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Iljitsch van Beijnum 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 X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Wed, 23 Jun 2010 13:10:17 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP password protection? 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, 23 Jun 2010 11:10:15 -0000 On Wed, 23 Jun 2010, Iljitsch van Beijnum wrote: > In my opinion, this is the main reason non-anonymous FTP is problematic, and > I think defining a login mechanism that doesn't expose cleartext passwords > would be a good addition to FTP. Isn't RFC4217, FTP with TLS good enough for this? -- / daniel.haxx.se From iljitsch@muada.com Wed Jun 23 04:13:25 2010 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 DD23E3A699E for ; Wed, 23 Jun 2010 04:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 6JpgKPxxeP1A for ; Wed, 23 Jun 2010 04:13:25 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id BF4CB3A695B for ; Wed, 23 Jun 2010 04:13:24 -0700 (PDT) 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 o5NBDGD8037994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jun 2010 13:13:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 23 Jun 2010 13:13:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58A35E57-7187-49B3-815B-A49121A5AD10@muada.com> References: To: Daniel Stenberg X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP password protection? 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, 23 Jun 2010 11:13:26 -0000 On 23 jun 2010, at 13:10, Daniel Stenberg wrote: >> In my opinion, this is the main reason non-anonymous FTP is = problematic, and I think defining a login mechanism that doesn't expose = cleartext passwords would be a good addition to FTP. > Isn't RFC4217, FTP with TLS good enough for this? That would be one solution, but it seems like overkill, especially as = users have to set up a certficate. The fact that FTP with TLS isn't used = (much? at all?) in practice suggests that something less ambitious might = be helpful.= From daniel@haxx.se Wed Jun 23 04:36:38 2010 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 ABE263A699E for ; Wed, 23 Jun 2010 04:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.734 X-Spam-Level: X-Spam-Status: No, score=-3.734 tagged_above=-999 required=5 tests=[AWL=-1.485, 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 lT5aFdbxRn5C for ; Wed, 23 Jun 2010 04:36:37 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 341A73A6A01 for ; Wed, 23 Jun 2010 04:36:30 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o5NBabeE017913; Wed, 23 Jun 2010 13:36:37 +0200 Date: Wed, 23 Jun 2010 13:36:37 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Iljitsch van Beijnum In-Reply-To: <58A35E57-7187-49B3-815B-A49121A5AD10@muada.com> Message-ID: References: <58A35E57-7187-49B3-815B-A49121A5AD10@muada.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 X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Wed, 23 Jun 2010 13:36:38 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP password protection? 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, 23 Jun 2010 11:36:39 -0000 On Wed, 23 Jun 2010, Iljitsch van Beijnum wrote: >> Isn't RFC4217, FTP with TLS good enough for this? > > That would be one solution, but it seems like overkill, especially as users > have to set up a certficate. The fact that FTP with TLS isn't used (much? at > all?) in practice suggests that something less ambitious might be helpful. For just adressing the plain text password it might be overkill, yes. But it is an existing, working, implemented and deployed approach... And I must disagree with you. I (as author of a client-side implementation) find it used quite a lot. -- / daniel.haxx.se From tj@castaglia.org Wed Jun 23 07:58:21 2010 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 135C53A6A2D for ; Wed, 23 Jun 2010 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_50=0.001, SARE_URI_CONS7=0.306] 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 PEQOi2mV0uQ3 for ; Wed, 23 Jun 2010 07:58:15 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 696573A684B for ; Wed, 23 Jun 2010 07:58:15 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BVY90122 (AUTH via LOGINBEFORESMTP); Wed, 23 Jun 2010 07:58:18 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Wed, 23 Jun 2010 07:57:13 -0700 (PDT) From: TJ Saunders To: Anthony Bryan In-Reply-To: Message-ID: References: <4C1127A0.5090503@isode.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1717369841-1277304621=:30072" Content-ID: Cc: ftpext@ietf.org Subject: [ftpext] MODE Z (was: FTPEXT BOF) 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, 23 Jun 2010 14:58:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1717369841-1277304621=:30072 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: > On Tue, Jun 22, 2010 at 10:43 AM, TJ Saunders wrote: > > > > I would also like to revive interest in the MODE Z draft, and see if it > > can get to RFC status, given that there now multiple implementations of > > it: > > > >  http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 > > how widespread is it implemented? A search on Google turns up: SmartFTP (www.smartftp.com) Gene6 (www.g6ftpserver.com) FTPRush (www.ftprush.com) RaidenFTPD (www.raidenftpd.com) FireFTP (fireftp.mozdev.org) CrossFTP (www.crossftp.com) XLight FTPD (www.xlightftpd.com) FileZilla (www.filezilla-project.org) ProFTPD mod_deflate (www.castaglia.org/proftpd/modules/mod_deflate.html) and others. > from a quick glance, this needs an "Updates: 959". and possibly update > MODE in "FTP Commands and Extensions" (see IANA considerations section > of ftp-hosts or ftp-hash). Thanks, will do. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A woman can become a man's friend only in the following stages - first an acquaintance, next a mistress, and only then a friend. -Anton Chekhov ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --8323328-1717369841-1277304621=:30072-- From anthonybryan@gmail.com Wed Jun 23 11:45:14 2010 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 885D528C154 for ; Wed, 23 Jun 2010 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_50=0.001] 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 EgUpkSfJNN49 for ; Wed, 23 Jun 2010 11:45:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4DE3028C0E4 for ; Wed, 23 Jun 2010 11:45:13 -0700 (PDT) Received: by gyh4 with SMTP id 4so4131117gyh.31 for ; Wed, 23 Jun 2010 11:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=lqEI37z4uObzrv2FX/kvStR7x+RXfTYg4IVtBoe3+24=; b=sNJj8F1+pquuJ6HMWtRar8o0RDYU8dW1aOBhXCpu7gWTuSMcqGdpZAEhlIURdkcw1g dNO2SS6U9oL5FNMkvZ780FjJs6F6pkhmAmiElyy9KkbETHvPNV+U0VIO2FLLFUeY8jXX TAxfe0mNJ43vEPHj5kN69/vb5/z7iURGqUgas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E08rXLbFlqNXvtJWgyT24BlfD+UzCGe5gBTGoGdenTkL1FhI8FqT2Swr9rcqD6z9Ca jVKRYfzQ0bfrvlihrdzV5AHXukdXjK4YfwQ+hQ8zcgYkw7AVona6VCNnW/YkKizA0Z9M QUZrXxj/570NMdz0O0T4YZKwJYDqFCq2WDcr0= MIME-Version: 1.0 Received: by 10.150.239.20 with SMTP id m20mr7925204ybh.407.1277318717883; Wed, 23 Jun 2010 11:45:17 -0700 (PDT) Received: by 10.231.160.132 with HTTP; Wed, 23 Jun 2010 11:45:17 -0700 (PDT) Date: Wed, 23 Jun 2010 14:45:17 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] Expired FTP ID review: draft-ietf-ftpext-restart-00 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, 23 Jun 2010 18:45:14 -0000 draft-ietf-ftpext-restart-00 (21 March 1997) http://tools.ietf.org/html/draft-ietf-ftpext-restart-00 Overview This memo describes changes to FTP [1], which were proposed by Rick Adams in May of 1989, to allow the RESTART mechanism to be used with STREAM mode transfers. Along with this, two new optional commands are added, MODIFICATION TIME (MDTM) and SIZE OF FILE (SIZE). All these changes have been implemented, and are in use today in many production FTP implementations. I think RFC 3659 (March 2007), Sections 3, 4, & 5 supersede this draft. http://tools.ietf.org/html/rfc3659 -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Thu Jun 24 13:11:02 2010 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 B56B03A6A5E for ; Thu, 24 Jun 2010 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_50=0.001] 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 sWqWUGlLKT99 for ; Thu, 24 Jun 2010 13:10:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2DE6C3A6A6A for ; Thu, 24 Jun 2010 13:10:57 -0700 (PDT) Received: by iwn37 with SMTP id 37so270183iwn.31 for ; Thu, 24 Jun 2010 13:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2jRRBQwdUAgubv3sgulfKfe3hQq5DUKRIxgWEc2o/2Q=; b=MjMh73IKdguVrl1FxuFrHY3/BpECa1V+oYZsnX1gg7ijDt4e0GA7Bg9w7LvS8ScJkj Th0k/bTCiR4Te1RxN4xH2I53g7ojHD4WKAGfvPKISdHyPkZkWnQ4qJYqswR72OqahnQD IzW09oZKVK6VSd2+dKmiZ4h7Zp9KIil3+Le5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YEPpnnddOgFKYaB/6cHziZ2M8beCmtyra5r92WvZL5dGZqBEH3XZWxfGjc0cx/8UQM 3+XMjCKIqI+goKm3hQSskWfceDqvAibILH2fC1bSFrj/5eu5DdPJQuvEhZy9EXZfa59V ubidNoWhOLyAvoh+QKoL+k5c7oYd6zHC/Fan8= MIME-Version: 1.0 Received: by 10.231.149.12 with SMTP id r12mr11585286ibv.57.1277410265151; Thu, 24 Jun 2010 13:11:05 -0700 (PDT) Received: by 10.231.160.132 with HTTP; Thu, 24 Jun 2010 13:11:05 -0700 (PDT) Date: Thu, 24 Jun 2010 16:11:05 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] FTP IDs 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, 24 Jun 2010 20:11:02 -0000 here's the list of FTP IDs with links. your help with triage/review is appreciated. looks like we have 3 identified as superceded by others. Active drafts: draft-bryan-ftp-hash http://tools.ietf.org/html/draft-bryan-ftp-hash draft-hethmon-mcmurray-ftp-hosts http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts Related: draft-ietf-behave-ftp64 http://tools.ietf.org/html/draft-ietf-behave-ftp64 Expired individual submission drafts. This list is derived from a quick search of the I-D database. Some of them have been superceded by other work; others were abandoned long ago by the authors. Posting dates are listed from the index; expiration dates six months later. Legend: ! = renewed interest in draft. # = draft superceded by another draft/RFC. draft-bonachea-sftp-00 Protocol Negotiation Extensions to Secure FTP 1999-06-18 http://tools.ietf.org/id/draft-bonachea-sftp-00.txt # draft-casey-url-ftp-00 A FTP URL Format 1997-01-09 (presumably superceded by draft-hoffman-ftp-uri) # http://tools.ietf.org/id/draft-casey-url-ftp-00.txt draft-chin-dnftp-01 Distributed New File Transfer Protocol 2006-05-02 http://tools.ietf.org/id/draft-chin-dnftp-01.txt draft-dilip-ftpext-safe-transfer-00 Safe GET & Safe PUT options for FTP 2006-01-17 http://tools.ietf.org/html/draft-dilip-ftpext-safe-transfer-00 draft-fordh-ftp-ssl-firewall-07 FTP/TLS Friendly Firewalls 2005-10-21 http://www.ford-hutchinson.com/~fh-1-pfh/draft-fordh-ftp-ssl-firewall-07.txt draft-hoffman-ftp-uri-04 The ftp URI Scheme 2005-01-03 http://tools.ietf.org/html/draft-hoffman-ftp-uri-04 draft-klensin-ftp-typeu-00 FTP Extension for Internationalized Text 2008-07-27 http://tools.ietf.org/id/draft-klensin-ftp-typeu-00.txt draft-metz-spasv-00 Short Passive (SPASV) Command for FTP 1998-01-13 http://tools.ietf.org/html/draft-metz-spasv-00 draft-mityok-macbin1-01 Adopt MacBinary II Mac File Encoding for FTP Transfers 1996-07-30 http://tools.ietf.org/id/draft-mityok-macbin1-01.txt draft-peterson-streamlined-ftp-command-extensions-06 Streamlined FTP Command Extensions 2008-08-29 http://tools.ietf.org/html/draft-peterson-streamlined-ftp-command-extensions-06 ! draft-preston-ftpext-deflate-03 Deflate transmission mode for FTP 2005-01-14 ! http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 draft-rajeshs-ftpext-rec-arch-transfer-01 FTP Extensions for recursive and archived file transfers 2005-04-29 http://tools.ietf.org/html/draft-rajeshs-ftpext-rec-arch-transfer-01 draft-rosenau-ftp-single-port-05 FTP EXTENSION ALLOWING IP FORWARDING (NATs) 2008-09-18 http://tools.ietf.org/id/draft-rosenau-ftp-single-port-05.txt draft-saul-ftp-plus-00 FTP Plus 2000-08-29 http://tools.ietf.org/id/draft-saul-ftp-plus-00.txt draft-somers-ftp-mfxx-03 The 'MFMT', 'MFCT', and 'MFF' Command Extensions for FTP 2008-07-28 http://tools.ietf.org/html/draft-somers-ftp-mfxx-03 draft-stewart-ftp-client-mib-00 FTP Client MIB 1998-11-17 http://tools.ietf.org/html/draft-stewart-ftp-client-mib-00 # draft-twine-ftpmd5-00 The 'MD5' and 'MMD5' FTP Command Extensions 2002-05-14 (superceded by draft-bryan-ftp-hash) # http://tools.ietf.org/id/draft-twine-ftpmd5-00.txt The following additional drafts were work products of the old FTPEXT WG that do not appear to have been replaced by RFCs: draft-ietf-ftpext-data-connection-assurance-00 FTP Data Connection Assurance 2002-05-24 http://tools.ietf.org/html/draft-ietf-ftpext-data-connection-assurance-00 # draft-ietf-ftpext-restart-00 REST Command and Extensions to FTP 1997-03-21 (superceded by RFC 3659?) # http://tools.ietf.org/html/draft-ietf-ftpext-restart-00 draft-ietf-ftpext-utf-8-option-00 UTF-8 Option for FTP 2002-05-24 http://tools.ietf.org/html/draft-ietf-ftpext-utf-8-option-00 -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From barryleiba.mailing.lists@gmail.com Thu Jun 24 19:08:32 2010 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 30E3E28C0EB for ; Thu, 24 Jun 2010 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AbuLapZN7Pz7 for ; Thu, 24 Jun 2010 19:08:31 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 6BA4228C0D6 for ; Thu, 24 Jun 2010 19:08:30 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so2559eye.51 for ; Thu, 24 Jun 2010 19:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=UNSYrIUc0JbnussTQoZY3+THcErCSRe9Iqv67iwIzgc=; b=rfaR+LjmPHZtPbHCIPU6gCtFfOJQgZW52xFaaMv+GvpTd7qhdlTOAqHAGmL49UrKhu YGCLdjLog9O0Sx9dizkeE8pQdpIgKu6+OCszPGAnXadkmMRllZEDPPs+pCPXOmXwggTw BB1HQE618zDYK+P+QBCQCCwBMh2bkmlRqJz/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=C+VIyfbR1FYOY2Wt3Vmn+p84KiQzGU4ERGUni453lc2YNRkWEXl41wrG45334aZq40 VWmjLX82PL4nzrAC58aSTVLek9qOm2FRUzD51wEsdpezd4JbKkeN970+pKhNQZ8KTL2E BbiUrlbTtLAA8eZnrRqOUETkm3BgC8XL+iLQw= MIME-Version: 1.0 Received: by 10.213.8.134 with SMTP id h6mr3119714ebh.20.1277431715636; Thu, 24 Jun 2010 19:08:35 -0700 (PDT) Received: by 10.213.34.197 with HTTP; Thu, 24 Jun 2010 19:08:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Jun 2010 22:08:35 -0400 Message-ID: From: Barry Leiba To: Anthony Bryan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP IDs X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 02:08:32 -0000 > here's the list of FTP IDs with links. your help with triage/review is > appreciated. looks like we have 3 identified as superceded by others. Anthony, thanks for putting this together. I have a request from Dapeng Liu to have time on the BOF agenda to discuss = this: draft-liu-behave-ftp64 IPv6 IPv4 translation FTP considerations http://tools.ietf.org/html/draft-liu-behave-ftp64 So we'll add that to the list. I need to put together an agenda for the BOF, so I'm going to post a separate message asking people to look at this list and tell us which drafts they want to see discussed/considered. > ! =3D renewed interest in draft. > ! =A0 draft-preston-ftpext-deflate-03 Deflate transmission mode for FTP 2= 005-01-14 > ! http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 Whence comes the "renewed interest"? If there really is renewed interest, the interested part(y/ies) should revive the draft by posting a new version, or an -00 version under a related name. The deadline for -00 drafts is 5 July at 17:00 PDT, so there's still time to do this. Barry Leiba, ftpext2 BOF chair From barryleiba.mailing.lists@gmail.com Thu Jun 24 19:17:13 2010 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 48F2228C10C for ; Thu, 24 Jun 2010 19:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 A+5m0pPpVGVt for ; Thu, 24 Jun 2010 19:17:12 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 31C6F28C0D0 for ; Thu, 24 Jun 2010 19:17:11 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so2798eye.51 for ; Thu, 24 Jun 2010 19:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=2GGvvNMfiIIKhSeksWl/fvK890gw5kHCTHkm7pqaW6U=; b=VK//vk2hTM8BLgr0eyEsC2M+slmEOXXk454ERG3GxHhXuttezhDH7NdhvVYVHkoxkj MTRMlfe3bF8LdOF8qBMpJlSW+5P+LNoVkH7Hj/3blP+wKZt2Gse3hWuUv+kYC0XJdw0z K7BsQeyb+FODUw5HenWGwVlkyMpSf37flxNfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=M8d/Bv3MMnmSxWAl6q5wIFFgibtCgqExNvA2qVOQrxX0LiKtJK4Ef7oPRuVfNiTjNs raSIk2DZ/DvY8KplkJdzuVOZjsPB8qie2OD+o7y2HrglcoPK8N0uSxqc36QBC9/cMRdu JF/jsoxJoJzeKTmReZ8I2Z6UFZ1JGTzf305SY= MIME-Version: 1.0 Received: by 10.213.40.198 with SMTP id l6mr2293731ebe.48.1277432234906; Thu, 24 Jun 2010 19:17:14 -0700 (PDT) Received: by 10.213.34.197 with HTTP; Thu, 24 Jun 2010 19:17:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Jun 2010 22:17:14 -0400 Message-ID: From: Barry Leiba To: Anthony Bryan , TJ Saunders Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP IDs X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 02:17:13 -0000 >> ! =3D renewed interest in draft. >> ! =A0 draft-preston-ftpext-deflate-03 Deflate transmission mode for FTP = 2005-01-14 >> ! http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 > > Whence comes the "renewed interest"? =A0If there really is renewed > interest, the interested part(y/ies) should revive the draft by > posting a new version, or an -00 version under a related name. =A0The > deadline for -00 drafts is 5 July at 17:00 PDT, so there's still time > to do this. Never mind; I see it, in TJ's note. TJ, since you are an original author of the draft, you should be able to submit an -04 version and get it revived. Can you do that by the 5 July deadline? Barry From barryleiba.mailing.lists@gmail.com Thu Jun 24 19:28:58 2010 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 452423A68A5 for ; Thu, 24 Jun 2010 19:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 pc1jfg9KtDAB for ; Thu, 24 Jun 2010 19:28:57 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 067E33A6852 for ; Thu, 24 Jun 2010 19:28:56 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so3067eye.51 for ; Thu, 24 Jun 2010 19:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=Ko3OaGh3b4bKUex2YGNz3MWQRpus6lazKMMNedd3B3M=; b=p47+xnoxaM7KY3UljI/GWwW+sIYLjzODgMCRwjmgo7PC7g+FTGZQcgc0VYQGYhz3pj Ozd37bBU/XkKUgrnkUwBHd1jkO06pSKAJ7u22djlY+aV+dGh40jimPX3U1K0R9lFUjug 7squK3mqorExVFRVM/7h0G9swHu4RS8zKzD6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=eYAzCk2f9sqdqMt4Bz7OBWz/Fb/eYajyAh32mzg2FF8etKAIgbJoXiuSitC3LQKJsE aiewJSddS9unqlRoqvBhR+0EaeftN+aHOzxUk2xBb2XVS7Lma77gsVvvwisv3HP+QTpE GmYjC+lDiW/pL294G2s+mmB0+ck9neZhsFXLQ= MIME-Version: 1.0 Received: by 10.213.101.212 with SMTP id d20mr1607820ebo.2.1277432941993; Thu, 24 Jun 2010 19:29:01 -0700 (PDT) Received: by 10.213.34.197 with HTTP; Thu, 24 Jun 2010 19:29:01 -0700 (PDT) Date: Thu, 24 Jun 2010 22:29:01 -0400 Message-ID: From: Barry Leiba To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] Working on the ftpext2 BOF agenda... X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 02:28:58 -0000 As I prepare an agenda for the (two-hour) ftpext2 BOF, I want to know which drafts people think we should be discussing/considering. Please look at Anthony's message: http://www.ietf.org/mail-archive/web/ftpext/current/msg00014.html ...and post *here*, in this thread, which drafts you have interest in. You may select from the active drafts and the expired ones. Please also let me know if you will (1) be in Maastricht and attending the BOF, (2) be in Maastricht but not attending the BOF, or (3) be attending the BOF remotely, through Jabber and/or the audio feed. Please just use this thread for direct response to this message, including any other agenda requests. Put any discussion in Anthony's thread or start another. Thanks. Barry Leiba, ftpext2 BOF chair From anthonybryan@gmail.com Sat Jun 26 13:00:26 2010 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 BEB873A67EF for ; Sat, 26 Jun 2010 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_50=0.001] 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 eGnZdWOYyBVU for ; Sat, 26 Jun 2010 13:00:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 606263A681D for ; Sat, 26 Jun 2010 13:00:24 -0700 (PDT) Received: by iwn40 with SMTP id 40so564041iwn.31 for ; Sat, 26 Jun 2010 13:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ilbRqENVkuu7scrltQ5g40IMay7mh22QPNcppGZCfd8=; b=QoveeL4F4AJ2VJY5PlXqNLWL59Uej7D4Mtu9J1gt+7f9pB6ooJRg/BZKAu6B5n4dMN cdd6majuFMvGdc3uAlcNOBrmD5eyJxa/HFvAc32cUNohLw5VEzKAgt/7FQMQ1IDVvU7G HjBnGD7w46jdjOtBU06iqUzc2yOx3XUOuw/7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EJtdKAVLULuVTt6AMvPqMhqUdPTz+/FkvSspK5Mh6IFR2DNTXaRhJ/qG7+7Uum7yVy j4gGw/hEQJq+bihw97ycbxKWXTWowHupguCTqdT4LOdImv3wu5uR7duAHXhpEtC4Z3NQ r4HcbOZw3vEE9lj9IkVEYwl8L9ukn/SzoSPK8= MIME-Version: 1.0 Received: by 10.231.35.10 with SMTP id n10mr175907ibd.161.1277582431646; Sat, 26 Jun 2010 13:00:31 -0700 (PDT) Received: by 10.231.160.132 with HTTP; Sat, 26 Jun 2010 13:00:31 -0700 (PDT) Date: Sat, 26 Jun 2010 16:00:31 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 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, 26 Jun 2010 20:00:26 -0000 this ID describes 6 new commands, of which HOST is more fully described in draft-hethmon-mcmurray-ftp-hosts. the other 5 commands: Remove Directory All (RMDA) Directory Size (DSIZ) Available Octets (AVBL) [similar to LOCAL DISK SIZE (LDSIZE) from draft-dilip-ftpext-safe-transfer-00] Retrieve Thumbnail of Remote Image File (THMB) Client / Server Identification (CSID) these are mostly self-explanatory, but I have quoted a bit on each: Remove Directory All (RMDA) The FTP command REMOVE DIRECTORY ALL (RMDA) removes a directory from the server and all of its contents including all files and subdirectories. The RMDA command is considered analogous to recursively deleting all files and directories contained in a given remote directory (including the directory itself) one at a time. Directory Size (DSIZ) The FTP command DIRECTORY SIZE (DSIZ) returns the number of octets (8-bit bytes) on the remote file system occupied by a given directory and its contents. Available Octets (AVBL) The FTP command AVAILABLE OCTETS (AVBL) can be used to retrieve the number of octets available to receive uploads in a specified remote directory. Retrieve Thumbnail of Remote Image File (THMB) The THMB FTP command allows the server-FTP process to locally generate a thumbnail of a requested image type and transfer the resulting image instead of the entire contents of the original image file. Client / Server Identification (CSID) The FTP command CLIENT / SERVER IDENTIFICATION (CSID) allows the client and server to exchange relevant identifying information about the programs and underlying platforms being used for the FTP communication. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Sun Jun 27 21:33:02 2010 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 3D5B33A68DB for ; Sun, 27 Jun 2010 21:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_50=0.001] 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 RaHDqH5zVAa9 for ; Sun, 27 Jun 2010 21:32:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BE8B23A68BD for ; Sun, 27 Jun 2010 21:32:59 -0700 (PDT) Received: by iwn35 with SMTP id 35so450854iwn.31 for ; Sun, 27 Jun 2010 21:33:09 -0700 (PDT) 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=zV+TLoM5vG09niGUZ0Hc/J9izscbcaC+ztNpFEJyyUc=; b=ItQAL69CfaJqpIUYcqNCdphmDv2SBBN07B2Ejk9fTLi4YFJgiicEl28IO2KipzuwcD jHHbm/ClNaZKoZ6w6v+g6eBKUJ1lXojB83V7qcWB3mxxvMMG/ivtxb80ZS1+FQELQ/fl dEDd8Ae6CY0a4rGgoXp1FkCLjv2S3UTqRQyiE= 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=p3oRM5FwcQ7phMfXjc7cGNFB7OlY4Rh4HMAu6V1UPOdM0k8IyDBa0nd3eEcS9JvRO1 JVZJmBZvX8UVgu8vAvF++KvxZyXGOBy1Ea0qAXJgsh0xq+HrL0VVKysomUIAszEjiDEv jnO0mhJ4oIbq4XcFeNhA+lqDJlVitJBjyi7Ls= MIME-Version: 1.0 Received: by 10.231.31.197 with SMTP id z5mr395474ibc.74.1277699588673; Sun, 27 Jun 2010 21:33:08 -0700 (PDT) Received: by 10.231.160.132 with HTTP; Sun, 27 Jun 2010 21:33:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Jun 2010 00:33:08 -0400 Message-ID: From: Anthony Bryan To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP IDs 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, 28 Jun 2010 04:33:02 -0000 On Thu, Jun 24, 2010 at 10:08 PM, Barry Leiba wrote: >> here's the list of FTP IDs with links. your help with triage/review is >> appreciated. looks like we have 3 identified as superceded by others. > > Anthony, thanks for putting this together. > > I have a request from Dapeng Liu to have time on the BOF agenda to discus= s this: > =A0 draft-liu-behave-ftp64 > =A0 IPv6 IPv4 translation FTP considerations > =A0 http://tools.ietf.org/html/draft-liu-behave-ftp64 > > So we'll add that to the list. added. here's a revised list that may be more readable, w/ a few corrections & notes. I've also emailed all of the ID authors & we have a few of them on the list now, so hopefully we'll be getting more feedback. Legend: % =3D On the FTPEXT BOF agenda at IETF Maastricht meeting on July 26, 2010 from 1740-1940. Reply to Barry's thread to have a draft put on the agenda. ! =3D Renewed interest in draft. # =3D Internet Draft superceded by another ID/RFC. % Active drafts: FTP Extensions for Cryptographic Hashes draft-bryan-ftp-hash http://tools.ietf.org/html/draft-bryan-ftp-hash File Transfer Protocol HOST Command for Virtual Hosts draft-hethmon-mcmurray-ftp-hosts http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts Related: IPv6-to-IPv4 translation FTP considerations draft-ietf-behave-ftp64 http://tools.ietf.org/html/draft-ietf-behave-ftp64 % IPv6 IPv4 translation FTP considerations % draft-liu-behave-ftp64 % http://tools.ietf.org/html/draft-liu-behave-ftp64 Expired individual submission drafts. This list is derived from a quick search of the I-D database. Some of them have been superceded by other work; others were abandoned long ago by the authors. Posting dates are listed from the index; expiration dates six months later. Protocol Negotiation Extensions to Secure FTP 1999-06-18 draft-bonachea-sftp-00 http://tools.ietf.org/id/draft-bonachea-sftp-00.txt Distributed New File Transfer Protocol 2006-05-02 draft-chin-dnftp-01 http://tools.ietf.org/id/draft-chin-dnftp-01.txt Safe GET & Safe PUT options for FTP 2006-01-17 draft-dilip-ftpext-safe-transfer-00 http://tools.ietf.org/html/draft-dilip-ftpext-safe-transfer-00 FTP/TLS Friendly Firewalls 2005-10-21 draft-fordh-ftp-ssl-firewall-07 http://www.ford-hutchinson.com/~fh-1-pfh/draft-fordh-ftp-ssl-firewall-07.tx= t The ftp URI Scheme 2005-01-03 draft-hoffman-ftp-uri-04 http://tools.ietf.org/html/draft-hoffman-ftp-uri-04 FTP Extension for Internationalized Text 2008-07-27 draft-klensin-ftp-typeu-00 http://tools.ietf.org/id/draft-klensin-ftp-typeu-00.txt Short Passive (SPASV) Command for FTP 1998-01-13 draft-metz-spasv-00 http://tools.ietf.org/html/draft-metz-spasv-00 Adopt MacBinary II Mac File Encoding for FTP Transfers 1996-07-30 draft-mityok-macbin1-01 http://tools.ietf.org/id/draft-mityok-macbin1-01.txt Streamlined FTP Command Extensions 2008-08-29 draft-peterson-streamlined-ftp-command-extensions-06 Note: HOST command same as draft-hethmon-mcmurray-ftp-hosts. AVBL command is similar to LOCAL DISK SIZE (LDSIZE) from draft-dilip-ftpext-safe-transfer-00. http://tools.ietf.org/html/draft-peterson-streamlined-ftp-command-extension= s-06 ! Deflate transmission mode for FTP 2005-01-14 ! draft-preston-ftpext-deflate-03 ! http://tools.ietf.org/html/draft-preston-ftpext-deflate-03 FTP Extensions for recursive and archived file transfers 2005-04-29 draft-rajeshs-ftpext-rec-arch-transfer-01 http://tools.ietf.org/html/draft-rajeshs-ftpext-rec-arch-transfer-01 FTP EXTENSION ALLOWING IP FORWARDING (NATs) 2008-09-18 draft-rosenau-ftp-single-port-05 http://tools.ietf.org/id/draft-rosenau-ftp-single-port-05.txt FTP Plus 2000-08-29 draft-saul-ftp-plus-00 http://tools.ietf.org/id/draft-saul-ftp-plus-00.txt The 'MFMT', 'MFCT', and 'MFF' Command Extensions for FTP 2008-07-28 draft-somers-ftp-mfxx-04 http://tools.ietf.org/html/draft-somers-ftp-mfxx-04 FTP Client MIB 1998-11-17 draft-stewart-ftp-client-mib-00 http://tools.ietf.org/html/draft-stewart-ftp-client-mib-00 The following additional drafts were work products of the old FTPEXT WG that do not appear to have been replaced by RFCs: FTP Data Connection Assurance 2002-05-24 draft-ietf-ftpext-data-connection-assurance-00 http://tools.ietf.org/html/draft-ietf-ftpext-data-connection-assurance-00 UTF-8 Option for FTP 2002-05-24 draft-ietf-ftpext-utf-8-option-00 Note: According to http://wiki.filezilla-project.org/Character_Set , this ID conflicts with RFC 2640. http://tools.ietf.org/html/draft-ietf-ftpext-utf-8-option-00 Drafts that are superceded or might be left abandoned. # A FTP URL Format 1997-01-09 # draft-casey-url-ftp-00 # Note: Presumably superceded by draft-hoffman-ftp-uri? # http://tools.ietf.org/id/draft-casey-url-ftp-00.txt # REST Command and Extensions to FTP 1997-03-21 # draft-ietf-ftpext-restart-00 # Note: Product of old FTPEXT WG. Superceded by RFC 3659? # http://tools.ietf.org/html/draft-ietf-ftpext-restart-00 # The 'MD5' and 'MMD5' FTP Command Extensions 2002-05-14 # draft-twine-ftpmd5-00 # Note: Superceded by draft-bryan-ftp-hash. # http://tools.ietf.org/id/draft-twine-ftpmd5-00.txt --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From paulfordh@uk.ibm.com Mon Jun 28 07:34:01 2010 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 05C083A6807 for ; Mon, 28 Jun 2010 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Xme+VCpScPHu for ; Mon, 28 Jun 2010 07:33:57 -0700 (PDT) Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by core3.amsl.com (Postfix) with ESMTP id ACDC83A67E9 for ; Mon, 28 Jun 2010 07:33:55 -0700 (PDT) Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o5SEY4YL029562 for ; Mon, 28 Jun 2010 14:34:04 GMT Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5SEY0t31474664 for ; Mon, 28 Jun 2010 15:34:04 +0100 Received: from d06av05.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5SEY0PS003640 for ; Mon, 28 Jun 2010 08:34:00 -0600 Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o5SEY0Si003637 for ; Mon, 28 Jun 2010 08:34:00 -0600 To: ftpext@ietf.org MIME-Version: 1.0 X-KeepSent: 221A265E:71CED6D5-80257750:004EEF80; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Mon, 28 Jun 2010 15:42:09 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 28/06/2010 15:42:10, Serialize complete at 28/06/2010 15:42:10 Content-Type: multipart/alternative; boundary="=_alternative 004FEF2E80257750_=" Subject: [ftpext] Hello, firewall draft and password protection 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, 28 Jun 2010 15:59:14 -0000 This is a multipart message in MIME format. --=_alternative 004FEF2E80257750_= Content-Type: text/plain; charset="US-ASCII" Firstly, hello FTP-EXTers - hope you're all well. Secondly, I have been asked about the current status of: draft-fordh-ftp-ssl-firewall-07 FTP/TLS Friendly Firewalls 2005-10-21 ( http://www.ford-hutchinson.com/~fh-1-pfh/draft-fordh-ftp-ssl-firewall-07.txt ) As far as I'm concerned, this document has outlived its usefulness. The war between firewalls and secure protocols has died right down now and I don't think this draft is needed any more. If, however, others disagree, then I'm happy for it to be resurrected. Finally, there is another thread on this list stating that TLS is overkill for protecting passwords in FTP. To which I have two replies: 1) implementing TLS isn't hard for server only authentication - the http world has managed it, I don't see why FTP should be any harder. 2) please, please think very carefully before calling for a new security mechanism to be created and deployed - such things are notoriously difficult to do correctly. Cheers, Paul -- Paul Ford-Hutchinson (Author - RFC4217) --=_alternative 004FEF2E80257750_= Content-Type: text/html; charset="US-ASCII"
Firstly, hello FTP-EXTers - hope you're all well.

Secondly, I have been asked about the current status of:
    draft-fordh-ftp-ssl-firewall-07 FTP/TLS Friendly Firewalls 2005-10-21 (http://www.ford-hutchinson.com/~fh-1-pfh/draft-fordh-ftp-ssl-firewall-07.txt)

As far as I'm concerned, this document has outlived its usefulness.  The war between firewalls and secure protocols has died right down now and I don't think this draft is needed any more.  If, however, others disagree, then I'm happy for it to be resurrected.

Finally, there is another thread on this list stating that TLS is overkill for protecting passwords in FTP.  To which I have two replies:

1) implementing TLS isn't hard for server only authentication - the http world has managed it, I don't see why FTP should be any harder.
2) please, please think very carefully before calling for a new security mechanism to be created and deployed - such things are notoriously difficult to do correctly.

Cheers,
Paul
--

Paul Ford-Hutchinson (Author - RFC4217) --=_alternative 004FEF2E80257750_=-- From iljitsch@muada.com Mon Jun 28 09:04:15 2010 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 F41B53A67A3 for ; Mon, 28 Jun 2010 09:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE+1mj6ZyiUg for ; Mon, 28 Jun 2010 09:04:14 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id CDCA63A6891 for ; Mon, 28 Jun 2010 09:04:13 -0700 (PDT) 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 o5SG44pL018201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jun 2010 18:04:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 28 Jun 2010 18:04:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0593513D-438C-4D49-A3AD-ED69D3DED92B@muada.com> References: To: Paul Ford-Hutchinson X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] Hello, firewall draft and password protection 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, 28 Jun 2010 16:04:15 -0000 On 28 jun 2010, at 16:42, Paul Ford-Hutchinson wrote: > Finally, there is another thread on this list stating that TLS is = overkill=20 > for protecting passwords in FTP. To which I have two replies: > 1) implementing TLS isn't hard for server only authentication - the = http=20 > world has managed it, I don't see why FTP should be any harder. There are tons of issues in the HTTP world with invalid certificates. > 2) please, please think very carefully before calling for a new = security=20 > mechanism to be created and deployed - such things are notoriously=20 > difficult to do correctly. All authentication protocols (HTTP basic auth, PPP CHAP, IMAP, ...) use = challenge/response mechanisms for password-based logins. Surely one can = be reused.= From daniel@haxx.se Mon Jun 28 10:45:58 2010 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 DE9C93A6873 for ; Mon, 28 Jun 2010 10:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=-1.188, 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 hNLoaDbvfQoy for ; Mon, 28 Jun 2010 10:45:58 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 8D0E53A691D for ; Mon, 28 Jun 2010 10:45:57 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o5SHk7uu017068; Mon, 28 Jun 2010 19:46:07 +0200 Date: Mon, 28 Jun 2010 19:46:07 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Iljitsch van Beijnum In-Reply-To: <0593513D-438C-4D49-A3AD-ED69D3DED92B@muada.com> Message-ID: References: <0593513D-438C-4D49-A3AD-ED69D3DED92B@muada.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 X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Mon, 28 Jun 2010 19:46:07 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] Hello, firewall draft and password protection 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, 28 Jun 2010 17:45:59 -0000 On Mon, 28 Jun 2010, Iljitsch van Beijnum wrote: > All authentication protocols (HTTP basic auth, PPP CHAP, IMAP, ...) use > challenge/response mechanisms for password-based logins. Surely one can be > reused. I trust you meant that to be HTTP Digest auth, as Basic is not challenge/response. -- / daniel.haxx.se From iljitsch@muada.com Mon Jun 28 11:23:30 2010 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 4F4A53A67CC for ; Mon, 28 Jun 2010 11:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.922, 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 HeYmQYw+oWb3 for ; Mon, 28 Jun 2010 11:23:29 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 0B1063A6403 for ; Mon, 28 Jun 2010 11:23:28 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o5SINKsD019042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jun 2010 20:23:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 28 Jun 2010 20:23:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B7DCD84-E8C6-4AAA-9875-47F996914CC1@muada.com> References: <0593513D-438C-4D49-A3AD-ED69D3DED92B@muada.com> To: Daniel Stenberg X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] Hello, firewall draft and password protection 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, 28 Jun 2010 18:23:30 -0000 On 28 jun 2010, at 19:46, Daniel Stenberg wrote: >> All authentication protocols (HTTP basic auth, PPP CHAP, IMAP, ...) = use challenge/response mechanisms for password-based logins. Surely one = can be reused. > I trust you meant that to be HTTP Digest auth, as Basic is not = challenge/response. Of course, thanks. From anthonybryan@gmail.com Mon Jun 28 13:50:29 2010 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 234D83A69BF for ; Mon, 28 Jun 2010 13:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_40=-0.185] 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 roNuJhiiRBzY for ; Mon, 28 Jun 2010 13:50:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DCB6B3A6A68 for ; Mon, 28 Jun 2010 13:50:06 -0700 (PDT) Received: by iwn40 with SMTP id 40so174793iwn.31 for ; Mon, 28 Jun 2010 13:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=S2LD5w6TyJawzHZ9ergBJZeaydOpduP7ACip2lnWugU=; b=A6JeJEMIJsTvdyv94lygGgERAkdmHshawNbKhoBjTl3sibQygeCCAe3TjMUOld9pyo v72+PNIE0TeR2yirpLP061skaPU5bZVdYd5cIjOgY+1TIsvIiT9A3ZcK53+fnBpXbW/N Z196vEKUXOJ5p2dVxr8dc2NPBC36M4jalKMq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=M0as2V0raQEJlH0kh8Uf9VqQwLRbnaxq1f0I4jX3TPKllHTDnBfsOx7jec6qSN/3Nk VERC6im2oCsopYtPHEbQzLXEG5v/2hjk4iq/16xXdPQVjZB+rSVQyWMxWrI/PnwIozWY Xft3f1JtDHkKbin5yUx4UlN6MWSSTbfGV/eKE= MIME-Version: 1.0 Received: by 10.231.158.132 with SMTP id f4mr6316174ibx.52.1277758216233; Mon, 28 Jun 2010 13:50:16 -0700 (PDT) Received: by 10.231.160.132 with HTTP; Mon, 28 Jun 2010 13:50:16 -0700 (PDT) Date: Mon, 28 Jun 2010 16:50:16 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ftpext] Expired FTP ID author overview: draft-saul-ftp-plus-00 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, 28 Jun 2010 20:50:29 -0000 FTP Plus 2000-08-29 draft-saul-ftp-plus-00 http://tools.ietf.org/id/draft-saul-ftp-plus-00.txt information from the author. ---------- Forwarded message ---------- From: Mike Saul Anthony Feel free to post what I wrote below if it is relevant. =A0Looking over the draft, it appears that most of the new commands were related to the XTP protocol (which is not widely used). =A0There were a few additions to RETR and STOR which may be of interest. Mike > On Mon, Jun 28, 2010 at 2:54 PM, Mike Saul wrote: >> >> Anthony >> >> =A0The draft that I wrote was on behalf of SMPTE, but they weren't inter= ested >> in supporting it. =A0I'm not sure how relevant this draft is to future F= TP >> work. >> >> However, I'm certainly interested in keeping up to some extent. >> >> Thanks for the email. >> >> Mike >> >> >> On Jun 28, 2010, at 11:31 AM, Anthony Bryan wrote: >> >>> >>> =A0Hi Mike, I'm writing because of your Internet Draft on FTP. Work is >>> starting up on FTP at the IETF. If you are interested, search for the F= TPEXT >>> mailing list. (I can't include a link in my first email). If you're not >>> interested, sorry to bother you :) >>> --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From tj@castaglia.org Mon Jun 28 15:08:09 2010 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 828533A6A8D for ; Mon, 28 Jun 2010 15:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_50=0.001] 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 8g8yLzQiFkmt for ; Mon, 28 Jun 2010 15:08:08 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id AE3663A67CC for ; Mon, 28 Jun 2010 15:08:08 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BWM56293 (AUTH via LOGINBEFORESMTP); Mon, 28 Jun 2010 15:08:17 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Mon, 28 Jun 2010 15:07:05 -0700 (PDT) From: TJ Saunders To: Anthony Bryan In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 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, 28 Jun 2010 22:08:09 -0000 > Directory Size (DSIZ) > > The FTP command DIRECTORY SIZE (DSIZ) returns the number of octets > (8-bit bytes) on the remote file system occupied by a given directory > and its contents. A different way of providing this information, rather than creating a new FTP command, is use the size fact for a directory file in an MLST/MLSD response. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No man can justly censure or condemn another, because indeed no man truly knows another. -Sir Thomas Browne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From prvs=17954cad90=mpp@rhinosoft.com Mon Jun 28 15:44:36 2010 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 98E523A69C5 for ; Mon, 28 Jun 2010 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 CZXnW0SUCvS7 for ; Mon, 28 Jun 2010 15:44:34 -0700 (PDT) Received: from rhinosoft.com (mail1.rhinosoft.com [97.88.242.106]) by core3.amsl.com (Postfix) with ESMTP id BFAC73A6A0B for ; Mon, 28 Jun 2010 15:44:34 -0700 (PDT) X-MDAV-Processed: rhinosoft.com, Mon, 28 Jun 2010 17:44:44 -0500 Received: from MPNOTEBOOK ([209.242.229.18]) (authenticated user mpp@rhinosoft.com) by rhinosoft.com (rhinosoft.com [127.0.0.1]) (MDaemon PRO v11.0.2) with ESMTP id md50009799963.msg for ; Mon, 28 Jun 2010 17:44:42 -0500 X-Spam-Processed: rhinosoft.com, Mon, 28 Jun 2010 17:44:42 -0500 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: mpp@rhinosoft.com X-MDRemoteIP: 209.242.229.18 X-Return-Path: prvs=17954cad90=mpp@rhinosoft.com X-Envelope-From: mpp@rhinosoft.com X-MDaemon-Deliver-To: ftpext@ietf.org Message-ID: <298980E3D8B14736A76922A8B992D568@rhinooffice.net> From: "Mark P. Peterson" To: "TJ Saunders" , "Anthony Bryan" References: In-Reply-To: Date: Mon, 28 Jun 2010 17:44:41 -0500 Organization: Rhino Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: ftpext@ietf.org Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 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, 28 Jun 2010 22:44:36 -0000 The problem with that is this can be a very lengthy operation. With a separate command one already knows it's going to be lengthy. Mark P. Peterson - President http://www.RhinoSoft.com Voice: +1(262) 560-9627 FAX: +1(262) 560-9628 -------------------------------------------------- From: "TJ Saunders" Sent: Monday, June 28, 2010 5:07 PM To: "Anthony Bryan" Cc: Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 > Directory Size (DSIZ) > > The FTP command DIRECTORY SIZE (DSIZ) returns the number of octets > (8-bit bytes) on the remote file system occupied by a given directory > and its contents. A different way of providing this information, rather than creating a new FTP command, is use the size fact for a directory file in an MLST/MLSD response. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No man can justly censure or condemn another, because indeed no man truly knows another. -Sir Thomas Browne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ ftpext mailing list ftpext@ietf.org https://www.ietf.org/mailman/listinfo/ftpext From tj@castaglia.org Mon Jun 28 16:00:04 2010 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 8F1AB3A6A99 for ; Mon, 28 Jun 2010 16:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_05=-1.11] 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 oaxRzOQSHcaf for ; Mon, 28 Jun 2010 16:00:03 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id DB2A73A683F for ; Mon, 28 Jun 2010 16:00:03 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BWM63398 (AUTH via LOGINBEFORESMTP); Mon, 28 Jun 2010 16:00:08 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Mon, 28 Jun 2010 15:58:56 -0700 (PDT) From: TJ Saunders To: "Mark P. Peterson" In-Reply-To: <298980E3D8B14736A76922A8B992D568@rhinooffice.net> Message-ID: References: <298980E3D8B14736A76922A8B992D568@rhinooffice.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 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, 28 Jun 2010 23:00:04 -0000 > The problem with that is this can be a very lengthy operation. With a > separate command one already knows it's going to be lengthy. How about an OPTS MLSD request for a different fact name, e.g. 'sizd', which is apparently already used by some FTP servers? At least pure-ftpd uses such a non-standard fact. But this would give a server a chance to refuse the OPTS request, if the server policy is such that providing such a fact would be too expensive. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The years teach much which the days never know. -Ralph Waldo Emerson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From prvs=17967e4a03=mpp@rhinosoft.com Mon Jun 28 17:56:57 2010 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 C0C263A68E8 for ; Mon, 28 Jun 2010 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 0sBdQG+e41bO for ; Mon, 28 Jun 2010 17:56:57 -0700 (PDT) Received: from rhinosoft.com (mail1.rhinosoft.com [97.88.242.106]) by core3.amsl.com (Postfix) with ESMTP id CF36F3A6892 for ; Mon, 28 Jun 2010 17:56:56 -0700 (PDT) X-MDAV-Processed: rhinosoft.com, Mon, 28 Jun 2010 19:57:06 -0500 Received: from MPNOTEBOOK ([209.242.229.18]) (authenticated user mpp@rhinosoft.com) by rhinosoft.com (rhinosoft.com [127.0.0.1]) (MDaemon PRO v11.0.2) with ESMTP id md50009800021.msg for ; Mon, 28 Jun 2010 19:57:05 -0500 X-Spam-Processed: rhinosoft.com, Mon, 28 Jun 2010 19:57:05 -0500 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: mpp@rhinosoft.com X-MDRemoteIP: 209.242.229.18 X-Return-Path: prvs=17967e4a03=mpp@rhinosoft.com X-Envelope-From: mpp@rhinosoft.com X-MDaemon-Deliver-To: ftpext@ietf.org Message-ID: From: "Mark P. Peterson" To: "TJ Saunders" References: <298980E3D8B14736A76922A8B992D568@rhinooffice.net> In-Reply-To: Date: Mon, 28 Jun 2010 19:57:03 -0500 Organization: Rhino Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: ftpext@ietf.org Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 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, 29 Jun 2010 00:56:57 -0000 Seems it would be clearer to support a simple command such as DSIZ. Can be documented and understood very clearly, no complexity with the requirement of multiple commands. Mark P. Peterson - President http://www.RhinoSoft.com Voice: +1(262) 560-9627 FAX: +1(262) 560-9628 -------------------------------------------------- From: "TJ Saunders" Sent: Monday, June 28, 2010 5:58 PM To: "Mark P. Peterson" Cc: "Anthony Bryan" ; Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 > The problem with that is this can be a very lengthy operation. With a > separate command one already knows it's going to be lengthy. How about an OPTS MLSD request for a different fact name, e.g. 'sizd', which is apparently already used by some FTP servers? At least pure-ftpd uses such a non-standard fact. But this would give a server a chance to refuse the OPTS request, if the server policy is such that providing such a fact would be too expensive. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The years teach much which the days never know. -Ralph Waldo Emerson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From tj@castaglia.org Tue Jun 29 09:55:59 2010 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 DEAF03A6880 for ; Tue, 29 Jun 2010 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=1.199, 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 nr9z2Qudnx1o for ; Tue, 29 Jun 2010 09:55:58 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 685BF3A67C1 for ; Tue, 29 Jun 2010 09:55:58 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BWO84799 (AUTH via LOGINBEFORESMTP); Tue, 29 Jun 2010 09:56:04 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Tue, 29 Jun 2010 09:54:50 -0700 (PDT) From: TJ Saunders To: "Mark P. Peterson" In-Reply-To: Message-ID: References: <298980E3D8B14736A76922A8B992D568@rhinooffice.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 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, 29 Jun 2010 16:56:00 -0000 > Seems it would be clearer to support a simple command such as DSIZ. > Can be documented and understood very clearly, no complexity with the > requirement of multiple commands. It's no more or less complex to add DSIZ than to use OPTS MLST, which already exists. Adding a new DSIZ command brings up the question of the relation between the value returned for DSIZ, if any, and the reported MLSD/MLST size fact for a directory. If they differ, what is the client implementation to make of it? Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Absence is to love what wind is to fire: it extinguishes the small, it enkindles the great. -Comte de Bussy-Rabutin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From daniel@haxx.se Tue Jun 29 15:10:34 2010 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 813993A67F8 for ; Tue, 29 Jun 2010 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.990, 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 2thsPC6fOQNd for ; Tue, 29 Jun 2010 15:10:32 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 2195A3A67EA for ; Tue, 29 Jun 2010 15:10:31 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o5TMAZxA031897; Wed, 30 Jun 2010 00:10:35 +0200 Date: Wed, 30 Jun 2010 00:10:35 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: ftpext@ietf.org In-Reply-To: <20100629052221.092623A6A5C@core3.amsl.com> Message-ID: References: <20100629052221.092623A6A5C@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 X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Wed, 30 Jun 2010 00:10:35 +0200 (CEST) Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-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: Tue, 29 Jun 2010 22:10:34 -0000 On Mon, 28 Jun 2010, IETF I-D Submission Tool wrote: > A new version of I-D, draft-bryan-ftp-hash-05.txt has been successfully > submitted by Anthony Bryan and posted to the IETF repository. I think this is in a pretty good shape now. First a little mistake: The second paragraph in section 6, the first line says: "For performance reasons, a server SHOULD a avoid hashing multiple" ^^^ But I'm a bit skeptic regarding that entire sentense. It advices server implementors to care about if files are on the "same physical media" or not, and I don't think A) it is a "Security Consideration" in the first place and B) it is probably not a factor in many or most cases such as when you have SSD media, simply have the files in the cache or if you only allow 2 simultaneous users on the server. My suggestion: remove that senstense and merge the rest of the paragraph 2 with the previous paragraph. (But yes, this is nitpicking.) -- / daniel.haxx.se From anthonybryan@gmail.com Tue Jun 29 16:34:24 2010 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 ABCCA3A69C8 for ; Tue, 29 Jun 2010 16:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_40=-0.185] 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 TxRcZvodmKpK for ; Tue, 29 Jun 2010 16:34:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 416953A67EF for ; Tue, 29 Jun 2010 16:34:21 -0700 (PDT) Received: by iwn40 with SMTP id 40so211196iwn.31 for ; Tue, 29 Jun 2010 16:34:32 -0700 (PDT) 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=Pzm0iruV3ljipj14Ad1lbcWd97OtWrmuIyqlr6c2nOc=; b=sOwWO3t5qD8mUvPxOmhaiXavxKlDCjzO99AJwUmsJD4plc6TxYo3H5ryPkOwTpuFII NQo77ahpBP7F3CSrcN6fT/M1epUl9ftw06lNi0LUweORcU3kKeHbHyq0e1t5goBKeass cjcVTfn16Z8YxB6AcM8T/QN07xnvvsQvchSOY= 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=f1kKClKE9qDAA3F58IgoEPBxRKfdDOtghSPeiBz6w0m/T1mI+PgOC9eprXopzGfSll UQ3mGBQpwVxloLROzyDrWeDVF0vmQ4BW66wRWvCVEaAU2Ius0Baf3R9mxG+10Y/SKC75 140XTcSvmYPzrqY9ZpxwlrzI+Pgyow0/vOWgY= MIME-Version: 1.0 Received: by 10.231.148.73 with SMTP id o9mr8109243ibv.21.1277854472526; Tue, 29 Jun 2010 16:34:32 -0700 (PDT) Received: by 10.231.160.132 with HTTP; Tue, 29 Jun 2010 16:34:32 -0700 (PDT) In-Reply-To: References: <20100629052221.092623A6A5C@core3.amsl.com> Date: Tue, 29 Jun 2010 19:34:32 -0400 Message-ID: From: Anthony Bryan To: Daniel Stenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-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: Tue, 29 Jun 2010 23:34:24 -0000 On Tue, Jun 29, 2010 at 6:10 PM, Daniel Stenberg wrote: > On Mon, 28 Jun 2010, IETF I-D Submission Tool wrote: > >> A new version of I-D, draft-bryan-ftp-hash-05.txt has been successfully >> submitted by Anthony Bryan and posted to the IETF repository. > > I think this is in a pretty good shape now. I think we're making progress! there may be some sentences or sections out of order tho. > First a little mistake: > > The second paragraph in section 6, the first line says: > > =A0"For performance reasons, a server SHOULD a avoid hashing multiple" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0^^^ good catch, writing late at night :) > But I'm a bit skeptic regarding that entire sentense. It advices server > implementors to care about if files are on the "same physical media" or n= ot, > and I don't think A) it is a "Security Consideration" in the first place = and > B) it is probably not a factor in many or most cases such as when you hav= e > SSD media, simply have the files in the cache or if you only allow 2 > simultaneous users on the server. > > My suggestion: remove that senstense and merge the rest of the paragraph = 2 > with the previous paragraph. agreed, removed that sentence. I don't think I've seen mention of related hardware concerns in similar specs. another thing I wanted to bring up, in the HASH draft we import terms from RFC 959 like pathname and other things like the Basic Tokens, Server Replies, and Interpreting Examples from RFC 3659. after reading draft-somers-ftp-mfxx-04, maybe we should import pathname from section 2.2 of RFC 3659? another thing, should we include the hash algorithm in the server reply like Robert suggested earlier? current, without alg: C> HASH filename.ext S> 213 80bc95fd391772fa61c91ed68567f0980bb45fd9 with alg (MD5) included: C> HASH filename.ext S> 213 MD5 80bc95fd391772fa61c91ed68567f0980bb45fd9 --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From tj@castaglia.org Tue Jun 29 16:42:16 2010 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 8A8293A69F8 for ; Tue, 29 Jun 2010 16:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.960, 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 k7holutzssTY for ; Tue, 29 Jun 2010 16:42:15 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id B2E153A69F0 for ; Tue, 29 Jun 2010 16:42:15 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BWP58867 (AUTH via LOGINBEFORESMTP); Tue, 29 Jun 2010 16:42:20 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Tue, 29 Jun 2010 16:41:06 -0700 (PDT) From: TJ Saunders To: Anthony Bryan In-Reply-To: Message-ID: References: <20100629052221.092623A6A5C@core3.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-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: Tue, 29 Jun 2010 23:42:16 -0000 > another thing, should we include the hash algorithm in the server > reply like Robert suggested earlier? > > current, without alg: > > C> HASH filename.ext > S> 213 80bc95fd391772fa61c91ed68567f0980bb45fd9 > > with alg (MD5) included: > > C> HASH filename.ext > S> 213 MD5 80bc95fd391772fa61c91ed68567f0980bb45fd9 I'm favor to the latter, i.e. including the hash algorithm name in the response. It provides more information for humans who casually glance at the client output, and for server administrators reading logs which capture the entire response lines. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Music, the greatest good that mortals know, And all of heaven we have below. -Joseph Addison ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From paulfordh@uk.ibm.com Wed Jun 30 01:41:50 2010 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 1C0F13A694C for ; Wed, 30 Jun 2010 01:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.693 X-Spam-Level: X-Spam-Status: No, score=-4.693 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 khCcWr3oXTG2 for ; Wed, 30 Jun 2010 01:41:48 -0700 (PDT) Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by core3.amsl.com (Postfix) with ESMTP id BEF023A68E9 for ; Wed, 30 Jun 2010 01:41:46 -0700 (PDT) Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o5U8fu01024533 for ; Wed, 30 Jun 2010 08:41:56 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5U8fuR3770056 for ; Wed, 30 Jun 2010 09:41:56 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o5U8fu4O025461 for ; Wed, 30 Jun 2010 09:41:56 +0100 Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o5U8ft3m025445 for ; Wed, 30 Jun 2010 09:41:55 +0100 To: ftpext@core3.amsl.com MIME-Version: 1.0 X-KeepSent: 5B8F7FAC:BDF21341-80257752:00272796; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Wed, 30 Jun 2010 09:50:06 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 30/06/2010 09:50:09, Serialize complete at 30/06/2010 09:50:09 Content-Type: multipart/alternative; boundary="=_alternative 002FC28580257752_=" Subject: [ftpext] A few comments on draft-bryan-ftp-hash-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, 30 Jun 2010 08:41:50 -0000 This is a multipart message in MIME format. --=_alternative 002FC28580257752_= Content-Type: text/plain; charset="US-ASCII" Hi all, a few comments for you ... Section 1.1 I see that somebody has suggested that the 213 HASH reply includes the mechanism, may I also suggest that it includes the filespec of the hashed file (the thing passed as a parameter in the HASH command). When writing FTP script post-processing logic (as opposed to writing an FTP client) having the information on a single line is so so much easier than having to remember state as you parse the ftpout file. e.g. C> HASH filename.ext S> 213 SHA-1 80bc95fd391772fa61c91ed68567f0980bb45fd9 filename.ext Section 3 >The HASH command is meant to be used for files transmitted in Image >type mode (TYPE I) and Stream transfer mode (MODE S). The returned >hash MUST be calculated over the raw octet data of the file >irrespective of the selected data type, transfer mode or any other >state affecting the transfer. In other words, if a client were to >download a full file using TYPE I and MODE S and were to calculate >the hash on the received octet data, it would be identical to the >hash returned by HASH. Where the draft states "the raw octet data of the file", it probably needs to be making fewer assumptions about the filesystem of the server. A "file" is not necessarily a byte stream. It may have a record structure for example. I'd remove that sentence and leave it as "The returned hash MUST be calculated as if a client were to download the full file using TYPE I and MODE S and were to calculate the hash on the received octet data." In which case, one of the replies to the HASH command has to be "5xy I cannot calculate the HASH as I would not be able to deliver that file to you with TYPE I and MODE S" Section 3.1 Should there be an allowance for "private" hash algorithms? not just those defined in the IANA registry named "Hash Function Textual Names" Section 3.4 I think there needs to be the possibility of a temporary refusal to hash a file and a permanent refusal to hash a file (i.e. a 4xy if you just don't want to hash that file now and a 5xy if you will never hash that file). 4xy could be for performance; user access permissions; file is not accessible (opened by another process, being appended to ...); that HASH mechanism isn't supported on that file etc... 5xy could be for user profile (i.e. the FTP server doesn't allow this user to use the HASH command at all), trying to hash a known special file (e.g. /dev/null) etc... (with different reasons having different values of xy, as defined in RFC959 section 4.2) Section 6: >Implementing the HASH command may impose a considerable load on the >server, which could lead to denial-of-service attacks. Servers have, >however, implemented this for many years, without significant >reported difficulties. On an affected server a malicious user could, >for example, continuously send HASH commands over multiple >connections and thus consume most of the FTP server's resources, >leaving little room for other operations. To mitigate this risk, a >server SHOULD cache the calculated hashes so that the hash of a file >is only calculated once even if multiple hash requests are sent for >that file. Not sure that a protocol specification is the right place to place a SHOULD on an implementation decision like this. Also, if you do start dipping toes into the murky waters of caching, you really need to specify how to update the cached value (for example STOR /xxx.txt; HASH /xxx.txt; STOR /xxx.txt; HASH /xxx.txt should return the hash for the second version of /xxx.txt and not the cached value from the first. And there is nothing to say that the FTP server is the only thing that might amend the contents of /xxx.txt) >For performance reasons, a server SHOULD a avoid hashing multiple >files at the same time which are located on the same physical media >and SHOULD instead hash them sequentially. These two SHOULD words should be MAY. The protocol impact of this is that a client MUST allow that a HASH command might take a reasonably long time to complete. >The FTP server's right to >refuse to calculate the hash is of course important to help against >denial-of-service risks. A possible solution is to use the 450 reply >code of HASH to indicate that the server is already busy with another >HASH operation. As a protocol spec, I would re-write something like ... "A server may refuse to process a HASH command for many reasons, one of which may be a suspected denial of service attack, a client MUST be able to understand that refusal to process HASH commands may be transient (if indicated by a 4xy response) and MAY be honoured later if the server so decides." >In addition, the HASH command can be used to draw conclusions about >the contents of a file. If the hash of a file on some server matches >the hash of some known file, then both files are likely identical. >To prevent this scenario it suffices to limit use of the HASH command >to users who would already be able to download the file. I think the issue of which files a server should process a HASH command for a logged in user for is a bit bigger than this ... - I think this draft needs to be stronger about saying that a HASH command MUST only be processable for files to which the server thinks the logged in user has a right to access - There is an issue about 'drop-box' type FTP servers, where I can login, dump a file into a write-only directory and might reasonably expect to be able to confirm the file isn't broken by subsequently running a HASH command against it. In *IX world with chroot()ed environments, this won't work. The draft should not be silent about this issue. More discussion required I think >Currently, some of the hash algorithms defined in the IANA registry >named "Hash Function Textual Names" are considered insecure. These >include the whole Message Digest family of algorithms that are not >suitable for cryptographically strong verification. Malicious people >could provide files that appear to be identical to another file >because of a collision, i.e., the weak cryptographic hashes of the >intended file and a substituted malicious file could match. I'd probably re-write this along the lines that "This mechanism simply allows the FTP protocol to expose HASH values of files, using the currently chosen mechanism, accessible to the server by the client. The suitability or otherwise of a specific hash algorithm for a specific purpose is an implementation decision." I would also add some other comments ... In Security Considerations: - By uploading a file, running HASH against it and running HASH against another file location, the client could infer some filesystem deployment information (e.g. that there is a logical link between a pair of directories in the tree). Whilst this is probably not an issue if the user has access to both branches of the directory tree, the possibility that this information is exposable in this manner should be noted in Security Considerations. General comments - The draft probably needs to state what should happen if somebody attempts to HASH something that isn't a file (e.g. it's a directory) Cheers, Paul -- Paul Ford-Hutchinson CISSP - Tivoli Security Consultant IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU Tel +44 (0)7500 078379 (internal: 37269105) --=_alternative 002FC28580257752_= Content-Type: text/html; charset="US-ASCII"
Hi all, a few comments for you ...

Section 1.1

I see that somebody has suggested that the 213 HASH reply includes the mechanism, may I also suggest that it includes the filespec of the hashed file (the thing passed as a parameter in the HASH command).  When writing FTP script post-processing logic (as opposed to writing an FTP client) having the information on a single line is so so much easier than having to remember state as you parse the ftpout file.

e.g.
C> HASH filename.ext
S> 213 SHA-1 80bc95fd391772fa61c91ed68567f0980bb45fd9 filename.ext

Section 3

>The HASH command is meant to be used for files transmitted in Image
>type mode (TYPE I) and Stream transfer mode (MODE S).  The returned
>hash MUST be calculated over the raw octet data of the file
>irrespective of the selected data type, transfer mode or any other
>state affecting the transfer.  In other words, if a client were to
>download a full file using TYPE I and MODE S and were to calculate
>the hash on the received octet data, it would be identical to the
>hash returned by HASH.

Where the draft states "the raw octet data of the file", it probably needs to be making fewer assumptions about the filesystem of the server.  A "file" is not necessarily a byte stream.  It may have a record structure for example.  I'd remove that sentence and leave it as "The returned hash MUST be calculated as if a client were to download the full file using TYPE I and MODE S and were to calculate the hash on the received octet data."

In which case, one of the replies to the HASH command has to be "5xy I cannot calculate the HASH as I would not be able to deliver that file to you with TYPE I and MODE S"

Section 3.1

Should there be an allowance for "private" hash algorithms? not just those defined in the IANA registry named "Hash Function Textual Names"

Section 3.4

I think there needs to be the possibility of a temporary refusal to hash a file and a permanent refusal to hash a file (i.e. a 4xy if you just don't want to hash that file now and a 5xy if you will never hash that file).

4xy could be for performance; user access permissions; file is not accessible (opened by another process, being appended to ...); that HASH mechanism isn't supported on that file etc...
5xy could be for user profile (i.e. the FTP server doesn't allow this user to use the HASH command at all), trying to hash a known special file (e.g. /dev/null) etc...

(with different reasons having different values of xy, as defined in RFC959 section 4.2)

Section 6:

>Implementing the HASH command may impose a considerable load on the
>server, which could lead to denial-of-service attacks.  Servers have,
>however, implemented this for many years, without significant
>reported difficulties.  On an affected server a malicious user could,
>for example, continuously send HASH commands over multiple
>connections and thus consume most of the FTP server's resources,
>leaving little room for other operations.  To mitigate this risk, a
>server SHOULD cache the calculated hashes so that the hash of a file
>is only calculated once even if multiple hash requests are sent for
>that file.

Not sure that a protocol specification is the right place to place a SHOULD on an implementation decision like this.  Also, if you do start dipping toes into the murky waters of caching, you really need to specify how to update the cached value (for example STOR /xxx.txt; HASH /xxx.txt; STOR /xxx.txt; HASH /xxx.txt should return the hash for the second version of /xxx.txt and not the cached value from the first.  And there is nothing to say that the FTP server is the only thing that might amend the contents of /xxx.txt)

>For performance reasons, a server SHOULD a avoid hashing multiple
>files at the same time which are located on the same physical media
>and SHOULD instead hash them sequentially.  

These two SHOULD words should be MAY.  The protocol impact of this is that a client MUST allow that a HASH command might take a reasonably long time to complete.

>The FTP server's right to
>refuse to calculate the hash is of course important to help against
>denial-of-service risks.  A possible solution is to use the 450 reply
>code of HASH to indicate that the server is already busy with another
>HASH operation.

As a protocol spec, I would re-write something like ...

"A server may refuse to process a HASH command for many reasons, one of which may be a suspected denial of service attack, a client MUST be able to understand that refusal to process HASH commands may be transient (if indicated by a 4xy response) and MAY be honoured later if the server so decides."

>In addition, the HASH command can be used to draw conclusions about
>the contents of a file.  If the hash of a file on some server matches
>the hash of some known file, then both files are likely identical.
>To prevent this scenario it suffices to limit use of the HASH command
>to users who would already be able to download the file.

I think the issue of which files a server should process a HASH command for a logged in user for is a bit bigger than this ...

- I think this draft needs to be stronger about saying that a HASH command MUST only be processable for files to which the server thinks the logged in user has a right to access

- There is an issue about 'drop-box' type FTP servers, where I can login, dump a file into a write-only directory and might reasonably expect to be able to confirm the file isn't broken by subsequently running a HASH command against it.  In *IX world with chroot()ed environments, this won't work.  The draft should not be silent about this issue.

More discussion required I think


>Currently, some of the hash algorithms defined in the IANA registry
>named "Hash Function Textual Names" are considered insecure.  These
>include the whole Message Digest family of algorithms that are not
>suitable for cryptographically strong verification.  Malicious people
>could provide files that appear to be identical to another file
>because of a collision, i.e., the weak cryptographic hashes of the
>intended file and a substituted malicious file could match.

I'd probably re-write this along the lines that "This mechanism simply allows the FTP protocol to expose HASH values of files, using the currently chosen mechanism,  accessible to the server by the client.  The suitability or otherwise of a specific hash algorithm for a specific purpose is an implementation decision."

I would also add some other comments ...

In Security Considerations:

- By uploading a file, running HASH against it and running HASH against another file location, the client could infer some filesystem deployment information (e.g. that there is a logical link between a pair of directories in the tree).  Whilst this is probably not an issue if the user has access to both branches of the directory tree, the possibility that this information is exposable in this manner should be noted in Security Considerations.

General comments

- The draft probably needs to state what should happen if somebody attempts to HASH something that isn't a file (e.g. it's a directory)


Cheers,
Paul

--

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU

Tel +44 (0)7500 078379  (internal: 37269105) --=_alternative 002FC28580257752_=-- From tj@castaglia.org Wed Jun 30 08:11:10 2010 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 32F163A6A5B for ; Wed, 30 Jun 2010 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 pZNDGs3CP+BJ for ; Wed, 30 Jun 2010 08:10:57 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 7B71B3A69B0 for ; Wed, 30 Jun 2010 08:10:56 -0700 (PDT) Received: from familiar.netflix.com (lg-nat.corp.netflix.com [208.75.77.65]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BWR47771 (AUTH via LOGINBEFORESMTP); Wed, 30 Jun 2010 08:10:58 -0700 X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none X-Mirapoint-Received-SPF: 208.75.77.65 familiar.netflix.com 5 none Date: Wed, 30 Jun 2010 08:09:44 -0700 (PDT) From: TJ Saunders To: barryleiba@computer.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] FTP IDs 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, 30 Jun 2010 15:11:10 -0000 > Never mind; I see it, in TJ's note. TJ, since you are an original > author of the draft, you should be able to submit an -04 version and > get it revived. Can you do that by the 5 July deadline? Done. I know the submitted draft still needs work, but I wanted to make sure it was revived before July 5. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No man can justly censure or condemn another, because indeed no man truly knows another. -Sir Thomas Browne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~