Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Expires: March 20, 2005 September 19, 2004
The ftp URI Scheme
draft-hoffman-ftp-uri-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 March 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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
updated by draft-fielding-uri-rfc2396bis [2396bis]. Those documents
also specify how to define schemes for URIs.
Hoffman Expires March 20, 2005 [Page 1]
Internet-Draft The ftp URI Scheme September 2004
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 :<port> 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:
<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
and <typecode> is one of the characters "a", "i", or "d". The part
";type=<typecode>" may be omitted. The <cwdx> and <name> parts may
be empty. The whole url-path may be omitted, including the "/"
delimiting it from the prefix containing user, password, host, and
port.
Historical note: The typecode option was not widely implemented. In
practice, dereferencing is done by guessing.
Hoffman Expires March 20, 2005 [Page 2]
Internet-Draft The ftp URI Scheme September 2004
The url-path is interpreted as a series of FTP commands as follows:
o Each of the <cwd> 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
<name> as the argument, and interpret the results as a file
directory listing.
o Otherwise, perform a TYPE command with <typecode> as the argument,
and then access the file whose name is <name> (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 "/".
For example, the URL <URL:ftp://myname@example.com/%2Fetc/motd> is
interpreted by FTP-ing to "example.com", logging in as "myname"
(prompting for a password if it is asked for), and then executing
"CWD /etc" and then "RETR motd". This has a different meaning from
<URL:ftp://myname@example.com/etc/motd> which would "CWD etc" and
then "RETR motd"; the initial "CWD" might be executed relative to the
default directory for "myname". On the other hand,
<URL:ftp://myname@example.com//etc/motd>, would "CWD " with a null
argument, then "CWD etc", and then "RETR motd".
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=<typecode> part of a FTP URL is optional. If it 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, e.g., 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
structure of the URL corresponds to the delimiter used to construct a
Hoffman Expires March 20, 2005 [Page 3]
Internet-Draft The ftp URI Scheme September 2004
file name hierarchy, and thus, the filename will look similar to the
URL path. This does NOT mean that the URL is a Unix filename.
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 March 20, 2005 [Page 4]
Internet-Draft The ftp URI Scheme September 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 March 20, 2005 [Page 5]