Fax Working Group Toru Maeda
Internet Draft CANON Inc
Expires: September 1998 10 March 1998
Extended MDN for Internet Fax Full Mode
draft-ietf-fax-mdn-fullmode-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 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."
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).
Abstract
This memo defines an additional MIME content-type defined in Message
Disposition Notifications (MDN) that may be used by a mail user agent
(UA) which is capable of Internet Fax Full Mode with Capabilities
exchange and Confirmation of receipt. This content-type is intended to
be machine-processable. Additional message headers are also defined to
permit that the sender (of the message) requires Message Disposition
Notifications (MDNs). MDN is "An Extensible Message Format for Message
Disposition Notification" in draft-ietf-receipt-mdn-07.txt
Maeda Expiers September 1998 Page 1
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
Table of Contents
1. Introduction ...........................................3
2. Method of capability exchange and confirmation .........5
3. Capability exchange phase ..............................6
4. Message transmission and confirmation phase ............9
5. Security considerations ...............................14
6. Collected Grammar .....................................16
7. Example ...............................................21
8. Acknowledgments .......................................24
9. References ............................................24
10. Copyright .............................................25
11. Author's Address ......................................25
Maeda Expiers September 1998 Page 2
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
1. Introduction
This memo defines an additional MIME content-type for extended message
disposition notifications (MDNs) for Intenet FAX Full Mode. MDN is
defined in "An Extensible Message Format for Message Disposition
Notification" in draft-ietf-receipt-mdn-07.txt [3]. Internet FAX Full
Mode which has capability echange and confirmation is defined in
ITU-T F.Ifax [7] and T.Ifax1 [8]. An extended MDN can be used to
exchange Internet FAX recipient capabilities and to notify the sender
of a message of any of several conditions that may occur after
successful delivery, such as reception of the Internet FAX Full Mode
or the recipient error in process of the Internet FAX Full Mode. An
extended MDN will be used for terminal to terminal capabilities
exchange and confirmation in Internet FAX Full Mode. Capability
exchange more than Internet FAX and TIFF-FX such as MS Word
application and PDF file are out of scope. The
"message/disposition-notification" content-type defined herein is
intended for use within the framework of the "multipart/report"
content type defined in RFC 1892 [6].
Internet FAX Full Mode is defined in F.Ifax [7] as follows;
(a) Capabilities of the terminals are exchanged.
(b) An acknowledgement of receipt is exchanged between gateways
and may be transfered from the receiving terminal to sending
terminal
(c) The contents of standard messages used by the transmitting
terminal are preserved
This memo defines the format of the capability exchange and
confirmation for Internet FAX Fullmode and the RFC 822 headers used
to request them.
The key words "MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT",
"SHOULD","SHOULD NOT","RECOMENDED","MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
New parameters of Disposition-Notification-Option header, modifier,
field are writen with prefix "G3Fax-" to make clear the extension
from MDN. These parameters will be registered to IANA.
Maeda Expiers September 1998 Page 3
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
1.1 Purposes
The extended MDNs defined in this memo are expected to serve
several purposes:
(a) Allow a sender of Internet FAX Full Mode to request
capabilities of recipient's Internet FAX Full Mode in terminal
to terminal communication;
(b) Notify capabilities of recipient's Internet FAX Full Mode to
the sender of Internet FAX Full Mode.
(c) Allow a sender of Internet FAX Full Mode to send image using
full function of TIFF-FX based on notified capabilities of
recipient's Internet FAX Full Mode, to send command and to
request report of recipient's Internet FAX Full Mode;
(d) Notify report of recipient's Internet FAX Full Mode to the
sender of Internet FAX Full Mode with part of received message,
and may notify capabilities
(e) Inform human beings of the disposition of messages after
Successful delivery of Internet FAX Full Mode message, in a
manner which is largely independent of human language;
(f) Allow Language-independed, yet reasonably precise, indications
of the disposition of a message to be delivered in Internet
FAX Full Mode.
1.2 Requirements
These purposes place the following constraints on the capability
exchange and confirmation protocol:
(a) It must be readable by humans as being machine parsable.
(b) It must be provide enough information to allow Internet FAX
Full Mode message senders to unambiguously associate an MDN
with the message that was sent and the original recipient
address for which the MDN is issued.
(c) It must also be able to describe the disposition of a Internet
FAX Full Mode message independent of any particular human
language or of the terminology of any particular mail system.
(d) The specification must be extensible in order to accommodate
future requirements of Internet FAX Full Mode.
Maeda Expiers September 1998 Page 4
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
2. Method of capability exchange and confirmation
A communication between Internet FAX Full Mode machines consists of
two phases that are the capability exchange phase and the message
transmission and confirmation phase. In the capability exchange phase,
a sender of Internet FAX Full Mode sends capability request message
using extended MDN. A recipient of Internet FAX Full Mode must
immediately return message with its capabilities using extended MDN.
In the message transmission and confirmation phase, based on this
reply messages, the sender sends message, command data and confirmation
request using extended MDN. The recipient must immediately returns
confirmation message after the processing of image using extended MDN.
The confirmation message includes human readable message, completion
code, total received page, error page numbers, partial or full
received message and capabilities of recipient. Capability exchange
phase and message transmission and confirmation phase are independent,
and not required to succeeded. A sender may perform capability
exchange phase only when capabilities of the destination is registered
in machine, and perform the message transmission and confirmation
phase for every transmission.
Maeda Expiers September 1998 Page 5
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
3. Capability exchange phase
A sender of Internet FAX Full Mode sends a capability request message
using extended MDN. A recipient of Internet FAX Full Mode must
immediately return a message with capabilities of Internet FAX Full
Mode using extended MDN. Capabilities of Internet FAX Full Mode is
expressed using FCF and FIF in CCITT T.30 [5].
3.1 Capability request message
Capability request message is requested by including a Disposition-
Notification-To and Disposition Notification-Options headers in the
message. Further information to be used by the recipient Internet FAX
Full Mode in generating the capability request may be provided by
including Original-recipient in the message.
A message that contains capability request, should contain a Message-ID
header as specified in RFC 822[2].
3.1.1 Disposition-Notification-To Header
A request that the receiving Internet FAX Full mode issue capability
is made by placing a Disposition-Notification-To header into the
message.
3.1.2 Disposition-Notification-Options Header
Disposition-Notification-Options header provides a request of
capability exchange in Internet FAX Full Mode.
Disposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
disposition-notification-parameters =
parameter *(";" parameter)
parameter = "G3Fax-capability-request" "=" "required"
3.1.3 Message-ID
A message that contains capability request for Internet FAX Full Mode
should contain a Message-ID header as specified in RFC 822[2].
Maeda Expiers September 1998 Page 6
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
3.2 capability response
A capability response message is a MIME message with a top level
content-type of multipart/report (defined in RFC 1892 [6]).
(a) The report-type parameter of the multipart/report content is
"disposition-notification".
(b) The first component of the multipart/report contains a human
readable explanation of the MDN, as described in RFC 1892 [6].
(c) The second component of the multipart/report is of
content-type message/disposition-notification, described in
section of this document.
The capability response must be addressed to the address from the
Disposition-Notification-To header from the original message for which
the capability response is being generated.
The From filed of the message header of the capability response must
contain the address of the Internet FAX Full Mode machine for which
capability response is being issued.
3.2.1 The message/disposition-notification content-type
The message/disposition-notification content-type for capability
response message is defined as follows:
MIME type name: message
MIME subtype name: disposition-notification
Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and
MUST be used.
Security considerations: will be discussed$B!!(J
The syntax of the message/disposition-notification content is
as follows:
disposition-notification-content = [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
original-message-id-field CRLF
disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
Maeda Expiers September 1998 Page 7
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
3.2.2 Final-Recipient-field
The Final-Recipient field indicates the recipient for which the
capability response is being issued.
3.2.3 Original-message-ID
The Original-Message-ID field indicates the message-ID of the message
for which the capability response is being issued. This field must be
present.
3.2.4 Disposition-field
The Disposition filed indicates the action performed by the recipient
of Internet FAX Full Mode. This filed must be present.
Disposition-modifier$B!J(J G3Fax-capability-request$B!K(J will be used for
capability response.
The syntax for the Disposition filed is:
Disposition: automatic-action/MDN-sent-Automatically
; processed / G3Fax-capability-request
3.2.5 Extension-field
Additional MDN field is defined for capability response. Capabilities
of recipient is expressed using FCF and FIF in T30 frame format [5].
field = "G3Fax-t30frame" ":" G3Fax-t30frame-field
G3Fax-t30frame-field = parameter * ( ";" parameter )
parameter = "G3Fax-t30frame-parameter"
G3Fax-t30frame-parameter =
"G3Fax-t30frame" "=" t30-fcf [ "," t30-fif ]
Maeda Expiers September 1998 Page 8
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
4. message transmission and confirmation phase
The sender transmits message, command data and confirmation request
based on previously received messages from the recipient Internet FAX
Full Mode using extended MDN. The recipient returns confirmation
message immediately after the processing of image using extended MDN.
The confirmation message includes human readable message, completion
code, total received page, error page numbers, part or full message of
received and capabilities of recipient.
4.1 message
The sender sends message, command data and confirmation request based
on previous knowledge of recipient Internet FAX Full Mode using
extended MDN.
4.2 Capability request message
Capability request message is requested by including a Disposition-
Notification-To and Disposition Notification-Options headers in the
message. Further information to be used by the recipient Internet FAX
Full Mode in generating the capability request may be provided by
including Original-recipient in the message.
A message that contains capability request, should contain a
Message-ID header as specified in RFC 822[2].
4.2.1 Disposition-Notification-To Header
A request that the receiving Internet FAX Full mode issue confirmation
is made by placing a Disposition-Notification-To header into the
message.
Maeda Expiers September 1998 Page 9
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
4.2.2 Disposition-Notification-Options Header
Disposition-Notification-Options header provides a request of
confirmation and command in Internet FAX Full Mode. Command is
expressed using FCF and FIF defined in CCITT T.30 frame[5].
$B!!!!!!(JDisposition-Notification-Options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
disposition-notification-parameters = parameter *(";" parameter)
parameter = "G3Fax-report-request" "=" "required"
parameter = "G3Fax-frame" "=" t30-fcf [ "," t30-fif ]
4.2.3 Message-ID
A message that contains confirmation request for Internet FAX Full Mode
should contain a Message-ID header as specified in RFC 822 [2].
Maeda Expiers September 1998 Page 10
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
4.3 confirmation
A confirmation message is a MIME message with a top level content-type
of multipart/report (defined in RFC 1892 [6]).
(a) The report-type parameter of the multipart/report content is
"disposition-notification".
(b) The first component of the multipart/report contains a human
readable explanation of the MDN, as described in RFC 1892.
(c) The second component of the multipart/report is of content-
type message/disposition-notification, described in section
of this document.
(d) If the original message or a portion of the message or report
is to be returned to the sender. The decision of whether or
not to return the message or report is up to the Internet FAX
Full Mode recipient.
The confirmation must be addressed to the address from the Disposition-
Notification-To header from the original message for which the
confirmation is being generated.
The From filed of the message header of the confirmation must contain
the address of the Internet FAX Full Mode machine for which
confirmation is being issued.
Maeda Expiers September 1998 Page 11
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
4.3.1 The message/disposition-notification content-type
The message/disposition-notification content-type for confirmation
message is defined as follows:
MIME type name: message
MIME subtype name: disposition-notification
Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and
MUST be used.
Security considerations: will be discussed$B!!(J
The syntax of the message/disposition-notification content is
as follows:
disposition-notification-content = [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
original-message-id-field CRLF
disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
4.3.2 final-recipient-field
The Final-Recipient field indicates the recipient of Internet FAX for
which the confirmation is being issued.
4.3.3 Original-message-ID
The Original-Message-ID field indicates the message-ID of the message
for which the confirmation is being issued. This field must be present.
4.3.4 disposition-field
The Disposition filed indicates the action performed by the recipient
of Internet FAX Full Mode. This filed must be present. disposition-
modifier$B!J(J G3Fax-report-request$B!K(J will be used for confirmation.
The syntax for the Disposition filed is:
Disposition: automatic-action/MDN-sent-Automatically
; processed / G3Fax-report-request
Maeda Expiers September 1998 Page 12
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
4.3.5$B!!(Jextension-field
(1) confirmation
Additional MDN field is defined for confirmation. confirmation of
recipient is expressed using result code, received page number and
error page number.
G3Fax-Report: G3Fax-Results=code
;G3Fax-Pages=received page number
;G3Fax-Errorpage=error page number
(2) capability response
Additional MDN field is defined for capability response. Capabilities
of recipient is expressed using FCF and FIF in CCITT T30 frame
format[5].
G3Fax-t30frame:G3Fax-frame= t30-fcf [ "," t30-fif ]
Maeda Expiers September 1998 Page 13
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
5. Security considerations
The following security considerations apply when using Extended
MDNs for Internet FAX Full Mode:
5.1 Forgery
Extended MDNs may be forged as easily as ordinary Internet
electronic mail. User agents and Internet that wish
to make automatic use of MDNs should take appropriate precautions
to minimize the potential damage from denial-of-service attacks.
Security threats related to forged MDNs include the sending of:
(a) A falsified disposition notification when the indicated dis-
position of the message has not actually ocurred,
(b) Unsolicited MDNs
5.2 Confidentiality
Another dimension of security is confidentiality. There may be
cases in which a message recipient does not wish the disposition of
messages addressed to a recipient of Internet FAX Full mode to be
known or is concerned that the sending of MDNs may reveal other
confidential information (e.g.,when the message was read).
In this situation, it is acceptable for the recipient of Internet
FAX Full mode to issue "denied" MDNs or to silently ignore requests
for MDNs.
Headers of the original message returned in part 3 of the
multipart/report could reveal confidential information about host
names and/or network topology inside a firewall.
An unencrypted MDN could reveal confidential information about an
encrypted message, especially if all or part of the original message
is returned in part 3 of the multipart/report. Encrypted MDNs are
not defined in this specification.
In general, any optional MDN field may be omitted if the Reporting
recipient of Internet FAX Full mode determines that inclusion of
the field would impose too great a compromise of site
confidentiality. The need for such confidentiality must be balanced
against the utility of the omitted information in MDNs.
Maeda Expiers September 1998 Page 14
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
5.3 Non-Repudiation
Within the framework of today's Internet Mail, the Extended MDNs
defined in this document provide valuable information to the mail
user; however, MDNs can not be relied upon as a guarantee that a
message was or was not not seen by the recipient. Even if MDNs are
not actively forged, they may be lost in transit. The Extended MDN
issuing mechanism may be bypassed in some manner by the recipient of
Internet FAX Full mode.
Maeda Expiers September 1998 Page 15
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
6. Collected Grammar
Additional grammar for MDN is described in IANA registration form.
6.1 IANA registration for Disposition-Notification-Options header
parameter names
6.1.1 G3Fax-capability-request
This is the parameter for Internet FAX capability request.
(a) proposed parameter name
G3Fax-capability-request
(b) syntax
Disposition-Notification-Options :
"Disposition-Notification-Options" ":"
"G3Fax-capability-request"$B!!(J"=" "required"
(c)parameter values
G3Fax-capability-request is capability request of Internet
FAX Full mode
6.1.2 G3Fax-report-request
This is the parameter for Internet FAX confirmation request.
(a) proposed parameter name
G3Fax-report-request
(b) syntax
Disposition-Notification-Options :
"Disposition-Notification-Options" ":"
"G3Fax-report-request"$B!!(J"=" "required"
(c)parameter values
G3Fax-report-request is confirmation request of Internet
FAX Full Mode.
Maeda Expiers September 1998 Page 16
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
6.1.3 G3Fax-t30frame-parameter
This is the parameter for Recipient capabilities of Internet FAX Full
Mode.
(a) proposed parameter name
G3Fax-t30frame-parametert
(b) syntax
Disposition-Notification-Options :
"Disposition-Notification-Options" ":"
disposition-notification-parameters
disposition-notification-parameters =
parameter * ( ";" parameter )
parameter = "G3Fax-t30frame-parameter"
G3Fax-t30frame-parameter =
"G3Fax-t30frame" "=" t30-fcf [ "," t30-fif ]
t30-fcf = *text
t30-fif = *text
(c)parameter values
t30-fcf =*text is hexdecimal expression of FCF octet in T.30.
Some FCFs are as follows;
NSF 20
CSI 40
DIS 80
NSS 23
TSI 43
DCS 83
t30-fif =*text is Hexdecimal expression of FIF octets in T.30.
The first octet of FIF is located in first character in text.
LSB of octet is the first bit of FIF.
Maeda Expiers September 1998 Page 17
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
6.2 IANA registration for disposition modifier names
6.2.1 G3Fax-capability-request
(a) disposition-modifier name
G3Fax-capability-request
(b)semantics
capability request of Internet FAX full Mode
6.2.2 G3Fax-report-request
(a) disposition-modifier name
G3Fax-report-request
(b) semantics
capability request of Internet FAX Full Mode
Maeda Expiers September 1998 Page 18
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
6.3 IANA registration for MDN extension field names
6.3.1$B!!(JG3Fax-t30frame
This is the field for Command data from sender in Internet FAX Full
Mode.
(a) field name
G3Fax-t30frame-field
(b)syntax
field = "G3Fax-t30frame" ":" G3Fax-t30frame-field
G3Fax-t30frame-field = parameter * ( ";" parameter )
parameter = "G3Fax-t30frame-parameter"
G3Fax-t30frame-parameter =
"G3Fax-t30frame" "=" t30-fcf [ "," t30-fif ]
t30-fcf = *text
t30-fif = *text
(c)field value
t30-fcf =*text is hexdecimal expression of FCF in T.30
Some FCFs are as follows;
NSF 20
CSI 40
DIS 80
NSS 23
TSI 43
DCS 83
t30-fif =*text is Hexdecimal expresion of FIF octets in T.30.
The first octet of FIF is located in first character in text.
LSB of octet is the first bit of FIF.
Maeda Expiers September 1998 Page 19
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
6.3.2 G3Fax-Report
This is the fieled foe confirmation of Internet FAX Full Mode
(a) field name
G3Fax-Report-field
(b)syntax
field = "G3Fax-Report" ":" $B!!(Jresults
; $B!!(Jpages
; $B!!(Jerrorpage
results = "G3Fax-Results" "=" code
pages = "G3Fax-Pages" "=" numeric
errorpage = "G3Fax-Errorpage" "=" numeric * ( "," numeric )
(c)field value
results =code is as follows;
"00" Successful reception
"01" Unsuccessful reception
"02" Capabilities mismatch. The receiving terminal cannot
interpret the message data correctly
"03" does not support the format used in this message
"04" does not support relay feature
pages =numeric is total page.
errorpage =numeric is error page number
Maeda Expiers September 1998 Page 20
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
7. Example
7.1 Capability request
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Capability Request
To: Tom Recipient <Tom_Recipient@mega.edu>
Disposition-Notification-To: Jane_Sender@huge.com
Disposition-Notification-Options: G3Fax-capability-request=required
7.2 Capability response
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@mega.edu>
Message-Id: <199509200020.12345@mega.edu>
Subject: Internet FAX Full Mode Capability Response
To: Jane Sender <Jane_Sender@huge.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615766/mega.edu"
--RAA14128.773615766/mega.edu
The message sent on 1995 Sep 19 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@mega.edu> with subject " Internet FAX Full
Mode Capability Request " has been processsed in Internet FAX Full Mode.
--RAA14128.773615766/mega.edu
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@mega.edu
Final-Recipient: rfc822;Tom-Recipient@mega.edu
Original-Message-ID: <199509200019.12345@huge.com>
Disposition: automatic-action/MDN-sent-automatically;
processed / G3Fax-capability-request
G3Fax-t30frame:G3Fax-frame=40,3333333320323220313131;
G3Fax-frame=20,000088;
G3Fax-frame=80,00CF79
--RAA14128.773615766/mega.edu--
Maeda Expiers September 1998 Page 21
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
7.3 Message and confirmation request
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender < Jane_Sender@huge.com>
Message-Id: <199509200021.12345@huge.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@mega.edu>
MIME-Version: 1.0
Disposition-Notification-To:
Jane_Sender@huge.com
Disposition-Notification-Options:G3Fax-report-request=required;
G3Fax-frame=43,3737373720383820393939;
G3Fax-frame=23,000088;
G3Fax-frame=83,00C679
Content-Type: multipart/ mixed;
boundary="RAA14128.773615768/ huge.com"
--RAA14128.773615768/huge.com
Content-type: text/plain; charset=us-ascii
[original text message goes here]
--RAA14128.773615768huge.com
Content-type: image/ tiff; application=faxbw
Content-Transfer-Encoding: base64
[original TIFF-FX message goes here]
--RAA14128.773615768/ huge.com--
Maeda Expiers September 1998 Page 22
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
7.4 Confirmation
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@mega.edu>
Message-Id: <199509200022.12345@mega.edu>
Subject: Internet FAX Full Mode Disposition notification
To: Jane Sender <Jane_Sender@huge.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615769/mega.edu"
--RAA14128.773615769/mega.edu
The message sent on 1995 Sep 19 at 00:21:00 (EDT) -0400 to Tom Recipient
<Tom_Recipient@mega.edu> with subject " Internet FAX Full Mode Image
Transmission" has been processed in Internet FAX Full Mode. This is no
guarantee that the message has been read or understood.
--RAA14128.773615769/mega.edu
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@mega.edu
Final-Recipient: rfc822;Tom-Recipient@mega.edu
Original-Message-ID: <199509200021.12345@huge.com>
Disposition: automatic-action/MDN-sent-automatically;
processed / G3Fax-report-request
G3Fax-Report:G3Fax-Results=00;
G3Fax-Pages=5
--RAA14128.773615769/mega.edu
Content-type: image/ tiff; application=faxbw
Content-Transfer-Encoding: base64
[ TIFF-FX message goes here]
--RAA14128.773615769/mega.edu--
Maeda Expiers September 1998 Page 23
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
8. Acknowledgements
Active for this document were: Yoshio Yosiura, Motoaki Yoshino,
Shinji Kume, Youichi Kudo.
9. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August l982.
[3] Fajman, R. "An Extensible Message Format for Message Disposition
Notification", RFC XXXX, November 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[5] ITU-T (CCITT), "Procedures for Document Facsimile Transmission in
the General Switched Telephone Network ", ITU-T (CCITT)
Recommendation T.30.
[6] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
Octel Network Services, January 1996.
[7] ITU-T, "Internet Facsimile: Guidelines for the Support of the
Comminication of Facsimile Documents", ITU-T Recommendation
F.Ifax
[8] ITU-T, "Procedures for the Transfer of Facsimile Data via Store
and Forward on the Internet", ITU-T Recommendation
T.Ifax1
Maeda Expiers September 1998 Page 24
Extended MDN for IFAX Full Mode 10 March 1998
Internet Draft
10. Copyright
Copyright (C) The Internet Society (1997, 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 InternetSociety 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 isprovided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALLWARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TOANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOTINFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Auther's Address
Toru MAEDA
CANON Inc
3-30-2,Shimomaruko, Ohtaku,
Tokyo, Japan
Email: maeda@ffm.canon.co.jp
Voice: +81 3 3757 9738
Fax: +81 3 3757 8205
Maeda Expiers September 1998 Page 25
Datatracker
Report a datatracker bug
draft-ietf-fax-mdn-fullmode-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |