idnits 2.17.1 draft-burger-smtp-deta-00.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 315. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 26, 2004) is 7176 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 2821 (ref. '2') (Obsoleted by RFC 5321) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-04) exists of draft-ietf-lemonade-burl-00 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual E. Burger 3 Internet-Draft Brooktrout Technology, Inc. 4 Expires: February 24, 2005 August 26, 2004 6 SMTP Service Extension for Detached Operation 7 draft-burger-smtp-deta-00 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 24, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The normal operation for the Simple Mail Transfer Protocol (SMTP) is 43 for the submitting device to wait for all processing to complete and 44 for the server to return a positive acknowledgement to the client. 45 However, some devices have very intermittent connectivity, such as 46 wireless mobile terminals. For such devices, a means to have 47 processing continue in the case of a dropped connection is desirable. 48 To this end, this SMTP service extension enables a client to submit a 49 message and reliably detach from the session, indicating to the 50 server to continue in the absence of a connection to the client. 52 Conventions used in this document 54 RFC2119 [1] provides the interpretations for the key words "MUST", 55 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 56 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 58 Table of Contents 60 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 61 2. Formal Description of the Extension . . . . . . . . . . . . . 3 62 2.1 Extension Definition . . . . . . . . . . . . . . . . . . . 3 63 2.2 Extension Operation . . . . . . . . . . . . . . . . . . . 4 64 2.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . 4 65 2.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . 4 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1 Detached Submit . . . . . . . . . . . . . . . . . . . . . 5 69 4.2 Piplined Submit . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 73 6.2 Informative References . . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 75 Intellectual Property and Copyright Statements . . . . . . . . 9 77 1. Introduction and Overview 79 There is a class of SMTP [2] clients that have intermittent IP 80 connectivity. This is a particular problem for devices that wish to 81 submit objects that have a long processing time requirement at the 82 server. For example, the object may have be physically large or have 83 a large number of recipients, both of which may result in a 84 relatively long processing time at the server. 86 The RDLV [3] SMTP service extension provides a mechanism for servers 87 to periodically inform a client that processing on a long delivery 88 item is in progress. This mechanism periodically emits 120 responses 89 to the client, to which the client issues the CONT verb to tell the 90 server that the client is still alive and the server should continue 91 processing the message. 93 The Detached Operation SMTP service extension builds upon the RDLV 94 mechanism, adding the DETA verb as an answer to the 120 response. 95 When the server receives the DETA verb, it terminates the connection 96 to the client yet continues processing the message. 98 This enables the client to definitively know the server has begun 99 working on the message. Likewise, it lets the server definitively 100 know the client is aware the server is working on the message. 102 Of course, the client will not know the immediate disposition of the 103 message. In particular, the client will not know if the message 104 submission succeeded. To address this problem, the server has to 105 support the message disposition notification service extension [6]. 106 If the client needs to know if the submission fails, the client asks 107 for a DSN. The server issues a DSN in the event of submission 108 failure, per the rules of RFC3464. 110 2. Formal Description of the Extension 112 2.1 Extension Definition 114 1. The text name of this SMTP service extension is DETA. 115 2. The EHLO keyword associated with this SMTP service extension is 116 DETA. 117 3. The DETA keyword has no parameters. 118 4. This document defines a new SMTP verb, DETA. The DETA verb 119 indicates that the server terminates the current session yet 120 continues the in-process command execution. 121 5. Servers implementing the Detached Operation SMTP service 122 extension MUST also support and advertise the following 123 extensions in addition to other extensions in their EHLO response 124 the RDLV [3] and DSN [4] service extensions. 126 6. This SMTP service extension does not introduce any new parameters 127 to existing SMTP verbs. 129 2.2 Extension Operation 131 2.2.1 Server Behavior 133 Servers implementing this specification MUST support the RDLV [3] and 134 DSN [4] SMTP service extensions. Servers MUST advertise RDLV, DSN, 135 and DETA in their EHLO response. 137 Upon receiving a RDLV verb followed by another verb, the server MAY 138 issue a 120 response, per RDLV [3]. 140 Instead of receiving a CONT verb from the client, the server may 141 receive a DETA verb from the client. In this case, the server MUST 142 continue processing the request. In addition, the server MUST issue 143 a 221 response and close the connection, as if it received a QUIT 144 verb. 145 DISCUSSION POINT: An alternative to having the server shut down 146 the session is to let the session continue, so the client could do 147 other SMTP stuff while the server processes the message. However, 148 this raises a few problems. The biggest one is the slippery slope 149 of clients wanting asynchronous notification of submission 150 completion. If we can punt that issue, then I do not have a 151 problem with allowing it. Input from server developers 152 appreciated here. 154 If the client requested a DSN, and the server is unable to complete 155 processing the request, the server MUST issue a DSN following the 156 procedures of RFC3461. 158 2.2.2 Client Behavior 160 The client issues a RDLV verb before issuing the submission verb. 161 This enables the server to return control to an in-process command to 162 the client. The client then issues the submission verb. When the 163 server responds with a 120 response after the timeout, the client MAY 164 issue the DETA verb to instruct the server to continue processing and 165 detach the session. 167 The client SHOULD request a DSN so the user can know if the 168 submission succeeded. 170 The client MAY use command pipelining [5] if supported and advertised 171 by the server. 173 3. IANA Considerations 175 Please register the DETA service extension in the Simple Mail 176 Transfer Protocol (SMTP) Service Extensions table as follows. 178 Service Extension 179 Keyword: DETA 180 Description: Detached Operation 181 Reference: RFCXXXX 182 Extension Parameters: none 184 4. Examples 186 These examples are informative in nature. For any discrepancies 187 between behavior here and the normative behavior, the normative 188 behavior is correct. 190 4.1 Detached Submit 192 The client submits a message using BURL [7] and detaches from the 193 session. 195 S: 220 example.net SMTP XYZ Ready 196 C: EHLO example.com 197 S: 250-example.net greets example.com 198 S: 250-8BITMIME 199 S: 250-BURL imap 200 S: 250-RDLV mintimer=30 201 S: 250-DETA 202 S: 250-DSN 203 S: 250 HELP 204 C: MAIL FROM: 205 S: 250 OK 206 C: RCPT TO: 207 S: 250 OK 208 C: RDLV maxtimer=30 209 S: 200 OK 210 C: DATA 211 S: 354 Start mail input; end with . 212 C: [... lots and lots of data ...] 213 C: . 214 [about 30 seconds pass] 215 S: 120 DATA processing in progress 216 C: DETA 217 S: 221 example.net Service closing transmission channel 219 4.2 Piplined Submit 221 A client can pipeline the submission commands. 223 S: 220 example.net SMTP XYZ Ready 224 C: EHLO example.com 225 S: 250-example.net greets example.com 226 S: 250-8BITMIME 227 S: 250-PIPELINING 228 S: 250-BURL imap 229 S: 250-RDLV mintimer=30 230 S: 250-DSN 231 S: 250 HELP 232 C: MAIL FROM: RET=HDRS ENV=A123bzq 233 C: RCPT TO: NOTIFY=FAILURE 234 ORCPT=rfc822;jones@example.com 235 C: RDLV maxtimer=30 236 C: BURL imap://handset@host.example.com/outbox 237 ;uidvalidity=a9j230r932/;uid=32 238 ;authid=fred;urlauth=submit+handset 239 :internal:91354a473744909de610943775f92038 LAST 240 S: 250 sender OK 241 S: 250 recipient OK 242 S: 200 reliable delivery OK 243 [about 30 seconds passes] 244 S: 120 DATA processing in progress 245 C: DETA 246 S: 221 example.net Service closing transmission channel 248 5. Security Considerations 250 Malicious clients can amplify server load by issuing a large number 251 of detached requests. Servers SHOULD implement reasonable policies 252 to limit the number of concurrent submissions on behalf of a given 253 sender. 255 6. References 257 6.1 Normative References 259 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 260 Levels", BCP 14, RFC 2119, March 1997. 262 [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 263 2001. 265 [3] Burger, E., "SMTP Service Extension for Reliable Submission", 266 August 2004. 268 [4] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 269 Extension for Delivery Status Notifications (DSNs)", RFC 3461, 270 January 2003. 272 [5] Freed, N., "SMTP Service Extension for Command Pipelining", STD 273 60, RFC 2920, September 2000. 275 6.2 Informative References 277 [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 278 Delivery Status Notifications", RFC 3464, January 2003. 280 [7] Newman, C., "Message Submission BURL Extension", Internet Draft 281 draft-ietf-lemonade-burl-00.txt, July 2004. 283 Author's Address 285 Eric Burger 286 Brooktrout Technology, Inc. 287 18 Keewaydin Dr. 288 Salem, NH 03079 289 USA 291 EMail: e.burger@ieee.org 293 Intellectual Property Statement 295 The IETF takes no position regarding the validity or scope of any 296 Intellectual Property Rights or other rights that might be claimed to 297 pertain to the implementation or use of the technology described in 298 this document or the extent to which any license under such rights 299 might or might not be available; nor does it represent that it has 300 made any independent effort to identify any such rights. Information 301 on the procedures with respect to rights in RFC documents can be 302 found in BCP 78 and BCP 79. 304 Copies of IPR disclosures made to the IETF Secretariat and any 305 assurances of licenses to be made available, or the result of an 306 attempt made to obtain a general license or permission for the use of 307 such proprietary rights by implementers or users of this 308 specification can be obtained from the IETF on-line IPR repository at 309 http://www.ietf.org/ipr. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights that may cover technology that may be required to implement 314 this standard. Please address the information to the IETF at 315 ietf-ipr@ietf.org. 317 The IETF has been notified of intellectual property rights claimed in 318 regard to some or all of the specification contained in this 319 document. For more information consult the online list of claimed 320 rights. 322 Disclaimer of Validity 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Copyright Statement 334 Copyright (C) The Internet Society (2004). This document is subject 335 to the rights, licenses and restrictions contained in BCP 78, and 336 except as set forth therein, the authors retain all their rights. 338 Acknowledgment 340 Funding for the RFC Editor function is currently provided by the 341 Internet Society.