2305
PROPOSED STANDARD
A Simple Mode of Facsimile Using Internet Mail (Obsoleted)
Authors: K. Toyoda, H. Ohno, J. Murai, D. Wing
Date: March 1998
Area: app
Working Group: fax
Stream: IETF
Obsoleted by:
RFC 3965
Abstract
This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]
RFC 2305
Obsoleted by: 3965 PROPOSED STANDARD
Network Working Group K. Toyoda
Request for Comments: 2305 H. Ohno
Category: Standards Track J. Murai
WIDE Project
D. Wing
Cisco
March 1998
<span class="h1">A Simple Mode of Facsimile Using Internet Mail</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
SUMMARY
This specification provides for "simple mode" carriage of facsimile
data over the Internet. Extensions to this document will follow.
The current specification employs standard protocols and file formats
such as TCP/IP, Internet mail protocols [<a href="#ref-1" title=""Simple Mail Transfer Protocol"">1</a>, <a href="#ref-2" title=""Standard for the Format of ARPA Internet Text Messages"">2</a>, <a href="#ref-3" title=""Requirements for Internet hosts - application and support"">3</a>], MIME [<a href="#ref-4" title="" Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples "">4</a>, <a href="#ref-16" title=""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"">16</a>, <a href="#ref-17" title=""Multipurpose Internet Mail Extensions (MIME) Three: Representation of Non-ASCII Text in Internet ge Headers"">17</a>],
and TIFF for Facsimile [<a href="#ref-5" title=""Tag Image File Format (TIFF) -- F Profile for Facsimile"">5</a>,<a href="#ref-6" title=""File Format for Internet Fax"">6</a>,<a href="#ref-19" title=""Tag Image File Format (TIFF) -- image/TIFF: MIME Sub-type Registration"">19</a>]. It can send images not only to
other Internet-aware facsimile devices but also to Internet-native
systems, such as PCs with common email readers which can handle MIME
mail and TIFF for Facsimile data. The specification facilitates
communication among existing facsimile devices, Internet mail agents,
and the gateways which connect them.
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in [<a href="#ref-7" title=""Key words for use in RFCs to Indicate Requirement Levels"">7</a>].
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a> SCOPE</span>
This specification defines a message-based facsimile communication
over the Internet. It describes a minimum set of capabilities,
taking into account those of typical facsimile devices and PCs that
can generate facsimile data.
<span class="grey">Toyoda, et. al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
A G3Fax device has substantial restrictions due to specifications in
the standards, such as for timers. This specification defines a
profile for Internet mail, rather than creating a distinct "facsimile
over the Internet" service. The semantics resulting from the profile
are designed to be compatible with facsimile operation over the
general switched telephone network, so that gateways between
facsimile and Internet mail can operate with very high fidelity.
The reason for developing this capability as an email profile is to
permit interworking amongst facsimile and email users. For example
it is intended that existing email users be able to send normal
messages to lists of users, including facsimile-based recipients, and
that other email recipients shall be able to reply to the original
and continue to include facsimile recipients. Similarly it is
intended that existing email software work without modification and
not be required to process new, or different data structures, beyond
what is normal for Internet mail users. Existing email service
standards are used, rather than replicating mechanisms which are more
tailored to existing facsimile standards, to ensure this
compatibility with existing email service.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Services</span>
A facsimile-capable device that uses T.4 [<a href="#ref-8" title=""Standardization of Group 3 facsimile apparatus for document transmission"">8</a>] and the general switched
telephone network (GSTN) is called a "G3Fax device" in this
specification. An "IFax device" is an Internet- accessible device
capable of sending, receiving or forwarding Internet faxes. A
message can be sent to an IFax device using an Internet mail
address. A message can be sent to a G3Fax device using an Internet
mail address; the message MAY be forwarded via an IFax offramp
gateway.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a> Cases</span>
This specification provides for communication between each of the
following combinations:
Internet mail => Network printer
Internet mail => Offramp gateway (forward to
G3Fax)
Network scanner => Network printer
Network scanner => Offramp gateway (forward to
G3Fax)
Network scanner => Internet mail
<span class="grey">Toyoda, et. al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a> COMMUNICATION PROTOCOLS</span>
The set of conventions necessary to achieve facsimile- compatible
service covers basic data transport, document data formats, message
(document) addressing, delivery confirmation, and message security.
In this section, the first 4 are covered. The remainder are covered
in following sections, along with additional details for addressing
and formats.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Transport</span>
This section describes mechanisms involved in the transport between
IFAX devices.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a> Relay</span>
Data transfer MAY be achieved using standard Internet mail transfer
mechanisms[1, 3]. The format of addresses MUST conform to the <a href="./rfc821">RFC</a>
<a href="./rfc821">821</a> <addr-spec> and <a href="./rfc822">RFC 822</a> <mailbox> Internet mail standards [1, 2,
3].
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a> Gateway</span>
A gateway translates between dissimilar environments. For IFax, a
gateway connects between Internet mail and the T.4/GSTN facsimile.
Gateways can service multiple T.4/GSTN facsimile users or can service
only one. In the former case, they serve as a classic "mail transfer
agent" (MTA) and in the latter as a classic "mail user agent" (UA).
An onramp is a gateway which connects from T.4/GSTN facsimile to
Internet mail. An offramp is a gateway which connects from Internet
mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for
this specification.
This specification describes the Internet mail service portion of
offramp addressing, confirmation and failure notification. Details
are provided in later sections.
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a> Mailbox protocols</span>
An offramp gateway that operate as an MTA serving multiple users
SHOULD use SMTP; a gateway that operates as a UA serving a single
mail recipient MAY use a mailbox access protocol such as POP or IMAP
[<a href="#ref-9" title=""Post Office Protocol - Version 3"">9</a>, <a href="#ref-10" title=""Internet Message Access Protocol - Version 4Rev1"">10</a>].
<span class="grey">Toyoda, et. al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
NOTE: An offramp gateway that relays mail based on addressing
information needs to ensure that it uses addresses supplied in the
MTA envelope, rather than from elsewhere, such as addresses listed in
the message content headers.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Formats</span>
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a> Headers</span>
IFax devices MUST be compliant with <a href="./rfc822">RFC 822</a> and <a href="./rfc1123">RFC1123</a>, which define
the format of mail headers. The header of an IFax message SHOULD
include Message-ID and MUST include all fields required by [<a href="#ref-2" title=""Standard for the Format of ARPA Internet Text Messages"">2</a>, <a href="#ref-3" title=""Requirements for Internet hosts - application and support"">3</a>],
such as DATE and FROM.
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a> MIME</span>
IFax devices MUST be compliant with MIME [<a href="#ref-4" title="" Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples "">4</a>], except as noted in
<a href="#appendix-A">Appendix A</a>.
<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a> Content</span>
The data format of the facsimile image is based on the minimum set of
TIFF for Facsimile[6], also known as the S profile. Such facsimile
data are included in a MIME object by use of the image/TIFF sub-type
[<a href="#ref-19" title=""Tag Image File Format (TIFF) -- image/TIFF: MIME Sub-type Registration"">19</a>]. Additional rules for the use of TIFF for Facsimile, for the
message-based Internet facsimile application, are defined later.
<span class="h4"><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a> Multipart</span>
A single multi-page document SHOULD be sent as a single multi- page
TIFF file, even though recipients MUST process multipart/mixed
containing multiple TIFF files. If multipart content is present and
processing of any part fails, then processing for the entire message
is treated as failing, per [Processing failure] below.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Error Handling</span>
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a> Delivery failure</span>
This section describes existing requirements for Internet mail,
rather than indicating special requirements for IFax devices.
In the event of relay failure, the sending relay MUST generate a
failure message, which SHOULD be in the format of a DSN. [<a href="#ref-14" title=""An Extensible Message Format for Delivery Status Notifications"">14</a>,<a href="#ref-15" title=""SMTP Service Extension for Delivery Status Notifications"">15</a>]
NOTE: Internet mail transported via SMTP MUST contain a MAIL
FROM address appropriate for delivery of return notices [Also
see <a href="#section-5.2.6">section 5.2.6</a>]
<span class="grey">Toyoda, et. al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a> Processing failure</span>
IFax devices with limited capabilities might be unable to process the
content of a message. If this occurs it is important to ensure that
the message is not lost without any notice. Notice MAY be provided in
any appropriate fashion, and the exact handling is a local matter.
(Also see <a href="#appendix-A">Appendix A</a>, second bullet.)
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a> ADDRESSING</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Classic Email Destinations</span>
Messages being sent to normal Internet mail recipients will use
standard Internet mail addresses, without additional constraints.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> G3Fax Devices</span>
G3Fax devices are accessed via an IFAX offramp gateway, which
performs any authorized telephone dial-up.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Address Formats Used by Offramps</span>
When a G3Fax device is identified by a telephone number, the entire
address used for the G3fax device, including the number and offramp
host reference MUST be contained within standard Internet mail
transport fields, such as RCPT TO and MAIL FROM [<a href="#ref-1" title=""Simple Mail Transfer Protocol"">1</a>, <a href="#ref-3" title=""Requirements for Internet hosts - application and support"">3</a>]. The address
MAY be contained within message content fields, such as <authentic>
and <destination> [<a href="#ref-2" title=""Standard for the Format of ARPA Internet Text Messages"">2</a>, <a href="#ref-3" title=""Requirements for Internet hosts - application and support"">3</a>], as appropriate.
As for all Internet mail addresses, the left-hand-side (local- part)
of an address is not to be interpreted except by the MTA that is
named on the right-hand-side (domain).
The telephone number format SHOULD conform to [<a href="#ref-11" title=""Minimal PSTN address format for Internet mail"">11</a>, <a href="#ref-12" title=""Minimal fax address format for Internet mail"">12</a>]. Other
formats MUST be syntactically distinct from [<a href="#ref-11" title=""Minimal PSTN address format for Internet mail"">11</a>, <a href="#ref-12" title=""Minimal fax address format for Internet mail"">12</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a> IMAGE FILE FORMAT</span>
Sending IFax devices MUST be able to write minimum set TIFF files,
per the rules for creating minimum set TIFF files defined in TIFF for
Facsimile (the S profile) [<a href="#ref-6" title=""File Format for Internet Fax"">6</a>], which is also compatible with the
specification for the minimum subset of TIFF-F in [<a href="#ref-5" title=""Tag Image File Format (TIFF) -- F Profile for Facsimile"">5</a>]. Receiving
IFax devices MUST be able to read minimum set TIFF files.
<span class="grey">Toyoda, et. al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
A sender SHOULD NOT use TIFF fields and values beyond the minimum
subset of TIFF for Facsimile unless the sender has prior knowledge of
other TIFF fields or values supported by the recipient. The
mechanism for determining capabilities of recipients is beyond the
scope of this document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a> SECURITY CONSIDERATIONS</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a> General Directive</span>
This specification is based on use of existing Internet mail. To
maintain interoperability with Internet mail, any security to be
provided should be part of the of the Internet security
infrastructure, rather than a new mechanism or some other mechanism
outside of the Internet infrastructure.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a> Threats and Problems</span>
Both Internet mail and G3Fax standards and operational services have
their own set of threats and countermeasures. This section attends
only to the set of additional threats which ensue from integrating
the two services. This section reviews relevant concerns about
Internet mail for IFax environments, as well as considering the
potential problems which can result of integrating the existing G3Fax
service with Internet mail.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a> Spoofed sender</span>
The actual sender of the message might not be the same as that
specified in the Sender or From fields of the message content headers
or the MAIL FROM address from the SMTP envelope.
In a tightly constrained environment, sufficient physical and
software controls may be able to ensure prevention of this problem.
The usual solution is through encryption-based authentication, either
for the channel or associated with the object, as discussed below.
It should be recognized that SMTP implementations do not provide
inherent authentication of the senders of messages, nor are sites
under obligation to provide such authentication. End-to-end
approaches such as S/MIME and PGP/MIME are currently being developed
within the IETF. These technologies can provide such authentication.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a> Resources consumed by dialout</span>
In addition to the resources normally consumed for email (CPU cycles
and disk), offramp facsimile causes an outdial which often imposes
significant resource consumption, such as financial cost. Techniques
<span class="grey">Toyoda, et. al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
for establishing authorization of the sender are essential to those
offramp facsimile services that need to manage such consumption.
Due to the consumption of these resources by dialout, unsolicited
bulk email which causes an outdial is undesirable.
Offramp gateways SHOULD provide the ability to authorize senders in
some manner to prevent unauthorized use of the offramp. There are no
standard techniques for authorization using Internet protocols.
Typical solutions use simple authentication of the originator to
establish and verify their identity and then check the identity
against a private authorization table.
Originator authentication entails the use of weak or strong
mechanisms, such as cleartext keywords or encryption-based data-
signing, respectively, to determine and validate the identify of the
sender and assess permissions accordingly.
Other control mechanisms which are common include source filtering
and originator authentication. Source filtering entails offramp
gateway verification of the host or network originating the message
and permitting or prohibiting relaying accordingly.
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a> GSTN authorization information</span>
Confidential information about the sender necessary to dial a G3Fax
recipient, such as sender's calling card authorization number, might
be disclosed to the G3Fax recipient (on the cover page), such as
through parameters encoded in the G3Fax recipients address in the To:
or CC: fields.
Senders SHOULD be provided with a method of preventing such
disclosure. As with mechanisms for handling unsolicited faxes, there
are not yet standard mechanisms for protecting such information.
Out-of-band communication of authorization information or use of
encrypted data in special fields are the available non-standard
techniques.
Typically authorization needs to be associated to specific senders
and specific messages, in order to prevent a "replay" attack which
causes and earlier authorization to enable a later dial-out by a
different (and unauthorized) sender. A non-malicious example of such
a replay would be to have an email recipient reply to all original
recipients -- including an offramp IFax recipient -- and have the
original sender's authorization cause the reply to be sent.
<span class="grey">Toyoda, et. al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a> Sender accountability</span>
In many countries, there is a legal requirement that the "sender" be
disclosed on a facsimile message. Email From addresses are trivial
to fake, so that using only the MAIL FROM [<a href="#ref-1" title=""Simple Mail Transfer Protocol"">1</a>, <a href="#ref-3" title=""Requirements for Internet hosts - application and support"">3</a>] or From [<a href="#ref-2" title=""Standard for the Format of ARPA Internet Text Messages"">2</a>, <a href="#ref-3" title=""Requirements for Internet hosts - application and support"">3</a>]
header is not sufficient.
Offramps SHOULD ensure that the recipient is provided contact
information about the offramp, in the event of problems.
The G3Fax recipient SHOULD be provided with sufficient information
which permits tracing the originator of the IFax message. Such
information might include the contents of the MAIL FROM, From, Sender
and Reply-To headers, as well as Message-Id and Received headers.
<span class="h4"><a class="selflink" id="section-5.2.5" href="#section-5.2.5">5.2.5</a> Message disclosure</span>
Users of G3Fax devices have an expectation of a level of message
privacy which is higher than the level provided by Internet mail
without security enhancements.
This expectation of privacy by G3Fax users SHOULD be preserved as
much as possible.
Sufficient physical and software control may be acceptable in
constrained environments. The usual mechanism for ensuring data
confidentially entail encryption, as discussed below.
<span class="h4"><a class="selflink" id="section-5.2.6" href="#section-5.2.6">5.2.6</a> Non private mailboxes</span>
With email, bounces (delivery failures) are typically returned to the
sender and not to a publicly-accessible email account or printer.
With facsimile, bounces do not typically occur. However, with IFax,
a bounce could be sent elsewhere (see section [Delivery Failure]),
such as a local system administrator's account, publicly-accessible
account, or an IFax printer (see also [Traffic Analysis]).
<span class="h4"><a class="selflink" id="section-5.2.7" href="#section-5.2.7">5.2.7</a> Traffic analysis</span>
Eavesdropping of senders and recipients is easier on the Internet
than GSTN. Note that message object encryption does not prevent
traffic analysis, but channel security can help to frustrate attempts
at traffic analysis.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a> Security Techniques</span>
There are two, basic approaches to encryption-based security which
support authentication and privacy:
<span class="grey">Toyoda, et. al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a> Channel security</span>
As with all email, an IFax message can be viewed as it traverses
internal networks or the Internet itself.
Virtual Private Networks (VPN) which make use of encrypted tunnels,
such as via IPSec technology [<a href="#ref-18" title=""Security Architecture for the Internet Protocol"">18</a>] or transport layer security, can be
used to prevent eavesdropping of a message as it traverses such
networks. It also provides some protection against traffic
analysis, as described above.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a> Object security</span>
As with all email, an IFax message can be viewed while it resides on,
or while it is relayed through, an intermediate Mail Transfer Agent.
Message encryption, such as PGP-MIME [<a href="#ref-13" title=""MIME Security with Pretty Good Privacy (PGP)"">13</a>] and S/MIME, can be used to
provide end-to-end encryption.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a> REFERENCES</span>
[<a id="ref-1">1</a>] Postel, J., "Simple Mail Transfer Protocol", STD 10, <a href="./rfc821">RFC</a>
<a href="./rfc821">821</a>, August 1982.
[<a id="ref-2">2</a>] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, <a href="./rfc822">RFC 822</a>, August l982.
[<a id="ref-3">3</a>] Braden, R., 1123 "Requirements for Internet hosts -
application and support", <a href="./rfc1123">RFC 1123</a>, October 1989.
[<a id="ref-4">4</a>] Borenstein, N., and N. Freed, " Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria and
Examples ", <a href="./rfc2049">RFC 2049</a>, November 1996.
[<a id="ref-5">5</a>] Parsons, G., and J. Rafferty, "Tag Image File Format
(TIFF) -- F Profile for Facsimile", <a href="./rfc2306">RFC 2306</a>, March 1998.
[<a id="ref-6">6</a>] McIntyre, L., Zilles, S., Buckley, R., Venable, D.,
Parsons, G., and J. Rafferty, "File Format for Internet Fax",
<a href="./rfc2301">RFC 2301</a>, March 1998.
[<a id="ref-7">7</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-8">8</a>] ITU-T (CCITT), "Standardization of Group 3 facsimile
apparatus for document transmission", ITU-T (CCITT),
Recommendation T.4.
<span class="grey">Toyoda, et. al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
[<a id="ref-9">9</a>] Myers, J., and M. Rose, "Post Office Protocol - Version
3", STD 53, <a href="./rfc1939">RFC 1939</a>, May 1996.
[<a id="ref-10">10</a>] Crispin, M., "Internet Message Access Protocol - Version
4Rev1", <a href="./rfc2060">RFC 2060</a>, December 1996.
[<a id="ref-11">11</a>] Allocchio, C., "Minimal PSTN address format for Internet
mail", <a href="./rfc2303">RFC 2303</a>, March 1998.
[<a id="ref-12">12</a>] Allocchio, C., "Minimal fax address format for Internet
mail", <a href="./rfc2304">RFC 2304</a>, March 1998.
[<a id="ref-13">13</a>] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", <a href="./rfc2015">RFC 2015</a>, October 1996.
[<a id="ref-14">14</a>] Moore, K., and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", <a href="./rfc1894">RFC 1894</a>, January
1996.
[<a id="ref-15">15</a>] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", <a href="./rfc1891">RFC 1891</a>, January 1996.
[<a id="ref-16">16</a>] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", <a href="./rfc2046">RFC 2046</a>,
November 1996.
[<a id="ref-17">17</a>] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Three: Representation of Non-ASCII Text in Internet ge Headers",
<a href="./rfc2047">RFC 2047</a>, November 1996.
[<a id="ref-18">18</a>] Atkinson, R., "Security Architecture for the Internet
Protocol", <a href="./rfc1825">RFC 1825</a>, Naval Research Laboratory, August 1995.
[<a id="ref-19">19</a>] Parsons, G. and Rafferty, J. "Tag Image File Format
(TIFF) -- image/TIFF: MIME Sub-type Registration", <a href="./rfc2302">RFC 2302</a>,
March 1998.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a> ACKNOWLEDGEMENTS</span>
This specification was produced by the Internet Engineering Task
Force Fax Working Group, over the course of more than one year's
online and face-to-face discussions. As with all IETF efforts, many
people contributed to the final product.
Active for this document were: Steve Huston, Jeffrey Perry, Greg
Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A.
Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James
Rafferty.
<span class="grey">Toyoda, et. al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a> AUTHORS' ADDRESSES</span>
Kiyoshi Toyoda
Matsushita Graphic Communication Systems, Inc.
2-3-8 Shimomeguro, Meguro-ku
Tokyo 153 Japan
Fax: +81 3 5434 7166
Email: [email protected]
Hiroyuki Ohno
Tokyo Institute of Technology
2-12-1 O-okayama, Meguro-ku
Tokyo 152 Japan
FAX: +81 3 5734 2754
Email: [email protected]
Jun Murai
Keio University
5322 Endo, Fujisawa
Kanagawa 252 Japan
Fax: +81 466 49 1101
Email: [email protected]
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Phone: +1 408 457 5200
Fax: +1 408 457 5208
Email: [email protected]
<span class="grey">Toyoda, et. al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a> APPENDIX A: </span>Exceptions to MIME
* IFax senders are NOT REQUIRED to be able to send
text/plain messages (<a href="./rfc2049">RFC 2049</a> requirement 4), although IFax
recipients are required to accept such messages, and to process
them.
* IFax recipients are NOT REQUIRED to offer to put results
in a file. (Also see 2.3.2.)
* IFax recipients MAY directly print/fax the received
message rather than "display" it, as indicated in <a href="./rfc2049">RFC 2049</a>.
<span class="grey">Toyoda, et. al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc2305">RFC 2305</a> Simple Mode of Facsimile March 1998</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a> Full Copyright Statement</span>
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.
Toyoda, et. al. Standards Track [Page 13]
Annotations
Select text to annotate