draft-ietf-ftpext2-hosts-00.txt   draft-ietf-ftpext2-hosts-01.txt 
Network Working Group P. Hethmon FTPEXT2 Working Group P. Hethmon
Internet-Draft Hethmon Brothers Internet-Draft Hethmon Brothers
Updates: 959 R. McMurray Updates: 959 R. McMurray
Intended status: Standards Track Microsoft Intended status: Standards Track Microsoft
Expires: May 28, 2011 November 2010 Expires: June 5, 2011 December 2010
File Transfer Protocol HOST Command for Virtual Hosts File Transfer Protocol HOST Command for Virtual Hosts
draft-ietf-ftpext2-hosts-00 draft-ietf-ftpext2-hosts-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 28, 2011. This Internet-Draft will expire on June 5, 2011.
Copyright Copyright
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the BSD License.
Abstract Abstract
This document defines a new FTP command that provides a mechanism for This document defines a new FTP command that provides a mechanism for
FTP clients and servers to identify individual virtual hosts on an FTP clients and servers to identify individual virtual hosts on an
FTP server. FTP server.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................2
skipping to change at page 3, line 22 skipping to change at page 3, line 25
hostname to IP address resolution and then ignore hostnames for the hostname to IP address resolution and then ignore hostnames for the
rest of the FTP session, therefore any mechanism to overcome this rest of the FTP session, therefore any mechanism to overcome this
issue would require modifications to the user-PI and server-PI. issue would require modifications to the user-PI and server-PI.
It should be noted that this same problem existed for HTTP/1.0 as It should be noted that this same problem existed for HTTP/1.0 as
defined in [RFC1945], and was resolved in HTTP/1.1 as defined in defined in [RFC1945], and was resolved in HTTP/1.1 as defined in
[RFC2616] through the addition of the Host request header. The goal [RFC2616] through the addition of the Host request header. The goal
of this document is to bring a similar level of feature parity to FTP of this document is to bring a similar level of feature parity to FTP
by introducing a new HOST command that allows user-FTP processes to by introducing a new HOST command that allows user-FTP processes to
specify which virtual host to connect to for a server-FTP process specify which virtual host to connect to for a server-FTP process
that is handling requests for mutiple virtual hosts on a single IP that is handling requests for multiple virtual hosts on a single IP
address. address.
2. Document Conventions 2. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
In examples, "C>" and "S>" indicate lines sent by the client and In examples, "C>" and "S>" indicate lines sent by the client and
server, respectively. server, respectively.
skipping to change at page 7, line 20 skipping to change at page 7, line 23
in section 3.1 of [RFC1034]. This implies that the name is to be in section 3.1 of [RFC1034]. This implies that the name is to be
treated as a case-independent string, meaning that uppercase ASCII treated as a case-independent string, meaning that uppercase ASCII
characters are to be treated as equivalent to their corresponding characters are to be treated as equivalent to their corresponding
lowercase ASCII characters, but otherwise preserved as given. It lowercase ASCII characters, but otherwise preserved as given. It
also implies some limits on the length of the parameter and of the also implies some limits on the length of the parameter and of the
components that create its internal structure. Those limits are not components that create its internal structure. Those limits are not
altered in any way here. altered in any way here.
Neither [RFC1034] nor [RFC1035] impose any other restrictions upon Neither [RFC1034] nor [RFC1035] impose any other restrictions upon
what kinds of names can be stored in the DNS. This specification, what kinds of names can be stored in the DNS. This specification,
however, allows only the of names that can be inferred from the ABNF however, only allows the use of names that can be inferred from the
grammar given for the "hostname". ABNF grammar given for the "hostname".
3.2. HOST command semantics 3.2. HOST command semantics
Upon receiving the HOST command, before authenticating the user-PI, a Upon receiving the HOST command, before authenticating the user-PI, a
server-FTP process SHOULD validate that the hostname given represents server-FTP process SHOULD validate that the hostname given represents
a valid virtual host for that server, and, if it is valid, establish a valid virtual host for that server, and, if it is valid, establish
the appropriate environment for that virtual host. The resultant the appropriate environment for that virtual host. The resultant
actions needed to create that environment are not specified here, and actions needed to create that environment are not specified here, and
may range from doing nothing at all, to performing a simple change of may range from doing nothing at all, to performing a simple change of
working directory, to changing authentication schemes and/or username working directory, to changing authentication schemes and/or username
skipping to change at page 14, line 32 skipping to change at page 14, line 36
b. Treat the HOST command as though a REIN command was sent and b. Treat the HOST command as though a REIN command was sent and
reset the user-PI to the state that existed after the previous reset the user-PI to the state that existed after the previous
HOST command was sent and before the user had been authenticated, HOST command was sent and before the user had been authenticated,
and then return the appropriate reply for the HOST command. and then return the appropriate reply for the HOST command.
A 501 reply SHOULD be sent if the hostname given is syntactically A 501 reply SHOULD be sent if the hostname given is syntactically
invalid, and a 504 reply SHOULD be sent if a syntactically valid invalid, and a 504 reply SHOULD be sent if a syntactically valid
hostname is not a valid virtual host name for the server. In all hostname is not a valid virtual host name for the server. In all
such cases, the server-FTP process MUST do one of the following: such cases, the server-FTP process MUST do one of the following:
a. Ignore the HOST command and act as if as if a HOST command a. Ignore the HOST command and act as if a HOST command had not
had not been sent. A user-FTP process MAY then send a subsequent been sent. A user-FTP process MAY then send a subsequent HOST
HOST command with a different hostname. command with a different hostname.
b. Close the connection. b. Close the connection.
A user-PI receiving a 500 or 502 reply to a HOST command SHOULD A user-PI receiving a 500 or 502 reply to a HOST command SHOULD
assume that the server-PI does not implement virtual servers by using assume that the server-PI does not implement virtual servers by using
the HOST command. The user-PI MAY then proceed to login as if the the HOST command. The user-PI MAY then proceed to login as if the
HOST command had not been sent. HOST command had not been sent.
A user-PI receiving an error reply that is different from the errors A user-PI receiving an error reply that is different from the errors
that have been described here SHOULD assume that the virtual HOST is that have been described here SHOULD assume that the virtual HOST is
skipping to change at page 19, line 38 skipping to change at page 19, line 41
HOST command in their Internet draft titled "Extensions to FTP" HOST command in their Internet draft titled "Extensions to FTP"
as part of their work with the FTPEXT Working Group at the IETF. as part of their work with the FTPEXT Working Group at the IETF.
Their work formed the basis for much of this document, and their Their work formed the basis for much of this document, and their
help has been greatly appreciated. They would also like to credit help has been greatly appreciated. They would also like to credit
Bernhard Rosenkraenzer for having first suggested and described the Bernhard Rosenkraenzer for having first suggested and described the
HOST command. HOST command.
Alexey Melnikov, Alfred Hoenes, John Klensin, and Joe Touch have made Alexey Melnikov, Alfred Hoenes, John Klensin, and Joe Touch have made
several suggestions about earlier versions of this document; many of several suggestions about earlier versions of this document; many of
their suggestions have been incorporated, and their contributions are their suggestions have been incorporated, and their contributions are
gratefully acknowledged. In addition, Alec Rowell's assitance in gratefully acknowledged. In addition, Alec Rowell's assistance in
making sections of this document more readable was invaluable. making sections of this document more readable was invaluable.
Authors' Addresses Authors' Addresses
Paul Hethmon Paul Hethmon
Hethmon Brothers Hethmon Brothers
2305 Chukar Road 2305 Chukar Road
Knoxville, TN 37923 USA Knoxville, TN 37923 USA
Email: phethmon@hethmon.com Email: phethmon@hethmon.com
 End of changes. 9 change blocks. 
14 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/