idnits 2.17.1 draft-somers-ftp-mfxx-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 733. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (July 28, 2008) is 5750 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission D. Somers 3 Internet-Draft July 28, 2008 4 Updates: 959 (if approved) 5 Intended status: Experimental 6 Expires: January 29, 2009 8 The "MFMT", "MFCT", and "MFF" Command Extensions for FTP 9 draft-somers-ftp-mfxx-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 29, 2009. 36 Abstract 38 This document defines extensions to the FTP specification STD 9, RFC 39 959, "FILE TRANSFER PROTOCOL (FTP)". These extensions provide the 40 ability for a FTP Client to modify the last modification time, the 41 creation time, or multiple facts (last modification time, creation 42 time, operating system permissions, etc.) of an object in the server- 43 FTP process NVFS. These extensions are implemented by three new 44 optional commands: "MFMT" (Modify Fact: Modification Time), "MFCT" 45 (Modify Fact: Creation Time), and "MFF" (Modify Fact: Facts). 47 Comments 49 Comments are solicited and should be addressed to David Somers 50 (dsomers@omz13.com). 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Pathnames . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . . 5 60 2.5. Interpreting Examples . . . . . . . . . . . . . . . . . . 5 61 3. Modify Fact: Modification Time (MFMT) . . . . . . . . . . . . 6 62 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Error responses . . . . . . . . . . . . . . . . . . . . . 7 64 3.3. FEAT response for MFMT . . . . . . . . . . . . . . . . . . 7 65 3.3.1. Example FEAT response . . . . . . . . . . . . . . . . 8 66 3.4. MFMT Examples . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Modify Fact: Creation Time (MFCT) . . . . . . . . . . . . . . 9 68 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. Error responses . . . . . . . . . . . . . . . . . . . . . 9 70 4.3. FEAT response for MFCT . . . . . . . . . . . . . . . . . . 10 71 4.3.1. Example FEAT response . . . . . . . . . . . . . . . . 10 72 4.4. MFCT Examples . . . . . . . . . . . . . . . . . . . . . . 10 73 5. Modify Fact: Facts (MFF) . . . . . . . . . . . . . . . . . . . 11 74 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.2. Standard facts . . . . . . . . . . . . . . . . . . . . . . 12 76 5.2.1. Create fact . . . . . . . . . . . . . . . . . . . . . 12 77 5.2.2. Modify fact . . . . . . . . . . . . . . . . . . . . . 13 78 5.3. Operating System specific facts . . . . . . . . . . . . . 13 79 5.3.1. Example Operating System specific facts . . . . . . . 13 80 5.4. Local/Experimental "X." facts . . . . . . . . . . . . . . 13 81 5.5. Error responses . . . . . . . . . . . . . . . . . . . . . 13 82 5.6. FEAT response for MFF . . . . . . . . . . . . . . . . . . 14 83 5.6.1. Example FEAT responses . . . . . . . . . . . . . . . . 14 84 5.7. MFF Examples . . . . . . . . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 6.1. The OS Specific fact registry . . . . . . . . . . . . . . 17 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 Intellectual Property and Copyright Statements . . . . . . . . . . 23 95 1. Introduction 97 The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 98 [1], and in place on the Internet allows files to be transferred 99 between a server-FTP and a user-FTP, and vice versa. When a file is 100 transferred from the user-FTP to the server-FTP, the creation time, 101 last modification time, and operating system facts (for example, file 102 permissions) can not be specified. The NVFS typically sets these to 103 default values. 105 This document defines extensions to the File Transfer Protocol, 106 specifically three new optional commands: "MFMT", "MFCT", and "MFF". 108 The "MFMT" command allows the last modification time an object in the 109 NVFS to be modified. This is an alternative to abusing "MDTM" (as 110 defined in section 3 of [2]), which was only intended to read the 111 modification time and not to set it as some implementations do. 113 The "MFCT" command allows the creation time an object in the NVFS to 114 be modified. 116 The "MFF" command allows multiple facts of an object in the NVFS to 117 be modified. The MFF command is complimentary to the MLSx commands 118 as detailed in [2]. The MLSx commands provides a standardized way of 119 retrieving facts for objects in the NVFS; the MFF command aims to 120 standardize modifying (or setting) the facts for the objects in the 121 NVFS. 123 2. Document Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [3]." 129 This document also uses notation defined in [1]. In particular, the 130 terms "reply", "user", "NVFS", "file", "pathname", "FTP commands", 131 "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP 132 process", "server-PI", "server-DTP", "mode", "type", "NVT", "control 133 connection", "data connection", and "ASCII", are all used here as 134 defined there. 136 Syntax required is defined using the Augmented BNF defined in [4]. 137 Some general ABNF definitions are required throughout the document, 138 those will be defined later in this section. At first reading, it 139 may be wise to simply recall that these definitions exist here, and 140 skip to the next section. 142 2.1. Basic Tokens 144 This document defines basic tokens in the same manner as that as 145 specified in section 2.1 of [2]. 147 2.2. Pathnames 149 This document defines pathnames in the same manner as that specified 150 in section 2.2 of [2]. 152 2.3. Times 154 This document defines times in the same manner as that as specified 155 in section 2.3 of [2]. 157 2.4. Server Replies 159 This document defines server replies in the same manner as that 160 specified in section 2.4 of [2]. 162 2.5. Interpreting Examples 164 This document presents examples in the same manner as that specified 165 in section 2.5 of [2]. 167 3. Modify Fact: Modification Time (MFMT) 169 The FTP command, MODIFY FACT: MODIFICATION TIME (MFMT), is used to 170 modify the last modification time of an object in the NVFS. 172 The ability to modify the last modification time MAY also be 173 achieved, if supported by the server-PI, by using the "Modify" fact 174 to the MFF command as detailed in Section 5. 176 It should be noted that similar functionality has been implemented by 177 some server-PIs as the command MDTM. However, the use of MDTM to 178 modify the last modification time of an object conflicts with the use 179 of the MDTM command to retrieve the last modification time of an 180 object as defined in [2]. It is RECOMMENDED that, if possible, 181 client-PIs use the MFMT command instead of abusing the MDTM command 182 to change the modification time of an object in the NVFS. 184 If the client-PI wants to modify both the modification time and the 185 creation time, it is RECOMMENDED that the MFF command, if supported 186 by the server-PI, be used instead. 188 If the NVFS supports the concept of both creation times and 189 modification times, it is RECOMMENDED that server-PI give priority to 190 setting the modification time, even if it means that to set the 191 modification time requested by the client-PI the server-PI must also 192 change the creation time. An example of this prioritization is if 193 the requested modification time is prior to the current creation time 194 and the NVFS does not permit the modification time to be prior to the 195 creation time; the only way to set the modification time in such a 196 situation is for the server-PI to automagically change the creation 197 time to a time before or of the same as the requested modification 198 time. The rationale for this prioritization of modification over 199 creation time is because, generally speaking, it is more important 200 for the modification time to be more valid than the creation time as 201 the modification time is typically used to perform object 202 synchronization between hosts. 204 3.1. Syntax 206 The syntax of the MFMT command is: 208 mfmt = "MFMT" SP time-val SP pathname CRLF 210 As with all FTP commands, the "MFMT" command label is interpreted in 211 a case insensitive manner. 213 The "time-val" specifies the last modification time to be applied to 214 the object. 216 The "pathname" specifies an object in the NVFS. 218 The server-PI MUST respond to the MFMT command with a 213 reply, or 219 an error response if the object does not exist, the last modification 220 time could not be modified, or some other error has occurred. 222 mfmt-response = "213" SP "Modify=" time-val ";" SP pathname CRLF / 223 error-response 225 The "time-val" in the response MUST be the modified last modification 226 time of the object. This value MAY not be the same as that requested 227 due to constraints of the NVFS to store the last modification time 228 (for example, it may only have sufficient resolution to store the 229 last modification time to the nearest minute instead of to the 230 thousandths of a second that "time-val" MAY be specified to). It is 231 RECOMMENDED that the client-PI parse the 213 response to determine 232 what the modification time was actually modified to by the server-PI. 234 3.2. Error responses 236 Where the command is correctly parsed, but the pathname identifies no 237 existing object, then a 550 reply SHOULD be sent. Where the command 238 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 239 the date or time specified is invalid (for example, February 29 in a 240 non-leap year), then a 501 reply MUST be sent. Various 4xy replies 241 are also possible in appropriate circumstances. 243 3.3. FEAT response for MFMT 245 Where a server-FTP process supports the MFMT command, as specified 246 here, it MUST include the response to the FEAT command [5]: 248 mfmt-feat = SP "MFMT" CRLF 250 The initial space shown in the mfmt-feat response is that required by 251 the FEAT command. 253 This string "MFMT" is not case sensitive, but SHOULD be transmitted 254 in upper case. Where MFMT is not supported, the MFMT line MUST NOT 255 be included in the FEAT response. 257 3.3.1. Example FEAT response 259 C> feat 260 S> 211- 261 S> ... 262 S> MFMT 263 S> ... 264 S> 211 end 266 The ellipses indicate place holders where other features may be 267 included, and are not required. The one space indentation of the 268 feature lines is mandatory [5]. 270 3.4. MFMT Examples 272 To modify the last modification time of a file called "Fred.txt" to 273 July 17, 2002 21:07:15, 275 C> MFMT 20020717210715 Fred.txt 276 S> 213 Modify=20020717210715; Fred.txt 278 4. Modify Fact: Creation Time (MFCT) 280 The FTP command, MODIFY FACT: CREATION TIME (MFCT), is used to modify 281 the creation time of an object in the NVFS. 283 The ability to modify the creation time MAY also be achieved, if 284 supported by the server-PI, by using the "Create" fact to the MFF 285 command as detailed in Section 5. 287 If the client-PI wants to modify both the modification time and the 288 creation time, it is RECOMMENDED that the MFF command, if supported 289 by the server-PI, be used instead. 291 4.1. Syntax 293 The syntax of the MFCT command is: 294 mfct = "MFCT" SP time-val SP pathname CRLF 296 As with all FTP commands, the "MFCT" command label is interpreted in 297 a case insensitive manner. 299 The "time-val" specifies the creation time to be applied to the 300 object. 302 The "pathname" specifies an object in the NVFS. 304 The server-PI MUST respond to the MFCT command with a 213 reply, or 305 an error response if the object does not exist, the creation time 306 could not be modified, or some other error has occurred. 308 mfct-response = "213" SP "Create=" time-val ";" SP pathname CRLF / 309 error-response 311 The "time-val" in the response MUST be the modified creation time of 312 the object. This value MAY not be the same as that requested due to 313 constraints of the NVFS to store the creation time (for example, it 314 may only have sufficient resolution to store the creation time to the 315 nearest minute instead of to the thousandths of a second that "time- 316 val" MAY be specified to). It is RECOMMENDED that the client-PI 317 parse the 213 response to determine what the creation time was 318 actually modified to by the server-PI. 320 4.2. Error responses 322 Where the command is correctly parsed, but the pathname identifies no 323 existing object, then a 550 reply SHOULD be sent. Where the command 324 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 325 the date or time specified is invalid (for example, February 29 in a 326 non-leap year), then a 501 reply MUST be sent. Various 4xy replies 327 are also possible in appropriate circumstances. 329 4.3. FEAT response for MFCT 331 Where a server-FTP process supports the MFCT command, as specified 332 here, it MUST include the response to the FEAT command [5]: 334 mfct-feat = SP "MFCT" CRLF 336 The initial space shown in the mfct-feat response is that required by 337 the FEAT command. 339 This string "MFCT" is not case sensitive, but SHOULD be transmitted 340 in upper case. Where MFCT is not supported, the MFCT line MUST NOT 341 be included in the FEAT response. 343 4.3.1. Example FEAT response 345 C> feat 346 S> 211- 347 S> ... 348 S> MFCT 349 S> ... 350 S> 211 end 352 The ellipses indicate place holders where other features may be 353 included, and are not required. The one space indentation of the 354 feature lines is mandatory [5]. 356 4.4. MFCT Examples 358 To modify the creation time of a file called "Jim.txt" in the current 359 directory to July 17, 2002 21:22:30, 361 C> MFCT 20020717212230 Jim.txt 362 S> 213 Create=20020717212230; Jim.txt 364 5. Modify Fact: Facts (MFF) 366 The FTP command, MODIFY FACT: FACTS (MFF), is used to modify one or 367 more facts of an object in the NVFS. These facts are attributes such 368 as creation time, last modification time, or operating system 369 specific attributes such as access permissions. 371 The MFF command is complimentary to the MLSx commands as detailed in 372 [2]. The MLSx commands provides a standardized way of retrieving 373 facts for objects in the NVFS; the MFF command aims to standardize 374 modifying (or setting) the facts for the objects in the NVFS. The 375 format of facts is identical to that specified in [2]. 377 If the client-PI wants to modify only the modification time or only 378 the creation time, it is RECOMMENDED that the MFCT (see Section 4) or 379 MFMT (see Section 3) commands, if supported by the server-PI, be used 380 respectively instead of the MFF command. 382 It MAY be possible for a client to attempt to set the modification 383 time prior to the creation time; this situation may be nonsensical, 384 but it may be necessary, and it is RECOMMENDED that it not be 385 considered an error by the server-PI. If necessary, the server-PI 386 SHOULD prioritize modifying the modification time, even if that means 387 automagically changing the creation time (due to, for example, NVFS 388 restrictions). 390 5.1. Syntax 392 The syntax of the MFF command is: 394 mff = "MFF" [ mff-facts ] SP pathname CRLF 395 mff-facts = 1*( mff-fact ";" ) 396 mff-fact = mff-standardfact / mff-osfact / mff-localfact 397 mff-standardfact = mff-create-fact / mff-modify-fact 398 mff-create-fact = "Create" "=" time-val 399 mff-modify-fact = "Modify" "=" time-val 400 mff-osfact = "." token "=" *SCHAR 401 mff-localfact = "X." token "=" *SCHAR 403 As with all FTP commands, the "MFF" command label is interpreted in a 404 case insensitive manner. 406 The "mff-facts" are a series of facts as keyword=value pairs each 407 separated by a semi-colon (";") character. Fact keyword names are 408 case-insensitive. 410 The "pathname" specifies an object in the NVFS. 412 The server-PI MUST respond to the MFF command with a 213 reply 413 containing a list of the facts that MUST detail the values actually 414 set for all the facts specified in the request (which MAY differ from 415 that requested), or an error response. 417 mff-response = "213" SP 1*( mff-fact ";") SP pathname CRLF / 418 error-response 420 The order of the "mff-fact" keyword=value pairs returned in the 421 response MAY be in any order. 423 The "time-val" in the response MAY not be the same as that requested 424 due to constraints of the NVFS to store such times (for example, it 425 may only have sufficient resolution to store the last modification 426 time to the nearest minute instead of to the thousandths of a second 427 that "time-val" MAY be specified to). 429 The error response MUST be returned if any of the following 430 conditions happen: 432 o The object does not exist. 434 o A fact could not be modified, for example due to insufficient 435 access control permissions. 437 o An unknown fact was specified. 439 When an error response is returned, the client-PI MUST make no 440 assumptions about which, if any, facts have been modified. In other 441 words, modifying facts is not an atomic operation. The client-PI can 442 issue an MLST (if the server-PI supports the MLST command) to 443 determine what attributes have, in fact, been modified. 445 5.2. Standard facts 447 This document defines the following standard facts for use by MFF: 449 o Create 451 o Modify 453 5.2.1. Create fact 455 The "Create" fact is used to modify the creation time of the object 456 specified by "pathname". 458 Note that this is the same fact that can be read using the MLST and 459 MLSD commands in [2], and is detailed in see section 7.5.4 of the 460 aforementioned document. 462 5.2.2. Modify fact 464 The "Modify" fact is used to modify the last modification time of the 465 object specified by "pathname". 467 Note that this is the same fact that can be read using the MLST and 468 MLSD commands in [2], and is detailed in see section 7.5.3 of the 469 aforementioned document. 471 5.3. Operating System specific facts 473 Facts that are specific to an operating system, or file system, 474 SHOULD be specified by keywords that are prefixed by an IANA 475 operating system name [7]. 477 Implementation Note: It is envisioned that the operating system 478 specific facts will be identical to those used by the MLSx command as 479 detailed in [2]; implementers can then use the same logic to process 480 facts whether for MLSx or MFF. 482 The specification of Operating Systems specific facts is explicitly 483 outside the scope of this document. Such specifications SHOULD be 484 documented elsewhere (that is, in an internet draft, RFC, etc.) 486 5.3.1. Example Operating System specific facts 488 The following examples are only indicative of how it is anticipated 489 that some Operating System specific facts could be implemented. 491 UNIX.mode -- Unix file mode (in octal) 492 UNIX.owner -- Unix owner (as a decimal Uid or a username) 493 UNIX.group -- Unix group (as a decimal Gid or a groupname) 494 WINDOWS-NT.SIS.Author -- Windows NT, 495 Summary Information Stream, Author property 497 5.4. Local/Experimental "X." facts 499 Implementations may define keywords for experimental, or private, 500 use. All such keywords MUST begin with the two character sequence 501 "X.". As fact names are case-insensitive, "X." and "x." are 502 equivalent. 504 5.5. Error responses 506 Where the command is correctly parsed, but the pathname identifies no 507 existing object, then a 550 reply SHOULD be sent. Where the command 508 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 509 the date or time specified for a Create or Modify fact is invalid 510 (for example, February 29 in a non-leap year), then a 501 reply MUST 511 be sent. If an unknown fact is provided, a 504 reply SHOULD be sent, 512 and it is RECOMMENDED that the 504 reply indicate the name(s) of the 513 unknown fact(s). Various 4xy replies are also possible in 514 appropriate circumstances. 516 5.6. FEAT response for MFF 518 Where a server-FTP process supports the MFF command, as specified 519 here, it MUST include in the response to the FEAT command [5], a 520 feature line containing the string "MFF". This string is not case 521 sensitive, but SHOULD be transmitted in upper case. As well as 522 indicating MFF support, the MFF feature line indicates, as a semi- 523 colon delimited list, which MFF facts are available for modification 524 by the server-FTP process. Where MFF is not supported, the MFF line 525 MUST NOT be included in the FEAT response. 527 mff-feat = SP "MFF" SP factlist CRLF 528 factlist = 1*( factname ";" ) 530 The initial space shown in the mff-feat response is that required by 531 the FEAT command. 533 5.6.1. Example FEAT responses 535 C> feat 536 S> 211- 537 S> ... 538 S> MFF Modify; 539 S> ... 540 S> 211 end 542 This server-FTP process indicates that it supports the MFF command, 543 and only supports modification of the modify fact of an object in the 544 NVFS. 546 C> feat 547 S> 211- 548 S> ... 549 S> MFF Create;Modify;WINDOWS-NT.SIS.Author; 550 S> ... 551 S> 211 end 553 This server-FTP process indicates that it supports the MFF command, 554 and supports modification of the create fact, modify fact, and an 555 operating system specific fact called "WINDOWS-NT.SIS.Author" of an 556 object in the NVFS. Note that the "WINDOWS-NT.SIS.Author" fact is an 557 example of what could be possible, not what is possible; such a fact 558 may exist, but its definition is outside the scope of this document. 560 The ellipses indicate place holders where other features may be 561 included, and are not required. The one space indentation of the 562 feature lines is mandatory [5]. 564 5.7. MFF Examples 566 Note that some of these examples refer to the UNIX.mode fact; whether 567 such a fact exists or not is outside the scope of this document, and 568 is used below only to show what could be possible and not what is 569 possible. 571 To modify the creation time of a file called "Sheila.txt" to July 17, 572 2002 21:22:30, 574 C> MFF Create=20020717212230; Sheila.txt 575 S> 213 Create=20020717212230; Sheila.txt 577 Note that the above could also be achieved using the MFCT command, 578 thus: 580 C> MFCT 20020717212230 Sheila.txt 581 S> 213 Create=20020717212230; Sheila.txt 583 To modify the permissions on a Unix-based NVFS for the file called 584 "Bob.txt" to (octal) 777, 586 C> MFF UNIX.mode=777; Bob.txt 587 S> 213 UNIX.mode=777; Bob.txt 589 To modify the permissions on a Unix-based NVFS for the file called 590 "Fred.txt" to (octal) 777, and the creation time to July 18, 2002 01: 591 28:45, 593 C> MFF UNIX.mode=777;Create=20020718012845; Fred.txt 594 S> 213 Create=20020718012845;UNIX.mode=777; Fred.txt 596 If the same request was made to a server-FTP process that does not 597 support the UNIX.mode fact, 599 C> MFF UNIX.mode=777;Create=20020718012845; Fred.txt 600 S> 504 Parameter Not Implemented (UNIX.mode) 602 The creation time may or may not have been modified by the server-PI 603 before the server-PI determined that the UNIX.mode fact was not 604 implemented. 606 6. IANA Considerations 608 This specification makes use of some lists of values currently 609 maintained by the IANA. It does not add any values to any existing 610 registries. 612 6.1. The OS Specific fact registry 614 The MFF command reuses the OS Specific fact registry that is used by 615 the MLSx commands as detailed in [2] 617 The OS names for the OS portion of the fact name must be taken from 618 the IANA's list of registered OS names. To add a fact name to this 619 OS specific registry of OS specific facts, an applicant must send to 620 the IANA a request, in which is specified the OS name, the OS 621 specific fact name, a definition of the syntax of the fact value, 622 which must conform to the syntax of a token as given in this 623 document, and a specification of the semantics to be associated with 624 the particular fact and its values. Upon receipt of such an 625 application, and if the combination of OS name and OS specific fact 626 name has not been previously defined, the IANA will add the 627 specification to the registry. 629 Any examples of OS specific facts found in this document are to be 630 treated as examples of possible OS specific facts, and do not form a 631 part of the IANA's registry merely because of being included in this 632 document. 634 7. Security Considerations 636 No significant security issues, not already present in the FTP 637 protocol, are believed to have been created by this extension. 639 A general discussion of issues related to the security of FTP can be 640 found in [6]. 642 8. References 644 8.1. Normative References 646 [1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 647 RFC 959, October 1985. 649 [2] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 651 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 652 Levels", BCP 14, RFC 2119, March 1997. 654 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 655 Specifications: ABNF", RFC 4234, October 2005. 657 [5] Hethmon, P., "Feature negotiation mechanism for the File 658 Transfer Protocol", RFC 2389, August 1998. 660 8.2. Informative References 662 [6] Allman, M. and S. Ostermann, "FTP Security Considerations", 663 RFC 2577, May 1999. 665 URIs 667 [7] 669 [8] 671 Appendix A. Acknowledgements 673 Thank you to the authors and editors of [2] for the facts in their 674 MLSx command which have been hijacked (in the nicest possible way) by 675 the MFF command herein. 677 A big thanks to xml2rfc [8] which greatly aided in the production of 678 this document. 680 Finally, many thanks to all who commented on drafts of this document 681 and helped clarify and improve it, and an even bigger thanks to those 682 who have implemented or who intend to implement the FTP commands 683 presented in this document. 685 Author's Address 687 David M. P. Somers 688 Tunnelstrooss 36 689 Lipperscheid 9164 690 LU 692 Email: dsomers@omz13.com 693 URI: http://www.omz13.com/ftp-mfxx 695 Full Copyright Statement 697 Copyright (C) The IETF Trust (2008). 699 This document is subject to the rights, licenses and restrictions 700 contained in BCP 78, and except as set forth therein, the authors 701 retain all their rights. 703 This document and the information contained herein are provided on an 704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 706 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 707 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 708 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Intellectual Property 713 The IETF takes no position regarding the validity or scope of any 714 Intellectual Property Rights or other rights that might be claimed to 715 pertain to the implementation or use of the technology described in 716 this document or the extent to which any license under such rights 717 might or might not be available; nor does it represent that it has 718 made any independent effort to identify any such rights. Information 719 on the procedures with respect to rights in RFC documents can be 720 found in BCP 78 and BCP 79. 722 Copies of IPR disclosures made to the IETF Secretariat and any 723 assurances of licenses to be made available, or the result of an 724 attempt made to obtain a general license or permission for the use of 725 such proprietary rights by implementers or users of this 726 specification can be obtained from the IETF on-line IPR repository at 727 http://www.ietf.org/ipr. 729 The IETF invites any interested party to bring to its attention any 730 copyrights, patents or patent applications, or other proprietary 731 rights that may cover technology that may be required to implement 732 this standard. Please address the information to the IETF at 733 ietf-ipr@ietf.org.