<pre>Network Working Group                                          K. Toyoda
Request for Comments: 3965                                       H. Ohno
Obsoletes: <a href="./rfc2305">2305</a>                                                 J. Murai
Category: Standards Track                                   WIDE Project
                                                                 D. Wing
                                                                   Cisco
                                                           December 2004


             <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 (2004).

Abstract

   This specification provides for "simple mode" carriage of facsimile
   data using Internet mail.  Extensions to this document will follow.
   The current specification employs standard protocols and file formats
   such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail
   Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile.
   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.

   This document is a revision of <a href="./rfc2305">RFC 2305</a>.  There have been no
   technical changes.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>

   This specification defines 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></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</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-15" title="&quot;Standardization of Group 3 facsimile apparatus for document transmission&quot;">15</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             =&gt;  Network printer
   Internet mail             =&gt;  Offramp gateway (forward to
                                 G3Fax)
   Network scanner           =&gt;  Network printer
   Network scanner           =&gt;  Offramp gateway (forward to
                                 G3Fax)
   Network scanner           =&gt;  Internet mail







<span class="grey">Toyoda, et al.              Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Key Words</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="#ref-13" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">13</a>].

<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 [<a href="#ref-1" title="&quot;Simple Mail Transfer Protocol&quot;">1</a>, <a href="#ref-3" title="&quot;Requirements for Internet hosts - application and support&quot;">3</a>].  The format of addresses MUST conform to the <a href="./rfc821">RFC</a>
   <a href="./rfc821">821</a> &lt;addr-spec&gt; and <a href="./rfc822">RFC 822</a> &lt;mailbox&gt; 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.













<span class="grey">Toyoda, et al.              Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


   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 [<a href="#ref-6" title="&quot;Post Office Protocol - Version 3&quot;">6</a>] or
   similar mailbox access protocols.

   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="./rfc2822">RFC 2822</a> and <a href="./rfc1123">RFC 1123</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 [2,
   3], 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="&quot;Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples&quot;">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 [<a href="#ref-5" title="&quot;File Format for Internet Fax&quot;">5</a>], 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-12" title="&quot;Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration&quot;">12</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="grey">Toyoda, et al.              Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


<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-9" title="&quot;An Extensible Message Format for Delivery Status Notifications&quot;">9</a>].

   NOTE:  Internet mail transported via SMTP MUST contain a MAIL FROM
          address appropriate for delivery of return notices.  (See
          <a href="#section-5.2.6">section 5.2.6</a>.)

<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.
   (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="&quot;Simple Mail Transfer Protocol&quot;">1</a>, <a href="#ref-3" title="&quot;Requirements for Internet hosts - application and support&quot;">3</a>].  The address
   MAY be contained within message content fields, such as &lt;authentic&gt;
   and &lt;destination&gt; [<a href="#ref-2" title="&quot;Internet Message Format&quot;">2</a>, <a href="#ref-3" title="&quot;Requirements for Internet hosts - application and support&quot;">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).





<span class="grey">Toyoda, et al.              Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


   The telephone number format SHOULD conform to [<a href="#ref-7" title="&quot;Minimal GSTN address format for Internet mail&quot;">7</a>, <a href="#ref-8" title="&quot;Minimal fax address format for Internet mail&quot;">8</a>].  Other formats
   MUST be syntactically distinct from [<a href="#ref-7" title="&quot;Minimal GSTN address format for Internet mail&quot;">7</a>, <a href="#ref-8" title="&quot;Minimal fax address format for Internet mail&quot;">8</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-5" title="&quot;File Format for Internet Fax&quot;">5</a>], which is also compatible with the
   specification for the minimum subset of TIFF-F in [<a href="#ref-14" title="&quot;Tag Image File Format (TIFF) -- F Profile for Facsimile&quot;">14</a>].  Receiving
   IFax devices MUST be able to read minimum set TIFF files.

   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.




<span class="grey">Toyoda, et al.              Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


   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
   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.





<span class="grey">Toyoda, et al.              Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


   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="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="&quot;Simple Mail Transfer Protocol&quot;">1</a>, <a href="#ref-3" title="&quot;Requirements for Internet hosts - application and support&quot;">3</a>]  or From [<a href="#ref-2" title="&quot;Internet Message Format&quot;">2</a>, <a href="#ref-3" title="&quot;Requirements for Internet hosts - application and support&quot;">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="grey">Toyoda, et al.              Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


<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="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), encrypted tunnels, 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.

   At the current time various protocols exist for performing the above
   functions, and are only mentioned here for information.  Such
   protocols are IPSec [<a href="#ref-17" title="&quot;Security Architecture for the Internet Protocol&quot;">17</a>] and TLS [<a href="#ref-18" title="&quot;SMTP Service Extension for Secure SMTP over Transport Layer Security&quot;">18</a>].

<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 can be used to provide end-to-end encryption.

   At the current time two protocols are commonly used for message
   encryption and are only mentioned here for information.  The two
   protocols are PGP-MIME [<a href="#ref-16" title="&quot;OpenPGP Message Format&quot;">16</a>] and S/MIME [<a href="#ref-19" title="&quot;S/MIME Version 3 Message Specification&quot;">19</a>].

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>

   [<a id="ref-1">1</a>]  Klensin, J., Editor, "Simple Mail Transfer Protocol", <a href="./rfc2821">RFC 2821</a>,
        April 2001.

   [<a id="ref-2">2</a>]  Resnick, P., Editor, "Internet Message Format", <a href="./rfc2822">RFC 2822</a>, April
        2001.





<span class="grey">Toyoda, et al.              Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


   [<a id="ref-3">3</a>]  Braden, R., "Requirements for Internet hosts - application and
        support", STD 3, <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>]  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
        Rafferty, "File Format for Internet Fax", <a href="./rfc3949">RFC 3949</a>, November
        2004.

   [<a id="ref-6">6</a>]  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
        53, <a href="./rfc1939">RFC 1939</a>, May 1996.

   [<a id="ref-7">7</a>]  Allocchio, C., "Minimal GSTN address format for Internet mail",
        <a href="./rfc3191">RFC 3191</a>, October 2001.

   [<a id="ref-8">8</a>]  Allocchio, C., "Minimal fax address format for Internet mail",
        <a href="./rfc3192">RFC 3192</a>, October 2001.

   [<a id="ref-9">9</a>]  Moore, K., and G. Vaudreuil, "An Extensible Message Format for
        Delivery Status Notifications", <a href="./rfc3464">RFC 3464</a>, January 2003.

   [<a id="ref-10">10</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-11">11</a>] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for Non-ASCII Text", <a href="./rfc2047">RFC 2047</a>,
        November 1996.

   [<a id="ref-12">12</a>] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -
        image/tiff MIME Sub-type Registration", <a href="./rfc3302">RFC 3302</a>, September
        2002.

   [<a id="ref-13">13</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>

   [<a id="ref-14">14</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-15">15</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 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


   [<a id="ref-16">16</a>] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
        Message Format", <a href="./rfc2440">RFC 2440</a>, November 1998.

   [<a id="ref-17">17</a>] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-18">18</a>] Hoffman, P., "SMTP Service Extension for Secure SMTP over
        Transport Layer Security", <a href="./rfc3207">RFC 3207</a>, February 2002.

   [<a id="ref-19">19</a>] Ramsdell, B., "S/MIME Version 3 Message Specification", <a href="./rfc2633">RFC</a>
        <a href="./rfc2633">2633</a>, June 1999.

<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 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


Appendix A:  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>.

Appendix B:  List of edits to <a href="./rfc2305">RFC 2305</a>

   +----+----------+-------------------------------------------------+
   | No.| Section  |             Edit  July 27, 2001                 |
   +----+----------+-------------------------------------------------+
   | 1. |Copyright | Updated copyright from "1998" to "1999,2000"    |
   |    |Notice    |                                                 |
   +----+----------+-------------------------------------------------+
   | 2. |SUMMARY   | Changed the phrase "over the Internet" to       |
   |    |          |               "using Internet mail"             |
   +----+----------+-------------------------------------------------+
   | 3. |5         | Changed the paragraphs regarding to the         |
   |    |          | following references to make them very          |
   |    |          | non-normative.                                  |
   |    |          |  "OpenPGP Message Format", <a href="./rfc2440">RFC 2440</a>             |
   |    |          |  "Security Architecture for the IP", <a href="./rfc2401">RFC 2401</a>   |
   |    |          |  "SMTP Service Extensions for Secure SMTP over  |
   |    |          |   TLS", <a href="./rfc2487">RFC 2487</a>                                |
   |    |          |  "S/MIME Version 2 Message Specification",      |
   |    |          |   <a href="./rfc2311">RFC 2311</a>                                      |
   +----+----------+-------------------------------------------------+
   | 4. |REFERENCES| Removed the following references because they   |
   |    |          | are non-normative                               |
   |    |          |  "SMTP Service Extensions for Delivery Status   |
   |    |          |   Notifications", <a href="./rfc1891">RFC 1891</a>                      |
   |    |          |  "Internet Message Access Protocol", <a href="./rfc2060">RFC 2060</a>   |
   +----+----------+-------------------------------------------------+
   | 5. |REFERENCES| Separated REFERENCES to the normative and       |
   |    |          | non-normative                                   |
   +----+----------+-------------------------------------------------+
   | 6. |Appendix  | Changed the phrase from "NOT REQUIRED" to       |
   |    | A        | "not required"                                  |
   +----+----------+-------------------------------------------------+
   | 7. |Appendix  | Added "Appendix B  List of edits to <a href="./rfc2305">RFC 2305</a>"   |
   +----+----------+-------------------------------------------------+




<span class="grey">Toyoda, et al.              Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


Authors' Addresses

   Kiyoshi Toyoda
   Panasonic Communications Co., Ltd.
   4-1-62 Minoshima Hakata-ku
   Fukuoka 812-8531 Japan

   Fax:   +81 92 477 1389
   EMail: toyoda.kiyoshi@jp.panasonic.com


   Hiroyuki Ohno
   National Institute of Information and Communications Technology
   4-2-1, Nukui-Kitamachi, Koganei, Tokyo,
   184-8795, Japan

   Fax:   +81 42 327 7941
   EMail: hohno@ohnolab.org


   Jun Murai
   Keio University
   5322 Endo, Fujisawa
   Kanagawa 252 Japan

   Fax:   +81 466 49 1101
   EMail: jun@wide.ad.jp


   Dan Wing
   170 W. Tasman Drive
   San Jose, CA 95134 USA

   Phone: +1 408 525 5314
   EMail: dwing@cisco.com
















<span class="grey">Toyoda, et al.              Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3965">RFC 3965</a>               A Simple Mode of Facsimile          December 2004</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Toyoda, et al.              Standards Track                    [Page 14]
</pre>