idnits 2.17.1 draft-ietf-ftpext-feat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9775 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FTPEXT Working Group P. Hethmon 3 Internet Draft Hethmon Brothers 4 Expiration Date: January 1998 5 R. Elz 6 University of Melbourne 8 July 1997 10 Feature negotiation mechanism for the File Transfer Protocol 12 draft-ietf-ftpext-feat-01.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 The File Transfer Protocol is, from time to time, extended with new 35 commands, or facilities. Implementations of the FTP protocol cannot 36 be assumed to all immediately implement all newly defined mechanisms. 37 This document provides a mechanism by which clients of the FTP 38 protocol can discover which new features are supported by a 39 particular FTP server. 41 A new security considerations section has been added. One previously 42 legal way to indicate no features has been deleted. The usual kinds 43 of editorial updates have been made. 45 Table of Contents 47 Abstract ................................................ 1 48 1 Introduction ............................................ 2 49 2 Document Conventions .................................... 2 50 2.1 Basic Tokens ............................................ 3 51 2.2 Server Replies .......................................... 3 52 3 Knowledge of Extra Capabilities - the FEAT Command ...... 3 53 3.1 Feature (FEAT) Command Syntax ........................... 4 54 3.2 FEAT Command Responses .................................. 4 55 3.3 Rationale for FEAT ...................................... 6 56 4 The OPTS Command ........................................ 6 57 5 Security Considerations ................................. 7 58 6 References .............................................. 8 59 Acknowledgements ........................................ 8 60 Editors' Addresses ...................................... 8 62 1. Introduction 64 This document amends the File Transfer Protocol (FTP) [1]. Two new 65 commands are added: "FEAT" and "OPTS". 67 These commands allow a client to discover which optional commands a 68 server supports, and how they are supported, and to select among 69 various options that any FTP command may support. 71 2. Document Conventions 73 This document makes use of the document conventions defined in BCP14 74 [2]. That provides the interpretation of some capitalized words like 75 MUST, SHOULD, etc. 77 Terms defined in [1] will be used here as defined there. These 78 include ASCII, reply, server-FTP process, user-FTP process, server- 79 PI, user-PI, and user. 81 Syntax required is defined using the Augmented BNF defined in [3]. 82 Some general ABNF definitions are required throughout the document, 83 those will be defined here. At first reading, it may be wise to 84 simply recall that these definitions exist here, and skip to the next 85 section. 87 2.1. Basic Tokens 89 This document imports the definitions given in Appendix A of [3]. 90 There definitions will be found for basic ABNF elements like ALPHA, 91 DIGIT, SP, etc. To that, the following terms are added for use in 92 this document. 94 PRCHAR = %x21-7e ; a printing character, ! to ~ 95 TXTCHAR = PRCHAR / SP / %x09 ; printing plus white space 97 The PRCHAR and TXTCHAR types give basic character types from varying 98 sub-sets of the ASCII character set for use in various commands and 99 responses. 101 error-response = error-code SP *TXTCHAR CRLF 102 error-code = ("4" / "5") 2DIGIT 104 Note that in ABNF, strings literals are case insensitive. That 105 convention is preserved in this document. However note that ALPHA, 106 in particular, is case sensitive, as are PRCHAR and TXTCHAR. 108 2.2. Server Replies 110 Section 4.2 of [1] defines the format and meaning of replies by the 111 server-PI to FTP commands from the user-PI. Those reply conventions 112 are used here without change. Implementors should note that the ABNF 113 syntax (which was not used in [1]) in this document, and other FTP 114 related documents, sometimes shows replies using the one line format. 115 Unless otherwise explicitly stated, that is not intended to imply 116 that multi-line responses are not permitted. Implementors should 117 assume that, unless stated to the contrary, any reply to any FTP 118 command (including QUIT) may be of the multiline format described in 119 [1]. 121 Throughout this document, replies will be identified by the three 122 digit code that is their first element. Thus the term "500 Reply" 123 means a reply from the server-PI using the three digit code "500". 125 3. Knowledge of Extra Capabilities - the FEAT Command 127 It is not to be expected that all servers will necessarily support 128 all of the new commands defined in all future amendments to the FTP 129 protocol. In order to permit clients to determine which new commands 130 are supported by a particular server, without trying each possible 131 command, one new command is added to the FTP command repertoire. 132 This command requests the server to list all extension commands, or 133 extended mechanisms, that it supports. That is, all defined and 134 specified commands and features not defined in [1], or this document, 135 must be included in the FEAT command output in the form specified in 136 the document that defines the extension. 138 User-FTP PIs must expect to see, in FEAT command responses, unknown 139 features listed. This is not an error, and simply indicates that the 140 server-FTP implementor has seen, and implemented, the specification 141 of a new feature that is unknown to the user-FTP. 143 3.1. Feature (FEAT) Command Syntax 145 feat = "Feat" CRLF 147 The FEAT command consists solely of the word "FEAT". It has no 148 parameters or arguments. 150 3.2. FEAT Command Responses 152 Where a server-FTP process does not support the FEAT command, it will 153 respond to the FEAT command with a 500 or 502 reply. This is simply 154 the normal "unrecognized command" reply that any unknown command 155 would elicit. Errors in the command syntax, such as giving 156 parameters, will result in a 501 reply. 158 Server-FTP processes that recognize the FEAT command, but implement 159 no extended features, and therefore have nothing to report, SHOULD 160 respond with the "no-features" 211 reply. However, as this case is 161 practically indistinguishable from a server-FTP that does not 162 recognize the FEAT command, a 500 or 502 reply MAY also be used. The 163 "no-features" reply MUST NOT use the multi-line response format, 164 exactly one response line is required and permitted. 166 Replies to the FEAT command MUST comply with the following syntax. 167 Text on the first line of the reply is free form, and not 168 interpreted, and has no practical use, as this text is not expected 169 to be revealed to end users. The syntax of other reply lines is 170 precisely defined, and if present, MUST be exactly as specified. 172 feat-response = error-response / no-features / feature-listing 173 no-features = "211" SP *TXTCHAR CRLF 174 feature-listing = "211-" *TXTCHAR CRLF 175 1*( SP feature CRLF ) 176 "211 End" CRLF 177 feature = feature-label [ SP feature-parms ] 178 feature-label = 1*PRCHAR 179 feature-parms = 1*TXTCHAR 181 Note that each feature line in the feature-listing begins with a 182 single space. That space is not optional, nor does it indicate 183 general white space. This space guarantees that the feature line can 184 never be misinterpreted as the end of the feature-listing, but is 185 required even where there is no possibility of ambiguity. 187 Each extension supported must be listed on a separate line to 188 facilitate the possible inclusion of parameters supported by each 189 extension command. The feature-label to be used in the response to 190 the FEAT command will be specified as each new feature is added to 191 the FTP command set. Often it will be the name of a new command 192 added, however this is not required. In fact it is not required that 193 a new feature actually add a new command. Any parameters included 194 are to be specified with the definition of the command concerned. 195 That specification shall also specify how any parameters present are 196 to be interpreted. 198 The feature-label and feature-params are nominally case sensitive, 199 however the definitions of specific labels and parameters specify the 200 precise interpretation, and it is to be expected that those 201 definitions will usually specify the label and params in a case 202 independent manner. Where this is done, implementations are 203 recommended to use upper case letters when transmitting the feature 204 response. 206 The FEAT command itself is not included in the list of features 207 supported, support for the FEAT command is indicated by return of a 208 reply other than a 500 or 502 reply. 210 A typical example reply to the FEAT command might be a multiline 211 reply of the form: 213 C> feat 214 S> 211-Extensions supported: 215 S> MLST size*;create;modify*;perm;media-type 216 S> SIZE 217 S> COMPRESSION 218 S> MDTM 219 S> 211 END 221 The particular extensions shown here are simply examples of what may 222 be defined in other places, no particular meaning should be 223 attributed to them. Recall also, that the feature names returned are 224 not command names, as such, but simply indications that the server 225 possesses some attribute or other. 227 The order in which the features are returned is of no importance, 228 server-FTP processes are not required to implement any particular 229 order, or even to consistently return the same order when the command 230 is repeated. 232 FTP implementations which support properly documented extensions 233 beyond those commands and mechanisms described in RFC959 [1] MUST 234 support FEAT. 236 User-FTP processes should, however, be aware that there have been 237 several FTP extensions developed, and in widespread use, prior to the 238 adoption of this document and the FEAT command. The effect of this 239 is that an error response to the FEAT command does not necessarily 240 imply that those extensions are not supported by the server-FTP 241 process. User-PIs should test for such extensions individually if an 242 error response has been received to the FEAT command. 244 3.3. Rationale for FEAT 246 While not absolutely necessary, a standard mechanism for the server- 247 PI to inform the user-PI of any features and extensions supported 248 will help reduce unnecessary traffic between the user-PI and server- 249 PI as more extensions may be introduced in the future. If no 250 mechanism existed for this, a user-FTP process would have to try each 251 extension in turn resulting in a series of exchanges between the 252 user-PI and server-PI. Apart from being possibly wasteful, this 253 procedure may not always be possible, as issuing of a command just to 254 determine if it is supported or not may have some effect that is not 255 desired. 257 4. The OPTS Command 259 The OPTS (options) command allows a user-PI to specify the desired 260 behavior of a server-FTP process when another FTP command (the target 261 command) is later issued. The exact behavior, and syntax, will vary 262 with the target command indicated, and will be specified with the 263 definition of that command. Where no OPTS behavior is defined for a 264 particular command there are no options available for that command. 266 Request Syntax: 267 opts = opts-cmd SP command-name 268 [ SP command-options ] CRLF 269 opts-cmd = "opts" 270 command-name = 271 command-options = 273 Response Syntax: 274 opts-response = opts-good / opts-bad 275 opts-good = "200" SP response-message CRLF 276 opts-bad = "451" SP response-message CRLF / 277 "501" SP response-message CRLF 278 response-message = *TXTCHAR 280 An "opts-good" response (200 reply) MUST be sent when the command- 281 name specified in the OPTS command is recognized, and the command- 282 options, if any, are recognized, and appropriate. An "opts-bad" 283 response is sent in other cases. A 501 reply is appropriate for any 284 permanent error. That is, for any case where simply repeating the 285 command at some later time, without other changes of state, will also 286 be an error. A 451 reply should be sent where some temporary 287 condition at the server, not related to the state of communications 288 between user and server, prevents the command being accepted when 289 issued, but where if repeated at some later time, a changed 290 environment for the server-FTP process may permit the command to 291 succeed. If the OPTS command itself is not recognized, a 500 or 502 292 reply will, of course, result. 294 The OPTS command MUST be implemented whenever the FEAT command is 295 implemented. Because of that, there is no indication in the list of 296 features returned by FEAT to indicate that the OPTS command itself is 297 supported. Neither the FEAT command, nor the OPTS command, have any 298 optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS" 299 commands. 301 5. Security Considerations 303 No significant new security issues, not already present in the FTP 304 protocol, are believed to have been created by this extension. 305 However, this extension does provide a mechanism by which users can 306 determine the capabilities of an FTP server, and from which 307 additional information may be able to be deduced. While the same 308 basic information could be obtained by probing the server for the 309 various commands, if the FEAT command were not provided, that method 310 may reveal an attacker by logging the attempts to access various 311 extension commands. This possibility is not considered a serious 312 enough threat to be worthy of any remedial action. 314 The security of any additional features that might be reported by the 315 FEAT command, and manipulated by the OPTS command, should be 316 addressed where those features are defined. 318 6. References 320 [1] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", 321 STD 9, RFC 959, October 1985 323 [2] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997 326 [3] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 327 Work In Progress , July 1997. 329 Acknowledgements 331 This protocol extension was developed in the FTPEXT Working Group of 332 the IETF, and the members of that group are all acknowledged as its 333 creators. 335 Editors' Addresses 337 Paul Hethmon 338 Hethmon Brothers 339 2305 Chukar Road 340 Knoxville, TN 37923 USA 342 Phone: +1 423 690 8990 343 Email: phethmon@hethmon.com 345 Robert Elz 346 University of Melbourne 347 Department of Computer Science 348 Parkville, Vic 3052 349 Australia 351 Email: kre@munnari.OZ.AU