idnits 2.17.1 draft-ietf-mailext-checkp-01.txt: ** The Abstract section seems to be numbered 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-03-28) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (April 3, 1995) is 10587 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 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1651 (ref. '4') (Obsoleted by RFC 1869) ** Obsolete normative reference: RFC 974 (ref. '6') (Obsoleted by RFC 2821) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group David Crocker 2 Internet Draft Ned Freed 3 Allan Cargille, WG Chair 5 SMTP Service Extension 6 for Checkpoint/Restart 8 April 3, 1995 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or obsoleted 20 by other documents at any time. It is not appropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as a "working draft" or "work in progress". 24 To learn the current status of any Internet-Draft, please 25 check the 1id-abstracts.txt listing contained in the 26 Internet-Drafts Shadow Directories on ds.internic.net (US East 27 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 28 or munnari.oz.au (Pacific Rim). 30 1. Abstract 32 This memo defines an extension to the SMTP service whereby an 33 interrupted SMTP transaction can be restarted at a later time 34 without having to repeat all of the message content sent prior 35 to the interruption. 37 2. Introduction 39 Although SMTP is widely and robustly deployed, various 40 extensions have been requested by parts of the Internet 41 community. In particular, when dealing with very large 42 messages over less reliable connections it is possible for 43 substantial resources to be consumed by repeated unsuccessful 44 attempts to transmit the message in its entirety. The original 45 SMTP specification [1] does not provide any means to continue 46 a transaction once the underlying TCP connection has been 47 broken. 49 This memo provides a facility by which a client can uniquely 50 identify a particular SMTP transaction. The server then stores 51 this identifying information along with all the information it 52 receives as the transaction proceeds. If the transaction is 53 interrupted during the data transfer phase the SMTP client may 54 establish a new SMTP session at a later time and ask the 55 server to continue the transaction from the point where the 56 server lost its connection with the client. The server then 57 reestablishes the transaction context and tells the client 58 where to resume operations. If this is acceptable the client 59 resumes operations at this point. 61 This extension may also be used to work around the common 62 timeout problem where a client times out waiting for a 63 response from the server acknowledging that the message has 64 been accepted. However, use of this extension is not an 65 acceptable substitute for proper setting of timeout 66 parameters. 68 3. Framework for the Checkpointing Extension 70 The checkpointing extension is laid out as follows: 72 (1) the name of the SMTP service extension defined here is 73 checkpointing; 75 (2) the EHLO keyword value associated with the extension is 76 CHECKPOINT; 78 (3) no parameter is used with the CHECKPOINT EHLO keyword; 80 (4) one optional parameter using the keyword TRANSID is 81 added to the MAIL FROM command. The value associated 82 with this parameter, coupled with the name of the 83 client taken from EHLO command, forms a globally unique 84 value that identifies this particular transaction and 85 serves to distinguish it from all others. This value is 86 case-sensitive. The syntax of the value is as follows, 87 using the ABNF notation of [2]: 89 transid-value ::= "<" transid-spec ">" 90 transid-spec ::= transid-local "@" transid-domain 91 transid-domain ::= transid-token 92 transid-local ::= transid-token 93 transid-token ::= transid-atom *("." transid-atom) 94 transid-atom ::= 1* 97 NOTE: tspecials is defined in [3]. The TRANSID is 98 likely to be different from the RFC822 message id, 99 since it must uniquely identify the particular copy of 100 the message being sent over this SMTP link. However, 101 the syntax of transid-value is designed so that any 102 TRANSID is both a legal RFC822 msg-id as well as being 103 a legal esmtp-value [4]. 105 (5) no additional SMTP verbs are defined by this extension; 106 and, 108 (6) the next section specifies how support for the 109 extension affects the behavior of a server and client 110 SMTP. 112 4. The checkpointing service extension 114 When a client SMTP wishes to use checkpointing to eliminate 115 the need to retransmit all message data in its entirety in the 116 event of a session interruption, it first issues the EHLO 117 command to the server SMTP. If the server SMTP responds with 118 code 250 to the EHLO command, and the response includes the 119 EHLO keyword value CHECKPOINT, then the server SMTP is 120 indicating that it supports SMTP checkpointing and will honor 121 requests to restart interrupted SMTP transactions. 123 The extended MAIL command is issued by a client SMTP when it 124 wishes to enable server checkpointing. The syntax for this 125 command is identical to the MAIL command in [1], except that a 126 TRANSID parameter must appear after the address. 128 The complete syntax of this extended command is defined in 129 [4], with the esmtp-keyword TRANSID and transid-value 130 parameter as previously defined. 132 The value associated with the TRANSID parameter must be an 133 identifier that serves to uniquely identify this particular 134 SMTP transaction. Only one TRANSID parameter may be used in a 135 single MAIL command. Care must be used in constructing TRANSID 136 values to simultaneously insure both uniqueness and the 137 ability to reidentify interrupted transactions. 139 The TRANSID is structured to ensure globally uniqueness 140 without any additional registry. The transid-domain part 141 should be a valid domain name that uniquely identifies the 142 SMTP client. Note that this is usually the same as the domain 143 name given in conjunction with the EHLO command, but not 144 always. The EHLO domain name identifies the specific host the 145 SMTP connection originated from, whereas the transid-domain 146 may refer to a group of hosts that collectively host a multi- 147 homed SMTP client. The transid-local part should be an 148 identifier that distinguishes this SMTP transaction from any 149 other originating from this SMTP client. 151 Despite the structured nature of the TRANSID the server should 152 treat the value as an opaque, case-sensitive string. 154 Note that the contents of the RFC822 message-id header 155 typically are NOT appropriate for use as the TRANSID parameter 156 value, since such identifiers may be associated with multiple 157 copies of the same message -- e.g. as it is split during 158 transmission down different network paths -- and hence with 159 multiple distinct SMTP transactions. 161 A server which supports the checkpointing extension will then 162 retain the transaction identifer as well as the most recent 163 state of the transaction in non-volatile storage. This 164 information should deleted only when the transaction is known 165 to be complete. Completion is assured only when the client 166 either explicitly aborts the transaction, starts a new 167 transaction, or closes the connection. 169 In the event of an interruption prior to completing a 170 transaction this preserved state will remain for some period 171 of time defined by the operational policies of the server 172 administrator. It is recommended that transaction state 173 information be preserved for at least 48 hours, although no 174 specific time is required. 176 When a client detects that a transaction has been interrupted, 177 it then must wait for some period before reconnecting. This 178 period must be long enough for server connections to time out 179 and for the transaction state associated with such connections 180 to be released for use by a new connection. The Internet Host 181 Requirements [5] also impose restriction on how quickly 182 reconnection attempts can be made (section 5.3.1.1). 184 Once the necessary period has elapsed the client first checks 185 the DNS as described in [6] and determine the set of 186 acceptable IP addresses the message can be transferred to. If 187 the IP address used to connect to the original server is still 188 on this list it should be tried first, since this server is 189 most likely to be capable of restarting the transaction. If 190 this connection attempt fails the client must then proceed as 191 described in [6] to try all the remaining IP addresses and 192 restart the transaction there. If the attempt to restart fails 193 on one of the other servers the client is required to 194 retransmit the transaction in its entirety at that point. 195 Waiting for a server with an interrupted transaction state to 196 come back online is not acceptable. 198 Note: Multi-homed SMTP servers do exist, which means that it 199 is entirely possible for a transaction to restart on a 200 different server host. 202 Once the connection is made the client issues the same MAIL 203 command with exactly the same transaction identifier. If the 204 transaction was interrupted during or at the end of the 205 transfer of actual message data, the server first 206 reestablishes its context to a point close as possible to the 207 point of interruption and then responds with the status 208 message: 210 355 octet-offset is the transaction offset 212 The actual status text can vary. However the octet-offset 213 field is required to be the first thing on the first line of 214 the reply, it must be separated from any following text by 215 linear whitespace, and it is structured as follows: 217 octet-offset ::= 1*DIGIT 219 The octet-offset represents an offset, counting from zero, to 220 the particular octet in the actual message data the server 221 expects to see next. (This is also a count of how many octets 222 the server has received and stored successfully.) This offset 223 does NOT account for envelope data, i.e. MAIL FROM and RCPT TO 224 commands. A value of 0 would indicate that the client needs to 225 start sending the message from the beginning, a value of 1 226 would indicate that the client should skip one octet, and so 227 on. 229 The SMTP canonical format for messages is used when this 230 offset is computed. Any octets added by any SMTP data- 231 stuffing algorithm do not count as part of this offset. In the 232 case of data transferred with the DATA command the offset must 233 also correspond to the beginning of a line. 235 Once this context is reestablished the client issues another 236 data transfer command (e.g. DATA) and sends the remaining 237 message data. Once this data is terminated the transaction 238 completes in the normal fashion and the server deletes the 239 transaction context from non-volatile storage. 241 Note that the semantics of the octet-offset immediately 242 suggest a particularly simple implementation strategy, where 243 the client retransmits the message data as it normally would 244 but suppresses output of the first octet-offset octets of 245 material. The semantics used here are intentionally designed 246 to make such implementation possible, but care must be taken 247 to insure that such an implementation strategy does not impose 248 a significant performance penalty on the client. 250 5. Usage Example 252 The following dialogue illustrates the use of the 253 checkpointing service extension: 255 S: 256 C: 257 S: 220 dbc.mtview.ca.us SMTP service ready 258 C: EHLO ymir.claremont.edu 259 S: 250-dbc.mtview.ca.us says hello 260 S: 250 CHECKPOINT 261 C: MAIL FROM: TRANSID=<12345@claremont.edu> 262 S: 250 ... Sender and TRANSID ok 263 C: RCPT TO: 264 S: 250 ... Recipient ok 265 C: DATA 266 S: 354 Send checkpointed message, ending in CRLF.CRLF 267 268 270 Some time later a new connection is established: 271 S: 272 C: 273 S: 220 dbc.mtview.ca.us SMTP service ready 274 C: EHLO ymir.claremont.edu 275 S: 250-dbc.mtview.ca.us says hello 276 S: 250 CHECKPOINT 277 C: MAIL FROM: TRANSID=<12345@claremont.edu> 278 S: 355 6135 is the transaction offset 279 C: DATA 280 S: 354 Send previously checkpointed message starting at octet 6135 281 C: 282 C: . 283 S: 250 OK 284 C: QUIT 285 S: 250 Goodbye 287 6. Security Considerations 289 This RFC does not discuss security issues and is not believed 290 to raise any security issues not already endemic in electronic 291 mail and present in fully conforming implementations of [1]. 293 7. References 295 [1] J.B. Postel. Simple Mail Transfer Protocol. Request for 296 Comments 821, (August, 1982). 298 [2] D.H. Crocker. Standard for the Format of ARPA Internet 299 Text Messages. Request for Comments 822, (August, 1982). 301 [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail 302 Extensions. Request for Comments 1521, (September, 303 1993). 305 [4] M.T. Rose, E.A. Stefferud, D.H. Crocker, J.C. Klensin, 306 N. Freed. SMTP Service Extensions. Request for Comments 307 1651, (July, 1994). 309 [5] R. Braden, Editor. Requirements for Internet Hosts -- 310 Application and Support. Request for Comments 1123, 311 (October, 1989). 313 [6] C. Partridge. Mail Routing and the Domain System. 314 Request for Comments 974, (January, 1986). 316 8. Author Addresses 318 Dave Crocker 319 Brandenburg Consulting 320 675 Spruce Dr. 321 Sunnyvale, CA 94086 USA 322 USA 323 tel: +1 408 246 8253 fax: +1 408 249 6205 324 email: dcrocker@mordor.stanford.edu 326 Ned Freed 327 Innosoft International, Inc. 328 1050 East Garvey Avenue South 329 West Covina, CA 91790 330 USA 331 tel: +1 818 919 3600 fax: +1 818 919 3614 332 email: ned@innosoft.com