INTERNET-DRAFT M. Yevstifeyev Intended Status: Standards Track June 28, 2011 Updates: 959, 1738 (if approved) Expires: December 30, 2011 The 'ftp' URI Scheme draft-yevstifeyev-ftp-uri-scheme-03 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 30, 2011 [Page 1] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology and Conventions . . . . . . . . . . . . . . . . 3 2. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 3 2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3 2.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 4 2.2.1. The Part . . . . . . . . . . . . . . . . . 5 2.2.2. The Part . . . . . . . . . . . . . . . . . 6 2.2.3. The Part . . . . . . . . . . . . . . . . . . 7 2.2.3.1. The Part . . . . . . . . . . . . . 9 2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 9 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 5.1. The 'ftp' URI Scheme . . . . . . . . . . . . . . . . . . . 12 5.2. The 'ftps' URI Scheme . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Dynamic Delegation Discovery System (DDDS) and 'ftp' URIs . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Previous Syntax Definitions . . . . . . . . . . . . . 17 B.1. RFC 1630 . . . . . . . . . . . . . . . . . . . . . . . . . 17 B.2. RFC 1738 . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix C. List of Changes since RFC 1738 . . . . . . . . . . . 19 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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, as well as many others, on IETF Standards Track. This document extracts the definition of the 'ftp' URI scheme from this document to allow to remain it to retain on Standard Track if RFC 1738 is moved Yevstifeyev Expires December 30, 2011 [Page 2] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 to Historic status 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 the examples of FTP dialogs presented in this document, lines that begin "C> " were sent over the control connection from the user-PI to 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 [ASCII, RFC0020] 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 'ftp' URI takes the form of rule below, specified using Augmented Backus-Naur Form (ABNF) [RFC5234]: Yevstifeyev Expires December 30, 2011 [Page 3] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 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 excluding semicolon (";") ; character (ASCII [ASCII, RFC0020] character 0x3B) typecode-part = ";type=" typecode typecode = "a" / "e" / "i" / "u" / "d" / typecode-ext typecode-ext = ALPHA where the , , , , and rules are defined in Appendix A of RFC 3986 [RFC3986] and rule specified in Appendix B.1 of RFC 5234 [RFC5234]. RFC 3986 deprecated the use of "user:pass" format of the 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. Please note that while processing the 'ftp' URI those character which appear percent-encoded, MUST be unescaped 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 either a server for establishing a connection (when is omitted) or a resource (a file a directory listing) on such FTP server (when is present). Yevstifeyev Expires December 30, 2011 [Page 4] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 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 on the port identified by the (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; and (4) perform a series of commands according to 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 error replies received during processing the URI, unless clearly stated in this document, is 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 Part The part, which is REQUIRED, consists of the and the parts. The part, which is REQUIRED within , specifies the server which a connection is to be established to. The part, which is OPTIONAL within , denotes the TCP port for establishing such connection. If the part with the preceding colon (":") character (ASCII Yevstifeyev Expires December 30, 2011 [Page 5] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 [ASCII, RFC0020] 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 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. 2.2.2. The Part The part, which is OPTIONAL, consists of the and the parts. The part, which is REQUIRED within , denotes the user name; the part, which is OPTIONAL within , - 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 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 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: Yevstifeyev Expires December 30, 2011 [Page 6] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 (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 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 decides to terminate connection. The 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 Part The part, which is OPTIONAL, denotes the resource (a file or a directory) on the server specified by . For better understanding the algorithm below, the ABNF definition of is copied here: ftp-path = [ cwd-part ] ( "/" last-segment [ typecode-part ] ) cwd-part = *( "/" cwd ) cwd = segment-nsc last-segment = segment-nsc segment-nsc = typecode-part = ";type=" typecode typecode = "a" / "e" / "i" / "u" / "d" / typecode-ext typecode-ext = ALPHA where the rule is specified in Appendix B.1 of RFC 5234 [RFC5234]. Yevstifeyev Expires December 30, 2011 [Page 7] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 The part SHALL be processed upon successful authentication per Section 2.2.2, using the following algorithm: (1a) if the is present, each of parts are consistently supplied as arguments to the CWD (change working directory) FTP command, or (1b) the whole is submitted as an argument to the aforementioned command; Note: Any null 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) if the is present and is either "a", "e", "i" or "u", perform the TYPE command with the as an argument; (3) whatever the path is, arrange the data connection to the server using either PORT or PASV command; (4a) if the is present and the is equal to "d", specifies the directory; in this case the NLST command with as an argument SHALL be issued; (4b) if is null (whatever is), perform NLST command with no arguments; (4c) otherwise, in the case described in (2) or when is omitted and is non-null, it refers to a file which is to be retrieved; using RETR command is strongly RECOMMENDED. If the reply which identifies the absence of the resource (a directory or a file) identified by one of the parts or a 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 is implementation-specific. Yevstifeyev Expires December 30, 2011 [Page 8] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 2.2.3.1. The Part The part specifies the data type of . Currently, there are five options of : "a", "e", "i", which are specified in RFC 959 [RFC0959] and stand for ASCII [ASCII, RFC0020], 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 is a directory. The 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 unescaped 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 [ASCII, RFC0020] equivalents. For instance, "%2F", if occurs in the , 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 may result in the following data exchange: S> 220 ExampleFTP Server ready Yevstifeyev Expires December 30, 2011 [Page 9] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 C> HOST example.com S> 220 Host accepted C> USER anonymous S> 331 Anonymous permitted; supply email as password 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 S> 226 Directory listing sent The URI may result in the following data exchange: 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) C> RETR file.txt S> 150 Transfer starts... S> 226 File is sent The following example illustrates the situation when supplied credentials are invalid. Thus, the URI may result in the following: S> 220 GigaSoft FTP - welcome C> HOST example.net S> 220 Why not :-) Yevstifeyev Expires December 30, 2011 [Page 10] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 C> USER user1 S> 331 Mention password C> PASS invalid-pass S> 530 Invalid credentials 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> NLST S> 150 Here comes the directory listing 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: may result in the following data interchange: S> 220 Yevstifeyev FTP ready C> HOST exmaple.org S> 504 Unknown host C> USER oh-no S> 331 Supply password C> PASS some-pass S> 530 Invalid credentials C> USER cool-man S> 331 Supply password C> PASS cool-pass S> 230 Authenticated C> CWD foo Yevstifeyev Expires December 30, 2011 [Page 11] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 S> 250 foo is an active directory C> CWD bar S> 250 foo/bar is an active directory 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 :-( 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] Yevstifeyev Expires December 30, 2011 [Page 12] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 Security considerations: see Section 4 of RFC xxxx Contact: IESG Author/Change controller: IETF 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 ; contact party is IESG . 6. References 6.1. Normative References [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. [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. Yevstifeyev Expires December 30, 2011 [Page 13] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 6.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", . [IANA-URIREG] Internet Assigned Numbers Authority (IANA), "Uniform Resource Identifier (URI) Schemes", . [I-D ietf-ftpext2-typeu] Klensin, J., "FTP Extension for Internationalized Text", Work in Progress (draft-ietf-ftpext2-typeu), June 2011. [MSG-REG] Mealling, M., "Registration of the 'ftp' URI scheme in uri.arpa under the key ftp.uri.arpa.", Mailing List Posting, January 2003, [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 Yevstifeyev Expires December 30, 2011 [Page 14] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 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. [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 Names", BCP 32, RFC 2606, June 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. [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. Yevstifeyev Expires December 30, 2011 [Page 15] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 [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. [RFC5538] Ellermann, F., "The 'news' and 'nntp' URI Schemes", RFC 5538, April 2010. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 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 Yevstifeyev Expires December 30, 2011 [Page 16] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 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 technique. A specific "hint" is required in order to denote this; for instance, "the URI 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 ] Yevstifeyev Expires December 30, 2011 [Page 17] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 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 | - | _ | . | + 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 * 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 Yevstifeyev Expires December 30, 2011 [Page 18] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 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 ] 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]. Yevstifeyev Expires December 30, 2011 [Page 19] INTERNET DRAFT The 'ftp' URI Scheme June 28, 2011 Given more detailed description of semantics. Clarified the syntax. Given detailed algorithm of handling . Clarified client's handling null s in . 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' 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., Apt. 25 Kotovsk Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires December 30, 2011 [Page 20]