idnits 2.17.1 draft-somers-ftp-mfxx-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 734. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 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. (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 31, 2007) is 6108 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) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission D. Somers 3 Internet-Draft July 31, 2007 4 Expires: February 1, 2008 6 The 'MFMT', 'MFCT', and 'MFF' Command Extensions for FTP 7 draft-somers-ftp-mfxx-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 1, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines extensions to the FTP specification STD 9, RFC 41 959, "FILE TRANSFER PROTOCOL (FTP)". These extensions provide the 42 ability for a FTP Client to modify the last modification time, the 43 creation time, or multiple facts (last modification time, creation 44 time, operating system permissions, etc.) of an object in the server- 45 FTP process NVFS. These extensions are implemented by three new 46 optional commands: "MFMT" (Modify Fact: Modification Time), "MFCT" 47 (Modify Fact: Creation Time), and "MFF" (Modify Fact: Facts). 49 Comments 51 Comments are solicited and should be addressed to David Somers 52 (david.somers@bcs.org). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Pathnames . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. Interpreting Examples . . . . . . . . . . . . . . . . . . 5 63 3. Modify Fact: Modification Time (MFMT) . . . . . . . . . . . . 6 64 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Error responses . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. FEAT response for MFMT . . . . . . . . . . . . . . . . . . 7 67 3.3.1. Example FEAT response . . . . . . . . . . . . . . . . 8 68 3.4. MFMT Examples . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Modify Fact: Creation Time (MFCT) . . . . . . . . . . . . . . 9 70 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2. Error responses . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. FEAT response for MFCT . . . . . . . . . . . . . . . . . . 10 73 4.3.1. Example FEAT response . . . . . . . . . . . . . . . . 10 74 4.4. MFCT Examples . . . . . . . . . . . . . . . . . . . . . . 10 75 5. Modify Fact: Facts (MFF) . . . . . . . . . . . . . . . . . . . 11 76 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.2. Standard facts . . . . . . . . . . . . . . . . . . . . . . 12 78 5.2.1. Create fact . . . . . . . . . . . . . . . . . . . . . 12 79 5.2.2. Modify fact . . . . . . . . . . . . . . . . . . . . . 13 80 5.3. Operating System specific facts . . . . . . . . . . . . . 13 81 5.3.1. Example Operating System specific facts . . . . . . . 13 82 5.4. Local/Experimental "X." facts . . . . . . . . . . . . . . 13 83 5.5. Error responses . . . . . . . . . . . . . . . . . . . . . 14 84 5.6. FEAT response for MFF . . . . . . . . . . . . . . . . . . 14 85 5.6.1. Example FEAT responses . . . . . . . . . . . . . . . . 14 86 5.7. MFF Examples . . . . . . . . . . . . . . . . . . . . . . . 15 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 6.1. The OS Specific fact registry . . . . . . . . . . . . . . 17 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 93 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 Intellectual Property and Copyright Statements . . . . . . . . . . 22 97 1. Introduction 99 The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 100 [1], and in place on the Internet allows files to be transferred 101 between a server-FTP and a user-FTP, and vice versa. When a file is 102 transferred from the user-FTP to the server-FTP, the creation time, 103 last modification time, and operating system facts (for example, file 104 permissions) can not be specified. The NVFS typically sets these to 105 default values. 107 This document defines extensions to the File Transfer Protocol, 108 specifically three new optional commands "MFMT", "MFCT", and "MFF". 110 The "MFMT" command allows the last modification time an object in the 111 NVFS to be modified. This is an alternative to abusing "MDTM" (as 112 defined in section 3 of [5]), which was only intended to read the 113 modification time and not to set it as some implementations do. 115 The "MFCT" command allows the creation time an object in the NVFS to 116 be modified. 118 The "MFF" command allows multiple facts of an object in the NVFS to 119 be modified. The "MFF" command is complimentary to the MLSx commands 120 as detailed in [5]. The MLSx commands provides a standardized way of 121 retrieving facts for objects in the NVFS; the MFF command aims to 122 standardize modifying (or setting) the facts for the objects in the 123 NVFS. 125 2. Document Conventions 127 This document makes use of the conventions in [2]. That provides the 128 interpretation of capitalized imperative words like MUST, SHOULD, 129 etc. 131 This document also uses notation defined in [1]. In particular, the 132 terms "reply", "user", "NVFS", "file", "pathname", "FTP commands", 133 "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP 134 process", "server-PI", "server-DTP", "mode", "type", "NVT", "control 135 connection", "data connection", and "ASCII", are all used here as 136 defined there. 138 Syntax required is defined using the Augmented BNF defined in [3]. 139 Some general ABNF definitions are required throughout the document, 140 those will be defined later in this section. At first reading, it 141 may be wise to simply recall that these definitions exist here, and 142 skip to the next section. 144 2.1. Basic Tokens 146 This document defines basic tokens in the same manner as that as 147 specified in section 2.1 of [5]. 149 2.2. Pathnames 151 This document defines pathnames in the same manner as that specified 152 in section 2.2 of [5]. 154 2.3. Times 156 This document defines times in the same manner as that as specified 157 in section 2.3 of [5]. 159 2.4. Server Replies 161 This document defines server replies in the same manner as that 162 specified in section 2.4 of [5]. 164 2.5. Interpreting Examples 166 This document presents examples in the same manner as that specified 167 in section 2.5 of [5]. 169 3. Modify Fact: Modification Time (MFMT) 171 The FTP command, MODIFY FACT: MODIFICATION TIME (MFMT), is used to 172 modify the last modification time of an object in the NVFS. 174 The ability to modify the last modification time MAY also be 175 achieved, if supported by the server-PI, by using the "Modify" fact 176 to the MFF command as detailed in Section 5. 178 It should be noted that similar functionality has been implemented by 179 some server-PIs as the command MDTM. However, the use of MDTM to 180 modify the last modification time of a file conflicts with the use of 181 the MDTM command to retrieve the last modification time of a file as 182 defined in [5]. It is RECOMMENDED that, if possible, client-PIs use 183 the MFMT command instead of abusing the MDTM command to change the 184 modification time of an object in the NVFS. 186 If the client-PI wants to modify both the modification time and the 187 creation time, it is RECOMMENDED that the MFF command, if supported 188 by the server-PI, be used instead. 190 If the NVFS supports the concept of both creation times and 191 modification times, it is RECOMMENDED that server-PI give priority to 192 setting the modification time, even if it means that to set the 193 modification time requested by the client-PI the server-PI must also 194 change the creation time. An example of this prioritization is if 195 the requested modification time is prior to the current creation time 196 and the NVFS does not permit the modification time to be prior to the 197 creation time; the only way to set the modification time in such a 198 situation is for the server-PI to automagically change the creation 199 time to a time before or of the same as the requested modification 200 time. The rationale for this prioritization of modification over 201 creation time is because, generally speaking, it is more important 202 for the modification time to be more valid than the creation time, as 203 the modification time is typically used to perform object 204 synchronization between hosts. 206 3.1. Syntax 208 The syntax of the MFMT command is: 210 mfmt = "MFMT" SP time-val SP pathname CRLF 212 As with all FTP commands, the "MFMT" command label is interpreted in 213 a case insensitive manner. 215 The "time-val" specifies the last modification time to be applied to 216 the object. 218 The "pathname" specifies an object in the NVFS. 220 The server-PI MUST respond to the MFMT command with a 213 reply, or 221 an error response if the object does not exist, the last modification 222 time could not be modified, or some other error has occurred. 224 mfmt-response = "213" SP "Modify=" time-val ";" SP pathname CRLF / 225 error-response 227 The "time-val" in the response MUST be the modified last modification 228 time of the object. This value MAY not be the same as that requested 229 due to constraints of the NVFS to store the last modification time 230 (for example, it may only have sufficient resolution to store the 231 last modification time to the nearest minute instead of to the 232 thousandths of a second that "time-val" MAY be specified to). It is 233 RECOMMENDED that the client-PI parse the 213 response to determine 234 what the modification time was actually modified to by the server-PI. 236 3.2. Error responses 238 Where the command is correctly parsed, but the pathname identifies no 239 existing object, then a 550 reply SHOULD be sent. Where the command 240 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 241 the date or time specified is invalid (for example, February 29 in a 242 non-leap year), then a 501 reply MUST be sent. Various 4xy replies 243 are also possible in appropriate circumstances. 245 3.3. FEAT response for MFMT 247 Where a server-FTP process supports the MFMT command, as specified 248 here, it MUST include the response to the FEAT command [4]: 250 mfmt-feat = SP "MFMT" CRLF 252 The initial space shown in the mfmt-feat response is that required by 253 the FEAT command. 255 This string "MFMT" is not case sensitive, but SHOULD be transmitted 256 in upper case. Where MFMT is not supported, the MFMT line MUST NOT 257 be included in the FEAT response. 259 3.3.1. Example FEAT response 261 C> feat 262 S> 211- <any descriptive text> 263 S> ... 264 S> MFMT 265 S> ... 266 S> 211 end 268 The ellipses indicate place holders where other features may be 269 included, and are not required. The one space indentation of the 270 feature lines is mandatory [4]. 272 3.4. MFMT Examples 274 To modify the last modification time of a file called "Fred.txt" to 275 July 17, 2002 21:07:15, 277 C> MFMT 20020717210715 Fred.txt 278 S> 213 Modify=20020717210715; Fred.txt 280 4. Modify Fact: Creation Time (MFCT) 282 The FTP command, MODIFY FACT: CREATION TIME (MFCT), is used to modify 283 the creation time of an object in the NVFS. 285 The ability to modify the creation time MAY also be achieved, if 286 supported by the server-PI, by using the "Create" fact to the MFF 287 command as detailed in Section 5. 289 If the client-PI wants to modify both the modification time and the 290 creation time, it is RECOMMENDED that the MFF command, if supported 291 by the server-PI, be used instead. 293 4.1. Syntax 295 The syntax of the MFCT command is: 296 mfct = "MFCT" SP time-val SP pathname CRLF 298 As with all FTP commands, the "MFCT" command label is interpreted in 299 a case insensitive manner. 301 The "time-val" specifies the creation time to be applied to the 302 object. 304 The "pathname" specifies an object in the NVFS. 306 The server-PI MUST respond to the MFCT command with a 213 reply, or 307 an error response if the object does not exist, the creation time 308 could not be modified, or some other error has occurred. 310 mfct-response = "213" SP "Create=" time-val ";" SP pathname CRLF / 311 error-response 313 The "time-val" in the response MUST be the modified creation time of 314 the object. This value MAY not be the same as that requested due to 315 constraints of the NVFS to store the creation time (for example, it 316 may only have sufficient resolution to store the creation time to the 317 nearest minute instead of to the thousandths of a second that "time- 318 val" MAY be specified to). It is RECOMMENDED that the client-PI 319 parse the 213 response to determine what the creation time was 320 actually modified to by the server-PI. 322 4.2. Error responses 324 Where the command is correctly parsed, but the pathname identifies no 325 existing object, then a 550 reply SHOULD be sent. Where the command 326 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 327 the date or time specified is invalid (for example, February 29 in a 328 non-leap year), then a 501 reply MUST be sent. Various 4xy replies 329 are also possible in appropriate circumstances. 331 4.3. FEAT response for MFCT 333 Where a server-FTP process supports the MFCT command, as specified 334 here, it MUST include the response to the FEAT command [4]: 336 mfct-feat = SP "MFCT" CRLF 338 The initial space shown in the mfct-feat response is that required by 339 the FEAT command. 341 This string "MFCT" is not case sensitive, but SHOULD be transmitted 342 in upper case. Where MFCT is not supported, the MFCT line MUST NOT 343 be included in the FEAT response. 345 4.3.1. Example FEAT response 347 C> feat 348 S> 211- <any descriptive text> 349 S> ... 350 S> MFCT 351 S> ... 352 S> 211 end 354 The ellipses indicate place holders where other features may be 355 included, and are not required. The one space indentation of the 356 feature lines is mandatory [4]. 358 4.4. MFCT Examples 360 To modify the creation time of a file called "Jim.txt" in the current 361 directory to July 17, 2002 21:22:30, 363 C> MFCT 20020717212230 Jim.txt 364 S> 213 Create=20020717212230; Jim.txt 366 5. Modify Fact: Facts (MFF) 368 The FTP command, MODIFY FACT: FACTS (MFF), is used to modify one or 369 more facts of an object in the NVFS. These facts are attributes such 370 as creation time, last modification time, or operating system 371 specific attributes such as access permissions. 373 The MFF command is complimentary to the MLSx commands as detailed in 374 [5]. The MLSx commands provides a standardized way of retrieving 375 facts for objects in the NVFS; the MFF command aims to standardize 376 modifying (or setting) the facts for the objects in the NVFS. The 377 format of facts is identical to that specified in [5]. 379 If the client-PI wants to modify only the modification time or only 380 the creation time, it is RECOMMENDED that the MFCT (see Section 4) or 381 MFMT (see Section 3) commands , if supported by the server-PI, be 382 used respectively instead of the MFF command. 384 It MAY be possible for a client to attempt to set the modification 385 time prior to the creation time; this situation may be nonsensical, 386 but it may be necessary, and it is RECOMMENDED that it not be 387 considered an error by the server-PI. If necessary, the server-PI 388 SHOULD prioritise modifying the modification time, even if that means 389 automagically changing the modification time (due to NVFS 390 restrictions). 392 5.1. Syntax 394 The syntax of the MFF command is: 396 mff = "MFF" [ mff-facts ] SP pathname CRLF 397 mff-facts = 1*( mff-fact ";" ) 398 mff-fact = mff-standardfact / mff-osfact / mff-localfact 399 mff-standardfact = mff-createtimefact / mff-modifytimefact 400 mff-createtimefact = "Create" "=" time-val 401 mff-modifytimefact = "Modify" "=" time-val 402 mff-osfact = <IANA assigned OS name> "." token "=" *SCHAR 403 mff-localfact = "X." token "=" *SCHAR 405 As with all FTP commands, the "MFF" command label is interpreted in a 406 case insensitive manner. 408 The "mff-facts" are a series of facts as keyword=value pairs each 409 separated by a semi-colon (";") character. Fact keyword names are 410 case-insensitive. 412 The "pathname" specifies an object in the NVFS. 414 The server-PI MUST respond to the MFF command with a 213 reply 415 containing a list of the facts that MUST detail the values actually 416 set for all the facts specified in the request (which MAY differ from 417 that requested), or an error response. 419 mff-response = "213" SP 1*( mff-fact ";") SP pathname CRLF / 420 error-response 422 The order of the "mff-fact" keyword=value pairs returned in the 423 response MAY be in any order. 425 The "time-val" in the response MAY not be the same as that requested 426 due to constraints of the NVFS to store such times (for example, it 427 may only have sufficient resolution to store the last modification 428 time to the nearest minute instead of to the thousandths of a second 429 that "time-val" MAY be specified to). 431 The error response MUST be returned if any of the following 432 conditions happen: 434 o The object does not exist. 436 o A fact could not be modified, for example due to insufficient 437 access control permissions. 439 o An unknown fact was specified. 441 When an error response is returned, the client-PI MUST make no 442 assumptions about which, if any, facts have been modified. In other 443 words, modifying facts is not an atomic operation. The client-PI can 444 issue an MLST (if the server-PI supports the MLST command) to 445 determine what attributes have, in fact, been modified. 447 5.2. Standard facts 449 This document defines the following standard facts for use by MFF: 451 o Create 453 o Modify 455 5.2.1. Create fact 457 The "Create" fact is used to modify the creation time of the object 458 specified by "pathname". 460 Note that this is the same fact that can be read using the MLST and 461 MLSD commands in [5], and is detailed in see section 7.5.4 of the 462 aforementioned document. 464 5.2.2. Modify fact 466 The "Modify" fact is used to modify the last modification time of the 467 object specified by "pathname". 469 Note that this is the same fact that can be read using the MLST and 470 MLSD commands in [5], and is detailed in see section 7.5.3 of the 471 aforementioned document. 473 5.3. Operating System specific facts 475 Facts that are specific to an operating system, or file system, 476 SHOULD be specified by keywords that are prefixed by an IANA 477 operating system name 478 (). 480 Implementation Note: It is envisioned that the operating system 481 specific facts will be identical to those used by the MLSx command as 482 detailed in [5]; implementers can then use the same logic to process 483 facts whether for MLSx or MFF. 485 The specification of Operating Systems specific facts is explicitly 486 outside the scope of this document. Such specifications SHOULD be 487 documented elsewhere (that is, in an internet draft, RFC, etc.) 489 5.3.1. Example Operating System specific facts 491 The following examples are only indicative of how it is anticipated 492 that some Operating System specific facts could be implemented. 494 UNIX.mode -- Unix file mode (in octal) 495 UNIX.owner -- Unix owner (as a decimal Uid or a username) 496 UNIX.group -- Unix group (as a decimal Gid or a groupname) 497 WINDOWS-NT.SIS.Author -- Windows NT, 498 Summary Information Stream, Author property 500 5.4. Local/Experimental "X." facts 502 Implementations may define keywords for experimental, or private, 503 use. All such keywords MUST begin with the two character sequence 504 "X.". As fact names are case-insensitive, "X." and "x." are 505 equivalent. 507 5.5. Error responses 509 Where the command is correctly parsed, but the pathname identifies no 510 existing object, then a 550 reply SHOULD be sent. Where the command 511 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 512 the date or time specified for a Create or Modify fact is invalid 513 (for example, February 29 in a non-leap year), then a 501 reply MUST 514 be sent. If an unknown fact is provided, a 504 reply SHOULD be sent, 515 and it is RECOMMENDED that the 504 reply indicate the name(s) of the 516 unknown fact(s). Various 4xy replies are also possible in 517 appropriate circumstances. 519 5.6. FEAT response for MFF 521 Where a server-FTP process supports the MFF command, as specified 522 here, it MUST include in the response to the FEAT command [4], a 523 feature line containing the string "MFF". This string is not case 524 sensitive, but SHOULD be transmitted in upper case. As well as 525 indicating MFF support, the MFF feature line indicates, as a semi- 526 colon delimited list, which MFF facts are available for modification 527 by the server-FTP process. Where MFF is not supported, the MFF line 528 MUST NOT be included in the FEAT response. 530 mff-feat = SP "MFF" SP factlist CRLF 531 factlist = 1*( factname ";" ) 533 The initial space shown in the mff-feat response is that required by 534 the FEAT command. 536 5.6.1. Example FEAT responses 538 C> feat 539 S> 211- <any descriptive text> 540 S> ... 541 S> MFF Modify; 542 S> ... 543 S> 211 end 545 This server-FTP process indicates that it supports the MFF command, 546 and only supports modification of the last modification time of an 547 object in the NVFS. 549 C> feat 550 S> 211- <any descriptive text> 551 S> ... 552 S> MFF Create;Modify;WINDOWS-NT.SIS.Author; 553 S> ... 554 S> 211 end 555 This server-FTP process indicates that it supports the MFF command, 556 and supports modification of the creation time, last modification 557 time, and an operating system specific fact called "WINDOWS- 558 NT.SIS.Author" of an object in the NVFS. Note that the "WINDOWS- 559 NT.SIS.Author" fact is an example of what could be possible - not 560 what is possible; such a fact may exist, but its definition is 561 outside the scope of this document. 563 The ellipses indicate place holders where other features may be 564 included, and are not required. The one space indentation of the 565 feature lines is mandatory [4]. 567 5.7. MFF Examples 569 Note that some of these examples refer to the UNIX.mode fact; whether 570 such a fact exists or not is outside the scope of this document, and 571 is used below only to show what could be possible and not what is 572 possible. 574 To modify the creation time of a file called "Sheila.txt" to July 17, 575 2002 21:22:30, 577 C> MFF Create=20020717212230; Sheila.txt 578 S> 213 Create=20020717212230; Sheila.txt 580 Note that the above could also be achieved using the MFCT command, 581 thus: 583 C> MFCT 20020717212230 Sheila.txt 584 S> 213 Create=20020717212230; Sheila.txt 586 To modify the permissions on a Unix-based NVFS for the file called 587 "Bob.txt" to (octal) 777, 589 C> MFF UNIX.mode=777; Bob.txt 590 S> 213 UNIX.mode=777; Bob.txt 592 To modify the permissions on a Unix-based NVFS for the file called 593 "Fred.txt" to (octal) 777, and the creation time to July 18, 2002 01: 594 28:45, 596 C> MFF UNIX.mode=777;Create=20020718012845; Fred.txt 597 S> 213 Create=20020718012845;UNIX.mode=777; Fred.txt 599 If the same request was made to a server-FTP process that does not 600 support the UNIX.mode fact, 602 C> MFF UNIX.mode=777;Create=20020718012845; Fred.txt 603 S> 504 Parameter Not Implemented (UNIX.mode) 605 The creation time may or may not have been modified by the server-PI 606 before the server-PI determined that the UNIX.mode fact was not 607 implemented. 609 6. IANA Considerations 611 This specification makes use of some lists of values currently 612 maintained by the IANA. It does not add any values to any existing 613 registries. 615 6.1. The OS Specific fact registry 617 The MFF command reuses the OS Specific fact registry that is used by 618 the MLSx commands as detailed in [5] 620 The OS names for the OS portion of the fact name must be taken from 621 the IANA's list of registered OS names. To add a fact name to this 622 OS specific registry of OS specific facts, an applicant must send to 623 the IANA a request, in which is specified the OS name, the OS 624 specific fact name, a definition of the syntax of the fact value, 625 which must conform to the syntax of a token as given in this 626 document, and a specification of the semantics to be associated with 627 the particular fact and its values. Upon receipt of such an 628 application, and if the combination of OS name and OS specific fact 629 name has not been previously defined, the IANA will add the 630 specification to the registry. 632 Any examples of OS specific facts found in this document are to be 633 treated as examples of possible OS specific facts, and do not form a 634 part of the IANA's registry merely because of being included in this 635 document. 637 7. Security Considerations 639 No significant security issues, not already present in the FTP 640 protocol, are believed to have been created by this extension. 642 A general discussion of issues related to the security of FTP can be 643 found in [6]. 645 8. References 647 8.1. Normative References 649 [1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 650 RFC 959, October 1985. 652 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 653 Levels", BCP 14, RFC 2119, March 1997. 655 [3] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 656 RFC 2234, November 1997. 658 [4] Hethmon, P., "Feature negotiation mechanism for the File 659 Transfer Protocol", RFC 2389, August 1998. 661 [5] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 663 8.2. Informative References 665 [6] Allman, M. and S. Ostermann, "FTP Security Considerations", 666 RFC 2577, May 1999. 668 URIs 670 [7] 672 Appendix A. Acknowledgements 674 Thank you to the authors and editors of [5] for the facts in their 675 MLSx command which have been hijacked (in the nicest possible way) by 676 the MFF command herein. 678 A big thanks to xml2rfc [7] which greatly aided in the production of 679 this document. 681 Many thanks to all who commented on drafts of this document and 682 helped clarify and improve it, and an even bigger thanks to those who 683 have implemented or who intend to implement the FTP commands 684 presented in this document. 686 Author's Address 688 David M. P. Somers 689 Tunnelstrooss 36 690 Lipperscheid 9164 691 LU 693 Email: dsomers@omz13.com 694 URI: http://www.omz13.com/ftp-mfxx 696 Full Copyright Statement 698 Copyright (C) The IETF Trust (2007). 700 This document is subject to the rights, licenses and restrictions 701 contained in BCP 78, and except as set forth therein, the authors 702 retain all their rights. 704 This document and the information contained herein are provided on an 705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 707 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 708 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 709 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Intellectual Property 714 The IETF takes no position regarding the validity or scope of any 715 Intellectual Property Rights or other rights that might be claimed to 716 pertain to the implementation or use of the technology described in 717 this document or the extent to which any license under such rights 718 might or might not be available; nor does it represent that it has 719 made any independent effort to identify any such rights. Information 720 on the procedures with respect to rights in RFC documents can be 721 found in BCP 78 and BCP 79. 723 Copies of IPR disclosures made to the IETF Secretariat and any 724 assurances of licenses to be made available, or the result of an 725 attempt made to obtain a general license or permission for the use of 726 such proprietary rights by implementers or users of this 727 specification can be obtained from the IETF on-line IPR repository at 728 http://www.ietf.org/ipr. 730 The IETF invites any interested party to bring to its attention any 731 copyrights, patents or patent applications, or other proprietary 732 rights that may cover technology that may be required to implement 733 this standard. Please address the information to the IETF at 734 ietf-ipr@ietf.org. 736 Acknowledgment 738 Funding for the RFC Editor function is provided by the IETF 739 Administrative Support Activity (IASA).