idnits 2.17.1 draft-ietf-ftpext-feat-00.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-27) 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 (June 1997) is 9813 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: December 1997 5 R. Elz 6 University of Melbourne 8 June 1997 10 Feature negotiation mechanism for the File Transfer Protocol 12 draft-ietf-ftpext-feat-00.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 This draft extracts the FEAT and OPTS commands from the "mlst" draft, 42 into this draft of their own. The descriptions of those commands 43 have been updated in an editorial way, no changes of substance have 44 been made. This paragraph will be deleted from the final version of 45 this document. 47 Table of Contents 49 Status of this Memo ..................................... 1 50 Abstract ................................................ 1 51 1 Introduction ............................................ 2 52 2 Document Conventions .................................... 2 53 2.1 Basic Tokens ............................................ 3 54 2.2 Server Replies .......................................... 3 55 3 Knowledge of Extra Capabilities - the FEAT Command ...... 3 56 3.1 Feature (FEAT) Command Syntax ........................... 4 57 3.2 FEAT Command Responses .................................. 4 58 3.3 Rationale for FEAT ...................................... 5 59 4 The OPTS Command ........................................ 6 60 5 Security ................................................ 7 61 6 References .............................................. 7 62 Acknowledgements ........................................ 7 63 Editors' Addresses ...................................... 7 65 1. Introduction 67 This document amends the File Transfer Protocol (FTP) [1]. Two new 68 commands are added: "FEAT" and "OPTS". 70 These commands allow a client to discover which optional commands a 71 server supports, and how they are supported, and to select among 72 various options that any FTP command may support. 74 2. Document Conventions 76 This document makes use of the document conventions defined in BCP14 77 [2]. That provides the interpretation of some capitalized words like 78 MUST, SHOULD, etc. 80 Terms defined in [1] will be used here as defined there. These 81 include ASCII, reply, server-FTP process, user-FTP process, server- 82 PI, user-PI, and user. 84 Syntax required is defined using the Augmented BNF defined in [3]. 85 Some general ABNF definitions are required throughout the document, 86 those will be defined here. At first reading, it may be wise to 87 simply recall that these definitions exist here, and skip to the next 88 section. 90 2.1. Basic Tokens 92 This document imports the definitions given in Appendix A of [3]. 93 There definitions will be found for basic ABNF elements like ALPHA, 94 DIGIT, SP, etc. To that, the following terms are added for use in 95 this document. 97 PCHAR = %x21-7e ; a printing character, ! to ~ 98 TCHAR = PCHAR / SP / %x08 ; printing plus white space 100 The PCHAR and TCHAR types give basic character types from varying 101 sub-sets of the ASCII character set for use in various commands and 102 responses. 104 error-response = error-code SP *TCHAR CRLF 105 error-code = ("4" / "5") 2DIGIT 107 Note that in ABNF, strings literals are case insensitive. That 108 convention is preserved in this document. However note that ALPHA, 109 in particular, is case sensitive, as are PCHAR and TCHAR. 111 2.2. Server Replies 113 Section 4.2 of [1] defines the format and meaning of replies by the 114 server-PI to FTP commands from the user-PI. Those reply conventions 115 are used here without change. Implementors should note that the ABNF 116 syntax (which was not used in [1]) in this document, and other FTP 117 related documents, sometimes shows replies using the one line format. 118 Unless otherwise explicitly stated, that is not intended to imply 119 that multi-line responses are not permitted. Implementors should 120 assume that, unless stated to the contrary, any reply to any FTP 121 command (including QUIT) may be of the multiline format described in 122 [1]. 124 Throughout this document, replies will be identified by the three 125 digit code that is their first element. Thus the term "500 Reply" 126 means a reply from the server-PI using the three digit code "500". 128 3. Knowledge of Extra Capabilities - the FEAT Command 130 It is not to be expected that all servers will necessarily support 131 all of the new commands defined in all future amendments to the FTP 132 protocol. In order to permit clients to determine which new commands 133 are supported by a particular server, without trying each possible 134 command, one new command is added to the FTP command repertoire. 135 This command requests the server to list all extension commands that 136 it supports. 138 3.1. Feature (FEAT) Command Syntax 140 feat = "Feat" CRLF 142 The FEAT command consists solely of the word "FEAT". It has no 143 parameters or arguments. 145 3.2. FEAT Command Responses 147 Where a server-FTP process does not support the FEAT command, it will 148 respond to the FEAT command with a 500 reply. This is simply the 149 normal "unrecognized command" reply that any unknown command would 150 elicit. Errors in the command syntax, such as giving parameters, 151 will result in a 501 reply. 153 Server-FTP processes that recognize the FEAT command, but implement 154 no extended features, and therefore have nothing to report, SHOULD 155 respond with the "no-features" 211 reply. However, as this case is 156 practically indistinguishable from a server-FTP that does not 157 recognize the FEAT command, a 500 reply MAY also be used. It is also 158 possible to indicate that no features are implemented by returning a 159 "feature-listing" 211 reply, with no features actually included, 160 however server-FTP processes SHOULD NOT use this method. 162 Replies to the FEAT command MUST comply with the following syntax. 163 Text on the first line of the reply is free form, and not 164 interpreted, but the syntax of other reply lines is precisely 165 defined, and if present, MUST be exactly as specified. 167 feat-response = error-response / no-features / feature-listing 168 no-features = "211" SP *TCHAR CRLF 169 feature-listing = "211-" *TCHAR CRLF 170 *( SP feature CRLF ) 171 "211 End" CRLF 172 feature = feature-label [ SP parms ] 173 feature-label = 1*PCHAR 174 parms = 1*TCHAR 176 Note that each feature line in the feature-listing begins with a 177 space. That space is not optional, nor does it indicate general 178 white space. This space guarantees that the feature line can never 179 be misinterpreted as the end of the feature-listing, but is required 180 even where there is no possibility of ambiguity. 182 Each extension supported must be listed on a separate line to 183 facilitate the possible inclusion of parameters supported by each 184 extension command. The feature-label to be used in the response to 185 the FEAT command will be specified as each new feature is added to 186 the FTP command set. Often it will be the name of a new command 187 added, however this is not required, in fact it is not required that 188 a new feature actually add a new command. Any parameters included 189 are to be specified with the definition of the command concerned. 190 That specification shall also specify how any parameters present are 191 to be interpreted. 193 The FEAT command itself is not included in the list of features 194 supported, support for the FEAT command is indicated by return of a 195 reply other than a 500 reply. 197 A typical example reply to the FEAT command might be a multiline 198 reply of the form: 200 C> FEAT 201 S> 211- Extensions supported: 202 S> MLST size*;create;modify*;perm;media-type 203 S> SIZE 204 S> MDTM 205 S> 211 End 207 The particular extensions shown here are simply examples of what may 208 be defined in other places, no particular meaning should be 209 attributed to them. 211 FTP implementations which support extension commands beyond those 212 commands described in RFC959 [1] MUST support FEAT. 214 3.3. Rationale for FEAT 216 While not absolutely necessary, a standard mechanism for the server- 217 PI to inform the user-PI of any features and extensions supported 218 will help reduce unnecessary traffic between the user-PI and server- 219 PI as more extensions may be introduced in the future. If no 220 mechanism existed for this, a user-FTP process would have to try each 221 extension in turn resulting in a series of exchanges between the 222 user-PI and server-PI. Apart from being possibly wasteful, this 223 procedure may not always be possible, as issuing of a command just to 224 determine if it is supported or not may have some effect that is not 225 desired. 227 4. The OPTS Command 229 The OPTS (options) command allows a user-PI to specify the desired 230 behavior of a server-FTP process when another FTP command (the target 231 command) is later issued. The exact behavior, and syntax, will vary 232 with the target command indicated, and will be specified with the 233 definition of that command. Where no OPTS behavior is defined for a 234 particular command there are no options available for that command. 236 Request Syntax: 237 opts = opts-cmd SP command-name 238 [ SP command-options ] CRLF 239 opts-cmd = "opts" 240 command-name = 241 command-options = 243 Response Syntax: 244 opts-response = opts-good / opts-bad 245 opts-good = "200" SP response-message CRLF 246 opts-bad = "451" SP response-message CRLF / 247 "501" SP response-message CRLF 248 response-message = *TCHAR 250 An "opts-good" response (200 reply) MUST be sent when the command- 251 name specified in the OPTS command is recognized, and the command- 252 options, if any, are recognized, and appropriate, An "opts-bad" 253 response is sent in other cases. A 501 reply is appropriate for any 254 permanent error. That is, for any case where simply repeating the 255 command at some later time, without other changes of state, will also 256 be an error. A 451 reply should be sent where some temporary 257 condition at the server, not related to the state of communications 258 between user and server, prevents the command being accepted when 259 issued, but where is repeated at some later time, a changed 260 environment for the server-FTP process may permit the command to 261 succeed. If the OPTS command itself is not recognized, a 500 reply 262 will, of course, result. 264 The OPTS command MUST be implemented whenever the FEAT command is 265 implemented. Because of that, there is no indication in the list of 266 features returned by FEAT to indicate that the OPTS command itself is 267 supported. Neither the FEAT command, nor the OPTS command, have any 268 optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS" 269 commands. 271 5. Security 273 This memo does not yet discuss security. It is possible that no new 274 security concerns are raised in this memo above what already exists 275 within the FTP protocol. However, the working group needs to 276 consider this carefully. 278 6. References 280 [1] J. Postel, J. Reynolds, "File Transfer Protocol (FTP)", 281 STD 9 (RFC 959), ISI, October 1985 283 [2] S. Bradner, "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14 (RFC 2119), Harvard University, 285 March 1997 287 [3] D. Crocker, "Augmented BNF for Syntax Specifications: ABNF", 288 Work In Progress , Internet 289 Mail Consortium, March 1997. 291 Acknowledgements 293 This protocol extension was developed in the FTPEXT Working Group of 294 the IETF, and the members of that group are all acknowledged as its 295 creators. 297 Editors' Addresses 299 Paul Hethmon 300 Hethmon Brothers 301 2305 Chukar Road 302 Knoxville, TN 37923 USA 304 Phone: 423-690-8990 305 Email: phethmon@hethmon.com 307 Robert Elz 308 University of Melbourne 309 Department of Computer Science 310 Parkville, Vic 3052 311 Australia 313 Email: kre@munnari.OZ.AU