Subject: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-01.txt

From: [email-masked]
Date: Wed, 08 Dec 2010 10:15:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF.

	Title		: File Transfer Protocol HOST Command for Virtual Hosts
	Author(s)	: P. Hethmon, R. McMurray
	Filename	: draft-ietf-ftpext2-hosts-01.txt
	Pages		: 20
	Date		: 2010-12-8
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-hosts-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 8 Dec 2010 23:21:55 +0100 (CET)

On Wed, 8 Dec 2010, [email-masked] wrote:

> 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.

This is a very well written document and I really like it. Two 
comments/remarks:

Section 3 (and 3.3) mentions that the server can respond to a late HOST in one 
of two ways (a or b).

Why two? Why not just specify one specific way which will make it easier for 
both client and server authors to behave? (I would personally prefer b but it 
is not a strong preference).

Section 3.1 details that HOST only specify host name or IP address, not port 
number. The HTTP Host: header can (optionally) include a port number. The text 
says that the port number is pointless but I'm not sure that it always is and 
will be. In a time when we use NATs and port forwarders and so on, I can 
imagine a case when you have a front end port (port A) open for clients to 
connect to, but once connected you forward the traffic to an internal site on 
port B (or C or D perhaps when load ballancing for example) and thus the 
internal receiver of the traffic doesn't know which port the client originally 
connected to unless it mentions that.

It's just so easy to also support the port number as I think it would be a 
shame to forbid it since there may actually be usecases for it!

-- 

  / daniel.haxx.se