IETF fax WG G. Klyne, Content Technologies Internet draft [[[et al]]] 22 October 1999 Expires: April 2000 Timely Delivery for Facsimile Using Internet Mail Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 1999. All Rights Reserved. Abstract This proposal is to describe a way to accomplish timely delivery of e-mail messages, with deterministic service quality guarantee, while preserving the traditional roles and responsibiltiies of the agents involved in e-mail transfers. It is essentially a profile of the DSN and DELIVERBY extentions for ESMTP, [[[and possibly]]] a new extension for establishing the deerministic service guarantee. Klyne, et al Internet draft [Page 1] Content Negotiation for Internet Fax 22 October 1999 NOTE: This is a first and very preliminary version of specification, rapidly drafted to indicate a possible way forward to achieve the timely delivery requirement for full mode Internet fax. The content is very rough, and the intent at this time is to indicate just the outline of a mechanism. Please address comments to major structural and semantic issues. Table of contents 1. Introduction.............................................2 1.1 Structure of this document ...........................2 1.2 Document terminology and conventions .................2 1.3 Discussion of this document ..........................3 2. Background and goals.....................................3 2.1 Background ...........................................3 2.2 Goals for timely delivery ............................4 3. Framework for timely delivery............................4 3.1 Transmitting a message for timely delivery ...........4 3.2 Relaying a message ...................................5 3.3 Accepting a message by the final MTA .................6 4. Compliance-required ESMTP extension......................7 5. DSN reporting extensions.................................7 6. Notes....................................................7 7. Examples.................................................7 8. IANA Considerations......................................8 9. Internationalization considerations......................8 10. Security considerations.................................8 11. Acknowledgements........................................8 12. References..............................................8 13. Authors' addresses......................................9 Appendix A: Amendment history...............................9 Full copyright statement....................................9 1. Introduction 1.1 Structure of this document [[[TBD]]] 1.2 Document terminology and conventions [[[TBD]]] NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant Klyne, et al Internet draft [Page 2] Content Negotiation for Internet Fax 22 October 1999 implementation, but may help those who wish to understand the design in greater depth. [[[Editorial comments and questions about outstanding issues are provided in triple brackets like this. These working comments should be resolved and removed prior to final publication.]]] 1.3 Discussion of this document Discussion of this document should take place on the content negotiation and media feature registration mailing list hosted by the Internet Mail Consortium (IMC): Please send comments regarding this document to: ietf-fax@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org". To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-fax/ 2. Background and goals 2.1 Background Traditional e-mail [2] is open-loop. The sender of a message normally has no certainty if or when a message is delivered. (A separate memo [6] contains a discussion of some open- and closed- loop issues in e-mail.) To be more than just a hint to the message transfer system, timely delivery requires a deterministic confirmation mechanism, to close the loop. This is provided by DSN [4]. Three kinds of timeliness can be identified: (a) timely delivery to the receipient (b) timely notification to the sender of delivery (c) timely notification to the sender that the message has been processed This proposal focuses on (a) and (b). A separate proposal is under consideration to address the final case (c). Klyne, et al Internet draft [Page 3] Content Negotiation for Internet Fax 22 October 1999 The DELIVERBY extension [5] provides a mechanism to ensure timely delivery of a message. From the sender's point of view, timely confirmation of delivery is the most desirable requirement. [[[Need to consider how timely confirmation (i.e. delay in the return path transfer of the confrmation) is handled]]] 2.2 Goals for timely delivery The primary goal is to provide a mechanism that allows a consenting parties to establish a relationship with guarenteed delivery within a specified time, or notification that the delivery was not achieved. Further goals are: o Deterministic behaviour. [[[TBD]]] 3. Framework for timely delivery Timely delivery is achieved through a number of ESMTP extensions used in concert: - Deivery Status Notification ("DSN") [RFC 1891] - Deliver-by ("DELIVERBY") [] - Compliance-required [[[NEW!]]] [[[if needed: deliver-by looks nearly sufficient.]]] The confirmation loop for succesful delivery looks something like this. The path through MTAs taken by the confirmation response is not defined, and may be different from the forward path of the original message. +-----------+ +--------+ +--------+ +---------+ |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| | MTA | | MTA | | MTA | --| MTA | +-----------+ +--------+ +--------+ | +---------+ | | | +-------------+ | +---------+ | Originating |--<-- ... .... ... --<-- |Receiving| | MUA | | MUA | +-------------+ +---------+ Klyne, et al Internet draft [Page 4] Content Negotiation for Internet Fax 22 October 1999 3.1 Transmitting a message for timely delivery A transmitted message for which timely delivery is required MUST include the following: - an ENVID parameter on the MAIL command, per DSN [4] - a NOTIFY=SUCCESS,FAILURE parameter on the corresponding RCPT command, per DSN [4] - an ORCPT parameter on the MAIL command, per DSN [4] - a 'BY' parameter on the corresponding RCPT command, per [5] - a COMPLIANCE-REQUIRED parameter on the corresponding RCPT, as described below The message MUST NOT be transmitted to any MTA that does not indicate support for all of these extensions in its response to the EHLO command. In this case, a negative delivery status report MUST be generated indicating the non-compliant MTA, the extensions that it does not support, and the name of the reporting MTA (per DSN, using the non-compliance reporting extensions noted below). 3.2 Relaying a message An MTA that relays a message for timely delivery MUST support all of the ESMTP extensions noted above, otherwise it should not receive the message in the first place. When a relaying MTA accepts a message (by its 2xx status response to receipt of the message data), it becomes responsible for its onward delivery, including satisfying all of the options associated with the message. In order to relay a message, an MTA must note when the message was received, note the time when the attempt to transmit the message to the next MTA is initiated, and reduce accordingly the time interval used for the 'deliver-by' parameter (see note below on handling fine-grained timing requirements). If the deliver-by interval is reduced to less than zero, (or less than some system-configurable value indicating that delivery within the indicated interval is unlikely to be achieved) then the message MUST NOT be relayed. Instead, a negative delivery status report MUST be generated indicating that the time for delivery of the message has expired, and the reporting MTA (per DSN, using the deliver-by extensions and/or non-compliance reporting extensions noted below). [[[Remove duplication between above and DELIVERBY spec]]] Klyne, et al Internet draft [Page 5] Content Negotiation for Internet Fax 22 October 1999 If the first attempt to relay a message fails, the relaying MTA MAY assume that delivery within the desired time will not be achieved, and immediately indicate a delivery failure, indicating the name of the next-hop MTA. Alternatively, the relaying MTA may wait and retry the transmission, provided that the retry attempt will be performed within the remaining deliver-by period; if the transmission cannot be completed after one or more such retries then a negative DSN should be generated as noted above. In all cases, any DSN generated should indicate the number of retries attempted (where 0 means no retries). The choice to retry or not retry is installation dependent. Effectively, when a relay does not retry, any reposibility for overcoming the delivery failure is passed back to the original sender. This strategy may be appropriate for cases where very rapid delivery is required or expected. [[[Need to limit the number and/or frequency of retries?]]] 3.3 Accepting a message by the final MTA The MTA that accepts final delivery of a message has responsibility for passing the message to a Mail User Agent. The exact mechanism by which this is achieved is a local matter, and not defined here or by the Internet e-mail specifications. The final MTA is also responsible for generating any successful DSN message. Before generating a DSN message, the final MTA must ensure that all of the conditions for delivery of the message have been achieved. Specifically, it should ensure that final delivery to the MTA will be completed within the deliver-by interval indicated. Exactly what constitutes final delivery to the MTA may depend somewhat on the nature of the MTA: in the simplest case, depositing the message in a local mailbox probably constitutes final delivery; a more complex case would be that of a fax offramp: in this case it may be reasonable for final delivery to be completion of a successful outdial and transmission of the fax. [[[DISCUSS: In environments where the timing of final delivery of the message is outside the control of the final MTA (e.g. the time required for an outdial, or waiting for a client to collect the message), an interim DSN report may be generated indicating that the message has been received pending final delivery. This report bshould be clear whether final delivery is dependent on the receiving user (e.g. mail collection) or some other unknown infrastructure delay (e.g. fax out-dial or external e-mail environment).]]] Klyne, et al Internet draft [Page 6] Content Negotiation for Internet Fax 22 October 1999 [[[I think the above is verging on trying to be too clever, getting too far into MDN teritory]]] 4. Compliance-required ESMTP extension [[[TBD]]] Essentially, the semantics will be to REQUIRE conformance to any SMTP extensions used for delivery to be successfully completed. [[[I am thinking the required extensions should be listed in the RCPT command; e.g. COMPLIANCE=DSN,DELIVER-BY]]] 5. DSN reporting extensions - Extension not supported - Delivery time exceeded - Delivered for further transmission: final confirmation pending [[[???]]] - Delivered for collection by user: final confimation pending [[[???]]] 6. Notes [[[These are placeholders for further discussion]]] - Use of alternative port (e.g. like message submission). - Scalability analysis. Required state information -- all at the edges? - Discussion of race conditions. Indeterminacy in time for status response to reach sender. Message duplication as the worst case. - Return path different from forward path. - Handling fine-grained timing requirements (deliver-by modification and implementation techniques). Must assume deliver- by interval is large relative to normal network transit times. - Partial non-delivery: failure to some recipients. Must be handled, since all-or-nothing cannot be imposed within the SMTP transfer environment. Klyne, et al Internet draft [Page 7] Content Negotiation for Internet Fax 22 October 1999 7. Examples [[[TBD]]] 8. IANA Considerations [[[TBD: ESMTP and DSN extension registrations]]] 9. Internationalization considerations [[[TBD?]]] 10. Security considerations [[[TBD]]] 11. Acknowledgements [[[TBD]]] 12. References [1] RFC 2542, "Terminology and Goals for Internet Fax" L. Masinter, Xerox Corporation March 1999. [2] RFC 821, "Simple Mail Transfer Protocol" Jonathan B. Postel, ISI/USC August 1982. [3] (SMTP extensions) [4] RFC 1891, "SMTP Service Extension for Delivery Status Notifications" K. Moore, University of Tennessee January 1996. [5] DELIVERBY: [6] [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" D. Crocker (editor), Internet Mail Consortium P. Overell, Demon Internet Ltd. November 1997. Klyne, et al Internet draft [Page 8] Content Negotiation for Internet Fax 22 October 1999 13. Authors' addresses Graham Klyne (editor) Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom. Telephone: +44 118 930 1300 Facsimile: +44 118 930 1301 E-mail: GK@ACM.ORG [[[et. al. TBD]]] Appendix A: Amendment history 00a 22-Oct-1999 Memo initially created. TODO: Full copyright statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Klyne, et al Internet draft [Page 9] Content Negotiation for Internet Fax 22 October 1999 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Klyne, et al Internet draft [Page 10]