Subject: [ftpext] NAT64 client/server document

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Jul 2010 14:27:14 +0200

Hi,

There was clear consensus (it wasn't even rough) yesterday that the current FTP64 document should be split up in an ALG spec and something else that specifies how clients and servers should behave to avoid the need for such an ALG in the presence of IPv6 to IPv4 translation.

The question is what would be the best way to approach this. On the one hand it's attractive to just update the standard. We can then obsolete PASV and PORT and mandate the use of EPSV and EPRT instead. I'm not sure that would accomplish much in practice, though, as many clients till issue PASV (or PORT) so servers will want to keep supporting that. And there's the issue of the boxes that work when there is a 227 response but 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.

The alternative would be to go for best current practice. This has the advantage that we can recommend some things that may or may not adhere to the strictest letter of the standard as long as doing them is obviously the best thing to do in practice. One of these things would be ignoring the address in 227 responses. On the other hand, BCPs carry less weight than standards, so people might find it even easier to ignore a BCP than a STD.

Thoughts?

The idea is that I will continue with draft-ietf-behave-ftp64 which will be reduced to the ALG spec and it looks like Dapeng Liu and myself will work together on the other document.

Iljitsch

---

From: "William F. Maton" <[email-masked]>
Date: Wed, 28 Jul 2010 10:31:29 -0400 (EDT)

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.

[On the BCP vs STD idea]

Given that this is addressing an issue related to the burgeoning 
deployment of IPv6, at the very least it should be a BCP.  Ideally a STD 
but I admit I don't know what weight that would really carry either.

wfms

[*] I am Not a Working Group Co-Chair.

---

From: Anthony Bryan <[email-masked]>
Date: Sat, 31 Jul 2010 04:55:59 -0400

On Wed, Jul 28, 2010 at 10:31 AM, William F. Maton <[email-masked]> wrote:
>> 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.
>

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