One document matched: draft-ietf-fax-mdn-fullmode-03.txt
Differences from draft-ietf-fax-mdn-fullmode-02.txt
Fax Working Group Toru Maeda
Internet Draft CANON Inc
Expires: August 1999 26 February 1999
Extended MDN for Internet Fax Full Mode
draft-ietf-fax-mdn-fullmode-03.txt
This document is an Internet-Draft and is NOT offered in
accordance with Section 10 of RFC2026, and will only exist as
an Internet-Draft.
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 RFC2298. Extension of MDN supports
Internet fax feature tags defined in schema document[RFC-SCHEMA].
Maeda Expires August 1999 Page 1
Extended MDN for IFAX Full Mode 26 February 1999
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 Expires August 1999 Page 2
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
1. Introduction
This memo defines an additional MIME content-type for extended message
disposition notifications (MDNs) for Internet FAX Full Mode. MDN is
defined in "An Extensible Message Format for Message Disposition
Notification" in RFC2298 [3]. Internet FAX Full
Mode which has capability exchange and confirmation is defined in
ITU-T F.185 [7] and T.37 [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]. An extended MDN also supports
Internet FAX feature tags defined in schema document[9].
Internet FAX Full Mode is defined in F.185 [7] as follows;
(a)Capabilities of the terminals are exchanged.
(b)An acknowledgment of receipt is exchanged between gateways
and may be transferred 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 Full Mode 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 written with prefix "G3Fax-" to make clear the extension
from MDN. These parameters will be registered to IANA.
Maeda Expires August 1999 Page 3
Extended MDN for IFAX Full Mode 26 February 1999
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-independent, yet reasonably precise, indications
of the disposition of a message to be delivered in Internet
FAX Full Mode.
(g)Allow G3FAX applications such as Polling, Selective Polling,
Subaddress, Relay, Password, BFT and NSF based on ITU-T T.30
protocol.
1.2 Requirements
These purposes place the following constraints on the capability
exchange and confirmation protocol:
(a)It must be readable by humans as well as being machine
parsable for Internet FAX Full mode.
(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.
Maeda Expires August 1999 Page 4
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
(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.
1.3 Extension from MDN
For the purposes, MDS in RFC2298 [3] is extended and modified as
follows for Internet FAX Full Mode.
(a)MDN is send automatically. The operator should recognize that
Internet FAX full Mode sends MDN by default setting.
(b)An empty message is used for capability request.
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 a request for a Message Disposition Notification which is an
empty mail message with a Disposition-Notification-To header. A
recipient of Internet FAX Full Mode SHOULD immediately return message
with its capabilities using extended MDN. This is a change of behavior
from the MDN.
In the message transmission and confirmation phase, based on this
reply messages, the sender sends message, command data and confirmation
request using a request for extended MDN. The recipient SHOULD 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.
A sender may not perform capability exchange phase when the transmitting
message is LCD.
Maeda Expires August 1999 Page 5
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
3. Capability exchange phase
A sender of Internet FAX Full Mode SHOULD send a capability request using
a request for an extended MDN. A recipient of Internet FAX Full Mode
SHOULD 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
Capability request is requested by including a Disposition-
Notification-To and Disposition Notification-Options headers with an
empty mail message. Further information to be used by the recipient of
Internet FAX Full Mode in generating the capability request may be
provided by including Original-recipient.
A 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 Expires August 1999 Page 6
Extended MDN for IFAX Full Mode 26 February 1999
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 RFC822 From field of the capability response MUST
contain the address of the Internet FAX Full Mode machine for which
the MDN is being issued.
3.2.1 The message/disposition-notification content-type
The message/disposition-notification content-type for capability
response message is as defined in RFC2298[3].
The syntax of the message/disposition-notification content is
as defined in RFC2298[3].
Maeda Expires August 1999 Page 7
Extended MDN for IFAX Full Mode 26 February 1999
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 field indicates the action performed by the recipient
of Internet FAX Full Mode. This field must be present.
Disposition-modifier（ G3Fax-capability-request） will be used for
capability response.
The syntax for the Disposition field 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 ]
Following extension fields are defined for media feature tags.
extension-field = media-feature CRLF
media-features = "Media-Accept-Features" ":" media-feature-tags
media-feature-tags = <defined in SYNTAX[]>
Maeda Expires August 1999 Page 8
Extended MDN for IFAX Full Mode 26 February 1999
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 SHOULD return 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 Message transmission and confirmation request
Confirmation 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 confirmation request may be provided by
including Original-recipient in the message.
A message that contains confirmation 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 Expires August 1999 Page 9
Extended MDN for IFAX Full Mode 26 February 1999
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].
Disposition-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 Expires August 1999 Page 10
Extended MDN for IFAX Full Mode 26 February 1999
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 field 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 Expires August 1999 Page 11
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
4.3.1 The message/disposition-notification content-type
The message/disposition-notification content-type for confirmation
message is as defined in RFC2298[3].
The syntax of the message/disposition-notification content is
as defined in RFC2298[3].
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 field indicates the action performed by the recipient
of Internet FAX Full Mode. This field must be present. disposition-
modifier（ G3Fax-report-request） will be used for confirmation.
The syntax for the Disposition field is:
Disposition: automatic-action/MDN-sent-Automatically
; processed / G3Fax-report-request
Maeda Expires August 1999 Page 12
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
4.3.5 extension-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 Expires August 1999 Page 13
Extended MDN for IFAX Full Mode 26 February 1999
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.
A SID/PWD field may be used to check the capability request.
A recipient of Internet FAX Full mode may check SID/PWD field before
sending capability response.
5.2 Confidentiality
Another dimension of security is confidentiality.
A recipient of Internet FAX Full mode should send MDN automatically.
MDN should be limited only capability response and confirmation.
Maeda Expires August 1999 Page 14
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
5.3 Non-Repudiation
The Extended MDNs defined in this document provide a confirmation of
receipt to the Internet FAX Full Mode user. The MDNs can not be relied
upon as a guarantee that a message was or was not seen by the recipient.
Maeda Expires August 1999 Page 15
Extended MDN for IFAX Full Mode 26 February 1999
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" "=" "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" "=" "required"
(c)parameter values
G3Fax-report-request is confirmation request of Internet
FAX Full Mode.
Maeda Expires August 1999 Page 16
Extended MDN for IFAX Full Mode 26 February 1999
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 hexadecimal 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 Hexadecimal 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 Expires August 1999 Page 17
Extended MDN for IFAX Full Mode 26 February 1999
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 Expires August 1999 Page 18
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
6.3 IANA registration for MDN extension field names
6.3.1 G3Fax-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 hexadecimal 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 Hexadecimal 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 Expires August 1999 Page 19
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
6.3.2 G3Fax-Report
This is the field foe confirmation of Internet FAX Full Mode
(a)field name
G3Fax-Report-field
(b)syntax
field = "G3Fax-Report" ":" results
; pages
; errorpage
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 Expires August 1999 Page 20
Extended MDN for IFAX Full Mode 26 February 1999
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 processed 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,000011;
G3Fax-frame=80,00CF79
--RAA14128.773615766/mega.edu--
Maeda Expires August 1999 Page 21
Extended MDN for IFAX Full Mode 26 February 1999
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,000011;
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 Expires August 1999 Page 22
Extended MDN for IFAX Full Mode 26 February 1999
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 Expires August 1999 Page 23
Extended MDN for IFAX Full Mode 26 February 1999
Internet Draft
8.Acknowledgments
Yoshio Yosiura CANON Inc and Motoaki Yoshino, Shinji Kume and Youichi
Kudo from other FAX manufacturers provided valuable comments.
Dan Wing provided valuable comments on previous version of this draft.
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 2298, March 1998.
[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
Communication of Facsimile Documents", ITU-T Recommendation
F.185
[8] ITU-T, "Procedures for the Transfer of Facsimile Data via Store
and Forward on the Internet", ITU-T Recommendation
T.37
[9] Klyne, G., "Content feature schema for Internet fax"
[RFC-SCHEMA], January 8, 1999,
Internet draft : <draft-ietf-fax-feature-schema-05.txt>
Maeda Expires August 1999 Page 24
Extended MDN for IFAX Full Mode 26 February 1999
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 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 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.Author'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 Expires August 1999 Page 25
| PAFTECH AB 2003-2026 | 2026-04-23 06:04:59 |