idnits 2.17.1 draft-klensin-ftp-registry-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC959, but the abstract doesn't seem to directly say this. It does mention RFC959 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC959, updated by this document, for RFC5378 checks: 1985-10-01) -- 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 (December 17, 2009) is 5238 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2773' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC4217' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC4844' is defined on line 483, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1545 (Obsoleted by RFC 1639) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft 4 Updates: 959 (if approved) A. Hoenes 5 Intended status: Standards Track TR-Sys 6 Expires: June 20, 2010 December 17, 2009 8 FTP Command and Extension Registry 9 draft-klensin-ftp-registry-04 11 Abstract 13 Every version of the FTP specification has added a few new commands, 14 with the early ones summarized in RFC 959. RFC 2389 established a 15 mechanism for specifying and negotiating FTP extensions. The number 16 of extensions, both supported by the mechanism and some that are not, 17 continues to increase. An IANA registry of FTP Command and Feature 18 names is established to reduce the likelihood of conflict of names 19 and the consequent ambiguity. This specification establishes that 20 registry. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on June 20, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Discussion List . . . . . . . . . . . . . . . . . . . . . 3 64 2. Registry Definition . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Registry Name . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Registry Format . . . . . . . . . . . . . . . . . . . . . 3 67 2.3. Criteria for Registration . . . . . . . . . . . . . . . . 5 68 2.4. Base FTP Commands . . . . . . . . . . . . . . . . . . . . 6 69 2.5. Obsolete Commands . . . . . . . . . . . . . . . . . . . . 6 70 3. Initial Contents of Registry . . . . . . . . . . . . . . . . . 7 71 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 78 A.1. Changes in Version -01 . . . . . . . . . . . . . . . . . . 11 79 A.2. Changes in Version -02 . . . . . . . . . . . . . . . . . . 11 80 A.3. Changes in Version -03 . . . . . . . . . . . . . . . . . . 12 81 A.4. Changes in Version -04 . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 Every version of the FTP specification has added a few new commands, 87 with the early ones summarized in RFC 959 [RFC0959]. RFC 2389 88 [RFC2389] established a mechanism for specifying and negotiating 89 extensions to the FTP protocol specified in RFC 959, by means of 90 "FEAT Strings" identifying extensions supported by the FTP server, 91 and sent in response to a "FEAT" command. The number of extensions 92 continues to grow, not all of them supported by FEAT. An IANA 93 registry is established to reduce the likelihood of conflict of names 94 and the consequent ambiguity and to encourage the sharing of 95 information. This specification establishes that registry. 97 1.1. Discussion List 99 [[ RFC Editor: please remove this section before publication. ]] 101 Until and unless a WG is created, this proposal will be discussed on 102 the list apps-discuss@ietf.org 104 2. Registry Definition 106 2.1. Registry Name 108 The recommended name of this registry is "FTP Commands and 109 Extensions". 111 2.2. Registry Format 113 IANA is requested to establish a registry for FTP commands and 114 extensions. Registration requests and registry entries should 115 include the following: 117 Command Name - The FTP command, either new or modified, used in the 118 extension or with which the extension is used. 120 Following the long-standing practice to capitalize command names 121 in specification documents for FTP, the command names are entered 122 in all uppercase. For extensions amending the operation of a 123 command, a plus sign ("+") is appended to the command name. 124 However, an extension might not be bound to one command (or a 125 small number of commands), but affect the overall command 126 parameter handling and/or transaction processing; in this case, 127 the string "-N/A-" is entered. 129 It is intended to have the registry entries ordered by ascending 130 ASCII collation order of this column (including the "+" suffix if 131 present). 133 Extension name - The name of the extension. 135 FTP extensions predating RFC 2389 [RFC2389], and some extensions 136 published after it, did not specify a keyword to identify the 137 extension in a FEAT response. Some later specifications 138 established FEAT strings with the respective command names as 139 their keywords. In order to provide for keywords for future 140 specifications in such cases, this document establishes 141 'placeholder' keywords to reserve reasonable feature names for 142 future standardization. Similarly, placeholder keywords are used 143 for the basic FTP commands specified in RFC 959 [RFC0959] and 144 those of its predecessors that are still in use. These 145 placeholder keywords are placed in the registry for convenience; 146 it is not intended that they be returned in FEAT responses. 147 To compensate for this idiosyncrasy, the column in the registry is 148 entitled "FEAT Code", and to clearly distinguish between the two 149 cases, defined FEAT keywords codes are listed in all uppercase, 150 whereas 'placeholder' keywords (henceforth called "pseudo FEAT 151 codes") are listed in lowercase. Future specifications are 152 allowed to "upgrade" a placeholder to a true keyword unless it is 153 specifically declared 'immutable' below, but otherwise IANA 154 maintains uniqueness of feature names (FEAT codes) based on case- 155 insensitive comparison. 157 Description - A brief description of the extension and, where 158 appropriate, the command. 160 FEAT String - (optional in registration requests to the IANA) 162 The string expected to be included in the response to the FEAT 163 command [RFC2389] if the extension is supported. 165 In many cases, the FEAT string required to identify an extension 166 only consists of the "FEAT Code", making this item redundant. 167 Therefore, this item should only be specified if it is intended to 168 register a FEAT string that contains mandatory elements other than 169 the "FEAT Code" itself. 171 Due to space restrictions, and to allow registrants to provide 172 additional information as well, IANA should present these 173 registration items (if given) in numbered footnotes to the table, 174 not in an additional table column. 176 Command Type - The type (or 'kind') of the command. 178 Section 4.1 of RFC 959 [RFC0959] introduced a subdivision of FTP 179 commands into three types: Access control, transfer Parameter 180 {setting}, and Service {execution}. For clarity and as a service 181 to the user of the registry, this subdivision is extended to all 182 registered FTP commands, using the characteristic initial of the 183 type, 'a', 'p', or 's', respectively, filed in the registry column 184 entitled "type"; combinations are allowed, e.g. 'p/s'. 186 Conformance Requirements - The support expectation for the command. 188 RFC 959 specifies mandatory-to-implement commands and optional 189 commands. This classification is carried over to all registered 190 commands, using a column entitled "conf" carrying a single 191 character -- either 'm' or 'o', for "mandatory" and "optional", 192 respectively. Similarly, obsoleted or historic entries are left 193 in the registry to avoid conflicts with deployed implementations, 194 and these entries are marked with 'h' (for "historic"). 195 Beyond the initial registrations, Standards Action [RFC5226] is 196 needed to register new "mandatory" entries or to move such entries 197 to "historic". 199 Reference - A reference to an RFC or other definition of the 200 extension and/or to implementations supporting it (see the next 201 section). 203 2.3. Criteria for Registration 205 This registry is primarily intended to avoid conflicting uses of the 206 same extension names and command keywords for different purposes, not 207 to demonstrate that an extension is somehow "approved". The "expert 208 review" method will be used, but the designated expert is expected to 209 check only that at least one of the two criteria that follow are met. 211 1. The extension is documented in a permanent and readily available 212 public specification (This is the same as the "Specification 213 Required" registration policy defined in RFC 5226 [RFC5226]. 215 2. The extension is actually implemented in FTP client and server 216 systems that are generally available (not necessarily either free 217 or unencumbered, but available). 219 For an extension or command to be marked "mandatory" ('m' in the 220 "conf" column), an IETF Standards Track Specification is required. 221 An IESG Standards Action is allowed to direct IANA to change the 222 Conformance Requirements listed for any entry. 224 2.4. Base FTP Commands 226 The following commands are part of the base FTP specification 227 [RFC0959] and are listed in the registry with the immutable pseudo 228 FEAT code "base". 230 Mandatory commands: 232 ABOR, ACCT, ALLO, APPE, CWD, DELE, HELP, LIST, MODE, NLST, NOOP, 233 PASS, PASV, PORT, QUIT, REIN, REST, RETR, RNFR, RNTO, SITE, STAT, 234 STOR, STRU, TYPE, USER 236 Optional commands: 238 CDUP, MKD, PWD, RMD, SMNT, STOU, SYST 240 Note: STD 3 [RFC1123] clarified and updated the status and 241 implementation requirements of these standard FTP commands, and it 242 contains important complementary information for the following 243 commands: 245 LIST, NLST, PASV, REST, SITE, STOU 247 2.5. Obsolete Commands 249 The following commands were specified as experimental in an extension 250 to an early version of the FTP specification [RFC0775] but later 251 deprecated by RFC 1123 [RFC1123], because Standard FTP [RFC0959] 252 specifies their standard successors. They are listed in the registry 253 with the immutable pseudo FEAT code "hist". 255 XCUP, XCWD, XMKD, XPWD, XRMD 257 Implementation note: Deployed FTP clients still make use of the 258 deprecated commands and most FTP servers support them as aliases 259 for the standard commands. 261 The following commands were specified as part of the "FOOBAR" IPng 262 effort in RFC 1545 [RFC1545] and, later, RFC 1639 [RFC1639] and are 263 now obsolete. They are listed in the registry with the immutable 264 pseudo FEAT code "hist". 266 LPRT, LPSV 268 3. Initial Contents of Registry 270 As a service to users of the registry and the authors of existing 271 specifications, all FTP commands and features published in RFCs after 272 STD 3 [RFC1123] and up to the time of this writing are to be included 273 into the registry upon creation. 275 The following pseudo FEAT codes have been assigned, according to 276 Section 2: 278 base - FTP standard commands [RFC0959] 279 hist - Historic experimental commands [RFC0775], [RFC1639] 280 secu - FTP Security Extensions [RFC2228] 281 feat - FTP Feature Negotiation [RFC2389] 282 nat6 - FTP Extensions for NAT/IPv6 [RFC2428] 284 +-------+------+-------------------+------+------+------------------+ 285 | cmd | FEAT | description | type | conf | RFC#s/References | 286 | | Code | | | | and Notes | 287 +-------+------+-------------------+------+------+------------------+ 288 | ABOR | base | Abort | s | m | 959 | 289 | ACCT | base | Account | a | m | 959 | 290 | ADAT | secu | Authentication/ | a | o | 2228, 2773, 4217 | 291 | | | Security Data | | | | 292 | ALLO | base | Allocate | s | m | 959 | 293 | APPE | base | Append (with | s | m | 959 | 294 | | | create) | | | | 295 | AUTH | secu | Authentication/ | a | o | 2228 | 296 | | | Security | | | | 297 | | | Mechanism | | | | 298 | AUTH+ | AUTH | Authentication/ | a | o | 2773, 4217 #2 | 299 | | | Security | | | | 300 | | | Mechanism | | | | 301 | CCC | secu | Clear Command | a | o | 2228 | 302 | | | Channel | | | | 303 | CDUP | base | Change to Parent | a | o | 959 | 304 | | | Directory | | | | 305 | CONF | secu | Confidentiality | a | o | 2228 | 306 | | | Protected Command | | | | 307 | CWD | base | Change Working | a | m | 959 | 308 | | | Directory | | | | 309 | DELE | base | Delete File | s | m | 959 | 310 | ENC | secu | Privacy Protected | a | o | 2228, 2773, 4217 | 311 | | | Command | | | | 312 | EPRT | nat6 | Extended Port | p | o | 2428 | 313 | EPSV | nat6 | Extended Passive | p | o | 2428 | 314 | | | Mode | | | | 315 | FEAT | feat | Feature | a | m #1 | 2389 | 316 | | | Negotiation | | | | 317 | HELP | base | Help | s | m | 959 | 318 | LANG | UTF8 | Language (for | p | o | 2640 | 319 | | | Server Messages) | | | | 320 | LIST | base | List | s | m | 959, 1123 | 321 | LPRT | hist | Data Port | p | h | 1545, 1639 | 322 | | | {FOOBAR} | | | | 323 | LPSV | hist | Passive Mode | p | h | 1545, 1639 | 324 | | | {FOOBAR} | | | | 325 | MDTM | MDTM | File Modification | s | o | 3659 | 326 | | | Time | | | | 327 | MIC | secu | Integrity | a | o | 2228, 2773, 4217 | 328 | | | Protected Command | | | | 329 | MKD | base | Make Directory | s | o | 959 | 330 | MLSD | MLST | List Directory | s | o | 3659 | 331 | | | (for machine) | | | | 332 | MLST | MLST | List Single | s | o | 3659 | 333 | | | Object | | | | 334 | MODE | base | Transfer Mode | p | m | 959 | 335 | NLST | base | Name List | s | m | 959, 1123 | 336 | NOOP | base | No-Op | s | m | 959 | 337 | OPTS | feat | Options | p | m #1 | 2389 | 338 | PASS | base | Password | a | m | 959 | 339 | PASV | base | Passive Mode | p | m | 959, 1123 | 340 | PBSZ | secu | Protection Buffer | p | o | 2228 | 341 | | | Size | | | | 342 | PBSZ+ | PBSZ | Protection Buffer | p | o | 4217 | 343 | | | Size | | | | 344 | PORT | base | Data Port | p | m | 959 | 345 | PROT | secu | Data Channel | p | o | 2228 | 346 | | | Protection Level | | | | 347 | PROT+ | PROT | Data Channel | p | o | 4217 | 348 | | | Protection Level | | | | 349 | PWD | base | Print Directory | s | o | 959 | 350 | QUIT | base | Logout | a | m | 959 | 351 | REIN | base | Reinitialize | a | m | 959 | 352 | REST | base | Restart | s/p | m | 959, 1123 | 353 | REST+ | REST | Restart (for | s/p | m | 3659 #3 | 354 | | | STREAM mode) | | | | 355 | RETR | base | Retrieve | s | m | 959 | 356 | RMD | base | Remove Directory | s | o | 959 | 357 | RNFR | base | Rename From | s/p | m | 959 | 358 | RNTO | base | Rename From | s | m | 959 | 359 | SITE | base | Site Parameters | s | m | 959, 1123 | 360 | SIZE | SIZE | File Size | s | o | 3659 | 361 | SMNT | base | Structure Mount | a | o | 959 | 362 | STAT | base | Status | s | m | 959 | 363 | STOR | base | Store | s | m | 959 | 364 | STOU | base | Store Unique | a | o | 959, 1123 | 365 | STRU | base | File Structure | p | m | 959 | 366 | SYST | base | System | s | o | 959 | 367 | TYPE | base | Representation | p | m | 959 #4 | 368 | | | Type | | | | 369 | USER | base | User Name | a | m | 959 | 370 | XCUP | hist | {precursor for | s | h | 775, 1123 | 371 | | | CDUP} | | | | 372 | XCWD | hist | {precursor for | s | h | 775, 1123 | 373 | | | CWD} | | | | 374 | XMKD | hist | {precursor for | s | h | 775, 1123 | 375 | | | MKD} | | | | 376 | XPWD | hist | {precursor for | s | h | 775, 1123 | 377 | | | PWD} | | | | 378 | XRMD | hist | {precursor for | s | h | 775, 1123 | 379 | | | RMD} | | | | 380 | -N/A- | TVFS | Trivial Virtual | p | o | 3659 | 381 | | | File Store | | | | 382 +-------+------+-------------------+------+------+------------------+ 384 Table 1 386 Notes: 388 #1 While an IETF Standards Action would be required to make the FEAT 389 mechanism [RFC2389] mandatory, implementation of that extension 390 mechanism is clearly required in conjunction with any extension or 391 feature that depends on it. 393 #2 FEAT String for RFC 4217: AUTH TLS 394 FEAT String for RFC 2773: AUTH KEA-SKIPJACK 396 #3 FEAT String: REST STREAM 398 #4 FEAT String: TYPE {semicolon-separated list of supported types} 400 4. Acknowledgments 402 Any work to update or extend FTP depends on the base specification in 403 RFC 959. The contributions of its editors, Jon Postel and Joyce 404 Reynolds, are gratefully acknowledged. The option negotiation 405 mechanism specified in RFC 2389 and the accumulation of features that 406 has followed it made this registry relevant; the authors of those 407 documents are acknowledged as well. 409 Barry Leiba and Alexey Melnikov made several suggestions about 410 earlier drafts of this document, most of which have been 411 incorporated. 413 Anthony Bryan spotted a few typographical errors. 415 Scott Bradner suggested a clarification to the "expert review" text 416 that has been incorporated. 418 The authors appreciate the comments and support for this work 419 received from FTP implementers and many IETF participants. Comments 420 from the IESG helped to shape this document and registry to improve 421 its utility. 423 5. IANA Considerations 425 IANA is requested to establish the registry described in Section 2 426 using the initial content specified in Section 3 and including the 427 body of 2.4 and 2.5 as explanatory text in the preface of the 428 registry. 430 New entries should be added to this registry when extensions to FTP 431 are approved or defined in published RFCs or when extensions that are 432 already in use and well-documented are identified. In other words, 433 the requirement for registration is a slightly relaxed version of 434 "Specification Required" [RFC5226] with Expert Review. See 435 Section 2.3 for specifics and exceptions. 437 6. Security Considerations 439 The creation of this registry provides improved documentation and 440 protection against interoperability problems. It introduces no new 441 security issues. 443 7. References 445 7.1. Normative References 447 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 448 STD 9, RFC 959, October 1985. 450 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 451 the File Transfer Protocol", RFC 2389, August 1998. 453 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 454 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 455 May 2008. 457 7.2. Informative References 459 [RFC0775] Mankins, D., Franklin, D., and A. Owen, "Directory 460 oriented FTP commands", RFC 775, December 1980. 462 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 463 and Support", STD 3, RFC 1123, October 1989. 465 [RFC1545] Piscitello, D., "FTP Operation Over Big Address Records 466 (FOOBAR)", RFC 1545, November 1993. 468 [RFC1639] Piscitello, D., "FTP Operation Over Big Address Records 469 (FOOBAR)", RFC 1639, June 1994. 471 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 472 October 1997. 474 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 475 for IPv6 and NATs", RFC 2428, September 1998. 477 [RFC2773] Housley, R. and P. Yee, "Encryption using KEA and 478 SKIPJACK", RFC 2773, February 2000. 480 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 481 October 2005. 483 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 484 Series and RFC Editor", RFC 4844, July 2007. 486 Appendix A. Change Log 488 [[ RFC Editor: Please remove this Appendix before publication. ]] 490 A.1. Changes in Version -01 492 Updated document to reflect new date and IPR statement. 494 A.2. Changes in Version -02 496 o Several small changes in response to initial AD review. 498 o Changed registry model from "extension" to "command" + 499 "extension". 501 o Corrections from Alfred Hoenes, followed by adding his initial 502 registry list and adding him as co-author. 504 o Added description of the derivation of Table 1 to Section 3. 506 o Swapped columns 2 and 3 in Table 1. 508 o Consolidated "cmd" column content format to tag command amendments 509 and FTP features without a particular command, and renamed space 510 eating column 5 to "conf". 512 o Added missing footnotes to Table 1. 514 o Aligned Section 2 with Table 1, adding much information on column 515 format; removed orphan; specified collation of entries by "cmd". 517 o Introduced Standards Track requirement for commands in the 518 registry to be designated as mandatory in Section 2.3 and 519 Section 2; specified particular IESG change control for the "conf" 520 column in the registry. 522 o Split list in Section 2.4 into Mandatory and Optional, added 523 pointer to RFC 1123. 525 o Mention std. replacements per RFC 959 in Section 2.5. 527 o Numerous editorial fixes. 529 A.3. Changes in Version -03 531 Version -03 was produced in response to IETF Last Call and subsequent 532 IESG comments: 534 o Removed References section entry for RFC 2119 -- not used. 536 o Added all "base" (RFC 959/ 1123) commands and obsolete commands 537 (RFCs 0775, 1545/1639) to registry after discussion during Last 538 Call and with IESG. Tentatively recast title and several bits of 539 the document to refer to "FTP Commands and Extensions", not just 540 extensions and made related text changes. 542 o Clarified instructions to IANA including the "peer reviewed 543 publication" requirement in Section 2.3. 545 o Adjusted references so that those which support commands in the 546 registry are all informative. 548 o Removed language more appropriate to a proposal than to a finished 549 spec (e.g., a few uses of "it appears useful"). 551 o Clarified the IANA Considerations text about "specification 552 required" to make it consistent with Section 2.3. Specifically, 553 specifications of a quality needed to permit interoperable 554 implementations are not required although they are certainly 555 desirable. 557 o After an extended discussion about the possible role of this 558 document in making some extensions mandatory to implement, 559 returned it to its status as a registry specification only. The 560 former text that made the RFC 2389 and 2428 extensions mandatory 561 has been removed. RFC 2389 (the FEAT mechanism itself) is now 562 identified as mandatory for the extensions that depend on it (with 563 a new Note); RFC 2389 (the nat6 extensions) are now simply 564 optional as far as FTP is concerned as they should probably remain 565 unless the IETF concludes that nat6 is either required or very 566 broadly deployed. 568 o More editorial fixes. 570 A.4. Changes in Version -04 572 Final editing patches -- probably will not be posted until after IESG 573 signoff. 575 o Correction of small typos spotted after -03 was posted. 577 o Another attempt at reformatting the table for better readability. 579 o Cleanup of comments used in the XML to keep the editors 580 synchronized. These changes do not affect the text (or other) 581 output forms of the document. 583 o Changed the registration criteria (See Section 2.3) at IESG 584 request. 586 Authors' Addresses 588 John C Klensin 589 1770 Massachusetts Ave, Ste 322 590 Cambridge, MA 02140 591 USA 593 Phone: +1 617 245 1457 594 Email: john+ietf@jck.com 596 Alfred Hoenes 597 TR-Sys 598 Gerlinger Str. 12 599 Ditzingen D-71254 600 Germany 602 Email: ah@TR-Sys.de