IETF fax WG                             G. Klyne, Content Technologies
Internet draft                                             [[[et al]]]
                                                     13 September 2000
                                                   Expires: March 2001


           Timely Delivery for Internet Messaging Services
               <draft-ietf-fax-timely-delivery-01.txt>

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 2000.  All Rights Reserved.

Abstract

  This proposal describes a way to request timely delivery for
  facsimile, voice and other messaging services that use Internet
  e-mail.  It provides a deterministic service quality response,
  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 a new COMPLIANCE extension for establishing the
  deterministic service quality response.








Klyne, et al                Internet draft                    [Page 1]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  NOTE: This is an early, preliminary version of specification,
  indicating a possible way to achieve the timely delivery
  requirement for full mode Internet fax.  The content is rough, and
  the intent at this time is to indicate the outline of a mechanism.
  Please address comments to major structural and semantic issues.

Discussion of this document

  Please send comments to:  <ietf-fax@imc.org>.

  To subscribe:  send a message with the body 'subscribe' to <ietf-
  fax-request@imc.org>.

  The mailing list archive is at:  <http://www.imc.org/ietf-fax/>.


Table of contents

1. Introduction.............................................3
  1.1 Structure of this document ...........................3
  1.2 Document terminology and conventions .................3
2. Background and goals.....................................3
  2.1 Background ...........................................3
  2.2 Basis for timely delivery ............................4
     2.2.1 The SMTP "contract"..............................4
     2.2.2 Framework for timely delivery....................5
  2.3 Why is 'compliance required' included? ...............6
  2.4 Goals for timely delivery ............................6
3. Mechanisms for timely delivery...........................7
  3.1 Transmitting a message for timely delivery ...........7
  3.2 Relaying a message ...................................8
  3.3 Accepting a message by the final MTA .................9
  3.4 Timely confirmation ..................................10
4. Compliance-required ESMTP extension......................11
5. DSN reporting extensions.................................11
6. Notes....................................................11
7. Examples.................................................12
8. IANA Considerations......................................12
9. Internationalization considerations......................12
10. Security considerations.................................12
11. Acknowledgements........................................12
12. References..............................................12
13. Authors' addresses......................................13
Appendix A: Amendment history...............................14
Full copyright statement....................................14










Klyne, et al                Internet draft                    [Page 2]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>




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
       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.]]]


2. Background and goals

  RFC 2852 [5] provides a mechanism to request timely delivery of a
  message using SMTP.  While this is helpful, it falls short of the
  goals for timely delivery of fax messages.  These goals are
  determined, in part, by the capabilities of traditional facsimile
  [8].

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
       received and processed





Klyne, et al                Internet draft                    [Page 3]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  From the sender's point of view, timely confirmation of receipt and
  processing is the most desirable requirement.

2.2 Basis for timely delivery

  A key premise of this proposal is that timeliness CAN be achieved
  using existing protocols, with appropriate software design and
  operational management.  BUT the sender and receiver do not control
  all the relays used:

  o  The real issue is lack of determinism:  a message might be
     delivered quickly, or it might take hours or even days, or it
     might not be delivered at all;  the sender has little knowledge
     and no control.

  o  A secondary issue is post-delivery handling:  will the receiving
     user agent process the message in timely fashion?

  One challenge to achieving this is dealing with uncertain transit
  times of the confirmation message over the return path (which is
  not necessarily the same as the forward path).

2.2.1 The SMTP "contract"

  On accepting a message, a normal SMTP message transfer agent (MTA)
  accepts responsibility to:

  (a)  use best efforts to ensure delivery of the message, or

  (b)  provide notification that delivery could not be achieved.

  This memo introduces mechanisms to allow this contract to be
  modified.  A timely-delivery MTA accepts responsibility to:

  (a)  use reasonable efforts to ensure delivery within a specified
       time, and to provide timely confirmation of delivery, or

  (b)  provide timely notification that delivery was not achieved.

  The sender can then decide a recovery strategy















Klyne, et al                Internet draft                    [Page 4]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


2.2.2 Framework for timely delivery

  The diagram shows typical SMTP message delivery and delivery status
  notification (DSN) paths.  Note that the confirmation path is not
  necessarily the same as the message delivery path.

                        Outbound message -->

         +-------+     +-----+     +-----+     +---------+
         |Sending|-->--|Relay| >>> |Relay|-->--|Receiving|
         | MTA   |     | MTA |     | MTA |     |   MTA   |
         +-------+     +-----+     +-----+     +---------+
           |                                     |     |
           ^                                     |     v
           |                                     |     |
     +-------+                                   |   +---------+
     |Sending|                                   |   |Receiving|
     |  UA   |-<-------------  <<<  -------------    |   UA    |
     +-------+                                       +---------+
                    <-- Return confirmation

  As well as requesting timely delivery of a message, this proposal
  needs to take account of the possibly varying characteristics of
  relays of the outbound and return message paths.  Practically, it
  is possible to require that every relay on the outbound path
  recognizes timely delivery semantics (using the ESMTP extension
  framework), but it is not possible to require this of every relay
  on the return path.  Thus, it may be necessary to make some
  assumptions about the confirmation return path.

       NOTE:  The uncertainty about return path characteristics
       might be removed by requiring an MTA to send any timely
       delivery notifcation to the MTA from which it was
       received, but this goes against trends in SMTP design and
       deployment.  This might also raise state maintenance and
       hence scalability concerns.

  The other issue apparent from the diagram is that providing timely
  delivery through the SMTP message relays does not ensure that the
  receiving MTA will process the message in a timely fashion.  If the
  receiving MTA delivers to a POP mailbox, thereis no way that it can
  guarantee timely delivery.













Klyne, et al                Internet draft                    [Page 5]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


2.3 Why is 'compliance required' included?

  For the purposes of SMTP transfer, the "compliance required"
  feature is not required and there is a strong case for pursuing
  timely delivery without that part.

  But consider the following scenario:

     +--------+     +-------+     +-----------+     +-----------+
     | Sender |-->--| Relay |-->--| Receiving |-->--| Disposing |
     |  MTA   |     |  MTA  |     |   MTA     |     |   agent   |
     +--------+     +-------+     +-----------+     +-----------+

               <------SMTP------->             <-?->

  The DELIVER-BY specification concerns itself only with the SMTP
  transfers.  But for the purposes of timely delivery, the goal is
  not satisfied from a user perspective unless the disposition also
  completes in "timely" fashion.

  The "compliance required" option expects that the receiving MTA
  communicates with the disposing agent (in some unspecified way),
  and confirms final delivery of the message only if the disposing
  agent confirms that it will deal with the message in timely
  fashion.  Simply putting the message into a POP mailbox would not
  meet this criterion.  It also permits an MTA to commute its
  responsibility for delivering the message from "best effort" to
  "reasonable effort".

  This is all consistent with the fundamental strategy of giving the
  sender control over the whole process:  if the disposing agent
  cannot communicate the required guarantee, delivery is not
  completed and the sender is duly notified.

2.4 Goals for timely delivery

  The primary goal is to provide a mechanism that allows consenting
  parties to establish a relationship with guaranteed delivery within
  a specified time, or notification that the delivery was not
  achieved.

  Further goals are:

  o  Provide "while-you-wait" delivery of facsimile messages by e-mail
     (where available infrastructure and connectivity permits).

  o  Deterministic behaviour.  A sender who requests timely delivery
     should be able to determine with reasonable certainty whether or
     not that request was successful.






Klyne, et al                Internet draft                    [Page 6]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  o  If the message cannot be delivered as requested, it should not be
     delivered at all.  This means that a sender can take control over
     alternative strategies for message delivery (e.g. if timely
     delivery by e-mail does not succeed, to resend the message as a
     traditional facsimile;  in such circumstances it is preferable
     that multiple copies of the message are not delivered.

  o  Operates within the existing ESMTP extension framework [3],using
     existing facilities where available.


3. Mechanisms for timely delivery

  Timely delivery is achieved through a number of ESMTP extensions
  used in concert:

  o  Delivery Status Notification ("DSN"), per RFC 1891 [4].

  o  Deliver-by ("DELIVERBY"), per RFC 2852 [5]

  o  A new "Compliance-required" extension, that serves to modify the
     SMTP contract and also to establish that the receiving user agent
     can process the message in timely fashion as required.

  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 than the forward path of the
  original message.

     +-----------+     +--------+     +--------+     +---------+
     |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving|
     |    MTA    |     |  MTA   |     |  MTA   |   --|   MTA   |
     +-----------+     +--------+     +--------+  |  +---------+
            |                                     |       |
     +-------------+                              |  +---------+
     | Originating |--<--  ...   ....   ...  --<--   |Receiving|
     |     MUA     |                                 |   MUA   |
     +-------------+                                 +---------+

3.1 Transmitting a message for timely delivery

  A transmitted message for which timely delivery is required MUST
  include the following:

  o  an 'ENVID' parameter on the MAIL command, per DSN [4]

  o  a 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT
     command, per DSN [4]

  o  an 'ORCPT' parameter on the MAIL command, per DSN [4]





Klyne, et al                Internet draft                    [Page 7]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  o  a 'BY' parameter on the corresponding RCPT command, per [5], with
     a 'by-mode' value of 'R'.

  o  a 'COMPLIANCE=TIMELY' 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]]]

  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.







Klyne, et al                Internet draft                    [Page 8]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  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.

       NOTE:  The presence of a 'COMPLIANCE=TIMELY' option may
       cause a relay to abandon a message that it would
       otherwise retry (even given a 'by-mode' value of 'R').
       The intent of this option is to establish that
       responsiveness to the sender is more important than
       getting the message through.  One effect of this may be
       to severely constrain the number and frequency of retry
       attempts.

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.

  In the presence of a 'COMPLIANCE=TIMELY' option, final delivery
  should not be completed unless the delivery MTA can establish that
  the receiving MUA will deal with the message promptly.  Here
  "promptly" means a reasonable waiting time for a human;  e.g. that
  the message (or at least the start of the message) will be
  available to its intended final recipient in a time comparable with
  that taken to establish a telephone call.

  [[[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





Klyne, et al                Internet draft                    [Page 9]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  the message has been received pending final delivery.   This report
  should 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).]]]

  [[[I think the above is verging on trying to be too clever, getting
  too far into MDN teritory]]]

3.4 Timely confirmation

  Fully deterministic behaviour requires that the round-trip time to
  deliver a message and receive a response is completed within a
  known time interval.

  As noted above, it cannot be guaranteed that confirmation of
  delivery or non-delivery will be transferred in timely fashion.  It
  seems reasonable to assume that return path transit times will
  normally be comparable with forward path times.

  Further, it is likely that perfect determinism can never be
  achieved using SMTP;  e.g. see RFC 1047 [9].  Repeat deliveries are
  probably less harmful than lost messages, but even these should be
  minimized.

  The following behaviour is proposed for achieving nearly
  deterministic behaviour:

  o  Always fail forward delivery if non-TIMELY MTA is encountered.

  o  Use the DELIVER-BY option to request timely delivery for DSN
     return, using same total time (x2?) as forward path, but
     specifying a 'by-mode' value of 'N' rather than 'R'.

  o  Use a high priority option for the DSN return (for MTAs that may
     take note of such things).

  o  Do NOT fail notification delivery if non-TIMELY or non-DELIVER-BY
     MTA is encountered on the return path.

  o  The return DSN does not itself request delivery-notification (as
     required by DSN).

  o  Sender may assume that message is lost after some multiple of
     original DELIVER-BY interval has passed without notificaton (x4
     is suggested).

  o  Sender is required to provide envelope ID with message.  If it
     re-tries, it should use same envelope ID and should do so within






Klyne, et al                Internet draft                   [Page 10]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


     some multiple of DELIVER-BY interval (x6 suggested) since the
     last retry.

  o  The receiver of a TIMELY message is strongly encouraged to keep
     note of received envelope ID for some multiple of the DELIVER-BY
     interval (x8 suggested) for the purpose of weeding out
     duplicates.


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.

  Unlike declared ESMTP extensions, this option requires the
  extensions to be applied for a specific message.

  [[[A simpler approach might be to simply define an extension and
  parameter called TIMELY whose semantics are similar to those
  attributed to COMPLIANCE=TIMELY.]]]


5. DSN reporting extensions

  [[[Details TBD]]]

  - 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?








Klyne, et al                Internet draft                   [Page 11]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


  - 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.


7. Examples

  [[[TBD]]]


8. IANA Considerations

  [[[TBD: ESMTP and DSN extension registrations]]]


9. Internationalization considerations

  [[[TBD?]]]


10. Security considerations

  [[[TBD]]]


11. Acknowledgements

  The authors thank Hiroshi Tamura-san for undertaking the task of
  reviewing a very rough, early draft and making several pertinent
  observations.


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.










Klyne, et al                Internet draft                   [Page 12]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


[3]  RFC 1651, "SMTP Service Extensions"
     J. Klensin, MCI
     N. Freed, Innosoft
     M. Rose, Dover Beach Consulting, Inc.
     E. Stefferud, Network Management Associates, Inc.
     D. Crocker, Silicon Graphics, Inc.
     July 1994.

[4]  RFC 1891, "SMTP Service Extension for Delivery Status
     Notifications"
     K. Moore, University of Tennessee
     January 1996.

[5]  RFC 2852, "Deliver By SMTP Service Extension"
     D. Newman, Sun Microsystems
     June 2000

[6]  <draft-ietf-fax-content-negotiation-03.txt>

[7]  RFC 2234, "Augmented BNF for Syntax Specifications: ABNF"
     D. Crocker (editor), Internet Mail Consortium
     P. Overell, Demon Internet Ltd.
     November 1997.

[8]  T.30

[9]  RFC 1047


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]]]












Klyne, et al                Internet draft                   [Page 13]
Content Negotiation for Internet Fax                      13 September
<draft-ietf-fax-timely-delivery-01.txt>


Appendix A: Amendment history

  00a  22-Oct-1999  Memo initially created.

  01a  13-Sep-1999  Incorporate review comments.  Update references.
                    Changed title.  Incorporate material from IETF
                    meeting presentations.

  TODO:




Full copyright statement

  Copyright (C) The Internet Society 2000.  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.

  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 14]