[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-yevstifeyev-ftp-iri) 00 01 02 03 04 05 06 07 08

INTERNET-DRAFT                                            M. Yevstifeyev
Intended Status: Standards Track                            July 7, 2011
Updates: 959, 1738 (if approved)
Expires: January 8, 2012

                          The 'ftp' URI Scheme
                  draft-yevstifeyev-ftp-uri-scheme-04

Abstract

   This document specifies the 'ftp' Uniform Resource Identifier (URI)
   scheme, which is used to refer to resources accessible via File
   Transfer Protocol (FTP).  It updates RFC 959 and RFC 1738.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 obsoleted 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/1id-abstracts.html

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

Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with 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



Yevstifeyev             Expires January 8, 2012                 [Page 1]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1  Terminology and Conventions . . . . . . . . . . . . . . . .  3
   2. URI Scheme Specification  . . . . . . . . . . . . . . . . . . .  4
     2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . .  4
     2.2. URI Scheme Semantics  . . . . . . . . . . . . . . . . . . .  5
       2.2.1. The <host-port> Part  . . . . . . . . . . . . . . . . .  6
       2.2.2. The <user-pass> Part  . . . . . . . . . . . . . . . . .  7
       2.2.3. The <ftp-path> Part . . . . . . . . . . . . . . . . . .  8
         2.2.3.1. The <typecode-part> Part  . . . . . . . . . . . . .  9
     2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 10
   3. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
     5.1. The 'ftp' URI Scheme  . . . . . . . . . . . . . . . . . . . 13
     5.2. The 'ftps' URI Scheme . . . . . . . . . . . . . . . . . . . 14
     5.3. Maintaining ftp.uri.arpa Domain . . . . . . . . . . . . . . 14
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1. Normative References  . . . . . . . . . . . . . . . . . . . 14
     6.2. Informative References  . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Dynamic Delegation Discovery System (DDDS) and
            'ftp' URIs  . . . . . . . . . . . . . . . . . . . . . . . 18
   Appendix B.  Previous Syntax Definitions . . . . . . . . . . . . . 19
     B.1. RFC 1630  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     B.2. RFC 1738  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Appendix C.  List of Changes since RFC 1738  . . . . . . . . . . . 21
   Appendix D.  Acknowledgments . . . . . . . . . . . . . . . . . . . 21
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

1. Introduction

   File Transfer Protocol (FTP) is a standard network protocol used to
   copy a file from one host to another over a TCP-based network.  It
   has had a very long history; the protocol is rooted in the early
   1970s, the times of ARPANET, with the first specification being RFC
   114 [RFC0114]; the most current FTP specification is RFC 959
   [RFC0959].  RFC 1123 [RFC1123] made a number of changes to FTP
   specification.

   The 'ftp' Uniform Resource Identifier (URI) scheme, used for
   referencing resources accessible via FTP, has been deployed.  It was
   first mentioned in RFC 1630 [RFC1630] - pre-Standard Track RFC on
   URIs.  Later, RFC 1738 [RFC1738], Section 3.2 specified this scheme,
   as well as many others, on IETF Standards Track.  This document
   extracts the definition of the 'ftp' URI scheme from this document to



Yevstifeyev             Expires January 8, 2012                 [Page 2]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   retain on Standard Track if RFC 1738 is moved to Historic status
   [RFC2026][HISTORIC] as well as makes several changes to suit current
   scheme usage.  (With the first respect it belongs to a series of
   similar documents like RFC 2368 [RFC2368] (which is now obsoleted by
   RFC 6068 [RFC6068]), RFC 4248 [RFC4248], RFC 4266 [RFC4266] and RFC
   5538 [RFC5538]; RFC 4156 [RFC4156] and RFC 4157 [RFC4157] also
   extracted definition of 'wais' and 'prospero' schemes from RFC 1738
   but have no relation to Standards Track, since the aforementioned
   schemes are historical.)  It updates RFC 959 and RFC 1738.

   Generic URI syntax is described in RFC 3986 [RFC3986]; registration
   procedures for new URI schemes - in RFC 4395 [RFC4395].

1.1  Terminology and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   In this document, the terms "client" and "server" are used in the
   meaning of "user-FTP process" and "server-FTP process", respectively,
   which are defined in Section 2.2 of RFC 959 [RFC0959].  The terms
   "FTP command" (referred to as "command" within this document), "user-
   PI", "server-PI", "user-DTP", "server-DTP", "control connection",
   "data connection", "reply" and "user" are used with the meaning
   defined ibidem.  Section 2.3 makes use of terms described in RFC
   3536bis [RFC3536bis].  Terms related to DDDS used in Appendix A,
   especially those which occur capitalized, are described in RFC 3402
   [RFC3402].

   In this document "ASCII" refers to the American Standard Code for
   Information Interchange, defined in [ASCII] and amended for use in
   network interchange by RFC 20 [RFC0020]; definition of "ASCII" found
   in RFC 959 [RFC0959] may be considered to be equivalent.  The
   construction "ASCII character 0xHH", where "HH" represents 2
   hexadecimal digits, is equivalent to RFC 20 construction "ASCII
   X'HH'" and denotes ASCII character which has been assigned the ASCII
   code HH.  For example, ASCII character 0x5E refers to the "^" (caret)
   and ASCII character 0x7B refers to "{" (left curly bracket).

   This document uses the Augmented Backus-Naur Form (ABNF) [RFC5234]
   for description of formal syntax.  The <host>, <port>, <unreserved>,
   <pct-encoded>, and <sub-delims> rules are imported from RFC 3986
   [RFC3986] and <ALPHA> rule - from RFC 5234 [RFC5234].

   In the examples of FTP dialogs presented in this document, lines that
   begin "C> " were sent over the control connection from the user-PI to



Yevstifeyev             Expires January 8, 2012                 [Page 3]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   the server-PI, and lines that begin "S> " were sent over the control
   connection from the server-PI to the user-PI.  In all cases, the
   prefixes shown above, including the one space, have been added for
   the purposes of this document, and are not a part of the data
   exchanged between client and server.  Within such dialogs text
   enclosed in angle brackets ("<" and ">", ASCII characters 0x3C and
   0x3E, respectively) is not an actual part of FTP exchange but rather
   describes actions taken by parties of exchange or provides general
   comment.

2. URI Scheme Specification

2.1. URI Scheme Syntax

   The syntax of 'ftp' URI is described in <ftp-uri> rule below.

     ftp-uri       = "ftp:" ftp-hier-part
     ftp-hier-part = "//" [ user-pass "@" ] host-port [ ftp-path ]

     user-pass     = user [ ":" pass ]
     user          = 1*usp-char
     pass          = *usp-char
     usp-char      = unreserved / pct-encoded / sub-delims

     host-port     = host [ ":" port ]

     ftp-path      = [ cwd-part ] "/" last-segment [ typecode-part ]
     cwd-part      = *( "/" cwd )
     cwd           = segment-nsc
     last-segment  = segment-nsc
     segment-nsc   = *pchar-nsc
     pchar-nsc     = unreserved / pct-encoded / sub-delims-nsc / ":"
                   / "@"
     sub-delims-nsc = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" /
                   / "," / "="
                   ; RFC 3986 <sub-delims> excluding semicolon (";")
                   ; character (ASCII character 0x3B)
     typecode-part = ";type=" typecode
     typecode      = "a" / "e" / "i" / "u" / "d" / typecode-ext
     typecode-ext  = ALPHA

   RFC 3986 deprecated the use of "user:pass" format of the <userinfo>
   part of URIs.  However, for some historical reasons, the benefits of
   the use of such construction for denoting the user information in the
   'ftp' URIs are valuable enough to overlook this issue; see Section
   2.2.2 of this document.

   When <ftp-path> is present, it should be noted that <last-segment> is



Yevstifeyev             Expires January 8, 2012                 [Page 4]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   always present, too; it may be null, though.  For instance, the URIs
   <ftp://exmaple.org/> and <ftp://example.net/foo/> have null <last-
   segment>s while <ftp://exmaple.com/big> has the <last-segment> equal
   to "big".

   Please note that while processing the 'ftp' URI those character which
   appear percent-encoded, MUST be decoded for the purpose of handling
   the URI, including the actual FTP exchange; see Section 2.3 for more
   information.

   The semantics of each part are defined in Section 2.2.

2.2. URI Scheme Semantics

   The 'ftp' URI specifies a resource (a file or a directory listing) on
   the definite FTP server.

   The application resolving the 'ftp' URI SHALL use the following
   algorithm:

   (1) establish the Transmission Control Protocol (TCP) [RFC0793]
       connection to the server identified by the <host> on the port
       identified by the <port> (or 21, if not supplied in the 'ftp'
       URI);

   (2) perform an attempt to identify the host it is trying to access
       using the HOST command [I-D ietf-ftpext2-hosts], as described in
       Section 2.2.1;

   (3) authenticate itself to the server;

   (4) request a list of supported features from server using FEAT
       command [RFC2389]; if feature negotiation mechanism is not
       supported by the server, act if the FEAT command has not been
       sent; and

   (5) perform a series of commands according to <ftp-path> part.

   Please note that the client MAY also perform other steps during this
   algorithm, such as requesting the server information using SYST
   command [RFC0959] or select a language of interchange using LANG
   command [RFC2640].  However, performing the steps of this algorithm
   is REQUIRED.

   If either 421, 500 or 501 reply is received during processing the
   'ftp' URI, the client SHALL stop handling the URI, notify the user
   and take no further actions.  Handling other error replies received
   during processing the URI, unless clearly stated in this document, is



Yevstifeyev             Expires January 8, 2012                 [Page 5]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   implementation-specific.

   Since 'ftp' URI does not denote the transmission mode which is to be
   used, the stream mode, which is described in Section 3.4.1 of RFC 959
   [RFC0959], MUST always be used.

   'ftp' URIs cannot be used for other operations, such as uploading or
   removing a file on a server.

     Note:  The 'ftp' URI scheme supports FTP over TCP only; such
     derivations as FTP over User Datagram Protocol (UDP) [RFC0768] are
     not supported by it.

     Note:  The 'ftp' and the 'file' URI are not the same, even though
     they both may refer to the resource on the local host.

   More detailed description of each URI's parts' semantics is below.

2.2.1. The <host-port> Part

   The <host-port> part, which is REQUIRED, consists of the <host> and
   the <port> parts.  The <host> part, which is REQUIRED within <host-
   port>, specifies the server which a connection is to be established
   to.  The <port> part, which is OPTIONAL within <host-port>, denotes
   the TCP port for establishing such connection.

   If the <port> part with the preceding colon (":") character (ASCII
   character 0x3A) is omitted, the port SHALL default to 21, as
   registered in [IANA-PORTREG].

   Upon establishing a successful TCP connection, the client SHALL first
   try to identify the host it is trying to access using the HOST
   command [I-D ietf-ftpext2-hosts].  It is performed by sending this
   command with the <host> part of the URI as an argument.

   If either 500 or 502 reply is received in response (which identify
   that the HOST command is unrecognized or unimplemented,
   respectively), the client SHALL act as if a HOST command had not been
   sent and continue processing the URI.  If either 501 or 504 reply is
   received (which identify that the supplied hostname is syntactically
   invalid or it is unavailable, respectively), the client's behavior
   depends on how does the server react.  If, in accordance with Section
   3.3 of RFC nnnn [I-D ietf-ftpext2-hosts], the server chooses to
   terminate the connection, the client SHALL notify the user and take
   no further actions.  Otherwise, if the server does not terminate the
   connection, the client SHALL act as if a HOST command had not been
   sent and continue processing the URI.




Yevstifeyev             Expires January 8, 2012                 [Page 6]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


2.2.2. The <user-pass> Part

   The <user-pass> part, which is OPTIONAL, consists of the <user> and
   the <pass> parts.  The <user> part, which is REQUIRED within <user-
   pass>, denotes the user name; the <pass> part, which is OPTIONAL
   within <user-pass>, - the password.  The user name and the password
   are delimited by the colon (":") character (ASCII character 0x3A).

   There are three cases of handling the <user-pass> part.  The first
   implies that the 'ftp' URI provides entire user credentials (a user
   name and a password).  In this case, upon establishing successful TCP
   connection to the server specified in the URI the client SHALL use
   supplied user name with the USER command; if the server requests the
   password via sending the 331 reply, one supplied in the URI SHALL
   first be used.

   The second case covers the situation when the only user name is
   supplied.  Under such circumstances, the client SHALL first use it in
   the USER command; if the server requests password, it SHALL be
   prompted from the user and then supplied with the PASS command.

   The third case is when the whole <user-pass> part is omitted in the
   URI.  In this case upon establishing the connection the "anonymous
   FTP" [RFC1635] SHALL be used; it implies use of the following
   credentials:

   (1) the user name "anonymous", and

   (2) the password "guest" or that which is the email address [RFC5322]
       of the user.

   However, the authentication which implies use of <user-pass> part of
   the URI might be unsuccessful (ie. the server might fail to
   authenticate the user), which is indicated by receiving the 530 reply
   in response to either USER or PASS command.  In this case, the user
   name and password SHALL be requested from the user and then used.  If
   the credentials supplied by the user did not lead to successful
   authentication as well, they SHALL be requested once more unless and
   until the user gets authenticated or decides to terminate connection.

   The 'ftp' URI does not provide a way to denote account information,
   used with ACCT command.  Thus, if the server requests it for
   authentication (via sending 332 reply to a successful PASS command)
   or it is required for performing other command (which is denoted by
   either 332 or 532 server reply received upon sending such command),
   it SHALL be requested from the user and then used.  In the case when
   sever refuses to accept such account information, it SHALL be
   requested once more unless and until the user gets authenticated or



Yevstifeyev             Expires January 8, 2012                 [Page 7]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   decides to terminate connection.

   The <user-pass> part is not intended to define information which
   should be used if the authentication is performed using the AUTH
   command or other mechanism spelled out in RFC 2228 [RFC2228]; see
   Section 3 of this document.

2.2.3. The <ftp-path> Part

   The <ftp-path> part, which is OPTIONAL, denotes the resource (a file
   or a directory listing) on the server specified by <host>.  For
   better understanding the algorithm below, the ABNF definition of
   <ftp-path> is copied here:

     ftp-path      = [ cwd-part ] "/" last-segment [ typecode-part ]
     cwd-part      = *( "/" cwd )
     cwd           = segment-nsc
     last-segment  = segment-nsc
     segment-nsc   = <defined in Section 2.1>
     typecode-part = ";type=" typecode
     typecode      = "a" / "e" / "i" / "u" / "d" / typecode-ext
     typecode-ext  = ALPHA

   Please note that when <ftp-path> is omitted, for the purpose of
   processing the URI it MUST be considered to be "/" and SHOULD be
   changed to "/" when normalizing the URI.

   The <ftp-path> part SHALL be processed using the following algorithm:

   (1)  if the <cwd-part> is present, each of <cwd> parts are
        consistently supplied as arguments to the CWD (change working
        directory) FTP command;

     Note:  Any null <cwd> parts, allowed per aforementioned syntax,
     MUST NOT cause sending CWD commands, since they might be
     erroneously interpreted by some FTP servers.

   (2)  if the <typecode-part> is present and <typecode> is either "a",
        "e", "i" or "u", perform the TYPE command with the <typecode> as
        an argument;

   (3)  whatever the path is, arrange the data connection to the server
        using an appropriate method, as per those facilities of server
        discovered with FEAT command [RFC2389] (eg. PORT, PASV
        [RFC0959], EPRT or EPSV [RFC2428] command; using LPRT and LPSV
        [RFC1639] commands, which were designated as historical by RFC
        5797 [RFC5797] and RFC oooo [I-D yevstifeyev-foobar-to-
        historic], is strongly discouraged);



Yevstifeyev             Expires January 8, 2012                 [Page 8]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   (4a) if <last-segment> is null (whatever <typecode> is), retrieve the
        listing of current directory using appropriate method, as per
        those facilities of server discovered with FEAT command
        [RFC2389] (eg. LIST, NLST [RFC0959] or MLSD [RFC3659] command);

     Note:  If <cwd-part> is omitted and <last-segment> is null,
     <ftp-path> refers to the default directory on the <host>; in this
     case directory listings are to be retrieved directly after
     establishing data connection, skipping steps (1) and (2) above.

   (4b) if the <typecode-part> is present and the <typecode> is equal to
        "d", <last-segment> specifies the directory; in this case
        retrieve listing of the directory specified by <last-segment>
        using the appropriate method (see above);

   (4c) in the case described in (2) <last-segment> refers to a file;
        retrieve this file using appropriate method (using RETR command
        is RECOMMENDED);

   (4d) otherwise, <last-segment> may refer either to a file or a
        directory listing; perform both subsequent attempts to access
        the file and a directory listing whereas the order of such
        attempts is non-substantial.

     Note:  Some client may involve additional heuristic algorithms to
     determine what does the <last-segment> refer to, such as checking
     its format to see whether is matches the "<name>.<extension>"
     format.  This document allows them to do in such way.

   Please note that the client MAY also perform other steps during this
   algorithm, such as retrieving file size using SIZE command or
   modification time using MSTM command [RFC3659].  However, performing
   the steps of this algorithm is REQUIRED.

   If the reply which identifies the absence of the resource (a
   directory or a file) identified by one of the <cwd> parts or a <last-
   segment> part of the URI (explicitly, 550 reply) is receivede, the
   client SHALL stop processing the 'ftp' URI, remain the most currently
   accessed directory active, notify the user, and take no further
   actions.

   Handling other error replies caused by processing the <ftp-path> is
   implementation-specific.

2.2.3.1. The <typecode-part> Part

   The <typecode-part> part specifies the data type of <last-segment>.
   Currently, there are five options of <typecode>: "a", "e", "i", which



Yevstifeyev             Expires January 8, 2012                 [Page 9]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   are specified in RFC 959 [RFC0959] and stand for ASCII [ASCII],
   EBCDIC [RFC0183] text, "raw" (binary) data, "u", which is specified
   in RFC mmmm [I-D ietf-ftpext2-typeu] and stands for Unicode [RFC5198]
   text, and "d", which is not an actual typecode but rather a "pseudo-
   typecode" to identify that the <last-segment> is a directory.

   The <typecode-ext> production provides a possibility to accommodate
   new typecodes in the 'ftp' URI.  Therefore, when a new FTP data type
   is defined, its specification MUST define its relationship with the
   'ftp' URI.

2.3. Encoding Considerations

   The 'ftp' URIs may contain characters form the Universal Character
   Set (UCS) [UCS], encoded using UTF-8 [RFC3629], as suggested by RFC
   3986 [RFC3986].  Then those octets that do not correspond to the
   characters allowed by ABNF in a particular part of the URI SHALL be
   percent-encoded within this part.  In fact, there are no other
   encoding considerations for 'ftp' URIs not addressed in Section 2 of
   RFC 3986.

   As mentioned before, those character which appear percent-encoded in
   the URI, MUST be decoded in the actual FTP exchange.  This means that
   when sending data over FTP control connection per Section 2.2 of this
   document percent-encoded characters SHALL be replaced with their
   ASCII equivalents.  For instance, "%2F", if occurs in the <cwd>, will
   be replaced with "/", ASCII character 0x2F, when sending as an
   argument to CWD command.

3. Examples

   This section provides several examples of 'ftp' URIs and their valid
   handling per this document.  Within it, DNS names reserved by RFC
   2606 [RFC2606] and IPv4 addresses reserved by RFC 5737 [RFC5737] are
   used.

   The URI

     <ftp://example.com:48557/%2Fsomedir/seconddir;type=d>

   may result in the following data exchange:

        <client connecting to exmaple.com on port 48557>
     S> 220 ExampleFTP Server ready
     C> HOST example.com
     S> 220 Host accepted
     C> USER anonymous
     S> 331 Anonymous permitted; supply email as password



Yevstifeyev             Expires January 8, 2012                [Page 10]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


     C> PASS bad-guy@example.com
     S> 230 Logged in
     C> CWD /somedir
     S> 250 Directory changed
     C> PASV
     S> 227 Entering Passive Mode (192,0,2,12,152,453)
     C> NLST seconddir
     S> 150 Here comes the directory listing
        <server-DTP sending directory listing over data connection
        to user-DTP>
     S> 226 Directory listing sent

   The URI

     <ftp://fellow:bad-guy@203.0.113.42/file.txt>

   may result in the following data exchange:

        <client connecting to 203.0.113.42 on port 21>
     S> 220 CoolFTP Server Ready
     C> HOST 203.0.113.42
     S> 220 Host OK
     C> USER fellow
     S> 331 Specify password
     C> PASS bad-guy
     S> 230 Congrats! Logged in
     C> PASV
     S> 227 Passive entered (203,0,113,42,259,853)
        <the <last-segment> is a file to the client's mind>
     C> RETR file.txt
     S> 150 Transfer starts...
        <server-DTP sending file.txt over data connection to user-DTP>
     S> 226 File is sent

   The following example illustrates the situation when supplied
   credentials are invalid.  Thus, the URI

     <ftp://user1:invalid-pass@example.net:48596/;type=d>

   may result in the following:

        <connecting to example.net on port 48596>
     S> 220 GigaSoft FTP - welcome
     C> HOST example.net
     S> 220 Why not :-)
     C> USER user1
     S> 331 Mention password
     C> PASS invalid-pass



Yevstifeyev             Expires January 8, 2012                [Page 11]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


     S> 530 Invalid credentials
        <client requests credentials from user>
        <user specified: "right-user" as user name and "right-pass" as
        password>
     C> USER right-user
     S> 331 Mention password
     C> PASS right-pass
     S> 230 right-user is a cool guy
     C> PASV
     S> 227 Passive opened on (198,51,100,41,125,623)
     C> MLSD
     S> 150 Here comes the directory listing
        <server-DTP sending directory listing over data connection
        to user-DTP>
     S> 226 Directory listing sent

   The last example illustrates the complicated URI where a number of
   issues should be considered.  Such issues include the server refusing
   to accept host name with HOST command, invalid user credentials,
   inability to support the "u" TYPE parameter and the absence of "bad-
   file.doc".  The URI:

     <ftp://oh-no@exmaple.org:48621/foo//bar/foobar/bad-file.doc;type=u>

   may result in the following data interchange:

        <client connecting to example.org on port 48621>
     S> 220 Yevstifeyev FTP ready
     C> HOST exmaple.org
     S> 504 Unknown host
        <server does not close connection>
     C> USER oh-no
     S> 331 Supply password
        <password not supplied in URI; client requests one from user>
        <user specified: "some-pass" is a password>
     C> PASS some-pass
     S> 530 Invalid credentials
        <client requests credentials from user>
        <user specified: "cool-man" as user name and "cool-pass" as
        password>
     C> USER cool-man
     S> 331 Supply password
     C> PASS cool-pass
     S> 230 Authenticated
     C> CWD foo
     S> 250 foo is an active directory
     C> CWD bar
     S> 250 foo/bar is an active directory



Yevstifeyev             Expires January 8, 2012                [Page 12]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


     C> CWD foobar
     S> 250 foo/bar/foobar is an active directory
     C> TYPE u
     S> 504 U TYPE not supported
     C> PORT 192,0,2,14,644,695
     S> 200 Accepted
     C> RETR bad-file.doc
     S> 550 No such file :-(
        <client notifies user>

4. Security Considerations

   Generic security considerations for URIs are discussed in Section 7
   of RFC 3986 [RFC3986].

   Security considerations for FTP are addressed in RFC 2577 [RFC2577].
   RFC 2228 [RFC2228] and RFC 4217 [RFC4217] provided several ways for
   securing FTP.  However, the 'ftp' URI does not allow to denote
   whether any of these ways should be used.  The 'ftps' URI scheme,
   which denotes the resource available via FTP secured as defined in
   RFC 4217, is known to be deployed; this document provisionally
   registers this scheme with IANA (see Section 5.2), but specifying it
   is out of the scope of this document.

5. IANA Considerations

5.1. The 'ftp' URI Scheme

   IANA is asked to update the registration of the 'ftp' URI scheme in
   the appropriate registry [IANA-URIREG] with the reference to this
   document using the following template, per [RFC4395]:

     URI scheme name: ftp

     Status: Permanent

     URI scheme syntax: see Section 2.1 of RFC xxxx

     URI scheme semantics: see Section 2.2 of RFC xxxx

     URI scheme encoding considerations: see Section 2.3 of RFC xxxx

     Protocols that use the scheme: File Transfer Protocol (FTP)
     [RFC0959]

     Security considerations: see Section 4 of RFC xxxx

     Contact: IESG <iesg@ietf.org>



Yevstifeyev             Expires January 8, 2012                [Page 13]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


     Author/Change controller: IETF <ietf@ietf.org>

     References: see Section 6 of RFC xxxx

   [RFC Editor: Please replace xxxx with assigned RFC number]

5.2. The 'ftps' URI Scheme

   IANA is requested to provisionally register the 'ftps' URI scheme per
   RFC 4395 [RFC4395] with reference for this document.  Specifying this
   scheme is out of the scope of this document; therefore the
   registration template is not supplied.  As required by Section 3 of
   RFC 4395, the change controller for the registration is IETF
   <ietf@ietf.org>; contact party is IESG <iesg@ietf.org>.

5.3. Maintaining ftp.uri.arpa Domain

   As primarily requested by [MSG-REG] per RFC 3405 [RFC3405], IANA will
   continue maintaining the ftp.uri.arpa domain for use of DDDS with
   'ftp' URIs (see Appendix A).  No further IANA actions are requested
   with this respect.

6. References

6.1. Normative References

   [ASCII]    American National Standards Institute (ANSI), "Coded
              Character Set -- 7-bit American Standard Code for
              Information Interchange", ANSI X3.4-1986, December 1986.

              ANSI X3.4-1968 has been replaced by newer versions with
              slight modifications, but the 1968 version remains
              definitive for the Internet.

   [I-D ietf-ftpext2-hosts]
              Hethmon, P., and R. McMurray, "File Transfer Protocol HOST
              Command for Virtual Hosts", Work in Progress (draft-ietf-
              ftpext2-hosts), February 2011.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, October 1985.

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




Yevstifeyev             Expires January 8, 2012                [Page 14]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


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

   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Four: The Uniform Resource Identifiers (URI)",
              RFC 3404, October 2002.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234, January
              2008.

6.2. Informative References

   [IANA-PORTREG]
              Internet Assigned Numbers Authority (IANA), "Port
              Numbers", <http://www.iana.org/>.

   [IANA-URIREG]
              Internet Assigned Numbers Authority (IANA), "Uniform
              Resource Identifier (URI) Schemes",
              <http://www.iana.org/>.

   [I-D ietf-ftpext2-typeu]
              Klensin, J., "FTP Extension for Internationalized Text",
              Work in Progress (draft-ietf-ftpext2-typeu), June 2011.

   [I-D yevstifeyev-foobar-to-historic]
              Yevstifeyev, M., "Moving RFC 1545 and RFC 1639 to
              Historic", Work in Progress (draft-yevstifeyev-foobar-to-
              historic), July 2011.

   [HISTORIC] The IESG, "IESG Statement on Designating RFCs as
              Historic", IESG Statement, June 2011,
              <http://www.ietf.org/iesg/statement/designating-rfcs-as-
              historic.html>.

   [MSG-REG]  Mealling, M., "Registration of the 'ftp' URI scheme in
              uri.arpa under the key ftp.uri.arpa.", Mailing List
              Posting, January 2003,
              <http://www.iana.org/protocols/archives/register-
              uri/msg00000.html>



Yevstifeyev             Expires January 8, 2012                [Page 15]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
              October 1969.

   [RFC0114]  Bhushan, A., "File Transfer Protocol", RFC 114, April
              1971.

   [RFC0183]  Winett, J., "EBCDIC Codes and Their Mapping to ASCII",
              RFC 183, July 1971.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0822]  Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
              TEXT MESSAGES", STD 11, RFC 822, August 1982.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123, October 1989.

   [RFC1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
              Unifying Syntax for the Expression of Names and Addresses
              of Objects on the Network as used in the World-Wide Web",
              RFC 1630, June 1994.

   [RFC1635]  Deutsch, P., Emtage, A., and A. Marine, "How to Use
              Anonymous FTP", FYI 24, RFC 1635, May 1994.

   [RFC1639]  Piscitello, D., "FTP Operation Over Big Address Records
              (FOOBAR)", RFC 1639, June 1994.

   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
              Resource Locators (URL)", RFC 1738, December 1994.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

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

   [RFC2428]  Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
              for IPv6 and NATs", RFC 2428, September 1998.

   [RFC2368]  Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
              URL scheme", RFC 2368, July 1998.

   [RFC2577]  Allman, M. and S. Ostermann, "FTP Security
              Considerations", RFC 2577, May 1999.

   [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS



Yevstifeyev             Expires January 8, 2012                [Page 16]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


              Names", BCP 32, RFC 2606, June 1999.

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

   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 3172, September 2001.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401, October 2002.

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3405]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Five: URI.ARPA Assignment Procedures", BCP 65,
              RFC 3405, October 2002.

   [RFC3659]  Hethmon, P., "Extensions to FTP", RFC 3659, March 2007.

   [RFC4156]  Hoffman, P., "The wais URI Scheme", RFC 4156, August 2005.

   [RFC4157]  Hoffman, P., "The prospero URI Scheme", RFC 4157, August
              2005.

   [RFC4248]  Hoffman, P., "The telnet URI Scheme", RFC 4248, October
              2005.

   [RFC4266]  Hoffman, P., "The gopher URI Scheme", RFC 4266, November
              2005.

   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
              October 2005.

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35,
              RFC 4395, February 2006.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.



Yevstifeyev             Expires January 8, 2012                [Page 17]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   [RFC5538]  Ellermann, F., "The 'news' and 'nntp' URI Schemes",
              RFC 5538, April 2010.

   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
              Reserved for Documentation", RFC 5737, January 2010.

   [RFC5797]  Klensin, J. and A. Hoenes, "FTP Command and Extension
              Registry", RFC 5797, March 2010.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, October 2010.

   [RFC3536bis]
              Hoffman, P., and J. Klensin, "Terminology Used in
              Internationalization in the IETF", Work in Progress
              (draft-ietf-appsawg-rfc3536bis), June 2011.

   [UCS]      International Organization for Standardization (ISO),
              "Information technology -- Universal Coded Character Set
              (UCS)", ISO/IEC 10646:2011, March 2011.

Appendix A.  Dynamic Delegation Discovery System (DDDS) and 'ftp' URIs

   Dynamic Delegation Discovery System (DDDS) is an abstract algorithm
   for applying dynamically retrieved string transformation rules to an
   application-unique string.  The comprehensive DDDS specification
   consists of 5 documents, which are defined in RFC 3401 [RFC3401].

   RFC 3404 [RFC3404] specified a DDDS Application for resolving URIs
   using DDDS Algorithm defined in RFC 3402 [RFC3402].  A corresponding
   second-level domain has been delegated in the "arpa" zone [RFC3172] -
   "uri.arpa" [RFC3405] - for use with this Application.  RFC 3404
   specified that First Well Known Rule for the aforementioned DDDS
   Application is to append the URI scheme name to ".uri.arpa".
   According to the provisions of RFC 3405 [RFC3405], the 'ftp' URI
   scheme was previously approved for inclusion in this zone [MSG-REG]
   in order to allow its resolving using DDDS.  Correspondingly, the
   following substitution expression was recorded in the NAPTR DNS
   resource record [RFC3403]:

     !^ftp://([^:/?#]*).*$!\1!i

   using the syntax defined in Section 3.2 of RFC 3402.  Refer to RFC
   3404 for detailed description of DDDS Application for resolving URIs
   and RFC 3402 for generic DDDS Algorithm.

   Please note that while there is a possibility to resolve 'ftp' URIs
   using DDDS, not every given 'ftp' URI may be resolved using this



Yevstifeyev             Expires January 8, 2012                [Page 18]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   technique.  A specific "hint" is required in order to denote this;
   for instance, "the URI <ftp://exmaple.org/foo/bar.txt> refers to the
   very valuable information; it is mirrored at a number of servers
   which are to be discovered using DDDS".

Appendix B.  Previous Syntax Definitions

   This appendix copies the definition of the syntax of 'ftp' URI from
   previous documents which specified it, which might be of some
   historical interest.  Within this appendix, BNF refers to the
   convention described in Section 2 of RFC 822 [RFC0822].

B.1. RFC 1630

   RFC 1630 [RFC1630] defined the syntax of 'ftp' URI with the following
   conventions:

     This is a BNF-like description of the URI syntax. at the level at
     which specific schemes are not considered.

     A vertical line "|" indicates alternatives, and [brackets] indicate
     optional parts.  Spaces are represented by the word "space", and
     the vertical line character by "vline".  Single letters stand for
     single letters.  All words of more than one letter below are
     entities described somewhere in this description.

   as follows:

     ftpaddress             f t p : / / login / path [  ftptype ]

     login                  [ user [ : password ] @ ] hostport

     user                   alphanum2 [ user ]
     password               alphanum2 [ password ]

     hostport               host [ : port ]
     host                   hostname | hostnumber
     hostname               ialpha [  .  hostname ]
     hostnumber             digits . digits . digits . digits

     path                   void |  segment  [  / path ]
     segment                xpalphas
     void

     ftptype                A formcode | E formcode | I | L digits
     formcode               N | T | C

     alphanum2              alpha | digit | - | _ | . | +



Yevstifeyev             Expires January 8, 2012                [Page 19]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


     alpha                  a | b | c | d | e | f | g | h | i | j | k |
                            l | m | n | o  | p | q | r | s | t | u | v |
                            w | x | y | z | A | B | C  | D | E | F | G |
                            H | I | J | K | L | M | N | O | P |  Q | R |
                            S | T | U | V | W | X | Y | Z
     digit                  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
     ialpha                 alpha [ xalphas ]
     xalphas                xalpha [ xalphas ]
     xalpha                 alpha | digit | safe | extra | escape
     safe                   $ | - | _ | @ | . | &  | + | -
     extra                  ! | * |  " |  ' | ( | )  | ,
     escape                 % hex hex
     hex                    digit | a | b | c | d | e | f | A | B | C |
                            D | E | F
     digits                 digit [ digits ]

B.2. RFC 1738

   RFC 1738, which was the first Standard Track specification for many
   URI schemes, defined the syntax of 'ftp' URIs with the following
   conventions:

     This is a BNF-like description of the Uniform Resource Locator
     syntax, using the conventions of RFC822, except that "|" is used to
     designate alternatives, and brackets [] are used around optional or
     repeated elements. Briefly, literals are quoted with "", optional
     elements are enclosed in [brackets], and elements may be preceded
     with <n>* to designate n or more repetitions of the following
     element; n defaults to 0.

   as follows:

     ftpurl         = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]

     login          = [ user [ ":" password ] "@" ] hostport
     hostport       = host [ ":" port ]
     host           = hostname | hostnumber
     hostname       = *[ domainlabel "." ] toplabel
     domainlabel    = alphadigit | alphadigit *[ alphadigit | "-" ]
                      alphadigit
     toplabel       = alpha | alpha *[ alphadigit | "-" ] alphadigit
     hostnumber     = digits "." digits "." digits "." digits
     port           = digits
     user           = *[ uchar | ";" | "?" | "&" | "=" ]
     password       = *[ uchar | ";" | "?" | "&" | "=" ]
     urlpath        = *xchar

     fpath          = fsegment *[ "/" fsegment ]



Yevstifeyev             Expires January 8, 2012                [Page 20]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


     fsegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]

     ftptype        = "A" | "I" | "D" | "a" | "i" | "d"

     alphadigit     = alpha | digit
     alpha          = lowalpha | hialpha
     lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                      "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                      "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                      "y" | "z"
     hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                      "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                      "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                      "Y" | "Z"
     digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                      "8" | "9"
     digits         = 1*digit
     uchar          = unreserved | escape
     unreserved     = alpha | digit | safe | extra
     safe           = "$" | "-" | "_" | "." | "+"
     extra          = "!" | "*" | "'" | "(" | ")" | ","
     escape         = "%" hex hex
     hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                      "a" | "b" | "c" | "d" | "e" | "f"
     xchar          = unreserved | reserved | escape
     reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="

Appendix C.  List of Changes since RFC 1738

   The first specification of the 'ftp' URI is RFC 1738.  This appendix
   lists main changes since that document.

     Updated syntax specification to use ABNF.
     Specification changed to suit RFC 3986.
     Changes made to accommodate HOST command [I-D ietf-ftpext2-hosts].
     Given more detailed description of <user-pass> semantics.
     Clarified the <ftp-path> syntax.
     Given detailed algorithm of handling <ftp-path>.
     Clarified client's handling null <cwd>s in <ftp-path>.
     Specified rules for handling errors.
     Clarified encoding considerations.
     Clarified security considerations.
     Added provisions regarding DDDS.
     Various editorial changes/corrections.

Appendix D.  Acknowledgments

   The authors of RFC 1630 and RFC 1738, who worked on the initial 'ftp'



Yevstifeyev             Expires January 8, 2012                [Page 21]


INTERNET DRAFT            The 'ftp' URI Scheme              July 7, 2011


   URI scheme definition, included Tim Berners-Lee, Larry Masinter and
   Mark McCahill.  Previous attempts to specify this URI scheme were
   undertaken by James Casey and Paul Hoffman.

   Considerable input to this document was provided by (in alphabetical
   order) John Klensin, Gordon Spoelhof, and Daniel Stenberg.

Author's Addresses

   Mykyta Yevstifeyev
   8 Kuzovkov St., Apt. 25
   Kotovsk
   Ukraine

   EMail: evnikita2@gmail.com




































Yevstifeyev             Expires January 8, 2012                [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/