idnits 2.17.1 draft-ietf-ftpext-restart-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 48 has weird spacing: '...markers into...' == Line 99 has weird spacing: '... was origi...' -- 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 (21 March 1997) is 9898 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FTPEXT Working Group Internet Engineering Task Force 2 INTERNET-DRAFT D. Borman 3 Berkeley Software Design, Inc. 4 Expires 21 September 1997 R. Adams 5 UUNET 6 21 March 1997 8 REST Command and Extensions to FTP 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 1. Overview 31 This memo describes changes to FTP [1], which were proposed by Rick 32 Adams in May of 1989, to allow the RESTART mechanism to be used with 33 STREAM mode transfers. Along with this, two new optional commands 34 are added, MODIFICATION TIME (MDTM) and SIZE OF FILE (SIZE). All 35 these changes have been implemented, and are in use today in many 36 production FTP implementations. 38 2. Motivation 40 The FTP specification has three modes of data transfer, Stream, Block 41 and Compressed. To avoid having to resend the entire file if the 42 file is only partially transferred, both sides need some way to be 43 able to agree on where in the data stream to restart the data 44 transfer. 46 In Block and Compressed mode, the data that is transferred over the 47 data connection is formatted, allowing the imbedding of restart 48 markers into the data stream. The sending side can send a restart 49 marker with whatever information it needs to be able to restart a 50 file transfer at that point. The receiving side can keep a list of 51 these restart markers, and corrolate them with how the file is being 52 saved. To restart the file transfer, the receiver just sends across 53 that last restart marker, and both sides know how to resume the data 54 transfer. Note that there are some flaws in the description of the 55 restart mechanism in RFC 959, see RFC 1123 [2] for the corrections. 57 Borman & Adams Expires 21 September 1997 [Page 1] 58 2.1 Restarting in STREAM Mode 60 In Stream mode, the data that is transferred over the data connection 61 is just a stream of unformatted bytes of data, hence explicit restart 62 markers cannot be inserted into the data stream. For this reason, 63 the FTP specification does not provide the ability to do restarts in 64 Stream mode. However, there is not really a need to have explicit 65 restart markers in this case, as restart markers can be implied by 66 the byte offset into the data stream. 68 If the data representation type is IMAGE, for many systems the file 69 will be stored exactly in the same format as it is sent across the 70 data connection. It is very easy for the receiver to determine how 71 much data was previously sent, and notify the sender the byte offset 72 where the transfer should be restarted. If the User FTP is doing the 73 retrieve, it will directly calculate the restart marker, and send 74 that information in the RESTart command. However, if the User FTP is 75 sending the file, it needs to be able to determine how much data was 76 previously sent. A new FTP command is needed to get this 77 information. 79 2.2 Determining File Size 81 A new FTP command, SIZE OF FILE (SIZE), is used to get the size of a 82 file on the remote side. If the data representation type is not 83 IMAGE, then how the file is stored may not match how it will look 84 when transferred over the wire. It is because of this that the 85 implied restart marker is a byte offset into the data stream, and the 86 SIZE of a file may change depending on what is the current mode of 87 transfer. The receiver will need to read the partially transferred 88 file, do any appropriate conversion, and count the number of bytes 89 that would be generated when sending the file. This is the byte 90 offset into the data stream, and is what is conveyed to the sender. 91 The sender will need to read the file, do the appropriate conversion, 92 and skip throw away as much of the data stream as the sender 93 requested. At this point, both sender and receiver will be at the 94 same point in the data stream, and the transfer of the file can be 95 continued. 97 When doing a restart of a file transfer, it is very possible that the 98 file may have been modified on the senders side between when the file 99 was originally transferred, and when the restart is being done. In 100 this case, it would be better to resend the entire file. The FTP 101 protocol does not provide a mechanism to automatically detect this 102 situation. However, with the addition of one new FTP command, this 103 can be done. 105 2.3 RESTarting and Source File Modification 107 The new FTP command, MODIFICATION TIME (MDTM), can be used to 108 determine when the file on the remote side of the connection was last 109 modified. When attempting to restart a RETRieve, if the User FTP 110 does a MDTM command, it can check and see if the modification time of 112 Borman & Adams Expires 21 September 1997 [Page 2] 113 the source file is more recent than the modification time of the 114 partially transferred file. If it is, then most likely the source 115 file has changed and it would be unsafe to restart in the middle of 116 the file transfer. When attempting to restart a STORe, the User FTP 117 can do a MDTM command to find out the modification time of the 118 partially transferred file. If it is older than the modification 119 time of the file that is about to be STORed, then most likely the 120 source file has changed and it would be unsafe to restart in the 121 middle of the file transfer. 123 Note that this is applicable to any RESTart attempt, regardless of 124 the mode of the file transfer. 126 3. Description 128 This section describes the specific changes that need to be made to 129 the FTP specification to add the changes described in Section 2. 130 Note that the FTP specification is modified by RFC 1123 [2], 131 specifically RFC 959 has errors in its description of the Restart 132 mechanism. 134 3.1 MODIFICATION TIME 136 In Section 4.1.3, "FTP SERVICE COMMANDS", insert: 138 MODIFICATION TIME (MDTM) 140 This command returns the time the file named in its argument 141 field was last modified. The time is returned in ISO 3307 142 "Representation of the Time of Day" format. This format is 143 YYYYMMDDHHmmSS or YYYYMMDDHHmmSS.xxx, where 145 YYYY is the year 146 MM is the month (01-12) 147 DD is the day of the month (01-31) 148 HH is the hour of the day (00-23) 149 mm is the minute of the hour (00-59) 150 SS is the second of the hour (00-59) 151 xxx if present, is a fractional second and may be 152 any length 154 Time is expressed in UTC (GMT), not local time. 156 3.2 SIZE OF FILE (SIZE) 158 In Section 4.1.3, "FTP SERVICE COMMANDS", insert: 160 SIZE OF FILE (SIZE) 162 This command returns the size of the file named in its 163 argument field. The value returned is in a format suitable 164 for use with the RESTART (REST) command. This format will 165 change depending on the current MODE and TYPE of the 166 connection. E.g. For mode stream and type image, it would be 168 Borman & Adams Expires 21 September 1997 [Page 3] 169 a count of the number of octets that would be transferred with 170 the RETRIEVE (RETR) command. This command is normally used in 171 conjunction with the RESTART (REST) command. 173 3.3 ERROR RECOVER AND RESTART 175 In Section 3.5, "ERROR RECOVERY AND RESTART", second paragraph, 176 replace: 178 The restart procedure is defined only for the block and 179 compressed mode of data transfer. It requires the sender... 181 with: 183 The restart procedure is defined for the block, compressed and 184 stream mode of data transfer. Block and compressed mode require 185 the sender... 187 At the end of Section 3.5, "ERROR RECOVERY AND RESTART", insert: 189 STREAM MODE transfers with FILE STRUcture may be restarted even 190 though no restart marker has been transferred in addition to the 191 data itself. This is done by using the SIZE command followed by 192 the RESTART (REST) command. 194 When using TYPE ASCII or IMAGE, the SIZE command will return the 195 number of bytes that would actually be transferred if the file 196 were to be sent between the two systems. I.e. with type IMAGE, 197 the SIZE normally would be the number of octets in the file. With 198 type ASCII, the SIZE would be the number of characters in the 199 file INCLUDING any characters that would be inserted during the 200 CR-LF expansion. 202 5. References 204 [1] Postel, J., and Reynolds, J., "FILE TRANSFER PROTOCOL (FTP)", RFC 205 959, ISI, October 1985 207 [2] Braden, R., editor, "Requirements for Internet Hosts -- 208 Application and Support", RFC 1123, October 1989 210 Author's Address 212 David A. Borman 213 Berkeley Software Design, Inc. 214 4719 Weston Hills Drive 215 Eagan, MN 55123 216 Phone: (612) 405-8194 217 Email: dab@bsdi.com 219 Rick Adams 220 UUNET Technologies, Inc. 221 3110 Fairview Park Drive, Suite 570 223 Borman & Adams Expires 21 September 1997 [Page 4] 224 Falls Church, VA 22042 USA 225 Phone: +1 703 204 8000 226 Email: rick@uunet.uu.net 228 Borman & Adams Expires 21 September 1997 [Page 5]