From anthonybryan@gmail.com Tue Aug 3 15:29:05 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 147983A69E6 for ; Tue, 3 Aug 2010 15:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 z9gHV04QTaNz for ; Tue, 3 Aug 2010 15:29:04 -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 EAC583A6B39 for ; Tue, 3 Aug 2010 15:29:03 -0700 (PDT) Received: by iwn3 with SMTP id 3so1527421iwn.31 for ; Tue, 03 Aug 2010 15:29: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=FIocsKnWKZdJdZm7CzKddq7qH7u6vUicA+h1nvmHpMc=; b=NqU+EETrngUYrOnFAYOnZQXP+P8v1+q4PCmeu4CYU4Gr+wz6KeWHgmHFsz02xhv56a wxBVLGhMClzpvrIUklmxFy1F6+qkQZirWJsBWL8Unw3VY46icnIn1wdo146PSsMWLv9R FAMeB1WOugnPupnbehK9gvh/vqtrls8rqxRzY= 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=XA/jGmzNX8LI6y2fEZcnM8cyD2aO/r6th7SqdutQFJtU4ByOMy7N8aCa49IMGWxVKk aRcEfipT87ENh9eE+n9VFNZj6xBGSgI1rTFjKnAcmV2w138FklXYXpYqkTe3b287NCwA swao9tJ3eYnVa6M3OtaLwcOKkp0z8MLOPoMk0= MIME-Version: 1.0 Received: by 10.231.59.212 with SMTP id m20mr9369686ibh.130.1280874571192; Tue, 03 Aug 2010 15:29:31 -0700 (PDT) Received: by 10.231.159.143 with HTTP; Tue, 3 Aug 2010 15:29:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Aug 2010 18:29:31 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 03 Aug 2010 22:29:05 -0000 On Fri, Jul 30, 2010 at 3:43 PM, William F. Maton wrote: > > =A0 =A0 =A0 =A0If this WG gains traction, would RFC errata (such as the o= nes I came > across for RFC 3659) also be dealt with as part of a charter? while on the subject of errata, I've come across a few in RFC 959 that I'll be posting for verification & discussion with the group. most are editorial though. here's one: RFC 959 type The data representation type used for data transfer and storage. Type implies certain transformations between the time of data storage and data transfer. The representation types defined in FTP are described in the Section on Establishing Data Connections. Errata The representation types defined in FTP are described in Section 3.1, Data Representation and Storage, or more specifically 3.1.1, Data Types. They don't seem to be described in 3.2, Establishing Data Connections. also, RFC 1123 contains a number of updates to RFC 959 (& others). (presumably, "Updates: XXXX" wasn't in use in 1989?) should this be reported as errata to RFC 1123? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From wmaton@ottix.net Tue Aug 3 15:50:44 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 BB2E33A69EE for ; Tue, 3 Aug 2010 15:50:44 -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 1dnQx0iGjkLS for ; Tue, 3 Aug 2010 15:50:44 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id BCE963A68E9 for ; Tue, 3 Aug 2010 15:50:43 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o73Mp5Mb015914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Aug 2010 18:51:05 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o73Mp5Mb015914 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o73Mp5s4015911; Tue, 3 Aug 2010 18:51:05 -0400 Date: Tue, 3 Aug 2010 18:51:05 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 03 Aug 2010 22:50:44 -0000 On Tue, 3 Aug 2010, Anthony Bryan wrote: [snip] > Errata > The representation types defined in FTP are described in Section 3.1, > Data Representation and Storage, or more specifically 3.1.1, Data > Types. They don't seem to be described in 3.2, Establishing Data > Connections. Good catch. > also, RFC 1123 contains a number of updates to RFC 959 (& others). > (presumably, "Updates: XXXX" wasn't in use in 1989?) should this be > reported as errata to RFC 1123? My suspicion is that RFC 1123's errata discussion of RFC 959 should be reported under the new system against RFC 959, if only to capture that errata more easily. On the other hand, not knowing enough about the mechanics about handling documents of that vintage, I'd wonder if the ADs could tell us if this sets a bad precedent of some kind. (i.e., review every RFC in that light and start going off and using the errata reporting for every nit). Then again, this could open up the discussion for creating an expanded RFC 959bis ... ! Personally if RFC 1123 shows us some errata (and I admit to have never come across that RFC) in RFC 959, perhaps it's best to out it for folks really only looking at RFC 959. I wonder if a survey of RFCs that 'touch' RFC 959 in some way isn't in order? wfms From anthonybryan@gmail.com Thu Aug 5 11:48:08 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 9567C3A6A2D for ; Thu, 5 Aug 2010 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-1.192, 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 uJ62nagDrS+k for ; Thu, 5 Aug 2010 11:48:05 -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 C48C53A6A74 for ; Thu, 5 Aug 2010 11:48:04 -0700 (PDT) Received: by iwn36 with SMTP id 36so396628iwn.31 for ; Thu, 05 Aug 2010 11:48: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vAdF2/49Pha/UQRR7F+HTAofUqdx93BiV8B/nsEZjXo=; b=AFGb6oiu+yOEYdcAYat5Q6Kjk6QFBZRdurqQ14YEm2QctvsXff/oCsKRx3OAWmxaH9 fNd/7KAFES5IY2D+0GoI2OMPPQH4ef5nhIKdzrx857/GZjB8u1ZRRBktlomtN78ObtN5 x3W+GtHLivtQLsuB4lA8LWRWFDpxzUWkJqd1Y= 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=lenOCoy4o0or7jpi1PkRGQOj+350G7QmUv0GvPiaTh8ebOqH+qKkXFW8FqQUM0XVjP UdRdPgjV8AiFtjgRIZ58m9nie9c3HiKt24W9cErYOiRC1qY6AZm5rkZ5RtVLeHI6XsPj Mh/1IVtNi1OR6A+AHgZmMQJdNVTQnmZCdrLKI= MIME-Version: 1.0 Received: by 10.231.166.9 with SMTP id k9mr12279425iby.127.1281034114816; Thu, 05 Aug 2010 11:48:34 -0700 (PDT) Received: by 10.231.159.143 with HTTP; Thu, 5 Aug 2010 11:48:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Aug 2010 14:48:34 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 05 Aug 2010 18:48:08 -0000 On Tue, Aug 3, 2010 at 6:51 PM, William F. Maton wrote: > On Tue, 3 Aug 2010, Anthony Bryan wrote: > > [snip] >> >> Errata >> The representation types defined in FTP are described in Section 3.1, >> Data Representation and Storage, or more specifically 3.1.1, Data >> Types. They don't seem to be described in 3.2, Establishing Data >> Connections. > > Good catch. thanks! another... 5.3. COMMANDS The commands are Telnet character strings transmitted over the control connections as described in the Section on FTP Commands. The command functions and semantics are described in the Section on Access Control Commands, Transfer Parameter Commands, FTP Service Commands, and Miscellaneous Commands. Errata: There does not appear to be a section on Miscellaneous Commands, although SITE and NOOP are listed as "Miscellaneous Commands" in Section 5.4, Sequencing of Commands and Replies. SITE and NOOP are described in 4.1.3, FTP Service Commands. >> also, RFC 1123 contains a number of updates to RFC 959 (& others). >> (presumably, "Updates: XXXX" wasn't in use in 1989?) should this be >> reported as errata to RFC 1123? > > My suspicion is that RFC 1123's errata discussion of RFC 959 should be > reported under the new system against RFC 959, if only to capture that > errata more easily. =A0On the other hand, not knowing enough about the > mechanics about handling documents of that vintage, I'd wonder if the ADs > could tell us if this sets a bad precedent of some kind. =A0(i.e., review > every RFC in that light and start going off and using the errata reportin= g > for every nit). I'm hoping someone who knows more about the policy will provide some guidan= ce... > Then again, this could open up the discussion for creating an expanded RF= C > 959bis ... ! > > Personally if RFC 1123 shows us some errata (and I admit to have never co= me > across that RFC) in RFC 959, perhaps it's best to out it for folks really > only looking at RFC 959. > > I wonder if a survey of RFCs that 'touch' RFC 959 in some way isn't in > order? yep, RFC 959's "Updated by: 2228, 2640, 2773, 3659, 5797" obviously only mentions a couple. RFC 1123 doesn't come up on a search for "FTP" on the RFC editor site ( http://www.rfc-editor.org/rfcsearch.html ). is it authoritative? that is, does it update/supersede RFC 959? I brought it up because I might as well apply the changes to the RFC 959bis I'd been working on here are the RFCs that I found that could be added to RFC 959's Appendix III "RFCs on FTP" (aka a list of all FTP RFCs). RFC 959 "File Transfer Protocol" RFC 1123 "Requirements for Internet Hosts -- Application and Support" RFC 1415 "FTP-FTAM Gateway Specification" RFC 1545 "FTP Operation Over Big Address Records (FOOBAR)" RFC 1579 "Firewall-Friendly FTP" RFC 1635 "How to Use Anonymous FTP" RFC 1639 "FTP Operation Over Big Address Records (FOOBAR)" RFC 2228 "FTP Security Extensions" RFC 2389 "Feature negotiation mechanism for the File Transfer Protocol" RFC 2428 "FTP Extensions for IPv6 and NATs" RFC 2577 "FTP Security Considerations" RFC 2585 "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP" RFC 2640 "Internationalization of the File Transfer Protocol" RFC 2773 "Encryption using KEA and SKIPJACK" RFC 3659 "Extensions to FTP" RFC 4217 "Securing FTP with TLS" RFC 4823 "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet" RFC 5797 "FTP Command and Extension Registry" --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From wmaton@ottix.net Thu Aug 5 12:53:56 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 032BC3A6831 for ; Thu, 5 Aug 2010 12:53:56 -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 uje8LQERKSVm for ; Thu, 5 Aug 2010 12:53:55 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 079B63A690D for ; Thu, 5 Aug 2010 12:53:54 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o75JsIhr001669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Aug 2010 15:54:18 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o75JsIhr001669 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o75JsHjC001666; Thu, 5 Aug 2010 15:54:17 -0400 Date: Thu, 5 Aug 2010 15:54:17 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 05 Aug 2010 19:53:56 -0000 On Thu, 5 Aug 2010, Anthony Bryan wrote: > I'm hoping someone who knows more about the policy will provide some >guidance... +1 > RFC 1123 doesn't come up on a search for "FTP" on the RFC editor site > ( http://www.rfc-editor.org/rfcsearch.html ). is it authoritative? > that is, does it update/supersede RFC 959? I brought it up because I > might as well apply the changes to the RFC 959bis I'd been working on > here are the RFCs that I found that could be added to RFC 959's > Appendix III "RFCs on FTP" (aka a list of all FTP RFCs). Now the interesting question to ask is this: GIven the listing of RFCs, which ones have actually been adopted for use versus partially versus ignored? For that, we'd need more implementor participants I think, plus a survey of archives from the old ftpext to determine that. wfms From wmaton@ottix.net Thu Aug 5 13: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 CC7633A6902 for ; Thu, 5 Aug 2010 13:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] 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 czWb2aJ1s2IY for ; Thu, 5 Aug 2010 13:45:13 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 2A88F3A68AF for ; Thu, 5 Aug 2010 13:45:12 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o75KjfY5007060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Aug 2010 16:45:41 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o75KjfY5007060 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o75Kjfqp007057 for ; Thu, 5 Aug 2010 16:45:41 -0400 Date: Thu, 5 Aug 2010 16:45:41 -0400 (EDT) From: "William F. Maton" To: ftpext@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [ftpext] FWD: ftp/959 reboot 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, 05 Aug 2010 20:45:14 -0000 All, I'm forwarding an email from Gregory Lundberg who is the author of a couple of expired drafts from the old WG and the former maintainer of wu-ftpd. I have his permission to send the relevant extract of an offline conversation he and I have been having about FTP in general. He might join us for further observations and discussions when he is able to, but in the meantime I can summarize responses to him offline. Thanks, wfms ---------- Forwarded message ---------- Date: Wed, 28 Jul 2010 08:44:36 -0500 Subject: Re: [wuftpd-dev] Sample help output from ftpd My opinion on the restart of the FTPEXT WG is that it's time (well past it, actually) to do a reboot on the FTP specification. Anyone today who attempts to determine what the protocol *is* has to look at far to many RFCs, some offering contradictory specifications. This is unacceptable for one of the core protocols of the Internet. Over the years, some have said the FTP is a dying protocol. Mainly this comes from the HTTP camp. The problem is very few people step back and look at first-principles. Another problem is what I call "nominal realism", which is a bit of a misuse of the term. What I mean is they see the word "file" in "file transfer protocol" and presume the FTP is only meant to transfer files in the traditional meaning as a sequential dataset on computer mass storage. To understand the FTP's place in the scheme of things we first need to ask ourselves: what are the various ways we can use IP, TPC and UPD for the transmission of large streams of information. A very efficient scheme is to use a TCP channel for the control of data transmissions and separate channels for each transmisison. This is the scheme implemented by the FTP. Another scheme is to use a single channel for both control and data as in the HTTP. A little analysis shows that the scheme used by HTTP works best when a large number of relatively short transmissions are involved. But when the size (or duration) of the transmission increases, the FTP quickly becomes more efficient. A re-boot of the FTP specification should include some discussion of this. It servers both as a rationale as to why the protocol is still important, and as a guide for implementors. Some years ago, the Apache Group was quite interested in taking a look at what it would take to merge wuFTPD into the Apache code base. This turned out to not be possible because the Apache code base assumed a single channel for both control and data and could not be bent far enough to support the two-channel approach of the FTP. This, however, was a software limitation. There is no particular reason a daemon could not be designed which supports both the FTP and the HTTP. Care should be taken when specifying the operation of the FTP so as to not specify or encourage the use of a particular implementation method. If we look at the current FTP specification we see some discussion which does promote a particular design. Another thing I'd suggest looking at is avoiding any semantic meaning for the data channel. The term "file" is often used. But the data channel is just a data channel. Once established, the FTP really does not care what is sent, which direction it goes, or if data is travelling both wats at the same time. The job of the FTP is to reliably and securely establish the data channel between two resources; nothing more. Recent additions to the protocol have provded addition information about the resources. This recognized that there is more to a resource than simply it's name and establishing a reliable communication can depend upon that information. One of the great features of the FTP is the actual *EASE* with which the protocol can be realized. It is virtually impossible to have a meaningful HTTP session using Telnet. While this is little used, part of the power of the FTP is it remains possible. The great failing of the FTP also stems from its strength. The use of a second connumication channel opens the door to abuse or misdirection of that channel. When I was last active I was in the process of designing a means where the controlling client and server could exchange information about the actual channel and ensure it was not intercepted or misdirected. I imagine all work in that direction ceased. If we re-visit the protocol, however, this should be one of the goals. OK .. enough for now .. ttyl -- Greg From iljitsch@muada.com Thu Aug 5 14:18: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 BEB2F3A6A3F for ; Thu, 5 Aug 2010 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUFi35kasIrr for ; Thu, 5 Aug 2010 14:18:35 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E95FB3A68D5 for ; Thu, 5 Aug 2010 14:18:34 -0700 (PDT) Received: from iljitsch-iphone.lan (ip5653d69e.direct-adsl.nl [86.83.214.158]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o75LIF3L084077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Aug 2010 23:18:16 +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: Thu, 5 Aug 2010 23:18:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17396AEB-BB12-4D62-85AD-0A910D71E4BE@muada.com> References: <40A8C49E-EFF7-482A-B444-81EDFF41449A@muada.com> To: Anthony Bryan X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC959 update WAS Re: NAT64 client/server document 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, 05 Aug 2010 21:18:37 -0000 On 31 jul 2010, at 10:55, Anthony Bryan wrote: >> In my mind, there are two approaches to updating RFC959: >> a) As you said, update it and allow for creeping featurism; >> b) Tightly scope the update to RFC 959 to just being an updated = version >> of the protocol as it stands today according to RFCs only (not = drafts, >> not even practices out there on the Internet) and look to fixing it >> later...much later. That seems pointless. The problem with FTP is that the intersection = between specifications that are out there and software that is in = something that can reasonably called use is quite limited. I think if we = want to make a new standards track FTP spec, we should just forget all = the existing documents, especially RFC 959, and write up a lean and mean = spec that specifies FTP as it is used today. The fact that this ignores = an enormous amount of history should be taken as a feature rather than a = bug. Anyone interested in that history can always go back all the way to = RFC 114 if they want to. But if we want FTP to remain a living, = breathing protocol (which is a question worthy of discussion in the = first place) we need to remove cruft as well as add new features. We've = done the latter for more than a decade, we need to work on the former = for a while. > we now also have RFC > 5797, the FTP command & extension registry I'm missing the response code registry, though. As for the NAT64 stuff that everyone in the room in Maastricht felt must = go into a separate document, I'm now convinced that this should be a = BCP. If anyone thinks that's not the right way forward, please let me = know. From daniel@haxx.se Thu Aug 5 14:18: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 205933A6A3F for ; Thu, 5 Aug 2010 14:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-2.475, 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 lSfzsw6TbHpN for ; Thu, 5 Aug 2010 14:18:48 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 2EBEF3A6959 for ; Thu, 5 Aug 2010 14:18:47 -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 o75LJLfe026711; Thu, 5 Aug 2010 23:19:21 +0200 Date: Thu, 5 Aug 2010 23:19:21 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: "William F. Maton" 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; format=flowed; charset=US-ASCII X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Thu, 05 Aug 2010 23:19:21 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 05 Aug 2010 21:18:50 -0000 On Thu, 5 Aug 2010, William F. Maton wrote (quoting Gregory Lundberg): > Anyone today who attempts to determine what the protocol *is* has to look at > far to many RFCs, some offering contradictory specifications. This is > unacceptable for one of the core protocols of the Internet. I can only agree that the situation is muddy and far from good. > A little analysis shows that the scheme used by HTTP works best when a large > number of relatively short transmissions are involved. But when the size > (or duration) of the transmission increases, the FTP quickly becomes more > efficient. > A re-boot of the FTP specification should include some discussion of this. > It servers both as a rationale as to why the protocol is still important, > and as a guide for implementors. I read this opinion from time to time, and I'm very curious: what facts or what particular details of TCP are you backing up this statement on (realizing this statement was quoted from a secondary author)? Why would a single HTTP stream be any worse than a single FTP stream? Given a large enough file, the tiny tiny difference that the HTTP headers add vanish, and the FTP transfer typically suffers from MANY more initial RTT delays etc. So yes, I would be very interested in such a rationale. In the past I've confronted others who have said similar things, but I've not yet heard anyone provide a believable explanation. > Care should be taken when specifying the operation of the FTP so as to not > specify or encourage the use of a particular implementation method. If we > look at the current FTP specification we see some discussion which does > promote a particular design. Really? As a client implementor I've never really seen that. Perhaps I'm just too indoctrinated by it by now. Any particular wordings or phrases that stand out and explain what you mean? > Another thing I'd suggest looking at is avoiding any semantic meaning for > the data channel. The term "file" is often used. But the data channel is > just a data channel. Once established, the FTP really does not care what is > sent, which direction it goes, or if data is travelling both wats at the > same time. The job of the FTP is to reliably and securely establish the data > channel between two resources; nothing more. I agree. I supposed we could look for inspirations for this in the httpbis work. > One of the great features of the FTP is the actual *EASE* with which the > protocol can be realized. It is virtually impossible to have a meaningful > HTTP session using Telnet. While this is little used, part of the power of > the FTP is it remains possible. I find that statement rather funny and something I wouldn't agree with. A HTTP-minded person would say it exactly the same way but replace HTTP and FTP in that sentense. The fact that HTTP is a single connection still wins I'd say, and makes TELNET possible while telnetting a FTP transfer with telnet requires two telnet invokes, or with PORT something like nc or what not. > The great failing of the FTP also stems from its strength. The use of a > second connumication channel opens the door to abuse or misdirection of that > channel. My experience with the data connection: it was possibly a good idea back in the early days. It is now a bad idea due to NATs, stateful firewalls, FTP over TLS and possibly other stuff. * NATs close idling connections, and there's no way to really portably keep traffic going on the control channel while a really long and slow data transfer is in process so implementations have to deal with the control channel being killed by the NAT before the data is done. * Firewalls need to understand FTP in order to support it fully without opening up ranges for it "just in case". * When FTP traffic is sent encrypted, said firewalls don't see the FTP traffic and thus cannot act stateful so the data connection cannot get setup. -- / daniel.haxx.se From anthonybryan@gmail.com Thu Aug 5 14:31:20 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 76D8E3A6B4D for ; Thu, 5 Aug 2010 14:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 AjIvFfVMYC+u for ; Thu, 5 Aug 2010 14:31:15 -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 F22693A6A91 for ; Thu, 5 Aug 2010 14:31:14 -0700 (PDT) Received: by iwn36 with SMTP id 36so514077iwn.31 for ; Thu, 05 Aug 2010 14:31:45 -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=KrwoaLdxjj33sJ1lQn0aucPWrlgzSRU6u6iQSzvfsBw=; b=sntw3UQLGLgSdlDMPsKOCujzzIFcMjzlbkA4YChlapJnnjyBZXLLepVZHRLv0t/9FP MB8iX3UOHNgayUmRJiT/2bAC/yUe8MXzrJ29oRRlnSPBYmCfErIjIMtjB8T9g1u5iGiY c79PaswevbAVCaIbCAOyL9GCTS5HKVPe7YFrY= 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=sfXuTBHT4OfknaebkYg4t4tLpzefHIT12U3U0X6uIzyUV8+68yw0QA4jCMnA0LLe2w xLzR5AYlZRgYkUV8LJcby4Sij1kCo3Vgh2q/PE8cZ0fJZZaqhpyRuxKbFfRu0caPiHD8 tz+Vo3VZCEbpb61bGaMD4qJI8NlJlzwCeqC5k= MIME-Version: 1.0 Received: by 10.231.146.141 with SMTP id h13mr12834012ibv.1.1281043905458; Thu, 05 Aug 2010 14:31:45 -0700 (PDT) Received: by 10.231.159.143 with HTTP; Thu, 5 Aug 2010 14:31:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Aug 2010 17:31:45 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 05 Aug 2010 21:31:20 -0000 On Thu, Aug 5, 2010 at 3:54 PM, William F. Maton wrote: > On Thu, 5 Aug 2010, Anthony Bryan wrote: > >> I'm hoping someone who knows more about the policy will provide some >> guidance... > > +1 > >> RFC 1123 doesn't come up on a search for "FTP" on the RFC editor site >> ( http://www.rfc-editor.org/rfcsearch.html ). is it authoritative? >> that is, does it update/supersede RFC 959? I brought it up because I >> might as well apply the changes to the RFC 959bis I'd been working on >> here are the RFCs that I found that could be added to RFC 959's >> Appendix III "RFCs on FTP" (aka a list of all FTP RFCs). > > Now the interesting question to ask is this: =A0GIven the listing of RFCs= , > which ones have actually been adopted for use versus partially versus > ignored? =A0For that, we'd need more implementor participants I think, pl= us a > survey of archives from the old ftpext to determine that. I know people from curl, FileZilla, IIS, SmartFTP, Serv-U/FTP Voyager, and others are on this list. I've contacted others too. who else do we need to engage? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From wmaton@ottix.net Thu Aug 5 14:38:08 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 343A23A6A71 for ; Thu, 5 Aug 2010 14:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 Xprd+GwrafK8 for ; Thu, 5 Aug 2010 14:38:02 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 204863A68D5 for ; Thu, 5 Aug 2010 14:38:01 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o75LcSvt012914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Aug 2010 17:38:28 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o75LcSvt012914 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o75LcSse012911; Thu, 5 Aug 2010 17:38:28 -0400 Date: Thu, 5 Aug 2010 17:38:28 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-406846748-1619138434-1281044308=:8379" Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 05 Aug 2010 21:38:08 -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. ---406846748-1619138434-1281044308=:8379 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 5 Aug 2010, Anthony Bryan wrote: >> Now the interesting question to ask is this: =A0GIven the listing of RFC= s, >> which ones have actually been adopted for use versus partially versus >> ignored? =A0For that, we'd need more implementor participants I think, p= lus a >> survey of archives from the old ftpext to determine that. > > I know people from curl, FileZilla, IIS, SmartFTP, Serv-U/FTP Voyager, > and others are on this list. > > I've contacted others too. who else do we need to engage? I have contacted a couple of draft authors from the past to invite their=20 interest as well. We'll see if the mob gels into a working group or it=20 flies madly off in all directions. But I think that if the willingness isn't there to create a consolidation= =20 of 959 et al, then perhaps it will be a catalyst to generate new work and= =20 review other FTP work. wfms ---406846748-1619138434-1281044308=:8379-- From anthonybryan@gmail.com Mon Aug 9 12:17:18 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 724213A69C0 for ; Mon, 9 Aug 2010 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=-1.929, 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 M+1iAHCVVWJw for ; Mon, 9 Aug 2010 12:17:17 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 077843A67F2 for ; Mon, 9 Aug 2010 12:17:16 -0700 (PDT) Received: by gxk20 with SMTP id 20so2055091gxk.31 for ; Mon, 09 Aug 2010 12:17:51 -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=NlgsRUfXu0hzuHOcPZ5o7mjTQ+fu4zGhGqnwLs24pOY=; b=W5bTVdmMjvEnP+LrNVD3jAfO2IxyBnIp8B7Ju+/rHygmlY+rgi4Mv+cSjXF2+g27j2 U+y363cf0Nbg2RDsREEr8dG+z2XI7Hy8IC9ZqnsEKCMUxu5uQN7tFRgCWPjLFYIjO72j 1ffJM8lP8hHTOOaKxvXUFVJlS1r+mucdhpmas= 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=YPAjhd6KqqYzS9YvJM3LYFsoSDlPUO6tElXd6fHvLAXD5ru2Bpvp2NsF+xuNajQ2N+ DW2Lot0eYg21+FTuANn9n+u2aUTDIllEbVUXGM8OH5+bHA9ydzfBLoHj9RcxLNV3Ng71 0mC6YI+A8fTGxNhU1r3bqGqeiErSPwaR/DbN0= MIME-Version: 1.0 Received: by 10.90.80.2 with SMTP id d2mr11188803agb.44.1281381470964; Mon, 09 Aug 2010 12:17:50 -0700 (PDT) Received: by 10.231.159.143 with HTTP; Mon, 9 Aug 2010 12:17:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Aug 2010 15:17:50 -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] FWD: ftp/959 reboot 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, 09 Aug 2010 19:17:18 -0000 On Thu, Aug 5, 2010 at 5:19 PM, Daniel Stenberg wrote: > On Thu, 5 Aug 2010, William F. Maton wrote (quoting Gregory Lundberg): > >> Anyone today who attempts to determine what the protocol *is* has to loo= k >> at far to many RFCs, some offering contradictory specifications. =A0This= is >> unacceptable for one of the core protocols of the Internet. > > I can only agree that the situation is muddy and far from good. Daniel, any thoughts/insight into the RFC 1123 discussion, which appears to update RFC 959? >> Another thing I'd suggest looking at is avoiding any semantic meaning fo= r >> the data channel. =A0The term "file" is often used. =A0But the data chan= nel is >> just a data channel. =A0Once established, the FTP really does not care w= hat is >> sent, which direction it goes, or if data is travelling both wats at the >> same time. The job of the FTP is to reliably and securely establish the = data >> channel between two resources; nothing more. > > I agree. I supposed we could look for inspirations for this in the httpbi= s > work. with inspiration from httpbis, I've been working on a collection of FTP RFCs: 959, 2389, 2428, 2577 (for now). the idea would be to have an updated, coherent, harmonious document of RFCs concerning FTP along with implementation and real world info like httpbis. http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html so far, besides collecting the RFCs and errata together, there are no real changes to text. here's the changelog: Incorporate [RFC0959] Errata. Incorporate [RFC2389] FEAT at Section 4.1.4. Incorporate [RFC2428] "FTP Extensions for IPv6 and NATs" at Section 4.1= .2.1. Incorporate [RFC2577] in Section 10. Include abstract of [RFC4217] in Section 10.2. BCP 14 wording. TODO if there is interest: Determine if changes in RFC 1123 should be applied. Triage and include or reference other FTP RFCs - RFC 2228, 2640, 2773?, 3659, 4217. Update BNF to ABNF. Standardize command organization (subsections?) like EPRT/EPSV, with separated ABNF? Move the whole sentence that is Section 8 into Section 3.2? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From daniel@haxx.se Mon Aug 9 14:11: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 3878C3A69CA for ; Mon, 9 Aug 2010 14:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=-2.364, 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 gnOMIN0zR5bA for ; Mon, 9 Aug 2010 14:11:12 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id AB7A03A67B7 for ; Mon, 9 Aug 2010 14:11:11 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o79LBjXK019215; Mon, 9 Aug 2010 23:11:45 +0200 Date: Mon, 9 Aug 2010 23:11:45 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Anthony Bryan 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]); Mon, 09 Aug 2010 23:11:46 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 09 Aug 2010 21:11:13 -0000 On Mon, 9 Aug 2010, Anthony Bryan wrote: > Daniel, any thoughts/insight into the RFC 1123 discussion, which appears to > update RFC 959? Yes, it seems to update or at least clarify a lot of RFC959 details but I must admit I've never really used 1123 much as a reference. I really can't tell at this point how valuable those sections are or aren't. > with inspiration from httpbis, I've been working on a collection of > FTP RFCs: 959, 2389, 2428, 2577 (for now). I would suggest 3659 to be one of the main RFCs for any modern FTP implementation, thanks mostly to SIZE and MTDM in my own case. > http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt Very cool. I noticed how it mentions RFC3659 describes REST as an extension, but that's slightly inaccurate. RFC959 includes REST already, it was just clarified and more detailed in RFC3659. -- / daniel.haxx.se From wmaton@ottix.net Mon Aug 9 17:02:41 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 5D4C33A67B2 for ; Mon, 9 Aug 2010 17:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 OPPM+olhdyeR for ; Mon, 9 Aug 2010 17:02:40 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 034833A67A4 for ; Mon, 9 Aug 2010 17:02:39 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o7A031Ri022623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Aug 2010 20:03:01 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o7A031Ri022623 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o7A0304m022618; Mon, 9 Aug 2010 20:03:00 -0400 Date: Mon, 9 Aug 2010 20:03:00 -0400 (EDT) From: "William F. Maton" To: Daniel Stenberg In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 10 Aug 2010 00:02:41 -0000 On Mon, 9 Aug 2010, Daniel Stenberg wrote: > On Mon, 9 Aug 2010, Anthony Bryan wrote: > >> Daniel, any thoughts/insight into the RFC 1123 discussion, which appears to >> update RFC 959? > > Yes, it seems to update or at least clarify a lot of RFC959 details but I > must admit I've never really used 1123 much as a reference. I really can't > tell at this point how valuable those sections are or aren't. I'm wondering how big an exercise it would be to determine the applicability of these types of RFCs relating to FTP? But anyways... >> with inspiration from httpbis, I've been working on a collection of >> FTP RFCs: 959, 2389, 2428, 2577 (for now). > > I would suggest 3659 to be one of the main RFCs for any modern FTP > implementation, thanks mostly to SIZE and MTDM in my own case. +1 >> http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt > > Very cool. Yes well done! If 1123 has been applied in practice, then perhaps obsolete that component of 1123 as well? wfms From anthonybryan@gmail.com Mon Aug 9 20:53:55 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 EE0193A69FA for ; Mon, 9 Aug 2010 20:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 yZtAIysxbvnC for ; Mon, 9 Aug 2010 20:53:53 -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 9D3613A69D9 for ; Mon, 9 Aug 2010 20:53:53 -0700 (PDT) Received: by iwn36 with SMTP id 36so4372485iwn.31 for ; Mon, 09 Aug 2010 20:54: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=Jel9h/gBB906lu9RDH0i6F8Yng/lV2Ap0dGSSaFbhYs=; b=LhJ/ivogRkTtpBaJX3pme+cxannBhTXDwlLYeg88BV9oXNOYZdfnFvvTOa6pzXlQdy Mfi5R6S/P3ssO6XGmyHm2K8bsk2q+3q7F3gTGvIXr3R6K7zhqilriMuuXp5qQUYrauU5 GZG1OXqnLHkdl0a1ypwBH6YZgHq+Pim5ypTyc= 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=tg5wGaVMqMubf1E3rV1I669qDov59qu6fpxw+01HJOP8D5fjIkyxQ090Hf2AfULqJi 1IYXn4kfI78odcpLOD/we3FV1wap6yN0txJxxVbrzVgF9Gr6i9wAAykJpbwKMnp37eQm oRFmVIzxUJhTY3vbI8iBVM5ZKVXCc4+awSm2c= MIME-Version: 1.0 Received: by 10.231.30.134 with SMTP id u6mr19674362ibc.121.1281412468259; Mon, 09 Aug 2010 20:54:28 -0700 (PDT) Received: by 10.231.159.143 with HTTP; Mon, 9 Aug 2010 20:54:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Aug 2010 23:54:28 -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] FWD: ftp/959 reboot 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, 10 Aug 2010 03:53:55 -0000 On Mon, Aug 9, 2010 at 5:11 PM, Daniel Stenberg wrote: > On Mon, 9 Aug 2010, Anthony Bryan wrote: > >> Daniel, any thoughts/insight into the RFC 1123 discussion, which appears >> to update RFC 959? > > Yes, it seems to update or at least clarify a lot of RFC959 details but I > must admit I've never really used 1123 much as a reference. I really can'= t > tell at this point how valuable those sections are or aren't. it would be nice to know how authoritative they are. it sounds like at least some people are not familiar w/ 1123. I only came across it after digging deep into stuff. now reading RFC 3659 more in depth, it at least treats it as more up to date than 959 in Section 5: Note that there are some flaws in the description of the restart mechanism in STD 9, RFC 959 [3]. See section 4.1.3.4 of RFC 1123 [9] for the corrections. >> with inspiration from httpbis, I've been working on a collection of >> FTP RFCs: 959, 2389, 2428, 2577 (for now). > > I would suggest 3659 to be one of the main RFCs for any modern FTP > implementation, thanks mostly to SIZE and MTDM in my own case. 3659's absence is only due to my laziness. :) getting these old RFCs into xml2rfc shape (even with rfc2xml) takes me quite a long time. the sheer length of 3659 & the fact that no one might be interested kept me from including it. it adds about 50 pages and is now included. >> http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt > > Very cool. thanks! > I noticed how it mentions RFC3659 describes REST as an extension, but tha= t's > slightly inaccurate. RFC959 includes REST already, it was just clarified = and > more detailed in RFC3659. thanks. I removed the original description from the 959 text so it is not duplicated. if I kept working on this, I would introduce some uniformity to the commands section. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Mon Aug 9 21:02:28 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 DED9D3A681F for ; Mon, 9 Aug 2010 21:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 xifrcxaFygNg for ; Mon, 9 Aug 2010 21:02:25 -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 7B7523A6A04 for ; Mon, 9 Aug 2010 21:02:25 -0700 (PDT) Received: by iwn36 with SMTP id 36so4379619iwn.31 for ; Mon, 09 Aug 2010 21:03:00 -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=GBdQoOUL50aGFEtTn861eh431TXtj1+6ghUpWoMe1I8=; b=t7rlOcL7+08y6frx1T7q72qYu3siwmiTdjgB0SOYsxGAjoX8KS+pBEz1PprEPtahtl 6OYJRMG7d8ZM4K3sDVQeGgeYFJnIScfs92ldXRzhwdN1H9jIi6Iko5O0XOd8ubXvEzgV YAptUQA1A2G1nO8b4H8hXeMMyThbasnUOxM4Q= 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=ucuaL3ZVjGsaLIJV1QlTRlVWgslKFue/guLUG5b0/x/oRfv2Bcm8Hm7k5QoQJc9SfI 6mV7uuKyx2rRW5KqRK7LJOPp9dtgS9z1NPVy6yQmxy9Drli3gCK2MZQeSJgkpI9d+Rra rcJ+gk0KHVF+YEt1XW9yrbdeiYq916Ke9+bJc= MIME-Version: 1.0 Received: by 10.231.169.149 with SMTP id z21mr20129690iby.11.1281412980176; Mon, 09 Aug 2010 21:03:00 -0700 (PDT) Received: by 10.231.159.143 with HTTP; Mon, 9 Aug 2010 21:03:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Aug 2010 00:03:00 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 10 Aug 2010 04:02:28 -0000 On Mon, Aug 9, 2010 at 8:03 PM, William F. Maton wrote: > On Mon, 9 Aug 2010, Daniel Stenberg wrote: > >> On Mon, 9 Aug 2010, Anthony Bryan wrote: >> >>> Daniel, any thoughts/insight into the RFC 1123 discussion, which appear= s >>> to update RFC 959? >> >> Yes, it seems to update or at least clarify a lot of RFC959 details but = I >> must admit I've never really used 1123 much as a reference. I really can= 't >> tell at this point how valuable those sections are or aren't. > > I'm wondering how big an exercise it would be to determine the applicabil= ity > of these types of RFCs relating to FTP? =A0But anyways... which RFCs besides 1123? 1123 only has about 15 pages dealing w/ FTP, I hope there should be enough of us here to determine what's still valid? >>> http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt >> >> Very cool. > > Yes well done! =A0If 1123 has been applied in practice, then perhaps obso= lete > that component of 1123 as well? thanks! I haven't applied 1123 to what I'm working on yet. do you mean "Obsoletes: 1123"? if so, I don't think that's possible. "Updates:" might be more correct, as 1123 contains much more than those few pages on FTP. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From wmaton@ottix.net Tue Aug 10 03:08:44 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 EED443A686E for ; Tue, 10 Aug 2010 03:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 2FbpMyMgH5oS for ; Tue, 10 Aug 2010 03:08:43 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id C7F173A680D for ; Tue, 10 Aug 2010 03:08:42 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o7AA9C6F026674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 06:09:12 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o7AA9C6F026674 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o7AA99kD026668; Tue, 10 Aug 2010 06:09:09 -0400 Date: Tue, 10 Aug 2010 06:09:09 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-406846748-283837737-1281434949=:24469" Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 10 Aug 2010 10:08:44 -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. ---406846748-283837737-1281434949=:24469 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 10 Aug 2010, Anthony Bryan wrote: >> I'm wondering how big an exercise it would be to determine the applicabi= lity >> of these types of RFCs relating to FTP? =A0But anyways... > > which RFCs besides 1123? Speaking generally of course. > I haven't applied 1123 to what I'm working on yet. > > do you mean "Obsoletes: 1123"? if so, I don't think that's possible. > "Updates:" might be more correct, as 1123 contains much more than > those few pages on FTP. I'm grasping at appropriate IETF terminology, but yes, something along the= =20 line of either obsoletes just that part of RFC 1123, or updates 1123,=20 whichever conveys the idea best. wfms ---406846748-283837737-1281434949=:24469-- From wmaton@ottix.net Tue Aug 10 10:11:42 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 D11613A6A8A for ; Tue, 10 Aug 2010 10:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 KGHbZS0Nh76s for ; Tue, 10 Aug 2010 10:11:36 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id BCBDF3A67E2 for ; Tue, 10 Aug 2010 10:11:35 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o7AHC2xe010229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 13:12:02 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o7AHC2xe010229 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o7AHBxvI010204; Tue, 10 Aug 2010 13:12:00 -0400 Date: Tue, 10 Aug 2010 13:11:59 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 10 Aug 2010 17:11:42 -0000 On Mon, 9 Aug 2010, Anthony Bryan wrote: > On Mon, Aug 9, 2010 at 5:11 PM, Daniel Stenberg wrote: >> On Mon, 9 Aug 2010, Anthony Bryan wrote: >> >>> Daniel, any thoughts/insight into the RFC 1123 discussion, which appears >>> to update RFC 959? >> >> Yes, it seems to update or at least clarify a lot of RFC959 details but I >> must admit I've never really used 1123 much as a reference. I really can't >> tell at this point how valuable those sections are or aren't. > > it would be nice to know how authoritative they are. it sounds like at > least some people are not familiar w/ 1123. I only came across it > after digging deep into stuff. So I've had another read of RFC 1123 4.1 coming from a different light. All it seems to do is clarify what implementors of RFC 959 should be supporting. "RFC 959 was SO barebones as to leave interpretation wide open, so he's a clarifcation on what to do to make FTP servers and clients right so they work." But I'm speculating because despite my efforts at looking for context (mailing lists, emails on the Internet), the RFC itself is all we have to go on. If we look at 4.1.5 then we have an idea of what RFC 1123 is trying to say and perhaps compare that to the post Oct 1989 outcome: Have implementations of the succeeding decade adopted any of that. Didn't someone here once say that a working group on FTP would require a lot of work? :-) > Note that there > are some flaws in the description of the restart mechanism in STD 9, > RFC 959 [3]. See section 4.1.3.4 of RFC 1123 [9] for the > corrections. OK, so FTPbis 'updates' RFC 1123, not obsoletes it. > sheer length of 3659 & the fact that no one might be interested kept > me from including it. it adds about 50 pages and is now included. I'll have another look. wfms From anthonybryan@gmail.com Tue Aug 10 18:31: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 007443A6877 for ; Tue, 10 Aug 2010 18:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 TcOc4hYzcfvY for ; Tue, 10 Aug 2010 18:31:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 24CD73A6967 for ; Tue, 10 Aug 2010 18:31:08 -0700 (PDT) Received: by yxj4 with SMTP id 4so4802307yxj.31 for ; Tue, 10 Aug 2010 18:31:44 -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=hXNqE+EpquIPyKF84x0vk4ZM0UTLWk1Xhzb2LoQG02I=; b=LBbM8KycXdNvrP7SlyLnuyQHNLwhNA2l9dOub+Cp1EAH/mQjLqZm8N5PZhX6hthFAl A5O45i7hutgRrhMdEWkhFpM7QlJYSbKh0HtS8T4nufnFNE5awSiqoRSES1uw8VhxK5em /yjd4KOkmd31qCLiTborEcgvXpbo/bM/WHsgU= 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=PiPqqOE3RwqzkPMSrEViJrHXYwGL5Sa9SID7mDYy+NzR/kQ3oK8N16pNECqdoiLgRS SCxe/GdN4ZfVukXGbMdZpX3gmEEsfmg/2FCEgm/N6Qb/FtGFNCfjfEW0BKQ/+32ZM9dM DLS+AWNXAjOqdf5QTE5DTr67mj2//6G4Hd9a4= MIME-Version: 1.0 Received: by 10.100.226.20 with SMTP id y20mr7878746ang.88.1281490303945; Tue, 10 Aug 2010 18:31:43 -0700 (PDT) Received: by 10.100.132.2 with HTTP; Tue, 10 Aug 2010 18:31:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Aug 2010 21:31:43 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 11 Aug 2010 01:31:15 -0000 On Tue, Aug 10, 2010 at 1:11 PM, William F. Maton wrote: > On Mon, 9 Aug 2010, Anthony Bryan wrote: > >> On Mon, Aug 9, 2010 at 5:11 PM, Daniel Stenberg wrote: >>> >>> On Mon, 9 Aug 2010, Anthony Bryan wrote: >>> >>>> Daniel, any thoughts/insight into the RFC 1123 discussion, which appea= rs >>>> to update RFC 959? >>> >>> Yes, it seems to update or at least clarify a lot of RFC959 details but= I >>> must admit I've never really used 1123 much as a reference. I really >>> can't >>> tell at this point how valuable those sections are or aren't. >> >> it would be nice to know how authoritative they are. it sounds like at >> least some people are not familiar w/ 1123. I only came across it >> after digging deep into stuff. > > So I've had another read of RFC 1123 4.1 coming from a different light. A= ll > it seems to do is clarify what implementors of RFC 959 should be supporti= ng. > =A0"RFC 959 was SO barebones as to leave interpretation wide open, so he'= s a > clarifcation on what to do to make FTP servers and clients right so they > work." > > But I'm speculating because despite my efforts at looking for context > (mailing lists, emails on the Internet), the RFC itself is all we have to= go > on. I contacted the author, perhaps we'll hear from him. reading RFC 3659 more, it refers to "STD 9, RFC 959 and STD 3, RFC 1123" as if they're to be taken together. > If we look at 4.1.5 then we have an idea of what RFC 1123 is trying to sa= y > and perhaps compare that to the post Oct 1989 outcome: =A0Have implementa= tions > of the succeeding decade adopted any of that. can some implementors chime in? > Didn't someone here once say that a working group on FTP would require a = lot > of work? :-) nahhh! :) >> =A0Note that there >> =A0are some flaws in the description of the restart mechanism in STD 9, >> =A0RFC 959 [3]. =A0See section 4.1.3.4 of RFC 1123 [9] for the >> =A0corrections. > > OK, so FTPbis 'updates' RFC 1123, not obsoletes it. > >> sheer length of 3659 & the fact that no one might be interested kept >> me from including it. it adds about 50 pages and is now included. > > I'll have another look. I merged in the changes from RFC 1123 now: http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From wmaton@ottix.net Tue Aug 10 19:05:22 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 108103A68CE for ; Tue, 10 Aug 2010 19:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 6JUn28x5K+iO for ; Tue, 10 Aug 2010 19:05:20 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 552943A68E0 for ; Tue, 10 Aug 2010 19:05:19 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o7B25eIh004283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 22:05:41 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o7B25eIh004283 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o7B25eEH004280; Tue, 10 Aug 2010 22:05:40 -0400 Date: Tue, 10 Aug 2010 22:05:40 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-406846748-1204631343-1281492340=:1146" Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 11 Aug 2010 02:05:22 -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. ---406846748-1204631343-1281492340=:1146 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 10 Aug 2010, Anthony Bryan wrote: >> But I'm speculating because despite my efforts at looking for context >> (mailing lists, emails on the Internet), the RFC itself is all we have t= o go >> on. > > I contacted the author, perhaps we'll hear from him. > > reading RFC 3659 more, it refers to "STD 9, RFC 959 and STD 3, RFC > 1123" as if they're to be taken together. And then there's RFC 1579 which makes a brief mention of RFC 1123. So I=20 think I'm starting to gain a historical context. >> If we look at 4.1.5 then we have an idea of what RFC 1123 is trying to s= ay >> and perhaps compare that to the post Oct 1989 outcome: =A0Have implement= ations >> of the succeeding decade adopted any of that. > > can some implementors chime in? (switching hats) I'm searching through the wu-ftpd mail archives (such as I have them) and= =20 see a few mentions about RFC 1123 and I see mentions of v 2.5.0 supporting= =20 that...I'm just wondering if we're not arguing the obvious in that RFC=20 1123 found its way into implementations in one way or another 15-20 years= =20 ago and all this is a moot discussion now? > I merged in the changes from RFC 1123 now: > > http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt > http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html Cool, thanks! > > --=20 > (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] > =A0 )) Easier, More Reliable, Self Healing Downloads > wfms ---406846748-1204631343-1281492340=:1146-- From anthonybryan@gmail.com Sun Aug 15 12:49:53 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 D7ABE3A6819 for ; Sun, 15 Aug 2010 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-0.483, 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 8sOkTpKozIhx for ; Sun, 15 Aug 2010 12:49:52 -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 9A94F3A66B4 for ; Sun, 15 Aug 2010 12:49:52 -0700 (PDT) Received: by iwn3 with SMTP id 3so1010649iwn.31 for ; Sun, 15 Aug 2010 12:50: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=w8ZNp8vtQ1nMuuDpAznhFd9anzBdp0n+YjQvVc15Das=; b=OH4/PrHM1mbF6YMRmeYq82lhHR1oVA7FbDpUhR1uk554qBS9pmyg/GaDcYqWWE8h1T e5305ijNd8TFHruidusgJE9QE03PL54bfCkxDnpTy2CwUe0M9tMFxgfqHI7dEAQEzKV0 MfTcmycGUAIz7JQ/no9vVfQM1bvJn3FU2NgWE= 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=KmlUpG8UKOX2R2S2MPSpEQNVP8dyRdmn+FsU9ihTO3fM7ICmtlmYJWNWJZikuk7q+S HqJoo5s+oQLziWH7COosjtK5wnhg7GixYfUBmnOMkeBpHVpdTKVZrVMzZBx4S9Wx6Jlz 5CdPM/SBdJ7IsN8NdRvRHdixMXhnfmz1QWqA0= MIME-Version: 1.0 Received: by 10.231.12.136 with SMTP id x8mr4520510ibx.54.1281901827942; Sun, 15 Aug 2010 12:50:27 -0700 (PDT) Received: by 10.231.170.212 with HTTP; Sun, 15 Aug 2010 12:50:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 Aug 2010 15:50:27 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 15 Aug 2010 19:49:53 -0000 On Tue, Aug 10, 2010 at 10:05 PM, William F. Maton wrote= : > On Tue, 10 Aug 2010, Anthony Bryan wrote: > >>> But I'm speculating because despite my efforts at looking for context >>> (mailing lists, emails on the Internet), the RFC itself is all we have = to >>> go >>> on. >> >> I contacted the author, perhaps we'll hear from him. >> >> reading RFC 3659 more, it refers to "STD 9, RFC 959 and STD 3, RFC >> 1123" as if they're to be taken together. > > And then there's RFC 1579 which makes a brief mention of RFC 1123. =A0So = I > think I'm starting to gain a historical context. > >>> If we look at 4.1.5 then we have an idea of what RFC 1123 is trying to >>> say >>> and perhaps compare that to the post Oct 1989 outcome: =A0Have >>> implementations >>> of the succeeding decade adopted any of that. >> >> can some implementors chime in? > > (switching hats) > > I'm searching through the wu-ftpd mail archives (such as I have them) and > see a few mentions about RFC 1123 and I see mentions of v 2.5.0 supportin= g > that...I'm just wondering if we're not arguing the obvious in that RFC 11= 23 > found its way into implementations in one way or another 15-20 years ago = and > all this is a moot discussion now? Bob Braden, RFC 1123 author, says that 1123 indeed "Updates: 959" but updates wasn't applied as religiously in 1988 as it is now. I think this is worth correcting, at least in errata or something similar (if not a new document like the one I've been working on) so people can find the updates & know about the changes. current implementations are probably mostly fine. the way things are, someone working on a new FTP app wouldn't even know 1123 existed. >> I merged in the changes from RFC 1123 now: >> >> http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt >> http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html > > Cool, thanks! my pleasure! --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From tim.kosse@filezilla-project.org Sun Aug 15 14:29: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 42A273A68D5 for ; Sun, 15 Aug 2010 14:29:31 -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 Cr+Zx8Nfbw52 for ; Sun, 15 Aug 2010 14:28:51 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id C54693A67EE for ; Sun, 15 Aug 2010 14:28:50 -0700 (PDT) Received: from p5795cd60.dip.t-dialin.net ([87.149.205.96] helo=[192.168.0.59]) by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Okklg-0006iL-9B; Sun, 15 Aug 2010 23:29:25 +0200 Message-ID: <4C685C23.9000801@filezilla-project.org> Date: Sun, 15 Aug 2010 23:29:07 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Anthony Bryan References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFB84DA11F26BE61E503DD20" Cc: "ftpext@ietf.org" Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 15 Aug 2010 21:29:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFB84DA11F26BE61E503DD20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-08-11 03:31, Anthony Bryan wrote: >> If we look at 4.1.5 then we have an idea of what RFC 1123 is trying >> to say and perhaps compare that to the post Oct 1989 outcome: Have >> implementations of the succeeding decade adopted any of that. >=20 > can some implementors chime in? I have been aware of RFC 1123 but haven't taken it much into consideration when implementing FileZilla (Server). Most of the points from RFC 1123 either were irrelevant for the implementation (e.g. 4.1.2.2, 4.1.3.4. ...) or were already a well-established best-practice most if not all popular implementations implicitly adhere to (e.g. 4.1.2.5, 4.1.2.6) Even though rare, there are still clients out there that use commands like XCWD (4.1.3.1) and TYPE L 8 (4.1.2.1). It appears that mostly (only?) legacy mainframe systems are using these commands, I haven't actually seen these commands being used by any modern client. Personally I would gladly see some parts of FTP obsoleted with other parts updated. Without going into the details too much, I would like to obsolete the following: - All TYPEs other than I and A - All MODES other than S (while the proposed MODE Z is a nice idea, I don't think it is relevant anymore, internet bandwidth has increased substantially since the first MODE Z draft was introduced) - All STRUs other than F and the related SNMT command - Telnet IP and Synch signals - XCWD and related commands On the updated part I would like to see - Mandatory UTF-8 support - Mandatory MLSD - Mandatory TVFS would be nice While it would definitely break compatibility with old implementations, it would greatly simplify the protocol. I wonder if it is even possible or desired to change FTP in such a drastic way or if that is a clear no-g= o. Tim --------------enigDFB84DA11F26BE61E503DD20 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxoXCkACgkQ8N9+lcqiUkWyFgCdGm36Hkzf5NQyo2KFjy/XFULV ECsAniX7sEhfnkCszyI7MZeoIfL+TO9k =/szl -----END PGP SIGNATURE----- --------------enigDFB84DA11F26BE61E503DD20-- From anthonybryan@gmail.com Sun Aug 15 15:17: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 E193C3A67EE for ; Sun, 15 Aug 2010 15:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, 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 m-1K5FAfx786 for ; Sun, 15 Aug 2010 15:17:20 -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 C3BBF3A67A2 for ; Sun, 15 Aug 2010 15:17:20 -0700 (PDT) Received: by iwn3 with SMTP id 3so1110496iwn.31 for ; Sun, 15 Aug 2010 15:17:57 -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=XZmCwFI7fb8yfVeFiWGSQpDJ+uDfurcMvFGVvxIM+FQ=; b=kVFhhmUO722a1Kz9qEKJ2GBiOx5mG0L5NLee1tVpYEA9HcgJ0gcz6q6uvJ/fZXXeK0 DdQbNlt5rt5cK8wLkpPkSnA5TxPj3rGb/lnRJacQyEuNbryhDzYOOzvhZY7MpioDRETt GsT3u0lyPVKpkKMzSlU0Sg59hcEH/xg578qDk= 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=EE4JprfSUX6sQVaNc6coj9cuDEE37uHNPiu2z8ah7dZq13J9TuJEl6OX3JdjQagIaT YV3KXuEkGPreaA78sJBl9qOxwXMNYb7W25fdl+sqfRwj1zkzEUk194SITT1luPyrKaQM p4crAJeImGjgikHH12FkhlIGSm8CUkx4p/ITQ= MIME-Version: 1.0 Received: by 10.231.15.70 with SMTP id j6mr4560406iba.141.1281910676684; Sun, 15 Aug 2010 15:17:56 -0700 (PDT) Received: by 10.231.170.212 with HTTP; Sun, 15 Aug 2010 15:17:56 -0700 (PDT) Date: Sun, 15 Aug 2010 18:17:56 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [ftpext] ftpbis 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, 15 Aug 2010 22:17:22 -0000 hi everybody, I posted this before in another thread but wanted to gauge if more than two people are interested. with inspiration from httpbis, I've been working on a collection of FTP RFCs: 959, 1123, 2389, 2428, 2577, 3659. the idea would be to have an updated, coherent, harmonious document of RFCs concerning FTP along with implementation and real world info like httpbis. http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.txt http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html in my completely unbiased opinion :), this is already an improvement in that most (?) important FTP information is in one document that is updated instead of 6-8 RFCs developed over a period of 25 years. (reading them is like digital archaeology). the drawback is that it is a long document, and would require more work to finish. so far, besides collecting the RFCs and errata together, there are no real changes to the text except where noted. here's the changelog/TODO: Changelog from RFC 959. Incorporate [RFC0959] Errata. Incorporate FTP specific clarifications (Sec 4.1) from [RFC1123] =93Requirements for Internet Hosts - Application and Support=94 into the various sections that it updated. Incorporate [RFC2389] =93Feature negotiation mechanism for the File Transfer Protocol=94 at Section 4.1.4. Incorporate [RFC2428] "FTP Extensions for IPv6 and NATs" at Section 4.1= .2.1. Incorporate [RFC2577] "FTP Security Considerations" in Section 10. Incorporate [RFC3659] "Extensions to FTP" Section 3 through Section 9 in Section 4.1.5 and its Section 2 into Section 2. Include abstract of [RFC4217] =93Securing FTP with TLS=94 in Section 10= .2. Update Appendix C to include all known FTP RFCs. Use BCP 14/[RFC2119] key words in text from [RFC0959] sections. TODO BCP 14/[RFC2119] key words incomplete. [RFC3659] references currently incomplete; also, [RFC3659] internal references to section 10 (which is not included in this draft) are not updated. Triage and include or reference other FTP RFCs: [RFC2228] (more reply codes and reply type 6yz), [RFC2640], 2773?, [RFC4217]. File recently found errata to older RFCs. Figure out if [RFC1123] errata should be filed against itself ("Updates: 959") or to [RFC0959] ("Updated by: 1123"). Update BNF to ABNF. Should we organize commands in a standard format (subsections?) like EPRT/EPSV (Section 4.1.2.1), with separated ABNF? Should we update IP Address:Port description to ABNF? Or standardize on one example: h1,h2,h3,h4,p1,p2 or A1,A2,A3,A4,a1,a2? Should we move the whole sentence that is Section 8 into Section 3.2? Should we deprecate features that are no longer common? Should we obsolete outdated RFCs (like 1639) with "Obsoletes:"? Should we use old IPR value because we're using old text? Are the author listing/credits in compound document done correctly? Some are deceased or inactive or may be otherwise hard to contact. any strong feelings one way or the other? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Sun Aug 15 15:54:37 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 E45443A6836 for ; Sun, 15 Aug 2010 15:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 ogzeHGKNmHfA for ; Sun, 15 Aug 2010 15:54:36 -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 A80A33A6835 for ; Sun, 15 Aug 2010 15:54:36 -0700 (PDT) Received: by iwn3 with SMTP id 3so1133709iwn.31 for ; Sun, 15 Aug 2010 15:55:12 -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=icdBOP/66V/5HYck7b1Y1JluIQPtFP087O4lFjpVwPk=; b=udUfno3iYKTcMfGi0e5zEPwBZRl3URKpGIf7k0uatwlghnNg2ZMeXT66tDzJxIPvik MladJSiVDJJ1PUB5aqUZcyD4aLEueDHnIcKQCHsLtMy/0XXDgiYBVzts254tbASV+7su YP8ruQK3803Sef2kBOX8eDuC9kp65mB6DNQzk= 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=wepnpr7FUdKKL9NX0CORuKbQhpYAl9X3Hw+i0OYYgZ/73rZcMjVkUdx31ewzxhq/5F ob4wd4JxNl8njQkrEBum9UOh8/ctRi0hTYcuG0ImwfgNhWGKBoST7ooI+wvnyJXGSnJF a0lX8Ea4E5ueszG4idJvVGVE1GhPJ2LFTvKFk= MIME-Version: 1.0 Received: by 10.231.152.143 with SMTP id g15mr4968181ibw.76.1281912912667; Sun, 15 Aug 2010 15:55:12 -0700 (PDT) Received: by 10.231.170.212 with HTTP; Sun, 15 Aug 2010 15:55:12 -0700 (PDT) In-Reply-To: <4C685C23.9000801@filezilla-project.org> References: <4C685C23.9000801@filezilla-project.org> Date: Sun, 15 Aug 2010 18:55:12 -0400 Message-ID: From: Anthony Bryan To: Tim Kosse Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 15 Aug 2010 22:54:38 -0000 On Sun, Aug 15, 2010 at 5:29 PM, Tim Kosse wrote: > On 2010-08-11 03:31, Anthony Bryan wrote: >>> If we look at 4.1.5 then we have an idea of what RFC 1123 is trying >>> to say and perhaps compare that to the post Oct 1989 outcome: =A0Have >>> implementations of the succeeding decade adopted any of that. >> >> can some implementors chime in? > > I have been aware of RFC 1123 but haven't taken it much into > consideration when implementing FileZilla (Server). > > Most of the points from RFC 1123 either were irrelevant for the > implementation (e.g. 4.1.2.2, 4.1.3.4. ...) or were already a > well-established best-practice most if not all popular implementations > implicitly adhere to (e.g. 4.1.2.5, 4.1.2.6) > > Even though rare, there are still clients out there that use commands > like XCWD (4.1.3.1) and TYPE L 8 (4.1.2.1). It appears that mostly > (only?) legacy mainframe systems are using these commands, I haven't > actually seen these commands being used by any modern client. > > > > Personally I would gladly see some parts of FTP obsoleted with other > parts updated. > > Without going into the details too much, I would like to obsolete the > following: > - All TYPEs other than I and A > - All MODES other than S (while the proposed MODE Z is a nice idea, I > don't think it is relevant anymore, internet bandwidth has increased > substantially since the first MODE Z draft was introduced) > - All STRUs other than F and the related SNMT command > - Telnet IP and Synch signals > - XCWD and related commands > > On the updated part I would like to see > - Mandatory UTF-8 support > - Mandatory MLSD > - Mandatory TVFS would be nice > > While it would definitely break compatibility with old implementations, > it would greatly simplify the protocol. I wonder if it is even possible > or desired to change FTP in such a drastic way or if that is a clear no-g= o. thanks, Tim. I think drastic changes to FTP are a no-go. drastic changes belong in new protocols (SPDY etc). what I am proposing is deprecating things that are no longer in use and recommending best practices. the nearly 40 year history of FTP makes obsoleting things that may not really be obsolete troublesome. but I think we can do a lot to help possible new implementors. for instance, regarding XCWD and related that you mention, we can keep the original text from RFC 1123: All FTP implementations SHOULD recognize both forms of these commands, by simply equating them with extra entries in the command lookup table. change the above to "FTP server" and add something like: All FTP client implementations SHOULD NOT send these deprecated commands. that way we preserve compatibility. similarly, we may not be able to add new things that are mandatory (MUST/REQUIRED). but we can certainly use SHOULD/RECOMMENDED for those things that all modern implementations SHOULD support. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From paulfordh@uk.ibm.com Mon Aug 16 02:47:06 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 F07733A69A4 for ; Mon, 16 Aug 2010 02:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fKlj3YdRoBQh for ; Mon, 16 Aug 2010 02:47:05 -0700 (PDT) Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by core3.amsl.com (Postfix) with ESMTP id 527F53A699E for ; Mon, 16 Aug 2010 02:47:04 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o7G9lbwh004234 for ; Mon, 16 Aug 2010 09:47:37 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7G9lab42183202 for ; Mon, 16 Aug 2010 10:47:36 +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 o7G9larg032488 for ; Mon, 16 Aug 2010 10:47:36 +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 o7G9lZZr032466; Mon, 16 Aug 2010 10:47:35 +0100 In-Reply-To: <4C685C23.9000801@filezilla-project.org> References: <4C685C23.9000801@filezilla-project.org> To: Tim Kosse MIME-Version: 1.0 X-KeepSent: CA35852F:D4B1CD2F-80257781:00339E13; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Mon, 16 Aug 2010 10:48:16 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 16/08/2010 10:48:17, Serialize complete at 16/08/2010 10:48:17 Content-Type: multipart/alternative; boundary="=_alternative 00347FCA80257781_=" Cc: "ftpext@ietf.org" Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 16 Aug 2010 09:47:07 -0000 This is a multipart message in MIME format. --=_alternative 00347FCA80257781_= Content-Type: text/plain; charset="US-ASCII" Tim Kosse wrote on 15/08/2010 22:29:07: > > Personally I would gladly see some parts of FTP obsoleted with other > parts updated. > > Without going into the details too much, I would like to obsolete the > following: > - All TYPEs other than I and A > - All MODES other than S (while the proposed MODE Z is a nice idea, I > don't think it is relevant anymore, internet bandwidth has increased > substantially since the first MODE Z draft was introduced) > - All STRUs other than F and the related SNMT command > - Telnet IP and Synch signals > - XCWD and related commands I really don't think this is a good idea. I certainly use "TYPE E" in my FTP server. IBM Mainframe and OS/400 systems use FTP extensively and need alot of these weird and wacky (from a WIN/*IX viewpoint) options. It is vitally important to remember when tinkering with the protocol that: A) a 'file' isn't necessarily a chunk of bits sitting sequentially on a disk somewhere B) a 'directory' isn't necessarily a hierarchical tree of containers For example, in the FTP server I wrote, CDUP makes no sense at all. > > While it would definitely break compatibility with old implementations, > it would greatly simplify the protocol. I wonder if it is even possible > or desired to change FTP in such a drastic way or if that is a clear no-go. My 2c - big, big no-go. Cheers, Paul --=_alternative 00347FCA80257781_= Content-Type: text/html; charset="US-ASCII"
Tim Kosse wrote on 15/08/2010 22:29:07:

>
> Personally I would gladly see some parts of FTP obsoleted with other
> parts updated.
>
> Without going into the details too much, I would like to obsolete the
> following:
> - All TYPEs other than I and A
> - All MODES other than S (while the proposed MODE Z is a nice idea, I
> don't think it is relevant anymore, internet bandwidth has increased
> substantially since the first MODE Z draft was introduced)
> - All STRUs other than F and the related SNMT command
> - Telnet IP and Synch signals
> - XCWD and related commands
I really don't think this is a good idea.  I certainly use "TYPE E" in my FTP server.  IBM Mainframe and OS/400 systems use FTP extensively and need alot of these weird and wacky (from a WIN/*IX viewpoint) options.

It is vitally important to remember when tinkering with the protocol that:

A) a 'file' isn't necessarily a chunk of bits sitting sequentially on a disk somewhere
B) a 'directory' isn't necessarily a hierarchical tree of containers

For example, in the FTP server I wrote, CDUP makes no sense at all.

>
> While it would definitely break compatibility with old implementations,
> it would greatly simplify the protocol. I wonder if it is even possible
> or desired to change FTP in such a drastic way or if that is a clear no-go.
My 2c - big, big no-go.

Cheers,
Paul
 --=_alternative 00347FCA80257781_=-- From paulfordh@uk.ibm.com Mon Aug 16 02:48:19 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 25F303A6960 for ; Mon, 16 Aug 2010 02:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YTIv9LrNIwWJ for ; Mon, 16 Aug 2010 02:48:18 -0700 (PDT) Received: from mtagate7.uk.ibm.com (mtagate7.uk.ibm.com [194.196.100.167]) by core3.amsl.com (Postfix) with ESMTP id B66E23A681F for ; Mon, 16 Aug 2010 02:48:17 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o7G9mr5i008365 for ; Mon, 16 Aug 2010 09:48:53 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7G9lacx3354826 for ; Mon, 16 Aug 2010 10:47:36 +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 o7G9laia032511 for ; Mon, 16 Aug 2010 10:47:36 +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 o7G9lZZs032466 for ; Mon, 16 Aug 2010 10:47:36 +0100 In-Reply-To: References: To: Anthony Bryan MIME-Version: 1.0 X-KeepSent: 5B02220E:0F9A99E3-80257781:003494C5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Mon, 16 Aug 2010 10:48:16 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 16/08/2010 10:48:18, Serialize complete at 16/08/2010 10:48:18 Content-Type: multipart/alternative; boundary="=_alternative 0035C62B80257781_=" Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 16 Aug 2010 09:48:19 -0000 This is a multipart message in MIME format. --=_alternative 0035C62B80257781_= Content-Type: text/plain; charset="US-ASCII" Anthony Bryan wrote on 15/08/2010 20:50:27: > > current implementations are probably mostly fine. the way things are, > someone working on a new FTP app wouldn't even know 1123 existed. > My experience of creating an FTP server from scratch in 1994 was that: RFC959 was obviously useful RFC1123 was just a list of things that I had to implement even if it made no sense in my environment (this is a _good_ thing from a standards and interoperability point of view) There were some other RFCs that were also useful, I don't remember exactly how though. To actually get it to work, I had to do an awful lot of dumping of tcp traffic between existing clients and servers because the spec (RFC959) is nowhere near defined enough to write an implementation. (for example, the relative timing of the opening/closing of the data connection and the related FTP control connection commands is critical but undocumented, which is why I put them into RFC4217.) I guess that the point I'm trying to make is: - to write an implementation, you need to do more than just read the obvious RFCs, whilst we can and should help people to find the required information, in order for them to get to end of job coding such a beast will require either a huge documentation effort on our behalf, or a bit of gumption on theirs. Paul --=_alternative 0035C62B80257781_= Content-Type: text/html; charset="US-ASCII"
Anthony Bryan wrote on 15/08/2010 20:50:27:

>
> current implementations are probably mostly fine. the way things are,
> someone working on a new FTP app wouldn't even know 1123 existed.
>

My experience of creating an FTP server from scratch in 1994 was that:

RFC959 was obviously useful
RFC1123 was just a list of things that I had to implement even if it made no sense in my environment (this is a _good_ thing from a standards and interoperability point of view)
There were some other RFCs that were also useful, I don't remember exactly how though.

To actually get it to work, I had to do an awful lot of dumping of tcp traffic between existing clients and servers because the spec (RFC959) is nowhere near defined enough to write an implementation.  (for example, the relative timing of the opening/closing of the data connection and the related FTP control connection commands is critical but undocumented, which is why I put them into RFC4217.)

I guess that the point I'm trying to make is:
- to write an implementation, you need to do more than just read the obvious RFCs, whilst we can and should help people to find the required information, in order for them to get to end of job coding such a beast will require either a huge documentation effort on our behalf, or a bit of gumption on theirs.

Paul
--=_alternative 0035C62B80257781_=-- From robmcm@microsoft.com Fri Aug 20 15:01:00 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 DD56E3A6898 for ; Fri, 20 Aug 2010 15:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKzlGkLI61zC for ; Fri, 20 Aug 2010 15:01:00 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id EB5453A67FB for ; Fri, 20 Aug 2010 15:00:59 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Aug 2010 15:01:34 -0700 Received: from TK5EX14MBXC127.redmond.corp.microsoft.com ([169.254.6.158]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0218.010; Fri, 20 Aug 2010 15:01:34 -0700 From: Robert McMurray To: "ftpext@ietf.org" Thread-Topic: Question about draft-bryan-ftp-hash-07 Thread-Index: ActAsz/cDiAopKTASBWkx2ZFdKuoeA== Date: Fri, 20 Aug 2010 22:01:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ftpext] Question about draft-bryan-ftp-hash-07 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, 20 Aug 2010 22:01:01 -0000 It's been a few weeks since we've discussed the draft for the HASH command,= which is logical given the discussions that followed IETF 78, but from an = admittedly biased implementation point-of-view I'd like to see this draft c= ontinue to move forward towards publication. With that in mind, I've been thinking through implementation scenarios in t= he wake of the denial-of-service discussion that took place before IETF 78.= More specifically, I've thinking about a scenario where the maximum file s= ize could be configured at the server, so HASH commands could be prevented = from stealing too many server resources when larger files are involved. Thi= s is purely a server implementation detail that has nothing to do with the = draft with the exception of considering which reply code to return. Looking at section "3.4. HASH Command Errors" in the draft it would seem th= at none of the 5yz errors that are listed would apply, but returning a 504 = reply might seem to make sense in this scenario. If so, would it be worthwh= ile to add a statement like the following to the draft? The server-PI SHOULD reply with a 504 reply if the HASH command is used on a file that cannot be processed for policy reasons. (For example, the file size exceeds the server's hashing policy.) Or would a 4yz reply be better since this is a configurable option at the s= erver? Perhaps a 452 reply? Thanks. Robert McMurray US-IIS Product Unit Email: robmcm@microsoft.com From daniel@haxx.se Fri Aug 20 15:12: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 E3CDF3A69B2 for ; Fri, 20 Aug 2010 15:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-1.379, 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 WVhZM9YRuEvO for ; Fri, 20 Aug 2010 15:12:12 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 25CA33A69DC for ; Fri, 20 Aug 2010 15:12:11 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o7KMCmgp003392; Sat, 21 Aug 2010 00:12:48 +0200 Date: Sat, 21 Aug 2010 00:12:48 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Robert McMurray 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]); Sat, 21 Aug 2010 00:12:48 +0200 (CEST) Cc: "ftpext@ietf.org" Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07 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, 20 Aug 2010 22:12:14 -0000 On Fri, 20 Aug 2010, Robert McMurray wrote: > Looking at section "3.4. HASH Command Errors" in the draft it would seem > that none of the 5yz errors that are listed would apply, but returning a 504 > reply might seem to make sense in this scenario. If so, would it be > worthwhile to add a statement like the following to the draft? > > The server-PI SHOULD reply with a 504 reply if the HASH command is > used on a file that cannot be processed for policy reasons. (For > example, the file size exceeds the server's hashing policy.) Seems fine to me! > Or would a 4yz reply be better since this is a configurable option at the > server? Perhaps a 452 reply? I see your reasoning but I think rejecting an operation for a policy reason is "permanent" rather than "transient" as trying again surely has very little hope of working. I vote for a 5xx error. -- / daniel.haxx.se From tim.kosse@filezilla-project.org Fri Aug 20 15:21: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 BDC6E3A688E for ; Fri, 20 Aug 2010 15:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YOCfh2nxUhS for ; Fri, 20 Aug 2010 15:21:09 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id DBC383A685A for ; Fri, 20 Aug 2010 15:21:08 -0700 (PDT) Received: from pd9e748bd.dip.t-dialin.net ([217.231.72.189] helo=[192.168.0.103]) by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OmZy1-0001Fb-5Q; Sat, 21 Aug 2010 00:21:41 +0200 Message-ID: <4C6EFFEB.4060805@filezilla-project.org> Date: Sat, 21 Aug 2010 00:21:31 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Robert McMurray References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEECB069128F15C7701067E2F" Cc: "ftpext@ietf.org" Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07 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, 20 Aug 2010 22:21:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEECB069128F15C7701067E2F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-08-21 00:01, Robert McMurray wrote: > The server-PI SHOULD reply with a 504 reply if the HASH command is > used on a file that cannot be processed for policy reasons. (For > example, the file size exceeds the server's hashing policy.) So far 504 is used for "Command not implemented for that parameter" which doesn't seem to fit too well. What about 554? > Or would a 4yz reply be better since this is a configurable option at t= he server? Perhaps a 452 reply?heh =46rom my understanding, 4yz is for temporary errors that require no intervention, encouraging the client to try again at some point in the future. Tim --------------enigEECB069128F15C7701067E2F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxu/+wACgkQ8N9+lcqiUkXv4gCg+bmOwn2fYNuiZB6pGRCmjqya VzMAnj9i1bPqWYOSwL3Izk7+2ZjNiNNA =PgLb -----END PGP SIGNATURE----- --------------enigEECB069128F15C7701067E2F-- From robmcm@microsoft.com Fri Aug 20 15:42:23 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 E07FF3A67FB for ; Fri, 20 Aug 2010 15:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPxhZiiy8-12 for ; Fri, 20 Aug 2010 15:42:22 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 33CBE3A685A for ; Fri, 20 Aug 2010 15:42:22 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Aug 2010 15:42:56 -0700 Received: from TK5EX14MBXC127.redmond.corp.microsoft.com ([169.254.6.158]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0218.010; Fri, 20 Aug 2010 15:42:56 -0700 From: Robert McMurray To: 'Tim Kosse' , "ftpext@ietf.org" Thread-Topic: [ftpext] Question about draft-bryan-ftp-hash-07 Thread-Index: ActAsz/cDiAopKTASBWkx2ZFdKuoeAAPXa+AAA49LPA= Date: Fri, 20 Aug 2010 22:42:55 +0000 Message-ID: References: <4C6EFFEB.4060805@filezilla-project.org> In-Reply-To: <4C6EFFEB.4060805@filezilla-project.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07 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, 20 Aug 2010 22:42:24 -0000 Pj4gVGhlIHNlcnZlci1QSSBTSE9VTEQgcmVwbHkgd2l0aCBhIDUwNCByZXBseSBpZiB0aGUgSEFT SCBjb21tYW5kIGlzDQo+PiB1c2VkIG9uIGEgZmlsZSB0aGF0IGNhbm5vdCBiZSBwcm9jZXNzZWQg Zm9yIHBvbGljeSByZWFzb25zLiAoRm9yDQo+PiBleGFtcGxlLCB0aGUgZmlsZSBzaXplIGV4Y2Vl ZHMgdGhlIHNlcnZlcidzIGhhc2hpbmcgcG9saWN5LikNCj4NCj4gU28gZmFyIDUwNCBpcyB1c2Vk IGZvciAiQ29tbWFuZCBub3QgaW1wbGVtZW50ZWQgZm9yIHRoYXQgcGFyYW1ldGVyIg0KPiB3aGlj aCBkb2Vzbid0IHNlZW0gdG8gZml0IHRvbyB3ZWxsLg0KPiANCj4gV2hhdCBhYm91dCA1NTQ/DQo+ IA0KPiBUaW0NCg0KUkZDIDExMjMgbGlzdHMgdGhlIDU1NCByZXBseSBhcyAiUmVxdWVzdGVkIGFj dGlvbiBub3QgdGFrZW46IGludmFsaWQgUkVTVCBwYXJhbWV0ZXIsIiBzbyB0aGlzIHdvdWxkbid0 IHNlZW0gdG8gbWFrZSBzZW5zZSBmb3IgSEFTSC4NCg0KUkZDIDIyMjggbGlzdHMgdGhlIDUzNCBy ZXBseSBhcyAiUmVxdWVzdCBkZW5pZWQgZm9yIHBvbGljeSByZWFzb25zLCIgYnV0IHRoYXQgaGFz IGFsd2F5cyBzZWVtZWQgdG8gbWUgdG8gYmUgbW9yZSBzcGVjaWZpYyBhcyBhIHJlc3BvbnNlIHRv IHRoZSBzZWN1cml0eSBleHRlbnNpb25zIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhhdCBSRkMgc28g SSBoYWRu4oCZdCBzdWdnZXN0ZWQgaXQsIGJ1dCBJJ2xsIG9wZW4gdGhhdCBmb3IgZGViYXRlLiA7 LV0NCg0K From wmaton@ottix.net Fri Aug 20 15:53: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 799183A699E for ; Fri, 20 Aug 2010 15:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 QWptcy-mcgMx for ; Fri, 20 Aug 2010 15:53:00 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 829493A691B for ; Fri, 20 Aug 2010 15:53:00 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o7KMrQ69026413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 18:53:26 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o7KMrQ69026413 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o7KMrQIZ026410; Fri, 20 Aug 2010 18:53:26 -0400 Date: Fri, 20 Aug 2010 18:53:26 -0400 (EDT) From: "William F. Maton" To: Paul Ford-Hutchinson In-Reply-To: Message-ID: References: <4C685C23.9000801@filezilla-project.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 20 Aug 2010 22:53:01 -0000 On Mon, 16 Aug 2010, Paul Ford-Hutchinson wrote: > Tim Kosse wrote on 15/08/2010 22:29:07: > >> While it would definitely break compatibility with old implementations, >> it would greatly simplify the protocol. I wonder if it is even possible >> or desired to change FTP in such a drastic way or if that is a clear > no-go. > > My 2c - big, big no-go. +1 wfms From iljitsch@muada.com Sat Aug 21 02:00: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 55A763A6849 for ; Sat, 21 Aug 2010 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z7PYn+KLYA9 for ; Sat, 21 Aug 2010 02:00:14 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 271873A67A4 for ; Sat, 21 Aug 2010 02:00:13 -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 o7L8xoIE067792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Aug 2010 10:59:51 +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: Sat, 21 Aug 2010 11:00:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D8ED1C7-F62F-4859-A016-FE8AABEAEBF4@muada.com> References: To: Anthony Bryan X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 21 Aug 2010 09:00:15 -0000 On 9 aug 2010, at 21:17, Anthony Bryan wrote: > the idea would be to have an updated, coherent, harmonious document of > RFCs concerning FTP along > with implementation and real world info like httpbis. I don't think simple reorganization and clarification will do it for = FTP. There is a ton of stuff in the current specs that is no longer used = at all (all the fancy file/record organization stuff), stuff that is = technically legal but doesn't make sense (PASV+PORT), stuff that is = technically legal but isn't used in practice and using it in practice = would cause big problems (PASV with a different address in the 227 than = the control channel address, EPSV with an argument), stuff that should = work but has issues in practice (EPSV), stuff that should have been = retired a decade ago but is still in wide use (PASV+PORT) and so on. I don't think revisiting the FTP spec without tightening the spec and = deprecating some currently legal options makes much sense. Yes, it's = annoying to have to read so many documents to create an FTP server or = client, but the real problem isn't the number of documents, but that = what's in those documents and what FTP servers and clients do in = practice is so different from what's in those documents. In that sense = an effort like RFC 1771 -> RFC 4271 where the focus was to document = what's really out there seems to make sense.= From anthonybryan@gmail.com Sat Aug 21 13:06: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 E3C993A6966 for ; Sat, 21 Aug 2010 13:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, 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 N9Lfo1cwmLG1 for ; Sat, 21 Aug 2010 13:06:25 -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 997833A67FE for ; Sat, 21 Aug 2010 13:06:25 -0700 (PDT) Received: by iwn3 with SMTP id 3so4676325iwn.31 for ; Sat, 21 Aug 2010 13:06:57 -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=naz/zgg1KQUbhoLunmpAak+qhBtC27yJVGlN0rj+yY4=; b=HAjCGrRqUiceyLlyXIuhuFEGSsXtZF/6tglZm5w5FapCLApDVKGx6WBMJ5qkZ0gZQw T6WfpZDHowxhNbM7kXqh0beXYX+eyb13v/OfdK6+L28GPhMaaci8ZTy3fRmZ1w/ZZTt6 5KlKgF50Igp/Jo/8OzbfIQbvUjcewg2vSlOVc= 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=gaQXK/3NURV5pEW4p4PBtv+ASbQXbTihZg2xlNvcjzHj+y6Sflbg5PnkblEkOrwKco QSBaO9ITOvOfx71TWXBwdSh7sbKrsex0qyivG4rKJZsw8N5Vs8PGWx6eyZNpChDrPQTT F9ebm6AqKEaKsC9EidTppslq+xCgLNOqZraGA= MIME-Version: 1.0 Received: by 10.231.157.212 with SMTP id c20mr3776318ibx.186.1282421216800; Sat, 21 Aug 2010 13:06:56 -0700 (PDT) Received: by 10.231.49.199 with HTTP; Sat, 21 Aug 2010 13:06:56 -0700 (PDT) In-Reply-To: References: <4C6EFFEB.4060805@filezilla-project.org> Date: Sat, 21 Aug 2010 16:06:56 -0400 Message-ID: From: Anthony Bryan To: Robert McMurray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ftpext@ietf.org" Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07 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, 21 Aug 2010 20:06:27 -0000 On Fri, Aug 20, 2010 at 6:42 PM, Robert McMurray wro= te: >>> The server-PI SHOULD reply with a 504 reply if the HASH command is >>> used on a file that cannot be processed for policy reasons. (For >>> example, the file size exceeds the server's hashing policy.) >> >> So far 504 is used for "Command not implemented for that parameter" >> which doesn't seem to fit too well. >> >> What about 554? > > RFC 1123 lists the 554 reply as "Requested action not taken: invalid REST= parameter," so this wouldn't seem to make sense for HASH. > > RFC 2228 lists the 534 reply as "Request denied for policy reasons," but = that has always seemed to me to be more specific as a response to the secur= ity extensions that are defined in that RFC so I hadn=92t suggested it, but= I'll open that for debate. ;-] thanks, Robert. good suggestion. I've added this text while we iron out the reply code: Server operators might wish to allow the HASH command but restrict its use to certain files, for example, if the file size exceeds the server's hashing policy. A client MUST be able to understand that refusal to process HASH commands may be permanent (if indicated by a 5yz response) and will not be honoured later. The server-PI SHOULD reply with a 5yz reply if the HASH command is used on a file that cannot be processed for policy reasons. (For example, if the file size exceeds the server's hashing policy.) suggestions? btw, for anyone interested I believe I have all reply codes listed in http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html#sec-4.2.3 --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Sat Aug 21 14:44:05 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 D2A7C3A6846 for ; Sat, 21 Aug 2010 14:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 yFaFPYUeYc96 for ; Sat, 21 Aug 2010 14:44:04 -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 698D63A67FE for ; Sat, 21 Aug 2010 14:44:04 -0700 (PDT) Received: by iwn3 with SMTP id 3so4735920iwn.31 for ; Sat, 21 Aug 2010 14:44:38 -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=8LkIymQrr2KTHZ+f9B0GODA9oGuA48x0cHr+t806uVs=; b=vwN50pZiQFgdCkxXEBklxULGAyv3Hxq486TBgIulMRvRxHt0781MxNoq3dXjX+fbA8 n3EcXvlyS0aiZ8lJSL8z9FJbdue4DzY5XPsC9kTP8LXvYudFUrGDCHYhZl5dwiB7tkC3 5+jfegUymmJSXZAh64h4bXruvxAaYdSI3jsyE= 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=B6NGvG66eADoAWw+n+E9QgfgTtmFdg7GgMQ9ojuRQrFdDQboKjJTZ1y3pMEtDThF/B v+a0H2l0KkT2ep3LuSWWxdLdtIz3zXdFwV941CgMpAnQLKUgFtts/5TNpZjVtrHUvWC0 CbBj0Ej76/1XYsfHd360kuOEuO9sr1quLe/5U= MIME-Version: 1.0 Received: by 10.231.152.78 with SMTP id f14mr4060310ibw.60.1282427078393; Sat, 21 Aug 2010 14:44:38 -0700 (PDT) Received: by 10.231.49.199 with HTTP; Sat, 21 Aug 2010 14:44:38 -0700 (PDT) In-Reply-To: <2D8ED1C7-F62F-4859-A016-FE8AABEAEBF4@muada.com> References: <2D8ED1C7-F62F-4859-A016-FE8AABEAEBF4@muada.com> Date: Sat, 21 Aug 2010 17:44:38 -0400 Message-ID: From: Anthony Bryan To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] FWD: ftp/959 reboot 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, 21 Aug 2010 21:44:05 -0000 On Sat, Aug 21, 2010 at 5:00 AM, Iljitsch van Beijnum wrote: > On 9 aug 2010, at 21:17, Anthony Bryan wrote: > >> the idea would be to have an updated, coherent, harmonious document of >> RFCs concerning FTP along >> with implementation and real world info like httpbis. > > I don't think simple reorganization and clarification will do it for FTP.= There is a ton of stuff in the current specs that is no longer used at all= (all the fancy file/record organization stuff), stuff that is technically = legal but doesn't make sense (PASV+PORT), stuff that is technically legal b= ut isn't used in practice and using it in practice would cause big problems= (PASV with a different address in the 227 than the control channel address= , EPSV with an argument), stuff that should work but has issues in practice= (EPSV), stuff that should have been retired a decade ago but is still in w= ide use (PASV+PORT) and so on. > > I don't think revisiting the FTP spec without tightening the spec and dep= recating some currently legal options makes much sense. Yes, it's annoying = to have to read so many documents to create an FTP server or client, but th= e real problem isn't the number of documents, but that what's in those docu= ments and what FTP servers and clients do in practice is so different from = what's in those documents. In that sense an effort like RFC 1771 -> RFC 427= 1 where the focus was to document what's really out there seems to make sen= se. yep that's what I'm proposing, but there doesn't seem to be enough interested people. I posted the httpbis charter here earlier, but I think it's worth reading http://datatracker.ietf.org/wg/httpbis/charter/ --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Thu Aug 26 12:52:41 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 A89BE3A68AF for ; Thu, 26 Aug 2010 12:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.027, 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 6g9JZY690Ao4 for ; Thu, 26 Aug 2010 12:52:40 -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 EF2553A68F3 for ; Thu, 26 Aug 2010 12:52:39 -0700 (PDT) Received: by gyc15 with SMTP id 15so139489gyc.31 for ; Thu, 26 Aug 2010 12:53:12 -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=oyL1sfCLiGfZ3yUSwC6Ll/EJsD9XzaUyk33R568575A=; b=L9k/43LMHFRfv0lQO+eWbb6P6u/bqzvSFvR/mvT5nlm/ibym5HzePW+jnJtPsFp4yf QLFkFKB6quFBEZFoGvug/U+/4pcDrCSEynz4JKVokuid+yFG2B7f5V5WklC1q9Ek6PTC PUPqHyhvFeEyOWHlttzDiHRxKRWujmKXQQhyU= 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=Ly4kUJ+B9BkZtBQhRuOA95egmLpLr6ppqmygC/QSV8CYV9HReXA2oHS8cqi4klr7QD 2nVucJrOoxq8iaXl1vbxE/HCP9CSO3vQei5FcLulg2fqhFHPT51B1v+Qd3hWis1ZT6yo nRDjMqoxjspAQfek7imwO1nHp+z9YlHeYK28w= MIME-Version: 1.0 Received: by 10.151.43.11 with SMTP id v11mr871003ybj.70.1282852391865; Thu, 26 Aug 2010 12:53:11 -0700 (PDT) Received: by 10.231.49.199 with HTTP; Thu, 26 Aug 2010 12:53:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Aug 2010 15:53:11 -0400 Message-ID: From: Anthony Bryan To: "William F. Maton" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 26 Aug 2010 19:52:41 -0000 On Thu, Aug 5, 2010 at 2:48 PM, Anthony Bryan wrot= e: > On Tue, Aug 3, 2010 at 6:51 PM, William F. Maton wrote= : >> On Tue, 3 Aug 2010, Anthony Bryan wrote: >> >> [snip] >>> >>> Errata >>> The representation types defined in FTP are described in Section 3.1, >>> Data Representation and Storage, or more specifically 3.1.1, Data >>> Types. They don't seem to be described in 3.2, Establishing Data >>> Connections. >> >> Good catch. here are the other 3 errata I've reported on FTP RFCs lately. these are all nitpicky editorial & not important, but I think these older documents are worth reviewing by anyone who has time. http://www.rfc-editor.org/errata_search.php?rfc=3D959&eid=3D2410 RFC0959, "File Transfer Protocol", October 1985 Source of RFC: Legacy Errata ID: 2410 Status: Verified Type: Editorial Reported By: Anthony Bryan Date Reported: 2010-08-03 Verifier Name: Alexey Melnikov Date Verified: 2010-08-03 Section Appendix III says: Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 776, BBN, December 1980. It should say: Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 775, BBN, December 1980. Notes: Typo. RFC 775 "Directory Oriented FTP Commands" RFC 776 "Assigned Numbers" --- http://www.rfc-editor.org/errata_search.php?rfc=3D1123&eid=3D2464 RFC1123, "Requirements for Internet Hosts - Application and Support", October 1989 Source of RFC: Legacy Errata ID: 2464 Status: Reported Type: Editorial Reported By: Anthony Bryan Date Reported: 2010-08-15 Section 4.1.2.6 says: IMPLEMENTATION: The format of the 227 reply to a PASV command is not well standardized. In particular, an FTP client cannot assume that the parentheses shown on page 40 of RFC-959 will be present (and in fact, Figure 3 on page 43 omits them). It should say: IMPLEMENTATION: The format of the 227 reply to a PASV command is not well standardized. In particular, an FTP client cannot assume that the parentheses shown on page 40 of RFC-959 will be present (and in fact, Figure 3 on page 45 omits them). Notes: In RFC 959, Figure 3 is actually on page 45, not page 43. --- http://www.rfc-editor.org/errata_search.php?rfc=3D3659&eid=3D2496 RFC3659, "Extensions to FTP", March 2007 Source of RFC: ftpext (app) Errata ID: 2496 Status: Reported Type: Editorial Reported By: Anthony Bryan Date Reported: 2010-08-21 Throughout the document, when it says: 3.2 ... Various 4xy replies are also possible in appropriate circumstances. 4.2 ... Various 4xy replies are also possible in appropriate circumstances. 7.2.1 Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. ... Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances. It should say: 3.2 ... Various 4yz replies are also possible in appropriate circumstances. 4.2 ... Various 4yz replies are also possible in appropriate circumstances. 7.2.1 Many of the 4yz and 5yz responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. ... Other replies (530, 553, 503, 504, and any of the 4yz replies) are also possible in appropriate circumstances. Notes: RFC 959, Section 4.2 refers to these reply codes as 4yz and 5yz, instead of 4xy and 5xy. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From wmaton@ottix.net Thu Aug 26 13:58: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 297093A6B06 for ; Thu, 26 Aug 2010 13:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 MjqRcgvOLQD5 for ; Thu, 26 Aug 2010 13:58:37 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by core3.amsl.com (Postfix) with ESMTP id 27C533A6B04 for ; Thu, 26 Aug 2010 13:58:36 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id o7QKx4YO025533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 16:59:04 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 iskra.ottix.net o7QKx4YO025533 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id o7QKx3tH025528; Thu, 26 Aug 2010 16:59:03 -0400 Date: Thu, 26 Aug 2010 16:59:03 -0400 (EDT) From: "William F. Maton" To: Anthony Bryan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] RFC Errata for consideration 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, 26 Aug 2010 20:58:38 -0000 On Thu, 26 Aug 2010, Anthony Bryan wrote: >>> Good catch. > > here are the other 3 errata I've reported on FTP RFCs lately. these > are all nitpicky editorial & not important, but I think these older > documents are worth reviewing by anyone who has time. Thanks. Interestingly enough I have been swimming around some of the FTP code I have around here and found this little gem: /* Note: a response of 425 is not mentioned as a possible response to the * PASV command in RFC959. However, it has been blessed as a legitimate * response by Jon Postel in a telephone conversation with Rick Adams on 25 * Jan 89. */ Ah, the good ol' days. :-) wfms