idnits 2.17.1 draft-somers-ftp-mfxx-03.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 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 737. 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 (August 3, 2007) is 6105 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 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 August 3, 2007 4 Updates: 959 (if approved) 5 Intended status: Standards Track 6 Expires: February 4, 2008 8 The "MFMT", "MFCT", and "MFF" Command Extensions for FTP 9 draft-somers-ftp-mfxx-03 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 February 4, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines extensions to the FTP specification STD 9, RFC 43 959, "FILE TRANSFER PROTOCOL (FTP)". These extensions provide the 44 ability for a FTP Client to modify the last modification time, the 45 creation time, or multiple facts (last modification time, creation 46 time, operating system permissions, etc.) of an object in the server- 47 FTP process NVFS. These extensions are implemented by three new 48 optional commands: "MFMT" (Modify Fact: Modification Time), "MFCT" 49 (Modify Fact: Creation Time), and "MFF" (Modify Fact: Facts). 51 Comments 53 Comments are solicited and should be addressed to David Somers 54 (dsomers@omz13.com). 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Pathnames . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . . 5 64 2.5. Interpreting Examples . . . . . . . . . . . . . . . . . . 5 65 3. Modify Fact: Modification Time (MFMT) . . . . . . . . . . . . 6 66 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Error responses . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. FEAT response for MFMT . . . . . . . . . . . . . . . . . . 7 69 3.3.1. Example FEAT response . . . . . . . . . . . . . . . . 8 70 3.4. MFMT Examples . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Modify Fact: Creation Time (MFCT) . . . . . . . . . . . . . . 9 72 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Error responses . . . . . . . . . . . . . . . . . . . . . 9 74 4.3. FEAT response for MFCT . . . . . . . . . . . . . . . . . . 10 75 4.3.1. Example FEAT response . . . . . . . . . . . . . . . . 10 76 4.4. MFCT Examples . . . . . . . . . . . . . . . . . . . . . . 10 77 5. Modify Fact: Facts (MFF) . . . . . . . . . . . . . . . . . . . 11 78 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.2. Standard facts . . . . . . . . . . . . . . . . . . . . . . 12 80 5.2.1. Create fact . . . . . . . . . . . . . . . . . . . . . 12 81 5.2.2. Modify fact . . . . . . . . . . . . . . . . . . . . . 13 82 5.3. Operating System specific facts . . . . . . . . . . . . . 13 83 5.3.1. Example Operating System specific facts . . . . . . . 13 84 5.4. Local/Experimental "X." facts . . . . . . . . . . . . . . 13 85 5.5. Error responses . . . . . . . . . . . . . . . . . . . . . 13 86 5.6. FEAT response for MFF . . . . . . . . . . . . . . . . . . 14 87 5.6.1. Example FEAT responses . . . . . . . . . . . . . . . . 14 88 5.7. MFF Examples . . . . . . . . . . . . . . . . . . . . . . . 15 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 6.1. The OS Specific fact registry . . . . . . . . . . . . . . 17 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 95 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 Intellectual Property and Copyright Statements . . . . . . . . . . 23 99 1. Introduction 101 The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 102 [1], and in place on the Internet allows files to be transferred 103 between a server-FTP and a user-FTP, and vice versa. When a file is 104 transferred from the user-FTP to the server-FTP, the creation time, 105 last modification time, and operating system facts (for example, file 106 permissions) can not be specified. The NVFS typically sets these to 107 default values. 109 This document defines extensions to the File Transfer Protocol, 110 specifically three new optional commands: "MFMT", "MFCT", and "MFF". 112 The "MFMT" command allows the last modification time an object in the 113 NVFS to be modified. This is an alternative to abusing "MDTM" (as 114 defined in section 3 of [2]), which was only intended to read the 115 modification time and not to set it as some implementations do. 117 The "MFCT" command allows the creation time an object in the NVFS to 118 be modified. 120 The "MFF" command allows multiple facts of an object in the NVFS to 121 be modified. The MFF command is complimentary to the MLSx commands 122 as detailed in [2]. The MLSx commands provides a standardized way of 123 retrieving facts for objects in the NVFS; the MFF command aims to 124 standardize modifying (or setting) the facts for the objects in the 125 NVFS. 127 2. Document Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [3]." 133 This document also uses notation defined in [1]. In particular, the 134 terms "reply", "user", "NVFS", "file", "pathname", "FTP commands", 135 "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP 136 process", "server-PI", "server-DTP", "mode", "type", "NVT", "control 137 connection", "data connection", and "ASCII", are all used here as 138 defined there. 140 Syntax required is defined using the Augmented BNF defined in [4]. 141 Some general ABNF definitions are required throughout the document, 142 those will be defined later in this section. At first reading, it 143 may be wise to simply recall that these definitions exist here, and 144 skip to the next section. 146 2.1. Basic Tokens 148 This document defines basic tokens in the same manner as that as 149 specified in section 2.1 of [2]. 151 2.2. Pathnames 153 This document defines pathnames in the same manner as that specified 154 in section 2.2 of [2]. 156 2.3. Times 158 This document defines times in the same manner as that as specified 159 in section 2.3 of [2]. 161 2.4. Server Replies 163 This document defines server replies in the same manner as that 164 specified in section 2.4 of [2]. 166 2.5. Interpreting Examples 168 This document presents examples in the same manner as that specified 169 in section 2.5 of [2]. 171 3. Modify Fact: Modification Time (MFMT) 173 The FTP command, MODIFY FACT: MODIFICATION TIME (MFMT), is used to 174 modify the last modification time of an object in the NVFS. 176 The ability to modify the last modification time MAY also be 177 achieved, if supported by the server-PI, by using the "Modify" fact 178 to the MFF command as detailed in Section 5. 180 It should be noted that similar functionality has been implemented by 181 some server-PIs as the command MDTM. However, the use of MDTM to 182 modify the last modification time of an object conflicts with the use 183 of the MDTM command to retrieve the last modification time of an 184 object as defined in [2]. It is RECOMMENDED that, if possible, 185 client-PIs use the MFMT command instead of abusing the MDTM command 186 to change the modification time of an object in the NVFS. 188 If the client-PI wants to modify both the modification time and the 189 creation time, it is RECOMMENDED that the MFF command, if supported 190 by the server-PI, be used instead. 192 If the NVFS supports the concept of both creation times and 193 modification times, it is RECOMMENDED that server-PI give priority to 194 setting the modification time, even if it means that to set the 195 modification time requested by the client-PI the server-PI must also 196 change the creation time. An example of this prioritization is if 197 the requested modification time is prior to the current creation time 198 and the NVFS does not permit the modification time to be prior to the 199 creation time; the only way to set the modification time in such a 200 situation is for the server-PI to automagically change the creation 201 time to a time before or of the same as the requested modification 202 time. The rationale for this prioritization of modification over 203 creation time is because, generally speaking, it is more important 204 for the modification time to be more valid than the creation time as 205 the modification time is typically used to perform object 206 synchronization between hosts. 208 3.1. Syntax 210 The syntax of the MFMT command is: 212 mfmt = "MFMT" SP time-val SP pathname CRLF 214 As with all FTP commands, the "MFMT" command label is interpreted in 215 a case insensitive manner. 217 The "time-val" specifies the last modification time to be applied to 218 the object. 220 The "pathname" specifies an object in the NVFS. 222 The server-PI MUST respond to the MFMT command with a 213 reply, or 223 an error response if the object does not exist, the last modification 224 time could not be modified, or some other error has occurred. 226 mfmt-response = "213" SP "Modify=" time-val ";" SP pathname CRLF / 227 error-response 229 The "time-val" in the response MUST be the modified last modification 230 time of the object. This value MAY not be the same as that requested 231 due to constraints of the NVFS to store the last modification time 232 (for example, it may only have sufficient resolution to store the 233 last modification time to the nearest minute instead of to the 234 thousandths of a second that "time-val" MAY be specified to). It is 235 RECOMMENDED that the client-PI parse the 213 response to determine 236 what the modification time was actually modified to by the server-PI. 238 3.2. Error responses 240 Where the command is correctly parsed, but the pathname identifies no 241 existing object, then a 550 reply SHOULD be sent. Where the command 242 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 243 the date or time specified is invalid (for example, February 29 in a 244 non-leap year), then a 501 reply MUST be sent. Various 4xy replies 245 are also possible in appropriate circumstances. 247 3.3. FEAT response for MFMT 249 Where a server-FTP process supports the MFMT command, as specified 250 here, it MUST include the response to the FEAT command [5]: 252 mfmt-feat = SP "MFMT" CRLF 254 The initial space shown in the mfmt-feat response is that required by 255 the FEAT command. 257 This string "MFMT" is not case sensitive, but SHOULD be transmitted 258 in upper case. Where MFMT is not supported, the MFMT line MUST NOT 259 be included in the FEAT response. 261 3.3.1. Example FEAT response 263 C> feat 264 S> 211- 265 S> ... 266 S> MFMT 267 S> ... 268 S> 211 end 270 The ellipses indicate place holders where other features may be 271 included, and are not required. The one space indentation of the 272 feature lines is mandatory [5]. 274 3.4. MFMT Examples 276 To modify the last modification time of a file called "Fred.txt" to 277 July 17, 2002 21:07:15, 279 C> MFMT 20020717210715 Fred.txt 280 S> 213 Modify=20020717210715; Fred.txt 282 4. Modify Fact: Creation Time (MFCT) 284 The FTP command, MODIFY FACT: CREATION TIME (MFCT), is used to modify 285 the creation time of an object in the NVFS. 287 The ability to modify the creation time MAY also be achieved, if 288 supported by the server-PI, by using the "Create" fact to the MFF 289 command as detailed in Section 5. 291 If the client-PI wants to modify both the modification time and the 292 creation time, it is RECOMMENDED that the MFF command, if supported 293 by the server-PI, be used instead. 295 4.1. Syntax 297 The syntax of the MFCT command is: 298 mfct = "MFCT" SP time-val SP pathname CRLF 300 As with all FTP commands, the "MFCT" command label is interpreted in 301 a case insensitive manner. 303 The "time-val" specifies the creation time to be applied to the 304 object. 306 The "pathname" specifies an object in the NVFS. 308 The server-PI MUST respond to the MFCT command with a 213 reply, or 309 an error response if the object does not exist, the creation time 310 could not be modified, or some other error has occurred. 312 mfct-response = "213" SP "Create=" time-val ";" SP pathname CRLF / 313 error-response 315 The "time-val" in the response MUST be the modified creation time of 316 the object. This value MAY not be the same as that requested due to 317 constraints of the NVFS to store the creation time (for example, it 318 may only have sufficient resolution to store the creation time to the 319 nearest minute instead of to the thousandths of a second that "time- 320 val" MAY be specified to). It is RECOMMENDED that the client-PI 321 parse the 213 response to determine what the creation time was 322 actually modified to by the server-PI. 324 4.2. Error responses 326 Where the command is correctly parsed, but the pathname identifies no 327 existing object, then a 550 reply SHOULD be sent. Where the command 328 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 329 the date or time specified is invalid (for example, February 29 in a 330 non-leap year), then a 501 reply MUST be sent. Various 4xy replies 331 are also possible in appropriate circumstances. 333 4.3. FEAT response for MFCT 335 Where a server-FTP process supports the MFCT command, as specified 336 here, it MUST include the response to the FEAT command [5]: 338 mfct-feat = SP "MFCT" CRLF 340 The initial space shown in the mfct-feat response is that required by 341 the FEAT command. 343 This string "MFCT" is not case sensitive, but SHOULD be transmitted 344 in upper case. Where MFCT is not supported, the MFCT line MUST NOT 345 be included in the FEAT response. 347 4.3.1. Example FEAT response 349 C> feat 350 S> 211- 351 S> ... 352 S> MFCT 353 S> ... 354 S> 211 end 356 The ellipses indicate place holders where other features may be 357 included, and are not required. The one space indentation of the 358 feature lines is mandatory [5]. 360 4.4. MFCT Examples 362 To modify the creation time of a file called "Jim.txt" in the current 363 directory to July 17, 2002 21:22:30, 365 C> MFCT 20020717212230 Jim.txt 366 S> 213 Create=20020717212230; Jim.txt 368 5. Modify Fact: Facts (MFF) 370 The FTP command, MODIFY FACT: FACTS (MFF), is used to modify one or 371 more facts of an object in the NVFS. These facts are attributes such 372 as creation time, last modification time, or operating system 373 specific attributes such as access permissions. 375 The MFF command is complimentary to the MLSx commands as detailed in 376 [2]. The MLSx commands provides a standardized way of retrieving 377 facts for objects in the NVFS; the MFF command aims to standardize 378 modifying (or setting) the facts for the objects in the NVFS. The 379 format of facts is identical to that specified in [2]. 381 If the client-PI wants to modify only the modification time or only 382 the creation time, it is RECOMMENDED that the MFCT (see Section 4) or 383 MFMT (see Section 3) commands, if supported by the server-PI, be used 384 respectively instead of the MFF command. 386 It MAY be possible for a client to attempt to set the modification 387 time prior to the creation time; this situation may be nonsensical, 388 but it may be necessary, and it is RECOMMENDED that it not be 389 considered an error by the server-PI. If necessary, the server-PI 390 SHOULD prioritize modifying the modification time, even if that means 391 automagically changing the modification time (due to NVFS 392 restrictions). 394 5.1. Syntax 396 The syntax of the MFF command is: 398 mff = "MFF" [ mff-facts ] SP pathname CRLF 399 mff-facts = 1*( mff-fact ";" ) 400 mff-fact = mff-standardfact / mff-osfact / mff-localfact 401 mff-standardfact = mff-create-fact / mff-modify-fact 402 mff-create-fact = "Create" "=" time-val 403 mff-modify-fact = "Modify" "=" time-val 404 mff-osfact = "." token "=" *SCHAR 405 mff-localfact = "X." token "=" *SCHAR 407 As with all FTP commands, the "MFF" command label is interpreted in a 408 case insensitive manner. 410 The "mff-facts" are a series of facts as keyword=value pairs each 411 separated by a semi-colon (";") character. Fact keyword names are 412 case-insensitive. 414 The "pathname" specifies an object in the NVFS. 416 The server-PI MUST respond to the MFF command with a 213 reply 417 containing a list of the facts that MUST detail the values actually 418 set for all the facts specified in the request (which MAY differ from 419 that requested), or an error response. 421 mff-response = "213" SP 1*( mff-fact ";") SP pathname CRLF / 422 error-response 424 The order of the "mff-fact" keyword=value pairs returned in the 425 response MAY be in any order. 427 The "time-val" in the response MAY not be the same as that requested 428 due to constraints of the NVFS to store such times (for example, it 429 may only have sufficient resolution to store the last modification 430 time to the nearest minute instead of to the thousandths of a second 431 that "time-val" MAY be specified to). 433 The error response MUST be returned if any of the following 434 conditions happen: 436 o The object does not exist. 438 o A fact could not be modified, for example due to insufficient 439 access control permissions. 441 o An unknown fact was specified. 443 When an error response is returned, the client-PI MUST make no 444 assumptions about which, if any, facts have been modified. In other 445 words, modifying facts is not an atomic operation. The client-PI can 446 issue an MLST (if the server-PI supports the MLST command) to 447 determine what attributes have, in fact, been modified. 449 5.2. Standard facts 451 This document defines the following standard facts for use by MFF: 453 o Create 455 o Modify 457 5.2.1. Create fact 459 The "Create" fact is used to modify the creation time of the object 460 specified by "pathname". 462 Note that this is the same fact that can be read using the MLST and 463 MLSD commands in [2], and is detailed in see section 7.5.4 of the 464 aforementioned document. 466 5.2.2. Modify fact 468 The "Modify" fact is used to modify the last modification time of the 469 object specified by "pathname". 471 Note that this is the same fact that can be read using the MLST and 472 MLSD commands in [2], and is detailed in see section 7.5.3 of the 473 aforementioned document. 475 5.3. Operating System specific facts 477 Facts that are specific to an operating system, or file system, 478 SHOULD be specified by keywords that are prefixed by an IANA 479 operating system name [7]. 481 Implementation Note: It is envisioned that the operating system 482 specific facts will be identical to those used by the MLSx command as 483 detailed in [2]; implementers can then use the same logic to process 484 facts whether for MLSx or MFF. 486 The specification of Operating Systems specific facts is explicitly 487 outside the scope of this document. Such specifications SHOULD be 488 documented elsewhere (that is, in an internet draft, RFC, etc.) 490 5.3.1. Example Operating System specific facts 492 The following examples are only indicative of how it is anticipated 493 that some Operating System specific facts could be implemented. 495 UNIX.mode -- Unix file mode (in octal) 496 UNIX.owner -- Unix owner (as a decimal Uid or a username) 497 UNIX.group -- Unix group (as a decimal Gid or a groupname) 498 WINDOWS-NT.SIS.Author -- Windows NT, 499 Summary Information Stream, Author property 501 5.4. Local/Experimental "X." facts 503 Implementations may define keywords for experimental, or private, 504 use. All such keywords MUST begin with the two character sequence 505 "X.". As fact names are case-insensitive, "X." and "x." are 506 equivalent. 508 5.5. Error responses 510 Where the command is correctly parsed, but the pathname identifies no 511 existing object, then a 550 reply SHOULD be sent. Where the command 512 can not be correctly parsed, a 500 or 501 reply SHOULD be sent. If 513 the date or time specified for a Create or Modify fact is invalid 514 (for example, February 29 in a non-leap year), then a 501 reply MUST 515 be sent. If an unknown fact is provided, a 504 reply SHOULD be sent, 516 and it is RECOMMENDED that the 504 reply indicate the name(s) of the 517 unknown fact(s). Various 4xy replies are also possible in 518 appropriate circumstances. 520 5.6. FEAT response for MFF 522 Where a server-FTP process supports the MFF command, as specified 523 here, it MUST include in the response to the FEAT command [5], a 524 feature line containing the string "MFF". This string is not case 525 sensitive, but SHOULD be transmitted in upper case. As well as 526 indicating MFF support, the MFF feature line indicates, as a semi- 527 colon delimited list, which MFF facts are available for modification 528 by the server-FTP process. Where MFF is not supported, the MFF line 529 MUST NOT be included in the FEAT response. 531 mff-feat = SP "MFF" SP factlist CRLF 532 factlist = 1*( factname ";" ) 534 The initial space shown in the mff-feat response is that required by 535 the FEAT command. 537 5.6.1. Example FEAT responses 539 C> feat 540 S> 211- 541 S> ... 542 S> MFF Modify; 543 S> ... 544 S> 211 end 546 This server-FTP process indicates that it supports the MFF command, 547 and only supports modification of the modify fact of an object in the 548 NVFS. 550 C> feat 551 S> 211- 552 S> ... 553 S> MFF Create;Modify;WINDOWS-NT.SIS.Author; 554 S> ... 555 S> 211 end 557 This server-FTP process indicates that it supports the MFF command, 558 and supports modification of the create fact, modify fact, and an 559 operating system specific fact called "WINDOWS-NT.SIS.Author" of an 560 object in the NVFS. Note that the "WINDOWS-NT.SIS.Author" fact is an 561 example of what could be possible, not what is possible; such a fact 562 may exist, but its definition is outside the scope of this document. 564 The ellipses indicate place holders where other features may be 565 included, and are not required. The one space indentation of the 566 feature lines is mandatory [5]. 568 5.7. MFF Examples 570 Note that some of these examples refer to the UNIX.mode fact; whether 571 such a fact exists or not is outside the scope of this document, and 572 is used below only to show what could be possible and not what is 573 possible. 575 To modify the creation time of a file called "Sheila.txt" to July 17, 576 2002 21:22:30, 578 C> MFF Create=20020717212230; Sheila.txt 579 S> 213 Create=20020717212230; Sheila.txt 581 Note that the above could also be achieved using the MFCT command, 582 thus: 584 C> MFCT 20020717212230 Sheila.txt 585 S> 213 Create=20020717212230; Sheila.txt 587 To modify the permissions on a Unix-based NVFS for the file called 588 "Bob.txt" to (octal) 777, 590 C> MFF UNIX.mode=777; Bob.txt 591 S> 213 UNIX.mode=777; Bob.txt 593 To modify the permissions on a Unix-based NVFS for the file called 594 "Fred.txt" to (octal) 777, and the creation time to July 18, 2002 01: 595 28:45, 597 C> MFF UNIX.mode=777;Create=20020718012845; Fred.txt 598 S> 213 Create=20020718012845;UNIX.mode=777; Fred.txt 600 If the same request was made to a server-FTP process that does not 601 support the UNIX.mode fact, 603 C> MFF UNIX.mode=777;Create=20020718012845; Fred.txt 604 S> 504 Parameter Not Implemented (UNIX.mode) 606 The creation time may or may not have been modified by the server-PI 607 before the server-PI determined that the UNIX.mode fact was not 608 implemented. 610 6. IANA Considerations 612 This specification makes use of some lists of values currently 613 maintained by the IANA. It does not add any values to any existing 614 registries. 616 6.1. The OS Specific fact registry 618 The MFF command reuses the OS Specific fact registry that is used by 619 the MLSx commands as detailed in [2] 621 The OS names for the OS portion of the fact name must be taken from 622 the IANA's list of registered OS names. To add a fact name to this 623 OS specific registry of OS specific facts, an applicant must send to 624 the IANA a request, in which is specified the OS name, the OS 625 specific fact name, a definition of the syntax of the fact value, 626 which must conform to the syntax of a token as given in this 627 document, and a specification of the semantics to be associated with 628 the particular fact and its values. Upon receipt of such an 629 application, and if the combination of OS name and OS specific fact 630 name has not been previously defined, the IANA will add the 631 specification to the registry. 633 Any examples of OS specific facts found in this document are to be 634 treated as examples of possible OS specific facts, and do not form a 635 part of the IANA's registry merely because of being included in this 636 document. 638 7. Security Considerations 640 No significant security issues, not already present in the FTP 641 protocol, are believed to have been created by this extension. 643 A general discussion of issues related to the security of FTP can be 644 found in [6]. 646 8. References 648 8.1. Normative References 650 [1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 651 RFC 959, October 1985. 653 [2] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 655 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 656 Levels", BCP 14, RFC 2119, March 1997. 658 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 659 Specifications: ABNF", RFC 4234, October 2005. 661 [5] Hethmon, P., "Feature negotiation mechanism for the File 662 Transfer Protocol", RFC 2389, August 1998. 664 8.2. Informative References 666 [6] Allman, M. and S. Ostermann, "FTP Security Considerations", 667 RFC 2577, May 1999. 669 URIs 671 [7] 673 [8] 675 Appendix A. Acknowledgements 677 Thank you to the authors and editors of [2] for the facts in their 678 MLSx command which have been hijacked (in the nicest possible way) by 679 the MFF command herein. 681 A big thanks to xml2rfc [8] which greatly aided in the production of 682 this document. 684 Finally, many thanks to all who commented on drafts of this document 685 and helped clarify and improve it, and an even bigger thanks to those 686 who have implemented or who intend to implement the FTP commands 687 presented in this document. 689 Author's Address 691 David M. P. Somers 692 Tunnelstrooss 36 693 Lipperscheid 9164 694 LU 696 Email: dsomers@omz13.com 697 URI: http://www.omz13.com/ftp-mfxx 699 Full Copyright Statement 701 Copyright (C) The IETF Trust (2007). 703 This document is subject to the rights, licenses and restrictions 704 contained in BCP 78, and except as set forth therein, the authors 705 retain all their rights. 707 This document and the information contained herein are provided on an 708 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 709 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 710 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 711 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 712 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 713 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 715 Intellectual Property 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be 724 found in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this 730 specification can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at 737 ietf-ipr@ietf.org. 739 Acknowledgment 741 Funding for the RFC Editor function is provided by the IETF 742 Administrative Support Activity (IASA).