Subject: Re: [ftpext] RFC959 update WAS Re: NAT64 client/server document

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 5 Aug 2010 23:18:53 +0200

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.