One document matched: draft-ietf-fax-confirmation-scenarios-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 06:17:27 |