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

[Anthony Bryan <[e-mail]>]

On Wed, Jul 28, 2010 at 10:31 AM, William F. Maton <[e-mail]> wrote:
> On Tue, 27 Jul 2010, Iljitsch van Beijnum wrote:
>
> [snip]
>>
>> not when there is a 229 response. I also worry that an overhaul of RFC 959
>> and rolling in stuff from later FTP RFCs would take quite a long time
>> because all kinds of other stuff would find its way into the document, too.
>
> IANAWGCC [*], but in my voyages through the 'heritage' that is the wu-ftpd
> experience, one downside is having to wade through a lot of RFCs to 'get'
> the protocol.  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.
>
> There is always the third option and that is to do nothing.

I love the third option! :) when given a choice between effort &
effortless, I always pick "less work"  (unless that means more work
lateron).

such an undertaking (ftpbis?) would likely take a number of years, I'd
guess. the httpbis WG is doing something similar. they're updating
HTTP, but also taking into account what's been put into practice. (I'm
including their charter at the end).

keep in mind that we didn't have enough BOF interest to convince the
AD to commit to a FTPEXT2 WG at the time (hoping that will change). I
think our best bet is to continue work on our drafts, documenting what
is in use in the wild or what is REALLY needed. we need to continue to
engage authors & implementers.

but... ftpbis would probably be a rising tide. we now also have RFC
5797, the FTP command & extension registry [1], which should be handy
to implementers. I've also tried to update the Wikipedia pages on FTP
[2] to keep them up to date, but I'm sure I've missed a lot. we can
also write articles or blogs...

that said, I had sketched out such a beast & started work on it
privately, but lost steam on my own.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

[1] http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml

[2] http://en.wikipedia.org/wiki/Ftp

HTTP is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial
issues. Additionally, after years of implementation and extension,
several ambiguities have become evident, impairing interoperability
and the ability to easily implement and use HTTP.

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries,
ABNF)
* Fix editorial problems which have led to misunderstandings of the
specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented
and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated
echanisms (e.g., Basic and Digest authentication, cookies, TLS) for
common applications

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

The Working Group must not introduce a new version of HTTP and should
not add new functionality to HTTP. The WG is not tasked with producing
new methods, headers, or extension mechanisms, but may introduce new
protocol elements if necessary as part of revising existing
functionality which has proven to be problematic

The Working Group's specification deliverables are:
* A document that is suitable to supersede RFC 2616
* A document cataloguing the security properties of HTTP