idnits 2.17.1 draft-ietf-fax-timely-delivery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '...which timely delivery is required MUST...' RFC 2119 keyword, line 228: '... The message MUST NOT be transmitted ...' RFC 2119 keyword, line 230: '...a negative delivery status report MUST...' RFC 2119 keyword, line 237: '...e for timely delivery MUST support all...' RFC 2119 keyword, line 254: '... MUST NOT be relayed. Instead, a neg...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 254 has weird spacing: '...egative deliv...' == Line 296 has weird spacing: '... should ensur...' -- 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 (22 October 1999) is 8952 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) -- Looks like a reference, but probably isn't: 'RFC 1891' on line 186 == Unused Reference: '1' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 398, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 409, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2542 (ref. '1') ** Obsolete normative reference: RFC 821 (ref. '2') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1891 (ref. '4') (Obsoleted by RFC 3461) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF fax WG G. Klyne, Content Technologies 2 Internet draft [[[et al]]] 3 22 October 1999 4 Expires: April 2000 6 Timely Delivery for Facsimile Using Internet Mail 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To view the entire list of current Internet-Drafts, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 34 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 35 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 36 West Coast). 38 Copyright Notice 40 Copyright (C) The Internet Society 1999. All Rights Reserved. 42 Abstract 44 This proposal is to describe a way to accomplish timely delivery of 45 e-mail messages, with deterministic service quality guarantee, 46 while preserving the traditional roles and responsibiltiies of the 47 agents involved in e-mail transfers. 49 It is essentially a profile of the DSN and DELIVERBY extentions for 50 ESMTP, [[[and possibly]]] a new extension for establishing the 51 deerministic service guarantee. 53 Content Negotiation for Internet Fax 22 October 1999 54 56 NOTE: This is a first and very preliminary version of 57 specification, rapidly drafted to indicate a possible way forward 58 to achieve the timely delivery requirement for full mode Internet 59 fax. The content is very rough, and the intent at this time is to 60 indicate just the outline of a mechanism. Please address comments 61 to major structural and semantic issues. 63 Table of contents 65 1. Introduction.............................................2 66 1.1 Structure of this document ...........................2 67 1.2 Document terminology and conventions .................2 68 1.3 Discussion of this document ..........................3 69 2. Background and goals.....................................3 70 2.1 Background ...........................................3 71 2.2 Goals for timely delivery ............................4 72 3. Framework for timely delivery............................4 73 3.1 Transmitting a message for timely delivery ...........4 74 3.2 Relaying a message ...................................5 75 3.3 Accepting a message by the final MTA .................6 76 4. Compliance-required ESMTP extension......................7 77 5. DSN reporting extensions.................................7 78 6. Notes....................................................7 79 7. Examples.................................................7 80 8. IANA Considerations......................................8 81 9. Internationalization considerations......................8 82 10. Security considerations.................................8 83 11. Acknowledgements........................................8 84 12. References..............................................8 85 13. Authors' addresses......................................9 86 Appendix A: Amendment history...............................9 87 Full copyright statement....................................9 89 1. Introduction 91 1.1 Structure of this document 93 [[[TBD]]] 95 1.2 Document terminology and conventions 97 [[[TBD]]] 99 NOTE: Comments like this provide additional nonessential 100 information about the rationale behind this document. 101 Such information is not needed for building a conformant 103 Content Negotiation for Internet Fax 22 October 1999 104 106 implementation, but may help those who wish to understand 107 the design in greater depth. 109 [[[Editorial comments and questions about outstanding issues are 110 provided in triple brackets like this. These working comments 111 should be resolved and removed prior to final publication.]]] 113 1.3 Discussion of this document 115 Discussion of this document should take place on the content 116 negotiation and media feature registration mailing list hosted by 117 the Internet Mail Consortium (IMC): 119 Please send comments regarding this document to: 121 ietf-fax@imc.org 123 To subscribe to this list, send a message with the body 'subscribe' 124 to "ietf-fax-request@imc.org". 126 To see what has gone on before you subscribed, please see the 127 mailing list archive at: 129 http://www.imc.org/ietf-fax/ 131 2. Background and goals 133 2.1 Background 135 Traditional e-mail [2] is open-loop. The sender of a message 136 normally has no certainty if or when a message is delivered. (A 137 separate memo [6] contains a discussion of some open- and closed- 138 loop issues in e-mail.) 140 To be more than just a hint to the message transfer system, timely 141 delivery requires a deterministic confirmation mechanism, to close 142 the loop. This is provided by DSN [4]. 144 Three kinds of timeliness can be identified: 146 (a) timely delivery to the receipient 148 (b) timely notification to the sender of delivery 150 (c) timely notification to the sender that the message has been 151 processed 153 This proposal focuses on (a) and (b). A separate proposal is under 154 consideration to address the final case (c). 156 Content Negotiation for Internet Fax 22 October 1999 157 159 The DELIVERBY extension [5] provides a mechanism to ensure timely 160 delivery of a message. 162 From the sender's point of view, timely confirmation of delivery is 163 the most desirable requirement. 165 [[[Need to consider how timely confirmation (i.e. delay in the 166 return path transfer of the confrmation) is handled]]] 168 2.2 Goals for timely delivery 170 The primary goal is to provide a mechanism that allows a consenting 171 parties to establish a relationship with guarenteed delivery within 172 a specified time, or notification that the delivery was not 173 achieved. 175 Further goals are: 177 o Deterministic behaviour. 179 [[[TBD]]] 181 3. Framework for timely delivery 183 Timely delivery is achieved through a number of ESMTP extensions 184 used in concert: 186 - Deivery Status Notification ("DSN") [RFC 1891] 188 - Deliver-by ("DELIVERBY") [] 190 - Compliance-required [[[NEW!]]] [[[if needed: deliver-by looks 191 nearly sufficient.]]] 193 The confirmation loop for succesful delivery looks something like 194 this. The path through MTAs taken by the confirmation response is 195 not defined, and may be different from the forward path of the 196 original message. 198 +-----------+ +--------+ +--------+ +---------+ 199 |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| 200 | MTA | | MTA | | MTA | --| MTA | 201 +-----------+ +--------+ +--------+ | +---------+ 202 | | | 203 +-------------+ | +---------+ 204 | Originating |--<-- ... .... ... --<-- |Receiving| 205 | MUA | | MUA | 206 +-------------+ +---------+ 208 Content Negotiation for Internet Fax 22 October 1999 209 211 3.1 Transmitting a message for timely delivery 213 A transmitted message for which timely delivery is required MUST 214 include the following: 216 - an ENVID parameter on the MAIL command, per DSN [4] 218 - a NOTIFY=SUCCESS,FAILURE parameter on the corresponding RCPT 219 command, per DSN [4] 221 - an ORCPT parameter on the MAIL command, per DSN [4] 223 - a 'BY' parameter on the corresponding RCPT command, per [5] 225 - a COMPLIANCE-REQUIRED parameter on the corresponding RCPT, as 226 described below 228 The message MUST NOT be transmitted to any MTA that does not 229 indicate support for all of these extensions in its response to the 230 EHLO command. In this case, a negative delivery status report MUST 231 be generated indicating the non-compliant MTA, the extensions that 232 it does not support, and the name of the reporting MTA (per DSN, 233 using the non-compliance reporting extensions noted below). 235 3.2 Relaying a message 237 An MTA that relays a message for timely delivery MUST support all 238 of the ESMTP extensions noted above, otherwise it should not 239 receive the message in the first place. When a relaying MTA 240 accepts a message (by its 2xx status response to receipt of the 241 message data), it becomes responsible for its onward delivery, 242 including satisfying all of the options associated with the 243 message. 245 In order to relay a message, an MTA must note when the message was 246 received, note the time when the attempt to transmit the message to 247 the next MTA is initiated, and reduce accordingly the time interval 248 used for the 'deliver-by' parameter (see note below on handling 249 fine-grained timing requirements). 251 If the deliver-by interval is reduced to less than zero, (or less 252 than some system-configurable value indicating that delivery within 253 the indicated interval is unlikely to be achieved) then the message 254 MUST NOT be relayed. Instead, a negative delivery status report 255 MUST be generated indicating that the time for delivery of the 256 message has expired, and the reporting MTA (per DSN, using the 257 deliver-by extensions and/or non-compliance reporting extensions 258 noted below). 260 [[[Remove duplication between above and DELIVERBY spec]]] 262 Content Negotiation for Internet Fax 22 October 1999 263 265 If the first attempt to relay a message fails, the relaying MTA MAY 266 assume that delivery within the desired time will not be achieved, 267 and immediately indicate a delivery failure, indicating the name of 268 the next-hop MTA. Alternatively, the relaying MTA may wait and 269 retry the transmission, provided that the retry attempt will be 270 performed within the remaining deliver-by period; if the 271 transmission cannot be completed after one or more such retries 272 then a negative DSN should be generated as noted above. 274 In all cases, any DSN generated should indicate the number of 275 retries attempted (where 0 means no retries). 277 The choice to retry or not retry is installation dependent. 278 Effectively, when a relay does not retry, any reposibility for 279 overcoming the delivery failure is passed back to the original 280 sender. This strategy may be appropriate for cases where very 281 rapid delivery is required or expected. 283 [[[Need to limit the number and/or frequency of retries?]]] 285 3.3 Accepting a message by the final MTA 287 The MTA that accepts final delivery of a message has responsibility 288 for passing the message to a Mail User Agent. The exact mechanism 289 by which this is achieved is a local matter, and not defined here 290 or by the Internet e-mail specifications. The final MTA is also 291 responsible for generating any successful DSN message. 293 Before generating a DSN message, the final MTA must ensure that all 294 of the conditions for delivery of the message have been achieved. 296 Specifically, it should ensure that final delivery to the MTA will 297 be completed within the deliver-by interval indicated. Exactly 298 what constitutes final delivery to the MTA may depend somewhat on 299 the nature of the MTA: in the simplest case, depositing the 300 message in a local mailbox probably constitutes final delivery; a 301 more complex case would be that of a fax offramp: in this case it 302 may be reasonable for final delivery to be completion of a 303 successful outdial and transmission of the fax. 305 [[[DISCUSS: In environments where the timing of final delivery of 306 the message is outside the control of the final MTA (e.g. the time 307 required for an outdial, or waiting for a client to collect the 308 message), an interim DSN report may be generated indicating that 309 the message has been received pending final delivery. This report 310 bshould be clear whether final delivery is dependent on the 311 receiving user (e.g. mail collection) or some other unknown 312 infrastructure delay (e.g. fax out-dial or external e-mail 313 environment).]]] 315 Content Negotiation for Internet Fax 22 October 1999 316 318 [[[I think the above is verging on trying to be too clever, getting 319 too far into MDN teritory]]] 321 4. Compliance-required ESMTP extension 323 [[[TBD]]] 325 Essentially, the semantics will be to REQUIRE conformance to any 326 SMTP extensions used for delivery to be successfully completed. 328 [[[I am thinking the required extensions should be listed in the 329 RCPT command; e.g. COMPLIANCE=DSN,DELIVER-BY]]] 331 5. DSN reporting extensions 333 - Extension not supported 335 - Delivery time exceeded 337 - Delivered for further transmission: final confirmation pending 338 [[[???]]] 340 - Delivered for collection by user: final confimation pending 341 [[[???]]] 343 6. Notes 345 [[[These are placeholders for further discussion]]] 347 - Use of alternative port (e.g. like message submission). 349 - Scalability analysis. Required state information -- all at the 350 edges? 352 - Discussion of race conditions. Indeterminacy in time for status 353 response to reach sender. Message duplication as the worst case. 355 - Return path different from forward path. 357 - Handling fine-grained timing requirements (deliver-by 358 modification and implementation techniques). Must assume deliver- 359 by interval is large relative to normal network transit times. 361 - Partial non-delivery: failure to some recipients. Must be 362 handled, since all-or-nothing cannot be imposed within the SMTP 363 transfer environment. 365 Content Negotiation for Internet Fax 22 October 1999 366 368 7. Examples 370 [[[TBD]]] 372 8. IANA Considerations 374 [[[TBD: ESMTP and DSN extension registrations]]] 376 9. Internationalization considerations 378 [[[TBD?]]] 380 10. Security considerations 382 [[[TBD]]] 384 11. Acknowledgements 386 [[[TBD]]] 388 12. References 390 [1] RFC 2542, "Terminology and Goals for Internet Fax" 391 L. Masinter, Xerox Corporation 392 March 1999. 394 [2] RFC 821, "Simple Mail Transfer Protocol" 395 Jonathan B. Postel, ISI/USC 396 August 1982. 398 [3] (SMTP extensions) 400 [4] RFC 1891, "SMTP Service Extension for Delivery Status 401 Notifications" 402 K. Moore, University of Tennessee 403 January 1996. 405 [5] DELIVERBY: 407 [6] 409 [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 410 D. Crocker (editor), Internet Mail Consortium 411 P. Overell, Demon Internet Ltd. 412 November 1997. 414 Content Negotiation for Internet Fax 22 October 1999 415 417 13. Authors' addresses 419 Graham Klyne (editor) 420 Content Technologies Ltd. 421 1220 Parkview, 422 Arlington Business Park 423 Theale 424 Reading, RG7 4SA 425 United Kingdom. 426 Telephone: +44 118 930 1300 427 Facsimile: +44 118 930 1301 428 E-mail: GK@ACM.ORG 430 [[[et. al. TBD]]] 432 Appendix A: Amendment history 434 00a 22-Oct-1999 Memo initially created. 436 TODO: 438 Full copyright statement 440 Copyright (C) The Internet Society 1999. All Rights Reserved. 442 This document and translations of it may be copied and furnished to 443 others, and derivative works that comment on or otherwise explain 444 it or assist in its implementation may be prepared, copied, 445 published and distributed, in whole or in part, without restriction 446 of any kind, provided that the above copyright notice and this 447 paragraph are included on all such copies and derivative works. 448 However, this document itself may not be modified in any way, such 449 as by removing the copyright notice or references to the Internet 450 Society or other Internet organizations, except as needed for the 451 purpose of developing Internet standards in which case the 452 procedures for copyrights defined in the Internet Standards process 453 must be followed, or as required to translate it into languages 454 other than English. 456 The limited permissions granted above are perpetual and will not be 457 revoked by the Internet Society or its successors or assigns. 459 Content Negotiation for Internet Fax 22 October 1999 460 462 This document and the information contained herein is provided on 463 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 464 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 465 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 466 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 467 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.