[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                           June 19, 2011
Updates: 959, 1738 (if approved)
Expires: December 21, 2011

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

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 December 21, 2011                [Page 1]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. URI Scheme Specification  . . . . . . . . . . . . . . . . . . .  3
     2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . .  3
     2.2. URI Scheme Semantics  . . . . . . . . . . . . . . . . . . .  4
       2.2.1. The <host-port> Part  . . . . . . . . . . . . . . . . .  4
       2.2.2. The <user-pass> Part  . . . . . . . . . . . . . . . . .  5
       2.2.3. The <ftp-path> Part . . . . . . . . . . . . . . . . . .  6
     2.3. Encoding Considerations . . . . . . . . . . . . . . . . . .  7
   3. Security Considerations . . . . . . . . . . . . . . . . . . . .  7
   4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   5. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1. Normative References  . . . . . . . . . . . . . . . . . . .  8
     5.2. Informative References  . . . . . . . . . . . . . . . . . .  9
   Appendix A.  List of Changes since RFC 1738  . . . . . . . . . . . 10
   Appendix B.  Known Issues  . . . . . . . . . . . . . . . . . . . . 11
   Appendix C.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

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].  (Also visit Section 4 of RFC 1123 [RFC1123] for
   "narrative" description of FTP.)

   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
   on IETF Standards Track.

   Subsequently, RFC 1738 was formally obsoleted by RFC 4248 [RFC4248]
   and RFC 4266 [RFC4266]; in fact RFC 2396 [RFC2396] and its successor
   - RFC 3986 [RFC3986] - replaced and deprecated it (formally they both
   updated RFC 1738).  Currently, almost all of URI schemes specified in
   RFC 1738 have been given a separate specification; one of the rare
   exceptions is the 'ftp' URI scheme.  This document removes this
   uncertainty; it gives the 'ftp' URI scheme an official, Standard
   Track documentation.  It updates RFC 959 and RFC 1738.




Yevstifeyev            Expires December 21, 2011                [Page 2]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   Please note that this document does not attempt to make radical
   changes to the existing 'ftp' URI scheme definition (even though they
   are considered necessary; see Appendix B), but rather describes is as
   currently used as well as copies its definition from obsoleted RFC
   1738 to allow it to remain on Standard Track (with this respect it
   belongs to a series of similar documents like RFC 4248 [RFC4248], RFC
   4266 [RFC4266] and RFC 5538 [RFC5538]).

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

1.1  Terminology

   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", "reply" and "user" are used with the meaning defined
   ibidem.

2. URI Scheme Specification

2.1. URI Scheme Syntax

   The 'ftp' URI takes the form of <ftp-uri> rule below, specified using
   Augmented Backus-Naur Form (ABNF) [RFC5234]:

     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       = path-abempty

   where the <host>, <port>, <unreserved>, <pct-encoded>, <sub-delims>,
   and <path-abempty> rules are defined in RFC 3986 [RFC3986], Appendix
   A.  Section 2.2.2 contains another definition of <ftp-path>, which
   is, though, compatible with the aforementioned.




Yevstifeyev            Expires December 21, 2011                [Page 3]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   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.

   The semantics of each part are defined in Section 2.2.

2.2. URI Scheme Semantics

   The 'ftp' URI specifies either a server for establishing a connection
   (when <ftp-path> is omitted) or a resource (a directory or a file) on
   such FTP server (when <ftp-path> is present).

   The application resolving the 'ftp' URI SHALL follow 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) Upon establishing a successful TCP connection authenticate itself
       to the server;

   (3) Perform a series of commands according to <ftp-path> part, if it
       is present.

   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 eror replies received
   during processing the URI, unless clearly stated in this document, is
   implementation-specific.

   '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




Yevstifeyev            Expires December 21, 2011                [Page 4]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   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
   [ASCII, RFC0020] character 0x3A) is omitted, the port SHALL default
   to 21, as registered in [IANA-PORTREG].

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 [ASCII, RFC0020]
   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 [RFC5598]
       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



Yevstifeyev            Expires December 21, 2011                [Page 5]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   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.

   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) on the server specified by <host>.  For better
   understanding the algorithm below, the ABNF definition of <ftp-path>
   which is different from (but, though, compatible with) that in
   Section 2.1 is provided:

     ftp-path       =/ cwd-part [ "/" name ]
     cwd-part       =  *( "/" cwd )
     cwd            =  segment
     name           =  segment

   where the <segment> rule is defined in RFC 3986 [RFC3986], Appendix
   A.

     Historical note:  RFC 1738 specified an additional part in the
     <ftp-path> which was used to denote the typecode used with TYPE
     command.  In practice, this option has rarely been implemented; the
     data type has usually been determined by guessing.  This
     specification deprecates the use of this part; however those
     applications which continue to support it MUST NOT be considered to
     be incompatible with this specification.

   The <ftp-path> part SHALL be processed upon successful authentication
   per Section 2.2.2, using the following algorithm:

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

   (1b) the whole <cwd-part> is submitted as an argument to the
        aforementioned command;



Yevstifeyev            Expires December 21, 2011                [Page 6]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


     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.

     Note:  The step (1b) below is NOT RECOMMENDED for action by this
     specification; it is only included for compatibility with some FTP
     clients.  FTP servers SHOULD support both variants and MUST support
     the (1a) behavior.

   (2)  access the file identified by the <name>, if it is present, in
        an appropriate way; using the RETR command is strongly
        RECOMMENDED.

     Note:  If the <cwd-part> is null (as allowed by the aforementioned
     syntax), but the <name> is present, the file identified by it is
     located in the default directory of the <host>.

   If the reply which identifies the absence of the resource (a
   directory or a file) identified by one of the <cwd> parts or a <name>
   part of the URI (explicitly, 550 reply) is received 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.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 in the unreserved set of RFC 3986 SHALL be percent-
   encoded.  In fact, there are no other encoding considerations for
   'ftp' URIs not addressed in Section 2 of RFC 3986.

   Please visit RFC 3536 [RFC3536] for definitions of the terms related
   to encoding.

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



Yevstifeyev            Expires December 21, 2011                [Page 7]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   RFC 4217, is known to be deployed; specifying it is out of the scope
   of this document.

4. IANA Considerations

   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 3 of RFC xxxx

     Contact: IESG <iesg@ietf.org>

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

     References: see Section 5 of RFC xxxx

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

5. References

5.1. Normative References

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

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




Yevstifeyev            Expires December 21, 2011                [Page 8]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


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

5.2. Informative References

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

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

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

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

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

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

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

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



Yevstifeyev            Expires December 21, 2011                [Page 9]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

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

   [RFC3536]  Hoffman, P., "Terminology Used in Internationalization in
              the IETF", RFC 3536, May 2003.

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

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

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

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

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

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
              2009.

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

Appendix A.  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.
     Given more detailed description of <user-pass> semantics.
     Clarified the <ftp-path> syntax.
     Deprecated the use of typecode part.
     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.
     Various editorial changes/corrections.



Yevstifeyev            Expires December 21, 2011               [Page 10]


INTERNET DRAFT            The 'ftp' URI Scheme             June 19, 2011


Appendix B.  Known Issues

   There are some issues known to exist with the current definition of
   the 'ftp' URI scheme, given in this document.  As identified above,
   it provides a very limited set of operations; see Section 2.2.  It is
   impossible to use it to, for instance, delete a file or create a
   directory at server.  Moreover, a number of other important features
   are not provided by the 'ftp' URI.  Among other, the 'ftp' URIs do
   not denote the account information used with the ACCT command,
   transmission mode, etc.  Finally, no extension mechanism, which might
   be used to accommodate new features in the URI scheme, is provided.

   This document does not try to address all the aforementioned
   problems, but rather describes the scheme as it is currently used and
   copies its definition from obsoleted RFC 1738 to allow it to remain
   on Standard Track (see Section 1).  Yet, the effort to produce the
   completely new definition of the 'ftp' URI scheme to replace this one
   is anticipated at the IETF soon.

Appendix C.  Acknowledgments

   The authors of RFC 1630 and RFC 1738, who worked on the initial 'ftp'
   URI scheme definition, included Tim Berners-Lee, Larry Masinter and
   Mark McCahill.  Previous attempt to specify this URI scheme was
   undertaken by 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., flat 25
   Kotovsk
   Ukraine

   EMail: evnikita2@gmail.com














Yevstifeyev            Expires December 21, 2011               [Page 11]


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