Re: [ftpext] FWD: ftp/959 reboot

Anthony Bryan <> Sun, 15 August 2010 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E45443A6836 for <>; Sun, 15 Aug 2010 15:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.285
X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ogzeHGKNmHfA for <>; Sun, 15 Aug 2010 15:54:36 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id g15mr4968181ibw.76.1281912912667; Sun, 15 Aug 2010 15:55:12 -0700 (PDT)
Received: by with HTTP; Sun, 15 Aug 2010 15:55:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
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: "" <>
Subject: Re: [ftpext] FWD: ftp/959 reboot
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:  Have
>>> 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., ...) or were already a
> well-established best-practice most if not all popular implementations
> implicitly adhere to (e.g.,
> Even though rare, there are still clients out there that use commands
> like XCWD ( and TYPE L 8 ( 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-go.

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.
(( Anthony Bryan ... Metalink [ ]
  )) Easier, More Reliable, Self Healing Downloads