1. Summary
The document shepherd is Tony Hansen. The responsible Area Director is
Barry Leiba.
This document defines a new FTP command that provides a mechanism for
FTP clients and servers to identify individual virtual hosts on an FTP
server.
2. Review and Consensus
The extension is straightforward. The first version of this draft was
published in 2007. Various alternatives were proposed before the final
version was chosen; the alternatives are discussed in an appendix, along
with reasons that they were not chosen. The following companies have
already implemented the FTP HOST command, so it's beginning to gain
industry acceptance even though it has yet to be formally published:
FTP SERVERS:
- FTP Daemon (see http://www.pro-bono-publico.de/projects/ftpd.html)
- Ipswitch (in the WS_FTP service; see http://www.ipswitchft.com/)
- Microsoft (in the IIS FTP service; see http://www.iis.net/)
- RhinoSoft (in the Serv-U File server; see http://www.serv-u.com/)
FTP CLIENTS:
- Microsoft (in the Visual Studio 2010, Visual Studio 2012, and Expression Web 4 products)
- Rebex (in the Rebex FTP/SSL for .NET library; see http://www.rebex.net/)
- RhinoSoft (in the FTP Voyager client; see http://www.rhinosoft.com/)
- Scooter Software (in the Beyond Compare client; see http://scootersoftware.com/)
- SmartFTP (in the SmartFTP client; see http://smartftp.com/)
All discussion occurred on the FTP Extensions mailing list. Before the
FTP Extensions working group disbanded, the working group was solidly
behind this. Minor editorial issues were found during shepherd review
and the document was revised.
See also the AD addendum in Section 4, below.
3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document.
4. Other Points
Addendum from the responsible AD:
This document has had three incarnations, and has now been to last
call three times. It started as draft-hethmon-mcmurray-ftp-hosts,
then went to the ftpext2 working group as draft-ietf-ftpext2-hosts.
When that working group was concluded, the document came back as the
current draft-hethmon-mcmurray-ftpext-ftp-hosts.
In the end, this really is a straightforward, deployed thing, which
belongs as a Proposed Standard. It's the most viable and mature of
the things that ftpext2 had on its docket.
The original document, draft-hethmon-mcmurray-ftp-hosts, was
proposed and discussed, and Alexey agreed to sponsor it because
there was no working group to deal with FTP at the time.
In Alexey's last call, John Klensin started a conversation with this
comment:
> This leads to a more general point, which I think is the main issue
> with this and the other FTP proposals that are at various points in
> the pipe. FTP is our oldest applications protocol that is still in
> active use. It was rather carefully designed. It is not HTTP and
> retrofitting HTTP syntax and concepts into it is not obviously the
> right thing to do.
>
> If we are going to start adding features to FTP, it seems to me that
> we need a strategy and to make design decisions: lots of little
> commands with four-letter names and single-token syntax versus a
> smaller number of more complex commands versus extending (or, in the
> words of the authors, "overloading") existing commands. Those
> decisions should not -- cannot -- be made by processing one command
> extension at a time, with each one reflecting the taste and
> assumptions of its authors in different ways.
>
> It seems to me that we need a WG or some other mechanism for
> establishing and determining community consensus around basic design
> principles for FTP extensions. If the IESG then wants to process
> individual extensions as individual submissions, that would be fine,
> but let's first at least establish a framework for evaluating them.
I agreed with that comment, and supported the creation of a working
group to collect the various proposals that were around at the time.
And there was a budding BoF proposal that led to a BoF in Maastricht.
Alexey was reluctant to delay the document, giving its acknowledged
utility, but was willing to hold it back from IESG Eval at least until
the Maastricht BoF.
The result of the BoF was that there seemed to be weak but sufficient
interest in having a working group look at the set of FTP-related
proposals from a strategic point of view. Alexey and Peter went off to
deal with that.
I'll note that the document also got a TSV Dir review from Joe Touch,
who had some minor comments that Robert McMurray engaged him on, and has
since addressed. The document wasn't "pulled back" for any reason
particular to a failure in the document, but because we thought it
better to hold off and look at all the FTP extension proposals
strategically.
The ftpext2 working group was chartered a few months after that, but it
never went very fast even at the best times. The working group handled
the doc as draft-ietf-ftpext2-hosts, and it got as far as going out for
last call.
There were a few comments during that last call, but there was concern
that there hadn't been serious enough review of the document in the
working group. The chairs agreed to bring it back to the working group
to get more review. After another 6 or 8 months of no real progress, the
working group was concluded. Again: no particular issues with this
document, but problems with working group energy. There was a GenART
review that said it was ready. There were two other minor exchanges,
but nothing significant, and Robert addressed both.
The idea then was to take the documents that had enough maturity and
enough energy and go back to AD-sponsoring them. And so, after a time,
here we are again. Repeating the point at the beginning: this documents
something sensible, mature, and at least somewhat deployed.