IETF Internet fax WG                                      Graham Klyne
Internet draft                              Integralis Technology Ltd.
                                                          2 April 1998
                                               Expires: 2 October 1998


           Scenarios for Internet fax message confirmation
            <draft-ietf-fax-confirmation-scenarios-00.txt>

Status of this memo

  This document is an Internet-Draft.  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 made obsolete 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''.

  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 (C) 1998, The Internet Society

Abstract

  The simple mode for Internet fax described in [1] does not provide
  positive confirmation of message delivery or disposition.  There is
  a widespread view that an important benefit of traditional fax [2]
  is the fact that it provides a delivery confirmation which is
  trusted by fax system users.

  This memo describes some of the options for message confirmation in
  Internet fax, taking account of the particular nature and goals of
  the application [3], with a view to informing the debate over what
  mechanisms should be used for this purpose.













Klyne                                                         [Page 1]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


Table of contents

1. Introduction.............................................2
  1.1 Terminology ..........................................3
  1.2 Structure of this document ...........................3
  1.3 Discussion of this document ..........................3
  1.4 Amendment history ....................................4
2. Message confirmation issues in Internet fax..............4
3. Current message confirmation mechanisms..................6
  3.1 Group 3 facsimile confirmation .......................6
  3.2 Internet e-mail confirmations ........................6
     3.2.1 Delivery Status Notifications (DSN)..............6
     3.2.2 Message Disposition Notifications (MDN)..........7
     3.2.2 Negative confirmations...........................8
4. Confirmation options and scenarios.......................8
  4.1 Internet e-mail to e-mail ............................8
  4.2 Internet e-mail to fax machine .......................9
  4.3 Fax machine to Internet e-mail .......................9
  4.4 Summary of scenarios .................................10
  4.5 Other mechanisms .....................................12
     4.5.1 Direct delivery..................................12
     4.5.2 Session mode SMTP extension......................12
     4.5.3 Real-time fax image transfer.....................13
5. Security considerations..................................14
6. Copyright................................................14
7. Acknowledgements.........................................15
8. References...............................................15
9. Author's address.........................................17


1. Introduction

  The simple mode for Internet fax described in [1] does not provide
  positive confirmation of message delivery or disposition.  There is
  a widespread view that an important benefit of traditional
  facsimile [2] is the fact that it provides a delivery confirmation
  which is trusted by fax system users.

  Proposals for extended Internet fax [4,5,6] aim to provide for both
  positive and negative confirmation of transmission of fax messages
  which go beyond the limited negative acknowledgement capabilities
  of SMTP [7].

  This memo describes some of the options for message confirmation in
  Internet fax, taking account of the particular nature and goals of
  the application [3], with a view to informing the debate over what
  mechanisms should be used for this purpose.








Klyne                                                         [Page 2]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


1.1 Terminology

  Terminology used in this document that is specific to Internet fax
  is taken from [3].

1.2 Structure of this document

  The main part of this draft addresses four main areas:

  Section 2 discusses some of the technical issues that make
  provision of traditional facsimile confirmation somewhat
  problematic in Internet e-mail, and contrasts the features of
  traditional fax transport mechanisms with Internet e-mail that make
  this so.

  Section 3 discusses some general concepts and mechanisms that might
  have a bearing on how capability identification might be
  implemented for Internet fax.

  Section 4 describes some options for message confirmations in
  Internet fax.

1.3 Discussion of this document

  Discussion of this document should take place on the Internet fax
  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/

  To unsubscribe from the ietf-fax mailing list, send a message to
  "ietf-fax-request@imc.org" containing the message 'unsubscribe'.

1.4 Amendment history

  00a       01-Apr-1998
            Document initially created.

  00b       03-Apr-1998
            Add material from IETF meeting discussions.  Section 4.4
            is new and helps to draw together some key ideas.





Klyne                                                         [Page 3]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


2. Message confirmation issues in Internet fax

  Technical differences between the Internet e-mail SMTP transport
  [7] and the facsimile T.30 transmission protocol [2] that tend to
  dictate different approaches to capability exchange are:

  .  SMTP separates the functions of message transmission from message
     preparation and message display.  Message transmission is
     performed by Message Transfer Agents (MTAs), and message
     preparation and display is handled by Message User Agents (MUAs).

     The MTA and MUA components of Internet e-mail deal with separate
     protocol elements: MTAs work with the SMTP protocol [7], where
     MUAs deal with construction and processing of RFC822 e-mail
     messages [8].  (MUAs also operate as SMTP clients for the purpose
     of initiating a message transfer)

     This separation of message transmission from message processing
     has a distinct bearing on the forms that a message confirmation
     can take:  one form handled by MTAs is DSN [9], another form
     handled by MUAs is MDN [10].  Further discussion of these appears
     later.

     A receiving MTA can be either a Message Store (MS) or a Gateway
     to some other kind of messaging system (GW).

  .  SMTP is a store-and-forward protocol, which means that the sender
     of a message is generally disengaged from the message transfer
     process at the time final delivery is accomplished. T.30, on the
     other hand, is a session mode protocol in which the transmitter
     of a message is directly involved in the process until final
     delivery is accomplished and signalled back to the sender.

     (There is a proposal to provide a session mode capability in
     SMTP, but in its present form even this may be forced to fall
     back to store-and-forward mode in some circumstances.)

     Because SMTP is a store-and-forward protocol, there may be
     arbitrary delays in the transfer of a message, and it is not
     generally possible to provide any kind of confirmation during the
     protocol session that sends a message.

  .  In traditional facsimile, message delivery and disposition
     (printing) are often handled at the same time and place:  with
     SMTP, the processes of delivery (e.g. to a POP mailbox) and
     disposition (e.g. collection and display of message) may be
     separated in time and space.








Klyne                                                         [Page 4]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


     There are exceptions to this, such as fax machines that receive
     into memory, and print later.  But it is widely held that the
     "user model" of fax that it is printed as soon as it has been
     sent.

  .  Being a store-and-forward Internet protocol, SMTP can service
     occasionally connected correspondents;  thus there is no
     requirement or expectation for the ultimate recipient to be
     accessible at the time a message is sent.  Traditional facsimile,
     on the other hand, relies on the fact that telephone devices are
     always physically connected to the network and available to
     receive calls (except when they are busy).

     A related consideration is that SMTP senders do not have to be
     concerned with the possibility that the recipient is busy at the
     time a message is sent, but the next-hop MTA may be unavailable
     for a variety of reasons so some system of retries is required.

  .  In T.30, the sender of a message connects directly to and
     interacts with the receiver.  Using SMTP, this is not generally
     the case and an indeterminate number of intermediate relays
     (MTAs) may be involved in the transmission process. The
     capabilities of these intermediate systems to handle confirmation
     mechanisms is not generally known.

  .  In general, there are significant per-message call setup and
     volume-related transmission costs associated with traditional
     facsimile.  When using SMTP, there are generally no per-message
     or volume-related transmission costs.  (This is a simplification,
     and there are exceptions in both cases, but this holds widely
     enough to be a good working model.)


3. Current message confirmation mechanisms

  There are two mechanisms currently defined for providing message
  confirmations in Internet e-mail, neither of which exactly match
  the traditional Group 3 facsimile confirmation mechanism.

3.1 Group 3 facsimile confirmation

  Group 3 fax confirmation relies upon a real-time connection from
  the sender to receiver.  As each page of image data is transmitted,
  a real-time protocol exchange occurs during which the receiver
  indicates that the page has been received OK.

  The confirmation generated by the receiving system often, but not
  always, indicates that the received data has been printed.  What it
  does always indicate is that the data has been received and that
  the receiving system has all information needed to process and





Klyne                                                         [Page 5]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


  print the data;  i.e. that it has accepted responsibility for
  further processing of the data.

  There may always be circumstances when a G3 fax confirmation does
  not guarantee that the intended recipient will see the message.  A
  power failure may destroy the message data stored in the receiving
  facsimile machine;  a printed message may be removed and lost
  before the intended recipient can see it.  But these are unlikely
  events, and a Group 3 confirmation of receipt is generally a good
  indication that the recipient will see the message.

3.2 Internet e-mail confirmations

  It should be noted that, in the Internet e-mail environment,
  message confirmations are generated only when explicitly requested
  by the sender of a message.  This rule is necessary to ensure that
  message confirmation loops to not occur.

3.2.1 Delivery Status Notifications (DSN)

  The request for DSN [9] is carried by the SMTP protocol, and is
  processed by MTAs.

  Advantages are:

  .  The sender is guaranteed some kind of response (unless the status
     notification itself is lost in transit).

  .  The generation of DSN notifications does not depend upon the
     capabilities of the receiving MUA.

  Disadvantages are:

  .  End-to-end DSN requires the support of every MTA along the
     transmission path from sender to recipient.  If any one of these
     MTAs does not support DSN then a notification response is
     generated at that point which tells the sender how far the
     message had progressed up to that point, but cannot provide
     information about its further progress

     Thus, the information provided by DSN may be of limited value.

  .  Even when DSN is fully supported by all MTAs, the final
     notification might still not indicate that the message has been
     delivered to the recipients receiving terminal.  When the
     recipient uses a mailbox protocol (e.g. POP3 [11]) to collect
     message, MTA delivery is achieved on receipt of the message into
     a message store serviced by the POP3 server.  The recipient still
     has to collect the message from the mailbox server before he can
     process it.





Klyne                                                         [Page 6]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


3.2.2 Message Disposition Notifications (MDN)

  A request for MDN [10] is carried in the message body where it is
  hidden from the activities of MTA.  The receiving MUA (or gateway)
  is responsible for generating all responses to an MDN request.

  Advantages are:

  .  End-to-end confirmation does not depend upon the capabilities of
     any MTA used to transmit the message.

  Disadvantages are:

  .  Generation of a response to MDN depends upon the capabilities of
     the receiving MUA.  If it does not recognize the MDN request then
     no MDN can be generated.

  .  There are a number of important security considerations
     associated with the use of MDNs, and they may not be generated
     without the receiving user's consent.  For normal e-mail MUAs,
     this means that a receiving user may prohibit generation of an
     MDN with no indication of this fact passed back to the sender.

     The security concerns are with possible disclosure of private
     information about a user (e.g. an MDN request in a message to a
     mailing list might be used to gather addresses for spamming), or
     with disclosure of information about the activities of a user
     (e.g. the response to an MDN might disclose that the user was
     connected to the Internet or reading e-mail at a particular
     time).

3.2.2 Negative confirmations

  The discussions above address mechanisms for positive message
  confirmation.

  For negiative confirmation (reporting of errors on the transmission
  path), Delivery Status Notifications are required, because there
  can be no guarantee that an Message Disposition Notification will
  ever be generated.  If a message is lost at any point along the
  path from sender to delivery point, there is no way for generation
  of an MDN to be triggered.

  Thus, in all cases, DSNs must are required for negative message
  confirmation.










Klyne                                                         [Page 7]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


4. Confirmation options and scenarios

  In this section, some options and message confirmation scenarios
  are suggested.

4.1 Internet e-mail to e-mail

      (1)              (2)             (3)               (4)
     +----------+     +---------+     +-----------+     +-----------+
     |Sender-MUA|-->--|Relay-MTA|-->--|Receive-MTA|-->--|Receive-MUA|
     +----------+     +---------+     +-----------+     +-----------+

  .  DSN end-to-end:  with DSN implemented at (2) and (3), provides
     notification of delivery to (3).  If (3) is a mailbox server, no
     indication of collection by (4) will be returned.

  .  DSN part-way:  with DSN implemented at (2) but not at (3),
     provides indication that the message was delivered to (3), but
     that no information about any further MTA hops will be provided.

  .  DSN not implemented:  with DSN not implemented at (2), the
     sending MUA knows only that the message was accepted at (2) for
     onward delivery.

  .  MDN implemented: if (4) implements MDN then an MDN might be
     generated when the message is received and displayed at (4).  But
     the user at (4) may choose to prohibit generation of MDN.

  .  MDN implemented at receiving Internet Fax (IFAX) device:  in this
     case, it might be possible to relax the conditions regarding
     automatic generation of MDN, since the security concerns about
     user privacy may not apply, to provide a dependably confirmation
     of receipt.

4.2 Internet e-mail to fax machine

      (1)              (2)             (3)               (4)
     +----------+     +---------+     +-----------+     +-----------+
     |Sender-MUA|-->--|Relay-MTA|-->--|offramp-MTA|-->--|Receive-fax|
     +----------+     +---------+     +-----------+     +-----------+

  .  DSN end-to-end:  with DSN implemented at (2) and (3), can
     provides notification of delivery to (4), assuming the offramp
     uses the T.30 confirmation from (4) to generate a DSN response.

  .  DSN part-way:  with DSN implemented at (2) but not at (3),
     provides indication that the message was delivered to the offramp
     (3), but that no information about receipt by (4) will be
     forthcoming.






Klyne                                                         [Page 8]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


  .  DSN not implemented:  with DSN not implemented at (2), the
     sending MUA knows only that the message was accepted at (2) for
     onward delivery, (just like corresponding the e-mail to e-mail
     case).

  .  MDN implemented: if (3) implements MDN then an MDN can be
     generated when the fax is delivered to (4), triggered by the T.30
     confirmation from (4).

     This is a situation where the prohibition of automatic MDNs can
     be relaxed, because they would not disclose information about the
     recipient which is not available by calling the receiving fax
     machine directly.

4.3 Fax machine to Internet e-mail

      (1)              (2)              (3)             (4)
     +----------+     +----------+     +---------+     +-----------+
     |Sender-fax|-->--|Onramp-MTA|-->--|Relay-MTA|-->--|Receive-MUA|
     +----------+     +----------+     +---------+     +-----------+

  .  DSN end-to-end:  with DSN implemented at (2) and (3), provides
     notification of delivery to (3).  If (3) is a mailbox server, no
     indication of collection by (4) will be returned.

     But, the confirmation of delivery received at (2) will be too
     late to provide a normal T.30 message confirmation back to (1).
     Confirmation of receipt would have to be provided by a separate
     out-dial by (2) and fax transmission of a confirmation slip.
     (The out-dial might be avoided by having the sender-fax poll for
     confirmation, but this would require a change of behaviour in the
     installed fax base, so is considered impractical.)

     The T.30 confirmation received at (1) will indicate only that the
     fax was received by the onramp, and no more.  To do better than
     this, it will be necessary to find ways of delivering the fax
     message to (3) within the time constraints imposed by the T.30
     protocol.

  .  DSN not implemented:  with DSN not implemented at (2), the
     sending fax machine receives an indication meaning only that the
     message was accepted at (2) for onward delivery.

  .  MDN implemented: if (2) and (4) implement MDN then an MDN might
     be generated when the message is received and displayed at (4).
     But the user at (4) may choose to prohibit generation of MDN.
     Also, the timing of any confirmation is subject to the same
     considerations as the end-to-end DSN case described above.







Klyne                                                         [Page 9]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


  .  MDN implemented at (2) and a receiving Internet Fax (IFAX) device
     at (4):  in this case, it might be possible to relax the
     conditions regarding automatic generation of MDN, since the
     security concerns about user privacy may not apply, to provide a
     dependably confirmation of receipt.  But timing considerations
     still apply.

4.4 Summary of scenarios

  The various scenarios touched in the preceding sections can be
  summarized in four basic scanarios (not including onramp cases):

      (1)                 (2)                        (3)
     +------+            +----------+               +------------+
     |Sender|->-(SMTP)->-|Receive-MS|->-(collect)->-|Receive-USER|
     +------+            +----------+               +------------+

  (A) This is the standard e-mail case where a receiving user
  collects messages from a message store, using a mailbox protocol
  such as POP or IMAP, or using some other local collection
  mechanism.

      (1)                 (2)                        (3)
     +------+            +----------+   (auto-  )   +------------+
     |Sender|->-(SMTP)->-|Receive-MS|->-(collect)->-|Receive-IFAX|
     +------+            +----------+               +------------+

  (B) This is an IFAX-to-IFAX case, where the receiving IFAX device
  collects from a message store using POP or IMAP.

  In protocol terms this is identical to the case above, but differs
  in its security implications because the collection of messages is
  presumed to be done automatically (e.g. on a regular timed basis).

      (1)                 (2)
     +------+            +------------+
     |Sender|->-(SMTP)->-|Receive-IFAX|
     +------+            +------------+

  (C) This is a simple IFAX-to-IFAX case using just SMTP.

      (1)                 (2)                          (3)
     +------+            +----------+                 +-----------+
     |Sender|->-(SMTP)->-|Receive-GW|->-(GSTN,T.30)->-|Receive-FAX|
     +------+            +----------+                 +-----------+

  (D) This case has SMTP delivery to an offramp gateway which in turn
  delivers to a receiving traditional facsimile machine via GSTN.







Klyne                                                        [Page 10]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


  Analysis of these cases suggests:

  (A) needs DSN.

  (B) needs automatically generated MDNs, or an enhanced DSN which
      can trigger notifcation when a message is collected from the
      store.

  (C) can use DSN or automated MDN.

  (D) can use DSN or automated MDN.

  Analysis of these cases suggests a possible interpetation of DSN
  which is very similar to the meaning of Group 3 facsimile
  coinfirmation, which might be made appropriate to all cases:

          A positive DSN response means that the message has
          been delieved to a point from which it requires
          action on the part of the recipient to collect.

4.5 Other mechanisms

  This section introduces some additional options which might be used
  to extend the various scenarios described above.

  The combination of session mode and direct delivery might be used
  to provide the closest possible approximation to traditional fax
  confirmation that can b achieved using MTA-based mechanisms.

4.5.1 Direct delivery

  If the sending MUA implements direct mail routing, following the
  procedures described in RFC 974 [13], the problems of intervening
  MTAs that do not implement required features may be avoided.

  This approach may be subject to difficulties when trying to cross
  corporate firewalls, etc.

  [[QUESTION: can this approach guarantee direct delivery?  I
  understand that DNS MX records may be used to direct all mail to,
  say, a corporate MTA for content analysis, etc., before it is
  delivered to the receiving MTA.]]













Klyne                                                        [Page 11]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


4.5.2 Session mode SMTP extension

  An SMTP extension for immediate delivery is proposed in [12].  This
  proposal operates at the MTA level (like DSN), and provides for
  immediate delivery and confirmation of delivery within a single
  SMTP protocol session between the sender MUA and first-hop MTA.
  The immediate delivery and confirmation semantics may be maintained
  through relay MTAs which support this extension.

  If the timing constraints of T.30 can be satisfied by the
  underlying transport mechanisms, this approach offers a possibility
  for providing a T.30 confirmation which indicates receipt at the
  receiving MTA.

  In its present form the overall message transfer may be forced to
  fall back to store-and-forward delivery if an intervening MTA
  cannot complete a transfer in session mode, due to the way that
  SMTP handles responsibility for message delivery. RFC 1047 [14]
  contains a useful analysis of some of the issues involved.

4.5.3 Real-time fax image transfer

  If a mechanism other than Internet e-mail is used to transfer fax
  messages across the Internet, that mechanism can be defined with a
  confirmation mechanism which mimics the T.30 mechanism.

  The disadvantage of this approach is that interoperability with
  Internet e-mail users may be sacrificed.

  It is conceivable that SMTP and real-time fax transfer mechanisms
  may be combined to provide mechanisms which provide
  interoperability with Internet e-mail, but allow message
  confirmation semantics to more closely match those of T.30.

  It involves moving the fax gateway functions away from the
  Internet/GSTN boundary.  The simple onramp/offramp scenario is:

     +---+         +------+         +------+
     |G3 |<--(A)-->|On/Off|<--(B)-->|e-mail|
     |fax|         | ramp |         |system|
     +---+         +------+         +------+
                      ||
     <......GSTN.....>||<.....TCP/IP.......>
                      ||

  where protocol (A) is T.30 over GSTN, and protocol (B) is SMTP-
  over-TCP/IP (and friends).








Klyne                                                        [Page 12]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


  If the Onramp/Offramp fax gateway functions are separated from the
  GSTN-TCP/IP boundary, an extended version of this can be envisaged:

     +---+         +---------+         +-------+         +------+
     |G3 |<--(A)-->|Transport|<--(C)-->|  Fax  |<--(B)-->|e-mail|
     |fax|         |converter|         |gateway|         |system|
     +---+         +---------+         +-------+         +------+
                       ||
     <......GSTN......>||<.....TCP/IP...........................>
                       ||

  In this case, protocol (C) is some form of real-time fax transfer
  (e.g. tunnelling of T.30 in TCP/IP), and (A)and (B) are as before.


5. Security considerations

  The following are primary security concerns for message
  confirmation mechanisms:

  .  Unintentional disclosure of private information, including
     possible information about a recipient's activity at the time of
     receipt, caused by automated generation of confirmations.

  .  Disruption to system operation (e.g. message loss), or
     inappropriate actions taken by the sender, caused by accidental
     or malicious provision of incorrect message confirmations.

  .  In a mixed Internet/GSTN environment, meeting the costs of any
     additional telephone calls that might be required to return a
     message confirmation.

  Some of the options for message confirmation that are discussed are
  very much coloured by the concerns for user privacy.

  Security considerations relevant to Internet fax are discussed
  further in [1,3].


















Klyne                                                        [Page 13]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


6. Copyright

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


7. Acknowledgements

  The ideas in this document came from a meeting with particular
  contributions from James Rafferty, Larry Masinter, Dan Wing and
  Dave Crocker.

  The summary of scenarios section is from a presentation by Larry
  Masinter.

  Further ideas have been taken from postings to the IETF-FAX mailing
  list, and various of the Internet drafts cited below.















Klyne                                                        [Page 14]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


8. References

[1]  "A Simple Mode of Facsimile Using Internet Mail"
     K. Toyoda,
     H. Ohno
     J. Murai, WIDE Project
     D. Wing, Cisco
     RFC 2305
     March 1998

[2]  ITU Recommendation T.30:
     "Procedures for document facsimile transmission in the General
     Switched Telephone Network"
     International Telecommunications Union, 1996

[3]  "Terminology and Goals for Internet Fax"
     Larry Masinter, Xerox Corporation
     Internet draft: <draft-ietf-fax-goals-02.txt>
     Work in progress, March 1998

[4]  "Extended Facsimile Using Internet Mail"
     Larry Masinter, Xerox Corporation
     Dan Wing, Cisco Systems
     Internet draft: <draft-ietf-fax-eifax-00.txt>
     Work in progress, March 1998

[5]  "Extended MDN for IFAX full mode"
     Mr Maeda, Canon Inc
     Internet draft: <draft-ietf-fax-mdn-fullmode-00.txt>
     Work in progress, March 1998

[6]  "Procedures for the Transfer of Facsimile Data via Internet Mail"
     D. Crocker, Internet Mail Consortium
     Internet draft: <draft-ietf-fax-itudc-00.txt>
     Work in progress, October 1997

[7]  RFC 821, "Simple Mail Transfer Protocol"
     J. Postel, Information Sciences Institute,
     University of Southern California
     August 1982.

[8]  RFC 822, "Standard for the format of ARPA Internet text messages"
     D. Crocker, Department of Electrical Engineering,
     University of Delaware
     August 1982.

[9]  RFC 1891, "SMTP service extension for delivery status
     notification"
     K. Moore, University of Tennessee
     January 1996.





Klyne                                                        [Page 15]


Internet draft                                            2 April 1998
Scenarios for Internet fax message confirmation


[10] RFC 2298, "An Extensible Message Format for Message Disposition
     Notifications"
     R Fajman, National Institutes of Health
     March 1998.

[11] RFC 1939: "Post Office Protocol - Version 3"
     J. Myers, Carnegie Mellon
     M. Rose, Dover Beach Consulting, Inc.
     May 1996

[12] "SMTP Service Extension for Immediate Delivery"
     Dan Wing,
     Neil Joffe, Cisco Systems
     Larry Masinter, Xerox Corporation
     Internet draft: <draft-ietf-fax-smtp-session-02.txt>
     Work in progress, February 1998

[13] RFC 974, "Mail Routing and the Domain System"
     Craig Partridge, CSNET CIC BBN Laboratories Inc
     January 1986.

[14] RFC 1047, "Duplicate Messages and SMTP"
     Craig Partridge, CIC at BBN Laboratories
     February 1988.


9. Author's address

  Graham Klyne
  Integralis Technology Ltd
  Brewery Court
  43-45 High Street
  Theale
  Reading, RG7 5AH
  United Kingdom

  Telephone: +44 118 930 6060

  Facsimile: +44 118 930 2143

  E-mail: GK@ACM.ORG














Klyne                                                        [Page 16]