Network Working Group R. McMurray Internet-Draft Microsoft Updates: 959 October 2010 Intended status: Standards Track Expires: April 13, 2011 File Transfer Protocol AGNT Command for User-FTP Process Identification draft-mcmurray-ftp-agnt-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 13, 2011. Copyright Copyright (c) 2010 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 McMurray Expires April 13, 2011 [Page 1] INTERNET-DRAFT FTP AGNT Command October 2010 (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. Abstract This document defines a new FTP command that provides a mechanism to identify the FTP client process that is being used to connect to an FTP server. Table of Contents 1. Introduction....................................................nn 2. Document Conventions ..........................................nn 2.1. Basic Tokens ..............................................nn 2.2. Server Replies ............................................nn 3. The AGNT command ...............................................nn 3.1. Syntax of the AGNT command .................................nn 3.2. AGNT command semantics .....................................nn 3.3. AGNT command errors ........................................nn 3.4. FEAT response for AGNT command .............................nn 4. Security Considerations ........................................nn 5. IANA Considerations ............................................nn 6. References .....................................................nn 6.1 Normative References ........................................nn 6.2 Informative References ......................................nn Acknowledgments ...................................................nn Author's Address ..................................................nn 1. Introduction The File Transfer Protocol (FTP) provides no mechanism for a user-FTP process to specify any meaningful information about itself to an FTP server-PI, which limits the gathering of statistical information for a server-FTP process and limits the ability for an FTP server-PI to tailor responses for a specific user-FTP process. HTTP resolves this issue in [RFC1945] and [RFC2616] through the definition of the User-Agent request header. The goal of this document is to bring a similar level of feature parity to FTP by introducing a new AGNT command that allows a user-FTP process to specify information about itself to an FTP server-PI. [[ Discussion of this draft should take place on ftpext@ietf.org (or apps-discuss@ietf.org if necessary). ]] 2. Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", McMurray Expires April 13, 2011 [Page 2] INTERNET-DRAFT FTP AGNT Command October 2010 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In examples, "C>" and "S>" indicate lines sent by the client and server, respectively. This document also uses notation defined in [RFC959] and [RFC1123]. In particular, the terms "reply", "user", "NVFS", "NVT", "file", "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "control connection", "data connection", and "ASCII", are all used here as defined there. Syntax required is defined using the Augmented BNF defined in [RFC5234]. Some general ABNF definitions are required throughout the document; those will be defined later in this section. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section. 2.1. Basic Tokens This document imports the core definitions given in Appendix B of [RFC5234]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. To that, the following term is added for use in this document. TCHAR = VCHAR / SP / HTAB ; visible plus white space The VCHAR (from [RFC5234]) and TCHAR rules give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses. Note that in ABNF, string literals are case insensitive. That convention is preserved in this document, and implies that FTP commands and parameters that are added by this specification have values that can be represented in any case. That is, "AGNT" is the same as "agnt", "Agnt", "AgNt", etc., and "FooBar/1.0" is the same as "foobar/1.0", "FOOBAR/1.0", etc. 2.2. Server Replies Section 4.2 of [RFC959] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change. error-response = error-code SP *TCHAR CRLF error-code = ("4" / "5") 2DIGIT Implementers should note that the ABNF syntax (which was not used in [RFC959]) used in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise McMurray Expires April 13, 2011 [Page 3] INTERNET-DRAFT FTP AGNT Command October 2010 explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementers should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) can be of the multi-line format described in [RFC959]. Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 reply" means a reply from the server-PI using the three digit code "500". 3. The AGNT command A new command "AGNT" is added to the FTP command set to allow a user-FTP process to identify itself and provide other information that may be meaningful about the user-FTP process to an FTP server-PI. By using this command, a user-FTP process may advertise (through a parameter) a particular product version to a server-PI, or it may specify support for specific features, or it may include information that is purely for statistical purposes. The server-PI may choose to completely ignore any of this information, or it may choose to use the information for the current FTP session. For example, a user-FTP process may specify its host operating system, which may have no impact on the session. In contrast, an implementer that creates both a user-PI and server-PI may choose to use the parameter for the AGNT command to tailor the server-PI responses for their specific user-PI; such as responses to commands like LIST/NLST. Examples: AGNT Foo/1.0 AGNT Bar/4.5 (UNIX) AGNT FooBar/6.1 (Windows; TLS/1.2; .NET 4.0) AGNT BarFoo/2.1 (Linux; en-us; RFC2640; RFC3659; RFC4217) In the preceding examples, most of the information is strictly for informative purposes. However, the "en-us" identifier is a practical example of information that should only be used for statistical usage; support for internationalization MUST be handled through the mechanisms that are described in [RFC2640] and MUST NOT be specified through the AGNT command. 3.1. Syntax of the AGNT command The AGNT command is defined as follows. agent-command = "AGNT" SP user-agent CRLF user-agent = agentchar [*(agentchar)] agentchar = ALPHA / DIGIT / SP / "-" / "_" / "/" / "." / "," / ";" / "(" / ")" McMurray Expires April 13, 2011 [Page 4] INTERNET-DRAFT FTP AGNT Command October 2010 host-response = host-ok / error-response host-ok = "200" CRLF As with all FTP commands, the "AGNT" command word is case independent, and MAY be specified in any character case desired. The "user-agent" (given as a parameter of the "agent-command") specifies the identifying information for the user-FTP process. TODO: What about internationalization of user agents? 3.2. AGNT command semantics The AGNT command is valid at any time during an FTP session, although it would make sense for the user-FTP process to send the AGNT command earlier in the session. TODO: Should a server-PI be allowed to require a successful login before accepting the AGNT command? Upon receiving the AGNT command, the FTP server-PI SHOULD validate that the user-agent given is syntactically correct, and, if it is valid, return the "host-ok" reply to the user-PI. The following example illustrates what a typical sequence might look like when the AGNT command is used: C> AGNT FooBar/1.0 S> 200 Command okay. The "200" reply code for the AGNT command is the standard reply for an FTP command that requires no further processing. TODO: Should a server-PI be allowed to deny a connection based on information that is presented by the AGNT command? (For example, if a particular user-FTP process version is insufficient or not supported.) 3.3. AGNT command errors The server-PI SHOULD reply with a 500 or 502 reply if the AGNT command is unrecognized or unimplemented. A 501 reply SHOULD be sent if the user-agent given is syntactically invalid. In none of these error conditions should the connection be closed. 3.4. FEAT response for AGNT command While the AGNT command is primarily used for the user-FTP process to McMurray Expires April 13, 2011 [Page 5] INTERNET-DRAFT FTP AGNT Command October 2010 identify itself, a server-FTP process that supports the AGNT command SHOULD include a line containing the single word "AGNT" when replying to the FEAT command [RFC2389] to indicate that the AGNT command is supported. This word is case insensitive, and MAY be sent in any mixture of upper or lower case, however it SHOULD be sent in upper case. That is, the response SHOULD be: C> FEAT S> 211- S> ... S> AGNT S> ... S> 211 End The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [RFC2389]. 4. Security Considerations An FTP user-PI may send an incorrect or false parameter for the AGNT command; HTTP suffers from this same issue, and in most situations the user-agent information will only be used for gathering usage statistics so an incorrect or false parameter for the AGNT command should not present a problem. However, an FTP server-PI implementer will need to be aware that this is a possibilty when choosing whether to do anything meaningful with the information that is presented by an FTP user-PI through the AGNT command. A general discussion of issues related to the security of FTP can be found in [RFC2577]. 5. IANA Considerations IANA is requested to register the following FTP extension according to the procedure established by [RFC5797]: +-------+------+-------------------+------+------+------------------+ | cmd | FEAT | description | type | conf | RFC#s/References | | | Code | | | | and Notes | +-------+------+-------------------+------+------+------------------+ | AGNT | AGNT | User-FTP Process | a | o | [#1] | | | | Description | | | | +-------+------+-------------------+------+------+------------------+ [[ RFC Editor: Please update note #1 in the above table with the number of this document. ]] 6. References 6.1. Normative References McMurray Expires April 13, 2011 [Page 6] INTERNET-DRAFT FTP AGNT Command October 2010 [RFC959] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", 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 [RFC2389] Hethmon, P., Elz, R., "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998 [RFC2640] Curtin, W., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999 [RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008 6.2. Informative References [RFC1945] Berners-Lee, T., Fielding, R., Frystyk, H., "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996 [RFC2577] Allman, M., Ostermann, S., "FTP Security Considerations", RFC 2577, May 1999 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 [RFC5797] Klensin, J., Hoenes, A., "FTP Command and Extension Registry", March 2010 Acknowledgments N/A for now. Author's Address Robert McMurray Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: robmcm@microsoft.com McMurray Expires April 13, 2011 [Page 7]