Network Working Group P. Hoffman Internet-Draft VPN Consortium Expires: April 20, 2005 October 20, 2004 The ftp URI Scheme draft-hoffman-ftp-uri-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document specifies the ftp Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be moved to historic while keeping the information about the scheme on standards track. 1. Introduction URIs are were previously defined in RFC 2396 [RFC2396], which was Hoffman Expires April 20, 2005 [Page 1] Internet-Draft The ftp URI Scheme October 2004 updated by draft-fielding-uri-rfc2396bis [2396bis]. Those documents also specify how to define schemes for URIs. The first definition for many URI schemes appeared in RFC 1738 [RFC1738]. Because that document has been moved to Historic status, this document copies the ftp URI scheme from it to allow that material to remain on standards track. 2. Scheme Definition The FTP URL scheme is used to designate files and directories on Internet hosts accessible using the FTP protocol described in STD 9 [FTP], RFC 959. A FTP URL follows the standard syntax described in draft-fielding-uri-rfc2396bis [2396bis]. If : is omitted, the port defaults to 21. 2.1 FTP Name and Password A user name and password may be supplied; they are used in the ftp "USER" and "PASS" commands after first making the connection to the FTP server. If no user name or password is supplied and one is requested by the FTP server, the conventions for "anonymous" FTP are to be used, as follows: o The user name "anonymous" is supplied. o The password is supplied as the Internet e-mail address of the end user accessing the resource. If the URL supplies a user name but no password, and the remote server requests a password, the program interpreting the FTP URL should request one from the user. 2.2 FTP url-path The url-path of a FTP URL has the following syntax: //...//;type= through and are (possibly encoded) strings and is one of the characters "a", "i", or "d". The and parts may be empty. The part ";type=" may be omitted. In fact, the whole url-path may be omitted, including the "/" delimiting it from the prefix containing user, password, host, and port. Hoffman Expires April 20, 2005 [Page 2] Internet-Draft The ftp URI Scheme October 2004 The url-path is interpreted as a series of FTP commands as follows: o Each of the elements is to be supplied, sequentially, as the argument to a CWD (change working directory) command. o If the typecode is "d", perform a NLST (name list) command with as the argument, and interpret the results as a file directory listing. o Otherwise, perform a TYPE command with as the argument, and then access the file whose name is (for example, using the RETR command.) Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". Historical note: Most FTP client implementations precede the with a "/" before sending the CWD command. This is arguably in conflict with RFC 1738, although the practice is quite widespread. Thus, a client that is presented with the URL might send the two commands "CWD /abc" and "RETR def" or it might send the two commands "CWD abc" and "RETR def". Server implementers should be aware of these two different interpretations of the same URL. FTP URLs may also be used for other operations; for example, it is possible to update a file on a remote file server, or infer information about it from the directory listings. The mechanism for doing so is not spelled out here. 2.3 FTP Typecode is Optional The entire ;type= part of a FTP URL is optional and is rarely used. Historically, the typecode option was rarely implemented and in practice, dereferencing is done by guessing. If the typecode is omitted, the client program interpreting the URL must guess the appropriate mode to use. In general, the data content type of a file can only be guessed from the name, such as from the suffix of the name; the appropriate type code to be used for transfer of the file can then be deduced from the data content of the file. 2.4 Hierarchy For some file systems, the "/" used to denote the hierarchical Hoffman Expires April 20, 2005 [Page 3] Internet-Draft The ftp URI Scheme October 2004 structure of the URL corresponds to the delimiter used to construct a file name hierarchy, and thus, the filename will look similar to the URL path. This does NOT mean that the URL is a filename in the Unix or similar filesystems. 2.5 Optimization Clients accessing resources via FTP may employ additional heuristics to optimize the interaction. For some FTP servers, for example, it may be reasonable to keep the control connection open while accessing multiple URLs from the same server. However, there is no common hierarchical model to the FTP protocol, so if a directory change command has been given, it is impossible in general to deduce what sequence should be given to navigate to another directory for a second retrieval, if the paths are different. The only reliable algorithm is to disconnect and reestablish the control connection. 3. Security Considerations There are many security considerations for URI schemes discussed in draft-fielding-uri-rfc2396bis [2396bis]. 4 Informative References [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [2396bis] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", work in progress, draft-fielding-uri-rfc2396bis-nn.txt. [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. Author's Address Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US EMail: paul.hoffman@vpnc.org Hoffman Expires April 20, 2005 [Page 4] Internet-Draft The ftp URI Scheme October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hoffman Expires April 20, 2005 [Page 5]