Network Working Group                                       M. Peterson
                                                          D. Papenthien
Internet Draft                                     Rhino Software, Inc.
Intended status: Streamlined FTP Command Extensions       April 8, 2008
Expires: October 2008


                    Streamlined FTP Command Extensions
         draft-peterson-streamlined-ftp-command-extensions-02.txt


Status of this Memo

   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
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   This document may only be posted in an Internet-Draft.

   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 October 8, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract





Peterson & Papenthien  Expires October 8, 2008                 [Page 1]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   This document specifies FTP commands to download thumbnails of remote
   images, remove entire directory trees, request the amount of storage
   space available to the user, request the size of a remote directory
   and its contents, and to specify an FTP host.  The commands are
   designed to reduce the number of server / client exchanges, provide
   information that was not previously available, and to reduce
   bandwidth requirements for some higher level operations.

Conventions used in this document

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

   This document uses previously established definitions for FTP related
   terms as defined in [RFC959].  In particular, the terms "data
   connection", "FTP command", "file", "pathname", "reply", "server-FTP
   process", "user", and "user-FTP process" are used as defined.  The
   terms "server" and "client" are also used in place of "server-FTP
   process" and "user-FTP process", respectively, for the sake of
   brevity.

   The syntax for responses to FTP commands used in this document is
   explained using Augmented BNF as defined in [RFC5234].  Additional
   tokens defined in [RFC3659] that extend ABNF are also used,
   specifically the TCHAR token.

   In command examples, "C>" and "S>" indicate lines sent by the client
   and server, respectively.

Table of Contents


   1. Introduction...................................................3
   2. Remove Directory All (RMDA)....................................3
      2.1. RMDA Syntax...............................................4
      2.2. RMDA Error Responses......................................4
      2.3. RMDA FEAT Response........................................4
      2.4. RMDA Examples.............................................5
   3. Directory Size (DSIZ)..........................................5
      3.1. DSIZ Syntax...............................................6
      3.2. DSIZ Error Responses......................................7
      3.3. DSIZ FEAT Response........................................7
      3.4. DSIZ Examples.............................................7
   4. Available Octets (AVBL)........................................8
      4.1. AVBL Syntax...............................................8
      4.2. AVBL Error Responses......................................9


Peterson & Papenthien  Expires October 8, 2008                 [Page 2]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


      4.3. AVBL FEAT Response........................................9
      4.4. AVBL Examples.............................................9
   5. Change Host (HOST)............................................10
      5.1. HOST Syntax..............................................10
      5.2. HOST Error Responses.....................................11
      5.3. HOST FEAT Response.......................................11
      5.4. HOST Examples............................................11
   6. Retrieve Thumbnail of Remote Image File (THMB)................12
      6.1. THMB Syntax..............................................12
      6.2. THMB Error Responses.....................................14
      6.3. THMB FEAT Response.......................................14
      6.4. THMB Examples............................................14
   7. Security Considerations.......................................15
   8. IANA Considerations...........................................15
   9. Conclusions...................................................15
   10. Acknowledgments..............................................16
   Authors' Addresses...............................................18
   Intellectual Property Statement..................................18
   Disclaimer of Validity...........................................19

1. Introduction

   This document updates the File Transfer Protocol [RFC959].  It adds
   five new commands: "RMDA", "DSIZ", "AVBL", "HOST", and "THMB".  The
   "HOST" command has been used in various forms for several years while
   the other four commands are new.  These commands have been designed
   to streamline certain client and server communications, reduce the
   amount of bandwidth required to perform various operations, and allow
   a server-FTP process to operate multiple hosts on the same IP address
   and port combination.

2. Remove Directory All (RMDA)

   The FTP command REMOVE DIRECTORY ALL (RMDA) removes a directory from
   the server and all of its contents including all files and
   subdirectories.  The RMDA command is considered analogous to
   recursively deleting all files and directories contained in a given
   remote directory (including the directory itself) one at a time.

   The primary advantage to using this command is the elimination of the
   additional commands usually required to perform the equivalent
   action.  For directories containing a large number of files and
   subdirectories, using RMDA eliminates the overhead of querying for
   subdirectory listings.  The end result is a more responsive operation
   for both the client and server.




Peterson & Papenthien  Expires October 8, 2008                 [Page 3]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   Depending on the content being deleted (files and subdirectories)
   this can be a very lengthy operation for the server.  Servers that
   implement this command are encouraged to do so in a way that does not
   block operations for other client connections.

2.1. RMDA Syntax

   The syntax of the RMDA command is:

      rmda           = "RMDA" SP pathname CRLF

   All FTP commands, including RMDA, are case insensitive.  However, the
   "pathname" variable provided with the command may be case sensitive
   as dictated by the server's operating system.

   The "pathname" specifies a remote directory that should be deleted
   along with all of its contents.

      rmda-response  = "250" SP *TCHAR CRLF /
                        error-response

   Responses should be the same as those for the RMD command.  If
   processing fails at any point during the operation, the specified
   pathname is not to be removed.  Any cached information about the
   pathname is considered invalid when RMDA returns an error.

2.2. RMDA Error Responses

   The RMDA command can return any error response listed for the RMD
   command in [RFC959].  The most common of these responses occurs in
   the event of an error while deleting a file or subdirectory, in which
   case the server should return a 550 reply.  A 550 reply should also
   be sent if the provided path is a file instead of a directory.

   In the event that a nested file or subdirectory cannot be deleted for
   any reason, the parent directories of that file or subdirectory
   should not be deleted.  When the server encounters this situation, it
   should attempt to delete all other files and subdirectories before
   stopping or responding to the client.  Once the server has attempted
   to delete all files and subdirectories, the server MUST report
   failure to the client if even a single file or subdirectory could not
   be deleted.

2.3. RMDA FEAT Response

   When replying to the FEAT command, a server-FTP process that supports
   the RMDA command MUST include a line starting with the word "RMDA".


Peterson & Papenthien  Expires October 8, 2008                 [Page 4]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   If descriptive text is optionally desired, a space MUST immediately
   follow the "RMDA" word.

      C> FEAT
      S> 211- <any descriptive text>
      S>  ...
      S>  RMDA <any descriptive text>
      S>  ...
      S> 211 End

   The ellipses indicate placeholders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory per [RFC2389].

2.4. RMDA Examples

   This example assumes that the server contains a directory named "A"
   and that the client has the necessary access to delete "A" and its
   contents.  The client-server exchange for using RMDA to accomplish
   this would be:

      C> RMDA A
      S> 250 RMDA command successful.

   If deletion of the directory, any contained file, or subdirectory
   fails the client-server exchange would be:

      C> RMDA A
      S> 550 A: Cannot delete directory.

   If deletion fails due to inadequate permissions for the directory,
   any contained file, or subdirectory for the connected client, the
   client-server exchange would be:

      C> RMDA A
      S> 550 A: Permission denied.

3. Directory Size (DSIZ)

   The FTP command DIRECTORY SIZE (DSIZ) returns the number of octets
   (8-bit bytes) on the remote file system occupied by a given directory
   and its contents.  The parameter to this command MUST represent a
   directory path, not a file path.

   While a method already exists to retrieve similar information by
   recursively issuing the SIZE command as defined in [RFC3659] and
   tallying the results, the SIZE command returns the number of transfer


Peterson & Papenthien  Expires October 8, 2008                 [Page 5]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   octets for a specified file, which means that it considers the
   current data representation type in its calculated response.  The
   DSIZ command should not consider this in its response, instead
   leaving it up to the underlying file system to determine the number
   of octets occupied by the files.

   In addition, issuing a single DSIZ command saves on the number of
   required commands and the overhead associated with recursively
   querying for the SIZE of each individual file.  This results in a
   more responsive and conservative communication exchange between the
   client and server.

   Depending on the size of the path being queried and its location
   relative to the server, this can be a very lengthy operation.
   Servers that implement this command are encouraged to do so in a way
   that does not block operations for other client connections.

3.1. DSIZ Syntax

   The syntax of the DSIZ command is:

      dsiz           = "DSIZ" [SP pathname] CRLF

   All FTP commands, including DSIZ, are case insensitive.  However, the
   "pathname" variable provided with the command may be case sensitive
   as dictated by the server's operating system.  If the "pathname"
   variable is not present in the received DSIZ command, its value is
   assumed to be the current directory (i.e., the path that would be
   returned in response to a Print Working Directory (PWD) command).

   The "pathname" specifies a remote directory that should be queried to
   retrieve the total storage space occupied by its contents on the
   server's file system.  The "pathname" MUST be a valid directory path;
   it cannot be a path to a file or a system device.

      dsiz-response  = "213" SP 1*DIGIT CRLF /
                        error-response

   The 213 reply is formatted in such a way that the returned size value
   can be machine parsed.

   A successful response includes a numeric value indicating the number
   of octets on the server's file system occupied by the provided
   pathname and its contents.





Peterson & Papenthien  Expires October 8, 2008                 [Page 6]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


3.2. DSIZ Error Responses

   In the event that the pathname is not a directory, the server MUST
   return a permanent 550 error reply.  Where the command cannot be
   parsed, a 500 or 501 reply SHOULD be sent.  The client MUST NOT
   assume that the presence of a 550 reply indicates that it cannot
   access the directory or its contents.  The server may generate this
   error for other reasons, for example the overhead required for the
   operation is too great.

3.3. DSIZ FEAT Response

   When replying to the FEAT command, a server-FTP process that supports
   the DSIZ command MUST include a line starting with the word "DSIZ".
   If descriptive text is optionally desired, a space MUST immediately
   follow the "DSIZ" word.

      C> FEAT
      S> 211- <any descriptive text>
      S>  ...
      S>  DSIZ <any descriptive text>
      S>  ...
      S> 211 End

   The ellipses indicate placeholders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory per [RFC2389].

3.4. DSIZ Examples

   Assuming the presence of directory "A" on the server and that the
   client has the necessary permissions to access and list it, a typical
   DSIZ client-server exchange would be:

      C> DSIZ A
      S> 213 123456

   Where 123456 is the number of octets on the server's file system
   occupied by the directory "A" and its contents.

   Assuming directory "A" cannot be listed due to client permissions,
   the client-server exchange would be:

      C> DSIZ A
      S> 550 A: Permission denied.




Peterson & Papenthien  Expires October 8, 2008                 [Page 7]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   Assuming the client provides the parameter "file.fid" where
   "file.fid" is an existing file, the client-server exchange would be:

      C> DSIZ file.fid
      S> 550 A: Is a file.

4. Available Octets (AVBL)

   The FTP command AVAILABLE OCTETS (AVBL) can be used to retrieve the
   number of octets available to receive uploads in a specified remote
   directory.  Many server-FTP processes have implemented proprietary
   methods for restricting the amount of space available, either to the
   user as a whole or within a specified remote location.  The AVBL
   command offers an interface for retrieving this value in a way that
   can be machine parsed.

4.1. AVBL Syntax

   The syntax of the AVBL command is:

      avbl           = "AVBL" [SP pathname] CRLF

   All FTP commands, including AVBL, are case insensitive.  However, the
   optional "pathname" variable provided with the command may be case
   sensitive as dictated by the server's operating system.  If the
   "pathname" variable is not present in the received AVBL command, its
   value is assumed to be the current directory (i.e., the path that
   would be returned in response to a Print Working Directory (PWD)
   command).

   The "pathname" variable specifies the remote directory that the
   client wants to know how many octets are available to the user for
   uploads.  The "pathname" MUST be a valid directory path; it cannot be
   a path to a file or a system device.

      avbl-response  = "213" SP 1*DIGIT CRLF /
                        error-response

   The 213 reply is formatted in such a way that the returned size can
   be machine parsed.

   A successful response includes a numeric value that may be the number
   of octets available as dictated by the physical limitations of the
   underlying storage mechanism.  It may also be a limit imposed upon
   "pathname" or even the user that issued the command.  The exact
   method for calculating this numeric value is up to the specific
   server-FTP process implementation.


Peterson & Papenthien  Expires October 8, 2008                 [Page 8]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


4.2. AVBL Error Responses

   In the event that the pathname is not a directory, the server MUST
   return a permanent 550 error reply.  Where the command cannot be
   parsed, a 500 or 501 reply should be sent.  The client MUST NOT
   assume that the presence of a 550 reply indicates that it cannot
   access the directory or its contents.  The server may generate this
   error for other reasons, for example the overhead required for the
   operation is too great.

4.3. AVBL FEAT Response

   When replying to the FEAT command, a server-FTP process that supports
   the AVBL command MUST include a line starting with the word "AVBL".
   If descriptive text is optionally desired, a space MUST immediately
   follow the "AVBL" word.

      C> FEAT
      S> 211- <any descriptive text>
      S>  ...
      S>  AVBL <any descriptive text>
      S>  ...
      S> 211 End

   The ellipses indicate placeholders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory per [RFC2389].

4.4. AVBL Examples

   A typical client-server exchange using the AVBL command may look like
   this:

      C> AVBL
      S> 213 123456

   Where 123456 is the number of octets the user has available for file
   uploads.  In this example, no pathname is provided with the AVBL
   command.  Therefore, the server has used the current working
   directory when processing its response.

   Assuming the presence of directory "A" on the server and that the
   client has the necessary permissions to access and list it:

      C> AVBL A
      S> 213 123456



Peterson & Papenthien  Expires October 8, 2008                 [Page 9]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   Assuming directory "A" cannot be listed due to client permissions,
   the client-server exchange would be:

      C> AVBL A
      S> 550 A: Permission denied.

   Assuming the client provides the parameter "file.fid" where
   "file.fid" is an existing file, the client-server exchange would be:

      C> AVBL file.fid
      S> 550 A: Is a file.


5. Change Host (HOST)

   The FTP command CHANGE HOST (HOST) allows the client to identify the
   name used to connect to the server.  This command allows the server
   to host many unique domains within the server-FTP process that make
   use of the same IP address and port number combination, much like the
   "Host" header field of the HTTP protocol as defined in [RFC2616]
   allows a web server to do the same.

5.1. HOST Syntax

   The syntax of the HOST command is:

      host           = "HOST" SP host_name CRLF

   All FTP commands, including HOST, are case insensitive.  The
   specified "host_name" is also case insensitive to provide
   compatibility with domain names, which are case insensitive as well
   [RFC1035].

   The "host_name" parameter can be any arbitrary text that uniquely
   identifies the client's desired domain to the server-FTP process.
   The most common and appropriate application of a "host_name" would be
   to specify a Fully Qualified Domain Name (FQDN) as this meets the
   criteria of being unique.  However, by not restricting this parameter
   to a FQDN, other usages become available such as one not defined at
   the time of this document's writing or a proprietary naming
   convention employed within a large internal network.

      host-response  = "220" SP *TCHAR CRLF /
                        error-response

   The HOST command MUST be sent prior to issuing the USER command or
   logging into the server.  If the specified host is valid, the server


Peterson & Papenthien  Expires October 8, 2008                [Page 10]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   responds with the usual 220 welcome response, returning the connect
   message specified for the host.

5.2. HOST Error Responses

   If the parameter is invalid, the server MUST use the 504 reply code.
   If the client session is already logged in (successfully issued USER
   and PASS commands), the server MUST use the 530 reply code.  If the
   host_name is unrecognized by the server, the server MUST use the 530
   reply code.

   If the server does not accept a host_name parameter, the server MUST
   continue with login to the default host on the IP address and port.

5.3. HOST FEAT Response

   When replying to the FEAT command, a server-FTP process that supports
   the HOST command SHOULD include a line starting with the word "HOST".
   If descriptive text is optionally desired, a space MUST immediately
   follow the "HOST" word.

      C> FEAT
      S> 211- <any descriptive text>
      S>  ...
      S>  HOST <any descriptive text>
      S>  ...
      S> 211 End

   The ellipses indicate placeholders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory per [RFC2389].

   NOTE: Some servers do not allow the FEAT command to be issued prior
   to the occurrence of a successful login.  Because the HOST command is
   required prior to login, a FEAT response code for HOST is optional
   depending on the server's implementation of FEAT.

5.4. HOST Examples

   Assuming host "ftp.domain.com" is defined for the server-FTP process,
   the client-server exchange would be:

      C> HOST ftp.domain.com
      S> 220 Welcome to ftp.domain.com, proceed...

   When the domain name (host) does not exist, the client-server
   exchange would be:


Peterson & Papenthien  Expires October 8, 2008                [Page 11]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


      C> HOST ftp.domain-x.com
      S> 550 Host not found.

   When invalid syntax is specified, the client-server exchange would
   be:

      C> HOST ftp domain com
      S> 504 Invalid parameter.

6. Retrieve Thumbnail of Remote Image File (THMB)

   Many user-FTP processes have implemented a view of the remote
   directory contents that allows for a size-reduced representation of
   remote files recognized as image types to be displayed.  This size-
   reduced representation of the image is commonly referred to as a
   thumbnail.  This view of the remote file system usually requires a
   large amount of resources, in the form of time and bandwidth, in
   order to be properly represented.

   The THMB FTP command allows the server-FTP process to locally
   generate a thumbnail of a requested image type and transfer the
   resulting image instead of the entire contents of the original image
   file.  This facilitates a faster and more efficient method of
   fulfilling a user-FTP process's implementation of a "thumbnail view".

   Depending on the size of the image file being processed and the CPU
   resources available to the server-FTP process, this can be a lengthy
   operation.  Servers that implement this command are encouraged to do
   so in a way that does not block operations for other client
   connections.

6.1. THMB Syntax

   The THMB FTP command initiates a file transfer of the generated
   thumbnail image in much the same way that the Retrieve (RETR) FTP
   command initiates a download of a remote file.  As such, thumbnail
   transfer occurs over a previously established data connection as
   indicated in [RFC959].  When the THMB command is received, an initial
   response is sent over the command connection, the thumbnail is
   transferred over the data connection, the data connection is closed,
   and the final response is sent over the command connection.

   The syntax of the THMB command is:

      thmb           = "THMB" SP fmt SP 1*DIGIT SP 1*DIGIT SP pathname
                       CRLF



Peterson & Papenthien  Expires October 8, 2008                [Page 12]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   All FTP commands, including THMB, are case insensitive.  However, the
   "pathname" variable provided with the command may be case sensitive
   as dictated by the server's operating system.

   The "fmt" parameter indicates an image format recognized by the
   server-FTP process that should be used to generate the thumbnail
   image.  Its value corresponds to the commonly accepted file extension
   used for the requested image format.  Image formats supported by the
   server are listed in the THMB FEAT Response [6.3].  The requested
   thumbnail format does not necessarily conform to the existing format
   of the image.  For example, a client-FTP process may request a PNG
   thumbnail of a JPEG image.

   The two numbers following "fmt" are the requested maximum width and
   maximum height in pixels, respectively, that the client is willing to
   accept for the generated thumbnail image.  The server SHOULD preserve
   the original aspect ratio of the image to avoid distortion while
   ensuring these maximum values are not exceeded by the generated
   thumbnail image.

   The "pathname" specifies a remote file, of a supported image type,
   that should be sent to the client in thumbnail form according to the
   other parameters.

   The syntax of a positive response is:

      Host-response  = "150" SP *TCHAR (1*DIGIT 1*TCHAR) CRLF /
                        error-response

   (1*DIGIT) represents the size in octets of the forthcoming file
   transfer.  The value within the parentheses MAY include descriptive
   text, for example (123456 Bytes).  By providing this information to
   the client, the client can determine the required file size and
   transfer status information.

   The potential responses to the THMB command that should be expected
   over the command channel correspond to the list of acceptable
   responses to the RETR command as defined in [RFC959].

   As the THMB command initiates a data transfer over a previously
   negotiated data connection, the binary image data for the server
   generated thumbnail image is transferred over this data connection.
   Because image data is always binary in nature, the server-FTP process
   will always send this data as if the current data representation type
   is BINARY, regardless of the setting that was established through the
   last received TYPE command.  After the THMB command is fully



Peterson & Papenthien  Expires October 8, 2008                [Page 13]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   processed, the server-FTP process reverts back to using the
   previously established data representation type.

6.2. THMB Error Responses

   If an error is encountered while attempting to process or generate
   the thumbnail image, the server MUST use the 550 reply code.  If an
   error is encountered while allocating resources for temporary storage
   of the generated thumbnail, the server MUST use the 550 reply code.

6.3. THMB FEAT Response

   When replying to the FEAT command, a server-FTP process that supports
   the THMB command MUST include a line starting with the word "THMB".
   If descriptive text is optionally desired, a space MUST immediately
   follow the required "fmt" parameter.

      C> FEAT
      S> 211- <any descriptive text>
      S>  ...
      S>  THMB <fmt> <any descriptive text>
      S>  ...
      S> 211 End

   The "fmt" variable represents the supported image format(s); multiple
   format abbreviations can be given separated by the "|" character.
   Each format abbreviation must be the media subtype name of an 'image'
   media type that is IANA-registered under the provisions established
   in [RFC4288] describing a unique file storage format and giving a
   specific file name extension. Supporting servers must support at
   least JPEG or PNG formats.  An example THMB response to the FEAT
   command might be:

   THMB JPEG|GIF|TIFF|PNG

   This response identifies JPEG, GIF, TIFF, and PNG formats as image
   types supported by the server for thumbnail generation.

   The ellipses indicate placeholders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory per [RFC2389].

6.4. THMB Examples

   Assuming the existence of image file "widget.png" on the server and
   that the client has all necessary permissions to access and transfer



Peterson & Papenthien  Expires October 8, 2008                [Page 14]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   the "widget.png" file, a request for a "widget.png" thumbnail might
   look like this:

      C> THMB PNG 80 80 widget.png
      S> 150 Starting thumbnail transfer (1234 Bytes) for widget.png
      S> 226 Transfer complete.

   In between the 150 and 226 server responses, the thumbnail image has
   been transferred over a negotiated data connection.

   If the client requests a thumbnail for an unsupported image type, the
   exchange would be:

      C> THMB PSP 80 80 widget.psp
      S> 501 Syntax error in parameters or arguments.

7. Security Considerations

   This document does not explicitly address security issues as they
   pertain to the FTP protocol in general.  The commands introduced in
   this document do not affect the security of the FTP protocol nor do
   they address any of the security considerations described in
   [RFC2577].

   Implementation of the RMDA, DSIZ, AVBL, and THMB commands can require
   significant server resources to process.  This knowledge could be
   used by attackers in a denial of service attack.  However, this issue
   has been addressed before with others commands, such as SIZE, and is
   traditionally mitigated by the server-FTP process's implementation of
   the command.

   The FTP server is encouraged to take specific care when implementing
   the RMDA command to avoid bypassing permissions.  While it may be
   tempting to take advantage of a method made available by the platform
   to delete an entire tree of the file system at once, doing so could
   allow for the possibility of bypassing permissions that apply to
   specific files.  Consequently, the contents of the path being deleted
   by RMDA must be individually evaluated.

8. IANA Considerations

   None.

9. Conclusions

   Inclusion of these commands both for servers and client can
   significantly reduce bandwidth requirements for many operations as


Peterson & Papenthien  Expires October 8, 2008                [Page 15]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


   well as improving the client-side experience by reducing the amount
   of time needed to perform these operations via other methods.

10. Acknowledgments

   We would like to thank Alfred Hoenes for reviewing this document and
   providing thorough and thoughtful suggestions on how to make it
   better.

   This document was prepared using 2-Word-v2.0.template.dot.

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




































Peterson & Papenthien  Expires October 8, 2008                [Page 16]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


Normative References

   [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol
              (FTP)", STD 9, RFC 959, October 1985.

   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, November 1987.

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

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

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

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

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December
              2005.

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

Informative References

   [RFC2616]  Fielding, R., et al., "Hypertext Transfer Protocol -
              HTTP/1.1", RFC 2616, June 1999.



















Peterson & Papenthien  Expires October 8, 2008                [Page 17]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


Authors' Addresses

   Mark P. Peterson
   Rhino Software, Inc.
   P.O. Box 53
   Helenville, WI  53137
   U.S.A.

   Phone: +1 (262) 560-9627
   FAX:   +1 (262) 560-9628
   Email: mark.peterson@rhinosoft.com


   Douglas J. Papenthien
   Rhino Software, Inc.
   P.O. Box 53
   Helenville, WI  53137
   U.S.A.

   Phone: +1 (262) 560-9627
   FAX:   +1 (262) 560-9628
   Email: douglas.papenthien@rhinosoft.com


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.


Peterson & Papenthien  Expires October 8, 2008                [Page 18]


Internet-Draft    Streamlined FTP Command Extensions         April 2008


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, THE IETF TRUST 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 IETF Trust (2008).

   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.
































Peterson & Papenthien  Expires October 8, 2008                [Page 19]