File Transfer Protocol HOST Command for Virtual Hosts
draft-hethmon-mcmurray-ftp-hosts-15

IANA comments:

Upon approval of this document, IANA will make the following assignment
in the "FTP Commands and Extensions" registry at
http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml

+-------+------+-------------------+------+------+-------------------------------------+
| cmd | FEAT | description | type | conf | RFC#s/References and Notes
|
| | Code | | | |
|

+-------+------+-------------------+------+------+--------------------------------------+
| HOST | HOST | Hostname | a | o |
[RFC-hethmon-mcmurray-ftp-hosts-11] |

+-------+------+-------------------+------+------+--------------------------------------+

AD review of the document:

2.1. Basic Tokens

  However note that ALPHA, in particular, is
  case sensitive.

I am not sure I understand why: ALPHA allows both lowercased
and uppercased US-ASCII letters.
I suggest you delete this sentence.


3. The HOST command

  A new command "HOST" is added to the FTP command set to allow the
  server-FTP process to determine to which of possibly many virtual
  hosts the client wishes to connect.  This command SHOULD be issued
  before the user is authenticated, allowing the authentication scheme,
  and set of legal users, to be dependent upon the virtual host chosen.
  Server-FTP processes may permit the HOST command to be issued after
  the user has been authenticated, or may treat that as an erroneous
  sequence of commands.  The behavior of a server-FTP process that
  allows late HOST commands is undefined.

I think the document should either prohibit this, or fully define possible outcomes (with corresponding error codes).

  One reasonable
  interpretation would be for the user-PI to be returned to the state
  that existed after the TCP connection was first established, before
  user authentication.


3.1. Syntax of the HOST command

  The HOST command is defined as follows.

      host-command    = "Host" SP hostname CRLF
      hostname        = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ]

I don't think this allows for IPv6 addresses due to use of "1*" in
1*( "." 1*DNCHAR )

I.e. at least 1 dot is required. I don't think this is what you wanted, considering that subsequent text allows IPv6 addresses.

      DNCHAR          = ALPHA / DIGIT / "-" / "_" / "$" /
                          "!" / "%" / "[" / "]" / ":"

Why allow "_" / "$" / "!" / "%" ?

It might be better to point to other documents that specify IPv4/IPv6 address syntax.

I think the document should explicitly state that Internationalized Domain Names are only allowed in punycode form here.


3.2. HOST command semantics

  If the hostname specified would normally be acceptable, but for any
  reason is temporarily unavailable, the server SHOULD reply to the
  HOST command with a 421 reply.

Minor: Does this mean that the server should close the connection after returning 421?

4. Security Considerations

  With the introduction of virtual hosts to FTP, and the possible
  accompanying multiple authentication environments, server
  implementers will need to take some care to ensure that integrity is
  maintained.

Integrity of what?
I think this sentence/section might need some improvements.


5. IANA Considerations

  This document has no IANA actions.

As draft-klensin-ftp-registry-04.txt is approved for publication (and thus will be a new RFC soon), you should register the HOST command/extension according to Section 2.2 of draft-klensin-ftp-registry-04.txt. The registration should replace content of Section 5 of your draft.

This section should start with something like:

"IANA is requested to register the following FTP extension according to procedure established by [draft-klensin-ftp-registry]."