Subject: Ftp-WG: draft--ietf-ftpext-mlst-11.txt

From: [email-masked]
Date: Mon, 18 Sep 2000 16:47:26 -0500

Whilst updating the FTP/SSL draft (soon to be
draft-murray-auth-ftp-sl-06.txt) I noticed that the HOST command has been
removed from the subject doc.

Should the following para be deleted from section 11 too ?

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

(sorry if this has been pointed out before, but it is very hard to extract
the signal from the spam in the archives.)

Cheers,
Paul

--
Paul Ford-Hutchinson : EMEA eCommerce application security :
[email-masked]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Sep 2000 04:10:37 -0500

Date:        Mon, 18 Sep 2000 16:47:26 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | Should the following para be deleted from section 11 too ?

Thanks, and yes, of course it should.   New version coming soon
(with just that one change).

kre

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Tue, 19 Sep 2000 10:34:42 -0500

I would phrase it more tentatively.

"If, in the advent of ...

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Sep 2000 10:41:42 -0500

Date:        Tue, 19 Sep 2000 10:34:42 -0500
    From:        "Gregory A Lundberg" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I would phrase it more tentatively.
  | 
  | "If, in the advent of ...

No, not needed at all, that came with the HOST text when it was
there, and should accompany that text to any final resting place
it finds for itself...

kre

---

From: "Mark Symons" <[email-masked]>
Date: Thu, 21 Sep 2000 16:24:16 -0500

Is there any chance that we will see HOST get defined in its own draft any
time soon?

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

Robert Elz responded:

> Thanks, and yes, of course it should.

..and, in a later message:

> that came with the HOST text when it was there, and should
> accompany that text to any final resting place it finds for
> itself...

This does agree with ftpext-mlst-09 (Dec 1999), which stated:

# The HOST command has been removed to a draft of its own,

This followed a lot of to and fro discussions on the list concerning HOST vs
Overloaded USER.  Alan Jones put it well (Oct 1999):

> A poorly-designed HOST command slipped into a much-wanted
> MLST draft might make it to RFC status simply because we
> want to see MLST that much sooner.  Separated into its own
> document, it will need to stand on its own to make it to RFC
> status.  As others have pointed out, the HOST command has not
> yet been completely discussed here, and it is perhaps immature
> or incomplete.  As such, I would hate to see a poorer version
> implemented because of a wish to get MLST out.

However, Robert's phrasing ("resting place") sounds rather ominous.

I want to see HOST get properly defined because of its importance to using
the AUTH comand for securing FTP with TLS.

From: draft-murray-auth-ftp-ssl-05.txt

# Although it is entirely an implementation decision, it is
# recommended that certificates used for server authentication of
# the TLS session contain the server identification information
# in a similar manner to those used for http servers.  (i.e.
# SubjectCommonName or SubjectAltName of type dNSName).

# For servers that support the 'HOST' extension defined in [FTP-
# EXT], this may mean that the server has to refuse the 'AUTH'
# command until a 'HOST' command has been issued, or else present
# the credentials for a default DNS name (which may be flagged as
# an exception by the connecting client to the user).

ie, a multi-homed server cannot maintain a certificate store per virtual
server unless the client can use HOST to specify which host it wishes to
connect to.  Allowing for virtual servers by overloading the USER command
will not help here.

As things stand, ftp-ssl-06 will remove all references to HOST.

So what can we do to advance discussion of HOST?

Mark Symons
Ipswitch, Inc
Augusta, GA

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Sep 2000 16:32:30 -0500

Date:        Thu, 21 Sep 2000 16:24:16 -0500
    From:        "Mark Symons" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is there any chance that we will see HOST get defined in its own
  | draft any time soon?
 
Someone needs to volunteer to be its editor... (I don't have the time
at the minute).    I can send the text that was in mlst-NN that related
to the HOST command for someone to use as a starting point though.

There's also the question of whether this WG will survive long enough to
complete it, which should not be assumed with discussions with the ADs etc.

kre

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Fri, 22 Sep 2000 08:59:55 -0500

<decloaking>
OK.  Here's what I have so far.

----- Original Message -----
From: "Robert Elz" <[email-masked]>
To: "FTPEXT Working Group" <[email-masked]>
Sent: Thursday, September 21, 2000 5:32 PM
Subject: Ftp-WG: draft--ietf-ftpext-mlst-11.txt

>     Message-ID:
<[email-masked]>

--

FTPEXT Working Group                                         G. Lundberg
Internet Draft                                 WU-FTPD Development Group
Updates: RFC 959                                         September, 2000

                            FTP HOST Command

                     draft-ietf-ftpext-host-01.txt
                          Expires: March, 2001

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or made obsolete by other documents at
   any time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society, 2000. All Rights Reserved.

Abstract

   This document describes the HOST command for the File Transfer
   Protocol [RFC959].

   The HOST command provides the FTP with name-based virtual hosting
   similar to that found in the Hypertext Transfer Protocol [RFC2616].
   More importantly, it provides a critical authentication element that
   has been missing from the FTP since its inception.

Lundberg                                                        [Page 1]
                            FTP HOST Command             September, 2000

Table of Contents

         Abstract......................................................1
   1.    Introduction..................................................3
   1.1.     Goals......................................................4
   1.2.     Alternatives...............................................4
   2.    Document Conventions..........................................6
   3.    HOST Command..................................................6
   3.1.     Syntax.....................................................6
   3.2.     Responses..................................................6
   4.    Security Considerations.......................................8
   5.    References....................................................8
         Acknowledgements..............................................9
         Author's Address..............................................9
         Notices.......................................................9
         Full Copyright Statement.....................................10

Lundberg        Proposed Standard - Expires March, 2001         [Page 2]
                            FTP HOST Command             September, 2000

1. Introduction

   A problem with the FTP is the lack of any means to inform the server
   of which hosted site name to use when interpreting various commands.
   If this information cannot be inferred from out-of-band data, it may
   prevent the server's taking appropriate action for the particular
   hosted site. What is needed is a means whereby the client may
   communicate the required information to the server.

   Currently, to obtain this information, the server must examine the
   address used for the control connection to determine which hosted
   site is being accessed. This depends upon both the information being
   available and a unique relationship between addresses and hosted
   sites.

   Hosting additional sites depends upon sufficient address space to
   maintain the one-to-one relationship. Much has been said about the
   growing scarcity of IPv4 Internet addresses. Recently, [ARIN] imposed
   severe restrictions upon certain IPv4 Internet address allocations.
   The impending deployment of IPv6 (see [IANA]) provides sufficient
   address space to continue using unique addresses for each hosted FTP
   site. These facts are often used as arguments, both for and against,
   name-based services. Such statements are misleading. They miss an
   essential point: the controlling factor in address allocation is not
   the total size of the Internet address pool. Even with the advent of
   IPv6, individual sites and networks will be continue to be subject to
   the address allocation rules of their regional authority, upstream
   providers, hosting service providers and local policy. The minimum
   largest-allocable block is a single address. Any presumption that
   more addresses are available is potentially false. Protocols, such as
   the FTP, which depend upon readily available addresses to host
   multiple sites on a single server or network run the risk of becoming
   unusable.

   Technologies such as Network Address Translation [RFC1631] provide
   network designers with a means to map Internet addresses to other
   addresses, potentially obscuring or even loosing the required one-to-
   one relationship. If such technologies are in place, unless care is
   taken to preserve the necessary information, in-band communication is
   the only reliable method for the client to inform the server of the
   hosted site being accessed.

   The Domain Name System [RFC1034, RFC1035] allows any number of host
   names to be directed to the same Internet address. Many site
   administrators make use of this feature to avoid the necessity of
   permanently assigning Internet addresses to hosts, possibly requiring
   reconfiguration of firewalls or routers, or depleting an address
   allocation. By using hostnames rather than Internet addresses, new
   sites may be added simply by ensuring the server is properly
   prepared, then adding appropriate information into the Domain Name
   System. Using this scheme, any number of sites may be hosted on a
   single server. Unfortunately, only the client knows which is being
   accessed. There is no means for the server to infer this information
   from out-of-band data.

Lundberg        Proposed Standard - Expires March, 2001         [Page 3]
                            FTP HOST Command             September, 2000

1.1. Goals

   Since only the client has the required information, any change will
   involve some modification of the client implementation. Any proposed
   correction to the FTP must meet the following goals:

    * Name-based hosting.

      The client must provide the server with the name of the hosted
      site being accessed. This information must be communicated in-
      band. The protocol cannot rely upon the ability to infer it from
      out-of-band information.

    * Name-based authentication and authorization.

      Clients should provide the hosted site name information prior to
      authentication.

      Administrators need control over which users may access specific
      services and the rights granted those users. Host name information
      communicated from the client to the server should be presented as
      part of the login sequence. The protocol should allow servers to
      adjust to authorization and authentication requirements based upon
      the host name provided by the client. For example, a given
      USER/PASS token pair may be considered valid when given in the
      context of one hosted site name, but invalid in others.

    * Interoperability with existing implementations.

      The protocol must realize that not all servers and clients will
      support the scheme. Whenever possible non-conforming clients
      should be able to use conforming servers and non-conforming
      servers should remain usable by conforming clients. Specifically,
      changes to the syntax or semantics of existing commands should be
      minimized.

    * Minimum impact upon performance.

      Network overhead should be minimized. The requirements of the
      protocol should not greatly increase the effort required by either
      the client or the server to process a command (particularly in
      relation to authentication).

    * Flexibility of implementation.

      The protocol should not force design choices upon the implementers
      unless necessary.

1.2. Alternatives

   Two basic schemes have been proposed. While the bulk of this document
   specifies one of those, this section describes the alternative and
   discusses why it was not chosen.

Lundberg        Proposed Standard - Expires March, 2001         [Page 4]
                            FTP HOST Command             September, 2000

   One recurring suggestion has been a change to the structure or
   interpretation of URLs. For instance, the URL

      ftp://ftp.example.com/pub/sample.txt

   might be interpreted as if it read

      ftp://ftp.example.com/ftp.example.com/pub/sample.txt

   thus providing the name of the site in the request.

   Mappings such as this could be implemented on the server with minimal
   impact, possibly simply by changing the site layout, requiring little
   or no change in the server's FTP implementation. In fact, a number of
   sites have taken this approach, and a case could be made for it being
   a best current practice. (If nothing else, it does make the best of a
   bad situation.) While such solutions satisfy the goal of providing
   the hosted site name, they fail to satisfy all other goals.

   The hosted site name is not available during initial authentication.
   This implies that either all users must be acceptable to all hosted
   sites, or servers must delay authentication and perform it on a by-
   command basis. Both alternatives are, at best, unpalatable.

   Furthermore, the approach only addresses a specific type of client
   implementation: web browsers. While, admittedly, this probably
   represents the largest class of client software currently deployed,
   it does not cover the full range of possible clients. Server
   implementations may require different authentication tokens based
   upon the hosted site being accessed. When viewed as a URL, where each
   session consists of a single file access command, this does not
   present too much of a problem. The FTP, however, is session based.
   Users of legacy clients would be required to remember the new
   semantics and specify the hosted site name on the appropriate
   commands, rendering the protocol cumbersome and error-prone for those
   users.

   Proposals such as given above do not minimize impact upon the
   protocol; in fact, they appear to maximize it. The syntax and
   semantics of a number of commands (and some replies) would require
   modification. The FTP currently does not specify the syntax for file
   or directory names: that is left to local convention. These
   proposals, however, require some form of syntactic analysis of names
   so that the hosted site name may be recognized. Semantically, RNFR
   and RNTO present a special problem; when sites are implemented as
   directories, should one be allowed to rename between sites?

   Finally, these schemes may have a large impact upon performance. In
   the context of an FTP session, they appear to require caching
   authentication tokens and re-evaluating them with each command. For
   cases where authentication information changes with each use (such as
   with one-time password schemes [RFC2289]) these tokens may no longer
   even be valid. The only reasonable recovery is to force early
   termination of each session so new tokens may be provided. (Notice

Lundberg        Proposed Standard - Expires March, 2001         [Page 5]
                            FTP HOST Command             September, 2000

   this could entirely preclude the use of RNFR and RNTO.)  Each session
   potentially requires human intervention to provide the necessary
   information, potentially rendering automata non-secure or unusable.

2. Document Conventions

   This document makes use of the document conventions defined in BCP14
   [RFC2119]. That provides the interpretation of some capitalized words
   like MUST, SHOULD, etc.

   Terms defined in [RFC959] will be used here as defined there. These
   include ASCII, reply, server-FTP process, user-FTP process, server-
   PI, user-PI, and user.

   The required syntax is defined using the Augmented BNF defined in
   [RCC2234]. Some general ABNF definitions are required throughout the
   document. Those will be defined later in this section. At first
   reading, it may be wise to simply recall that these definitions exist
   here, and skip to the next section.

3. HOST Command

3.1. Syntax

3.2. Responses

3.3. State Diagrams

   The FTP specification presents state diagrams for a very simple
   minded FTP implementation.  The HOST command changes the Login
   diagram.

   For each command there are three possible outcomes: success (S),
   failure (F), and error (E).  In the state diagram, there are two
   special symbols: begin (B), and "wait for reply" (W).

Lundberg        Proposed Standard - Expires March, 2001         [Page 6]
                            FTP HOST Command             September, 2000

   The following state diagram shows the HOST Login sequence.

                -----
               |     |
               |   1 |
               |     |
                -->+---+------------------
   +---+ HOST   -->+---+------------------
   | B |---------->| W | 2                |
   +---+           +---+------            |
                    | |       |           |
                   3| |4,5    |           |
      -----------   -------------      |
     |                     |     |     |
     |                     |     |     V
     |             ------------------->o
     |           1|        |     |     |
     V            |   2    V     |     |
   +---+ USER   +---+----->o     |     |
   |   |------->| W | 4,5  |     V     |
   +---+        +---+----------->o     |
                  |        |     |     |
                 3|        |     |     |
      ------------         |     |     |
     |                     |     |     V
     |             ------------------->o
     |           1|        |     |     |
     V            |   2    |     |     |
   +---+ PASS   +---+----->o     |     |
   |   |------->| W | 4,5  |     V     |
   +---+        +---+------------o     |
                  |        |     |     |
                 3|        |     |     |
      ------------         |     |     |
     |                     |     |     V
     |             ------------------->o
     |         1,3|        |     |     |
     V            |   2    |     |     |
   +---+ ACCT   +---+----->o     |     |
   |   |------->| W | 4,5  |     V     |
   +---+        +---+----------->o     |
                           |     |     |
                           V     V     V
                         +---+ +---+ +---+
                         | S | | F | | E |
                         +---+ +---+ +---+

Lundberg        Proposed Standard - Expires March, 2001         [Page 7]
                            FTP HOST Command             September, 2000

3.4. Typical Scenario

3.5. Interaction with AUTH

3.6. Interaction with FEAT

3.7. Interaction with LANG

3.8.

4. Security Considerations

   The HOST command presents no more risk than that already present in
   the USER, PASS and ACCT commands. The transmission of host names in
   clear-text could be used in traffic analysis. Where this poses an
   unacceptable risk, the control connection should be encrypted through
   transport layer security (the specifications of which are currently
   under development, see [FTPEXT]) or through the FTP Security
   Extensions (see Section 3.5 and [RFC2228]).

5. References

   [RFC959]    J. Postel and J. Reynolds, "File Transfer Protocol
               (FTP)", STD 9, RFC 959, October 1985

   [RFC1034]   P. Mockapetris, "Domain names - concepts and facilities",
               STD 13, RFC 1034, November 1987

   [RFC1035]   P. Mockapetris, "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987

   [RFC1631]   K. Egevang and P. Francis, "Network Address Translator",
               RFC 1631, May 1994

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997

   [RFC2228]   M. Horowitz and S. Lunt, "FTP Security Extensions", RFC
               2228, October 1997

   [RFC2234]   D. Crocker and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997

   [RFC2289]   N. Haller, C. Metz, P. Nesser and M. Straw, "A One-Time
               Password System", RFC 2289, February 1998

   [RFC2389]   P. Hethmon and R. Elz, "Feature negotiation mechanism for
               the File Transfer Protocol", RFC 2389, August 1998

   [RFC2616]   R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L.
               Masinter, P. Leach and T. Berners-Lee, "Hypertext
               Transfer Protocol -- HTTP/1.1", RFC 2068, June 1999

Lundberg        Proposed Standard - Expires March, 2001         [Page 8]
                            FTP HOST Command             September, 2000

   [RFC2640]   B. Curtin, "Internationalization of the File Transfer
               Protocol", RFC 2640, July 1999

   [ARIN]      ARIN, "POLICY CHANGES RESULTING FROM ARIN V",
               http://www.arin.net/announcements/policy_changes.html,
               April 2000

   [IANA]      J. Elliott, "Delegation of IPv6 address space",
               http://www.iana.org/ipaddress/ipv6-announcement.txt, July
               1999

   [FTPEXT]    P. Ford-Hutchinson, M. Carpenter, T. Hudson, E. Murray
               and V. Wiegand, "Securing FTP with TLS", Internet Draft,
               January 2000

Acknowledgements

   This protocol extension was developed in the FTPEXT Working Group of
   the IETF, and the members of that group are all acknowledged as
   contributors.

Author's Address

   Gregory A Lundberg
   WU-FTPD Development Group
   1441 Elmdale Drive
   Dayton, OH 45409-1615

   Phone:   +1 937-299-7653
   Fax:     +1 937-299-8743
   EMail:   [email-masked]

Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on IETF
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP-11. Copies of claims of
   rights made available for publication and any assurances of licenses
   to be made available, or the result of an attempt made to obtain a
   general license or permission for the use of such proprietary rights
   by implementers or users of this specification can be obtained from
   the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Lundberg        Proposed Standard - Expires March, 2001         [Page 9]
                            FTP HOST Command             September, 2000

Full Copyright Statement

   Copyright (C) The Internet Society, 2000. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Lundberg        Proposed Standard - Expires March, 2001        [Page 10]

---

From: "Mark Symons" <[email-masked]>
Date: Fri, 22 Sep 2000 16:38:14 -0500

>                      draft-ietf-ftpext-host-01.txt

Looks like a great starting point.

The HOST command was removed from mlst-09.  At the end of this message I
attach the relevent HOST sections from mlst-08.  I have not even removed the
original section numbering.  This fills in the gaps in
draft-ietf-ftpext-host-01.txt, such as Syntax and Responses.  The State
Diagram is also slightly different.

The mlst-08 HOST definition makes no reference to DNS SRV records.  I think
that they should be covered, perhaps also in the "Alternatives" section, as
they provide an alternate route for running muliple FTP hosts on a single IP
address.

Mark Symons
Ipswitch, Inc
Augusta, GA

================

6.1. The HOST command

   A new command "HOST" is added to the FTP command set to allow
   server-FTP process to determine to which of possibly many virtual
   hosts the client wishes to connect.  This command is intended to 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, if they desire, 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 the
   server-FTP process which does allow late HOST commands is undefined.
   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.

   Servers should note that the response to the HOST command is a
   sensible time to send their "welcome" message.  This allows the
   message to be personalized for any virtual hosts that are supported,
   and also allows the client to have determined supported languages, or
   representations, for the message, and other messages, via the FEAT
   response, and selected an appropriate one via the LANG command.  See
   [7] for more information.

6.2. Syntax of the HOST command

   The HOST command is defined as follows.

        host-command     = "Host" SP hostname CRLF
        hostname         = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ]
        DNCHAR           = ALPHA / DIGIT / "-" / "_" / "$" /
                           "!" / "%" / "[" / "]" / ":"
        host-response    = host-ok / error-response
        host-ok          = "220" [ SP *TCHAR ] CRLF

   As with all FTP commands, the "host" command word is case
   independent, and may be specified in any character case desired.

   The "hostname" given as a parameter specifies the virtual host to
   which access is desired.  It should normally be the same name that
   was used to obtain the IP address to which the FTP control connection
   was made, after any client conversions to convert an abbreviated or
   local alias to a complete (fully qualified) domain name, but before
   resolving a DNS alias (owner of a CNAME resource record) to its
   canonical name.

   If the client was given a network literal address, and consequently
   was not required to derive it from a hostname, it should send the
   HOST command with the network address, as specified to it, enclosed
   in brackets (after eliminating any syntax, which might also be
   brackets, but is not required to be, from which the server deduced
   that a literal address had been specified.) That is, for example

                         HOST [10.1.2.3]

   should be sent if the client had been instructed to connect to
   "10.1.2.3", or "[10.1.2.3]", or perhaps even IPv4:10.1.2.3.  The
   method of indicating to a client that a literal address is to be used
   is beyond the scope of this specification.

   The parameter is otherwise to be treated as a "complete domain name",
   as that term is defined in section 3.1 of RFC 1034 [10].  That
   implies that the name is to be treated as a case independent string,
   in that upper case ASCII characters are to be treated as equivalent
   to the corresponding lower case ASCII characters, but otherwise
   preserved as given.  It also implies some limits on the length of the
   parameter and of the components that create its internal structure.
   Those limits are not altered in any way here.

   RFC 1034 imposes no other restrictions upon what kinds of names can
   be stored in the DNS.  Nor does RFC 1035.  This specification,
   however, allows only a restricted set of names for the purposes of
   the HOST command.  Those restrictions can be inferred from the ABNF
   grammar given for the "hostname".

6.3. HOST command semantics

   Upon receiving the HOST command, before authenticating the user-PI, a
   server-FTP process should validate that the hostname given represents
   a valid virtual host for that server, and if so, establish the
   appropriate environment for that virtual host.  The meaning of that
   is not specified here, and may range from doing nothing at all, or
   performing a simple change of working directory, to much more
   elaborate state changes, as required.

   If the hostname specified is unknown at the server, or if the server
   is otherwise unwilling to treat the particular connection as a
   connection to the hostname specified, the server will respond with a
   504 reply.

   Note: servers may require that the name specified is in some sense
   equivalent to the particular network address that was used to reach
   the server.

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

   The "220" reply code for the HOST command is the same as the code
   used on the initial connection established "welcome" message.  This
   is done deliberately so as to allow the implementation to implement
   the front end FTP server as a wrapper which simply waits for the HOST
   command, and then invokes an older, RFC959 compliant, server in the
   appropriate environment for the particular hostname received.

6.3.1. The REIN command

   As specified in [3], the REIN command returns the state of the
   connection to that it was immediately after the transport connection
   was opened.  That is not changed here.  The effect of a HOST command
   will be lost if a REIN command is performed, a new HOST command must
   be issued.

   Implementors of user-FTP should be aware that server-FTP
   implementations which implement the HOST command as a wrapper around
   older implementations will be unable to correctly implement the REIN
   command.  In such an implementation, REIN will typically return the
   server-FTP to the state that existed immediately after the HOST
   command was issued, instead of to the state immediately after the
   connection was opened.

6.3.2. User-PI usage of HOST

   A user-PI that conforms to this specification, MUST send the HOST
   command after opening the transport connection, or after any REIN
   command, before attempting to authenticate the user with the USER
   command.

   The following state diagram shows a typical sequence of flow of
   control, where the "B" (begin) state is assumed to occur after the
   transport connection has opened, or a REIN command has succeeded.
   Other commands (such as FEAT [6]) which require no authentication may
   have intervened.  This diagram is modeled upon (and largely borrowed
   from) the similar diagram in section 6 of [3].

   In this diagram, a three digit reply indicates that precise server
   reply code, a single digit on a reply path indicates any server reply
   beginning with that digit, other than any three digit replies that
   might take another path.

              +---+   HOST    +---+ 1,3,5
              | B |---------->| W |-----------------
              +---+           +---+                 |
                               | |                  |
                     2,500,502 | | 4,501,503,504    |
                 --------------   -------------     |
                |                              |    |
                V                   1          |    V
              +---+   USER    +---+-------------->+---+
              |   |---------->| W | 2       ----->| E |
              +---+           +---+------  |  --->+---+
                               | |       | | | |
                             3 | | 4,5   | | | |
                 --------------   -----  | | | |
                |                      | | | | |
                |                      | | | | |
                |                 ---------  | |
                |               1|     | |   | |
                V                |     | |   | |
              +---+   PASS    +---+ 2  |  ------->+---+
              |   |---------->| W |-------------->| S |
              +---+           +---+   ----------->+---+
                               | |   | |     | |
                             3 | |4,5| |     | |
                 --------------   --------   | |
                |                    | |  |  |  ----
                |                    | |  |  |      |
                |                 -----------       |
                |             1,3|   | |  |         |
                V                |  2| |  |         V
              +---+   ACCT    +---+--  |   ------>+---+
              |   |---------->| W | 4,5 --------->| F |
              +---+           +---+-------------->+---+

6.4. HOST command errors

   The server-PI shall reply with a 500 or 502 reply if the HOST command
   is unrecognized or unimplemented.  A 503 reply may be sent if the
   HOST command is given after a previous HOST command, or after a user
   has been authenticated.  Alternately, the server may accept the
   command at such a time, with server defined behavior.  A 501 reply
   should be sent if the hostname given is syntactically invalid, and a
   504 reply if a syntactically valid hostname is not a valid virtual
   host name for the server.

   In all such cases the server-FTP process should act as if no HOST
   command had been given.

   A user-PI receiving a 500 or 502 reply should assume that the
   server-PI does not implement the HOST command style virtual server.
   It may then proceed to login as if the HOST command had succeeded,
   and perhaps, attempt a CWD command to the hostname after
   authenticating the user.

   A user-PI receiving some other error reply should assume that the
   virtual HOST is unavailable, and terminate communications.

   A server-PI that receives a USER command, beginning the
   authentication sequence, without having received a HOST command
   SHOULD NOT reject the USER command.  Clients conforming to earlier
   FTP specifications do not send HOST commands.  In this case the
   server may act as if some default virtual host had been explicitly
   selected, or may enter an environment different from that of all
   supported virtual hosts, perhaps one in which a union of all
   available accounts exists, and which presents a NVFS which appears to
   contain sub-directories containing the NVFS for all virtual hosts
   supported.

6.5. FEAT response for HOST command

   A server-FTP process that supports the host command, and virtual FTP
   servers, MUST include in the response to the FEAT command [6], a
   feature line indicating that the HOST command is supported.  This
   line should contain the single word "HOST".  This MAY be sent in
   upper or lower case, or a mixture of both (it is case insensitive)
   but SHOULD be transmitted in upper case only.  That is, the response
   SHOULD be

        C> Feat
        S> 211- <any descriptive text>
        S>  ...
        S>  HOST
        S>  ...
        S> 211 End

   The ellipses indicate place holders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory [6].