Re: [ftpext] FWD: ftp/959 reboot

[Anthony Bryan <[e-mail]>]

On Sun, Aug 15, 2010 at 5:29 PM, Tim Kosse
<[e-mail]> 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. 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-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 [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads