Internet Fax Working Group Larry Masinter Internet Draft Xerox Corporation November 20, 1997 Dan Wing Expires May 1998 Cisco Systems draft-ietf-fax-fpim-00.txt Fax Profile for Internet Mail 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1997). All Rights Reserved. Table of contents 1. Introduction 2. Background 3. Formats 4. Addressing 5. Message headers 6. Transport 7. Capabilities 8. Security 9. Operational Requirements and Limitations 10. Security Considerations 11. Acknowledgements 14. Copyright 15. Appendix - Example Fax Message 16. Authors' Addresses 1. Introduction This specification provides for carriage of facsimile data over the Internet. It employs standard protocols and file formats such as TCP/IP, SMTP[SMTP], POP3[POP], MIME[MIME], and TIFF[TIFF]. It can send images not only to other Internet-aware fax devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF data. The document [FAXREQ] defines the requirements and desired properties for facsimile over the Internet. The facilities proposed here purport to satisfy the requirements identified in [FAXREQ]. This proposal expands previous proposals [WIDE2] as it deals with expanded capabilities as well as simple facsimile transmission. It defines the behavior of devices that provide gateway functions between SMTP and traditional fax machines connected to the public switched telephone network (PSTN), as well as behavior of SMTP sender and receivers that are exchanging fax images [TIFF]. The specification is based on previous work in Internet Fax within the IETF and ITU, and the work of the Voice Profile for Internet Mail group [VPIM]. The Fax Profile of Internet Mail consists of the application of several existing and proposed Internet Standards to accomlish the task of sending image data. The profile calls for the use of standards for: - Message formats (section 3) - Addressing (section 4) - Message headers (section 5) - Transport (section 6) - Capabilities (Section 7) - Security (Section 8) - Operational requirements (Section 9) 2. Background Many fax, printer, and multi-function peripheral manufacturers are adding network connectivity to their devices. The complexity of the IP-based services offered by the network connections is increasing. Traditionally, images sent between fax machines are transmitted over the analog telephone network using modems. As the demand for networking increases, there is a need for a standard high-quality digital protocol to transmit images. 2.1 Functional elements of Fax The functions of a traditional fax device can be separated into three primary functions: scanning printing transmission Transmission can be further divided into its primary functions: capabilities negotiation image data transmission delivery confirmation 2.2 User Experience of Fax and Email The primary user experience with fax is: immediate delivery delivery confirmation ease of use The primary user experience with email is: delayed delivery no delivery confirmation ability to reply to sender easy to send to multiple recipients The protocols specified here attempt to reconcile the differences between the two environments. 2.2 Design Goals It is a goal of this profile to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the requirements outlined in [FAXREQ]. This goal is motivated by the desire to increase the accessibility to digital messaging by enabling the use of proven existing networking software for rapid development. This profile is intended to be robust enough to be used in an environment, such as the global Internet with installed-base gateways which do not understand MIME, though typical use is expected to be within corporate intranets. Full functionality, such as reliable error messages and binary transport, will require careful selection of gateways (e.g., via MX records) to be used as forwarding agents. Nothing in this document precludes use of a general purpose MIME email packages (such as Eudora, Navigator, Internet Explorer) to read and compose FPIM messages. While no special configuration is required to receive FPIM-compliant messages, some may be required to originate compliant structures. 3. Formats Standard Internet mail headers and MIME content packaging also are used. Fax offramps may choose to use the contents of the RFC822 headers to form a cover page, in addition to any cover page included in the document body. Unique message identification is achieved with the standard RFC822 Message-ID header. At a minimum, the data format of the facsimile image is based on the minimum set of TIFF[TIFF]. Rules for the use of TIFF for the message-based Internet fax application are defined below. TIFF binary data requires a proper Content-transfer-encoding, using base64, when the data is transported over channels which do not support binary transport. Multiple fax documents may be aggregated within a single Internet mail message, by using Multipart/mixed. This section lays out, in detail, the message content types that are appropriate for the application of fax, and the contexts in which these formats might be sent. Each of these is explained below. Type Send? Receive? image/tiff;application=f should must image/tiff;application=* may (when appropriate) should (as appropriate) multipart/alternative may must message/rfc822 must not must multipart/signed may must accept, should verify multipart/encrypted may may message/delivery-status may must message/disposition-notification must (when appropriate) must Multipart/Report may (when appropriate) must text/plain should not should multipart/mixed may must 3.1. Image data: image/tiff The baseline format that all FPIM devices MUST accept for image data is the minimum 'F' profile of image/tiff, as defined in [TIFF]. FPIM servers SHOULD use image/tiff;application=F for image data when no other capabilities are known. Senders MAY use other applications of [TIFF] when it is known to correspond to the capabilities of the recipient. Recipients SHOULD accept other applications of tiff when it corresponds to the capabilities of the device. 3.2 multipart/alternative In order to allow for the upgrade of facsimile messages to different capabilities, even when the recipients capabilities are unknown, fax recipients MUST accept multipart/alternative, and process the message for an acceptable type. Limited memory recipients may find processing other than the first acceptable type to be difficult. A sender MAY send a multipart/alternative that contains any media types intermixed, as long as one of the parts is allowable. Similarly, a recipient MUST accept multipart/alternative, as long as one of the parts is acceptable. 3.3 message/rfc822 Fax messages may be stored by users and forward to other Internet Fax user agents, e.g., through anInternet fax machine, fax offramp, or a normal SMTP mailbox. Because of this, fax offramps and Internet Fax devices must be able to process message/rfc822. 3.4 multipart/signed, multipart/encrypted In order to promote the use of authentication technology, recipients MUST accept signed messages, even if the signature block for the message is merely discarded. Senders SHOULD also use MIME message security. In order to promote the use of authentication technology, recipients SHOULD accept encrypted messages. Senders SHOULD be capable of sending encrypted messages. 3.5 message/delivery-status, message/disposition-notification, multipart/report Message delivery notification is provided by sending a return message to the original sender. FPIM devices must send message notifications when appropriate, and must be able to recieve them. Message delivery notifications are wrapped in multipart/report MIME types. Similarly, FPIM devices must send message notifications when appropriate, and must be able to recieve them. 3.6 text/plain Fax senders should not send plain text messages, at least to nominal fax recipients. However, in the normal email environment, the prevalence of text/plain;charset=US-ASCII as the baseline format for Internet mail means that recipients that reject simple text messages may not be able to properly function. A fax recipient MAY initially accept a text message and then forward it on to another recipient that is more capable, but in all cases, text messages should not be discarded as unread. 3.7 multipart/mixed Messages forwarded my mail user agents are sent as multipart/mixed with the entire original message enclosed in a message/rfc822 content type and the annotation as a separate text/* or image/tiff body part. 4. Addressing The mechanism by which a user specifies a fax address is outside the scope of this specification, but one might imagine using a URL to specify the the destination. Using a URL would allow facsimile profiles for other transport protocols, e.g., IPP [IPP], or HTTP's POST [HTTP], while the Fax Profile for Internet Mail would use a 'mailto' URL. This specification only describes email addresses for Internet Fax. 4.1 Classic Email Destinations Messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints. 4.2 Classic Fax Devices (accessed via a Fax Offramp) Classic fax devices may be accessed via telephone dial-up from an Internet Fax offramp. A number of different addressing schemes are feasible for processing by an IFAX offramp gateway. This specification provides for only one, to have a single, simple convention. However this is not intended to preclude use of others schemes which are acceptable by private conventions and which may be candidates for standardization in the future. The Internet mail address for such a device must encode the name of the IFAX gateway and the telephone number to be called. The destination fax telephone number is in the local-part (left-hand side) of the address. The name of the gateway is in the domain name (right-hand-side) of the address. The specification for the syntax of FAX-number is defined by "PSTN and fax address in e-mail services"[CLAUDIO]. 4.3 Special addresses Special addresses are provided for compatibility with the conventions of Internet mail. These addresses do not use numeric local addresses, both to conform to current Internet practice and to avoid conflict with existing numeric addressing plans. 4.3.1 postmaster@domain [RFC822] requires special mailbox named "postmaster" MUST exist on all systems. For a fax offramp, this address could be mapped to the phone number of a local fax machine, or the offramp's printer. This mailbox is particularly likely to receive text messages. 4.3.2 non-mail-user@domain If a reply to a message is not possible, then the special address "non-mail-user" must be used as the originator's address. This special address is used as a token to indicate an unreachable originator. For compatibility with the installed base of mail user agents, implementations that generate this special address MUST send a non-delivery notification for reply messages sent to the undeliverable address. The status code for such NDN's is 5.1.1 "Mailbox does not exist". 4.4 From/Reply Address for Fax Onramps Fax onramps that serve multiple users or locations must be able to synthesize a valid "From" address, to allow the recipient of a fax to identify the sender and possibly to reply, to accept errors, etc. If generating a valid "From" address is impossible (caller-ID unavailable), the special address "non-mail-user" MUST be used as the "From" address. 5. Message Headers Embedding messages in Internet Mail require the standard message headers for RFC822 and MIME messages. These standards are not repeated here, but the minimum headers needed for a compliant implementation are listed. Internet messages contain a header information block. This header block contains information required to identify the sender, the list of recipients, the message send time, and other information intended for user presentation. Except for specialized gateway and mailing list cases, headers do not indicate delivery options for the transport of messages. Exploder lists are noted for modifying or adding to the headers of messages that pass through them. FPIM systems MUST be able to accept and ignore headers that are not defined here. From, To, Subject, MIME-Version, Content-Type, Content-Transfer-Encoding, Date, Message-ID, Reply-To 5.1 From The From header indicates the originator's (fully qualified) email address. The From address is likely to be used for replies by email users. However, if the From address contains , the user SHOULD NOT be offered the option to reply, nor should notifications be sent to this address. 5.2 To The To header contains the recipient's fully-qualified domain address. Example: To: fax=+12145551213@mycompany.com If present, the addresses in the To header MAY be used for a reply message to all recipients. Note that the "To" address may not be the same as the delivery address of the recipient, e.g., for messages that are forward through mailing lists, mail forwarding programs, etc. 5.3 Date The Date header contains the date, time, and time zone in which the message was sent by the originator, as specified in [DRUMS]. The sending system MUST report the time the message was sent. If the FPIM sender is relaying a message from a system which does not provide a timestamp, the time of arrival at the FPIM system SHOULD be used as the date. 5.4 Received The Received header contains trace information added to the beginning of a message by Mail Transfer Agents. This is the only header permitted to be added by an MTA. Information in this header is useful for debugging. A compliant system MUST add Received headers when acting as a gateway and MUST NOT remove any. These headers MAY be ignored or deleted when the message is received at the final destination (from [RFC822]). Fax offramps MAY cause the Received headers of incoming messages to be printed in the outgoing fax messages, e.g., as a configuration option, when the headers do not match, upon first receipt of a message from a given source, when the transmission is not signed or authenticated, or as a matter of course. 5.5 Subject The subject field is often provided by email systems and can be used by fax offramps if automatic cover page generation is being performed. Fax onramps SHOULD insert a generic subject header, including the word "Fax", for the benefit of text-capable recipients. Fax offramps MAY include a printed representation of the subject line in the generated cover sheet of a message. 5.6 Disposition-Notification-To This message header is specified in [MDN]. Sending of the response when a message is received is as specified in that standard. 5.7 Notification Messages MDN: Receipt Notification messages MUST only be sent only if the MDN header is present, and typically after the user or fax machine has initiated the notification by some action (like viewing or printing the message). DSN: DSN messages may be positive or negative, and indicate delivery at the server or receipt by the client. It is recommended that systems that do not support the DSN notification format, or, if they do support DSN but didn't receive a NOTIFY=FAILURE request, SHOULD still send a DSN-formatted delivery failure message. 6. Transport Data transfer is achieved using any acceptable Internet mail transfer mechanism. The typical choice is SMTP, especially between organizations across the Internet. As for all Internet mail, delivery can be effected using SMTP, POP or IMAP, as appropriate for a local configuration. For delivery to classic fax devices via a gateway, Internet mail delivery refers to transport to the gateway, rather than transport to the final, classic fax device. Section 6.1 explains the use of SMTP for Fax; section 6.2 lists a number of extensions for ESMTP that are recommended for fax, and Section 6.3 describes other transport protocols that may be used for fax messaging. 6.1 Standard SMTP protocol elements 6.1.1 MAIL FROM This indicates where errors (bounces) are to be sent. Note that this doesn't necessarily have any relationship to the "From:" or "Sender:" headers. The MAIL FROM is converted to a Return-path header by the final delivering SMTP server. If present, it contains the address from the MAIL FROM parameter of the ESMTP exchange to which error messages MUST be sent (see [DRPT] for additional details). Note that if the Return-path is null ("<>"), e.g. no path, a notification MUST NOT be sent. If the Return path address is not available (either from this header or the MAIL FROM parameter) the Sender or From addresses may be used to deliver notifications. 6.1.2 RCPT TO This is the actual recipient. Note that this doesn't necessarily have any relationship to the "To:" or "CC:" message headers. 6.2 ESMTP extensions The following ESMTP [ESMTP] extensions are allowed or recommended. This section discusses each extension. Extension status --------------- ----------- Pipelining [PIPE] recommended Binary MIME [BINARY] recommended Size estimates [SIZE] allowed Delivery notifications [DSN] recommended (to request) Capabilities request/response [CAPS] recommended Immediate delivery [SESSION] recommended Checkpoint/Restart [CHECK] allowed Note that no STMP extensions are required, and that ordinary SMTP is allowed. 6.2.1 Pipelining The pipelining feature may reduce the initial setup time of an Internet Fax transmission, because some of the command responses need not be delayed. 6.2.2 Binary MIME Binary MIME is recommended as a way of reducing the overhead of base64 encoding of TIFF images. 6.2.3 Size estimates The use of the [SIZE] extension is recommended as a way of avoiding sending a message that is too large through a mail gateway. The conventional means of splitting large messages into smaller message/partial components seems to be not as useful for Internet Fax. The sending application might instead split a single fax into multiple messages. 6.2.4 Delivery notifications A sending agent MAY request Delivery Service Notification [DSN] since this is a natural part of existing facsimile service and is a standard part of Internet mail. A receiving agent SHOULD correctly process a DSN request which accompanies a facsimile-related message. For such messages, a DSN SHOULD be generated by an email recipient according to the standard rules for DSNs. If an offramp gateway supports DSN, it SHOULD generate one upon receipt of a fax delivery confirmation issued by the receiving facsimile device. 6.2.5 Capability request The capability extensions in [CAPS] allow an ESMTP server to tell the sending ESMTP implementation about the format capabilities of various recipients. This allows efficient transfer of appropriate data. It is only useful when the ESMTP server is able to access direct and up-to-date information about the recipient; its use is recommended in that situation. Senders SHOULD attempt to request capabilities if they are able to generate documents in multiple formats. 6.2.6 Immediate delivery The SESSION draft allows for immediate delivery end-to-end when there are live connections between sender and recipient. It is most appropriate when sender and recipient are both connected directly to the Internet. Its use is recommended. 6.2.7 Checkpoint/Restart The checkpoint/restart features of ESMTP would help onramps keep connections alive. This extension is allowed, but its utility is uncertain. 6.3 Other transport mechanisms The use of client/server desktop mailbox protocols like IMAP or POP to retrieve FPIM messages from a message store is possible without any special modifications to this specification. Email clients (and web browsers) typically have a table for mapping from MIME type to displaying application. The image/tiff and content can be configured so that they invoke the correct viewer for rendering. 7. Capabilities Knowing the capabilities, preferences and characteristics of recipients is useful to a sender in preparing an appropriate message. This specification lays out a method for describing capabilities, and protocols for making the capabilities available to recipients. 7.1 Capabilities descriptions In general, it is useful to know several orthoganal aspects of facsimile recipients: paper size, image resolution, data formats, compression schemes. It is desirable to allow page description languages such as application/pdf or application/postscript as facsimile messages. Thus, capabilities are expressed using a combination of media type and feature types. Fax recipients are assumed to accept all media types listed as "MUST ACCEPT" in section 3. This includes application F of TIFF. Other media types are acceptable using the feature notation in [features]. A recipients capabilities are identified by a sequence of feature tags. This draft defines the feature of 'TIFF' with a value taken from the list of allowable feature types, e.g., TIFF=M for TIFF application M. 7.2 message/capabilities A delivery status notification may be extended to include a capabilities statement for the recipients, of the form Capabilities-for: Date: Expires: Features: Types: 7.3 Mechanisms for publishing capabilities Senders may maintain a directory of recipient addresses and their corresponding capabilities. The mechanisms for update of those directories are many, but this profile defines the following: 7.3.1 As part of DSN Any failure of a message should result in a reply message which includes a message/capabilities component. 7.3.1 Using the CAPABILITIES SMTP extension This delivers fax recipients capabilities directly 7.3.2 As part of RR record of recipient's RHS A capabilities statement may be obtained directly from DNS. This is useful when the offramp has high capabilities (e.g., is willing to downgrade), and does not add round trip times. 8. Security Security of fax messaging can be obtained by several methods. Using authenticated connections between sender and offramp, using S/MIME or PGP messages with multipart/signed & multipart/encrypted. 9. Operational Requirements and Limitations This section describes operational requirements for several elements and agents, and the limitations expected for such devices. 9.1 Fax onramp requirements A fax onramp provides a service of accepting a PSTN fax telephone call, and forwarding the fax via the (E)SMTP protocol, as outlined herein. In order to meet the timeouts of PSTN fax, it is necessary either that the onramp be able to store and guarantee complete delivery of the message at a later time, or else that the next hop SMTP server provide a positive response of message receipt within the timeout interval. In practice, this requirement means that the onramp's next hop must respond to the end-of-mail data (which is "." if using normal DATA, or BDAT LAST if using BDAT from [CHUNK]) within the nominal T.30 timeouts [T.30], believed to be 30 seconds. 9.2 Fax Offramp requirements Must implement [DSN, MDN], and must implement [FAX-DSN]. 9.3 IFax sender limitations Internet fax machines usually act as an integrated Message User Agent, often only collecting telephone numbers from the user, but sometimes having a full alphanumeric keypad allowing entering usernames (looked up in a database) or a normal email address; Internet fax machines are not expected to contain a disk drive or sufficient memory to buffer many pages of document images, e.g., to hold the document until confirmation is available. 9.4 Limitations of Internet Mail The following are limitations of Internet Mail agents that were considered in designing this protocol. 9.4.1 number of recipients Some Internet Mail implementations may limit the number of recipients allowed for a single message; a redistribution agent for Internet Fax may not be able to queue a large number of outgoing fax messages, with the limit even possibly being a single recipient. However, ESMTP currently does not provide a mechanism for indicating the number of supported recipients. If an SMTP server has reached its limit for maximum number of recipients, it should respond with a 4xx reply code which allows the SMTP client to retry sending later. 9.4.2 limitations on message size Some Internet Mail transfer agents may have a limit on the maximum message length, and may be unable to transfer long documents. This protocol does not limit the maximum message length. Implementors should understand that some mailers will be unable to accept excessively long messages. A mechanism is defined in [SIZE] to declare the maximum message size supported. 9.4.3 Limitations on quick delivery and confirmation In many configurations of Internet Mail, the SMTP server does not handle final delivery to the recipient, but to some shared message repository. Thus, any available configurations, 'delivery' is weaker than that expected for fax. SMTP delivery is usually not immediate, and confirmation of delivery (if any) is also not immediate. SMTP cannot, in general, guarantee to provide confirmation or non-confirmation of delivery. (Extensions to SMTP may allow immediate delivery.) There is no mechanism to regenerate lost confirmation messages, ven when such facilities are deployed. 10. Security Considerations The requirements for security in Internet Fax are enumerated in [FAXREQ], and are addressed here: No unsolicited confirmation messages Messages may be signed and encrypted Traffic between SMTP servers can be encrypted, SMTP sessions can be authenticated. 11. References [8BIT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1426, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. [ANTI] A. Vaha-Sipila, "URLs for Telephony", Internet Draft, Work in Progress, draft-antti-telephony-url-??.txt. [BINARY] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, Octel Network Services, October 1995. [CAPS] D. Wing, N. Joffe, "SMTP Service Extension for Capabilities Exchange", Internet Draft, Work in Progress, draft-ietf-fax-smtp-capabilities-??.txt. [CHECK] D. Crocker, N. Freed, A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC1845, September 1995. [CLAUDIO] C. Allocchio, "PSTN and fax address format in e-mail services", Internet Draft, Work in Progress, draft-ietf-fax-addressing-??.txt. [DSN] K. Moore, "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, University of Tennessee, January 1996. K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996 [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extensions", RFC 1869, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, November 1995. [FAXREQ] L. Masinter, "Requirements for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-requirements-??.txt. [FAX-DSN] D. Wing, "Extensions to Delivery Status Notifications for Fax", Internet Draft, Work in Progress, draft-ietf-fax-dsn-extensions-??.txt [ITUDC] D. Crocker, "Procedures for the Transfer of Facsimile Data via Internet Mail", Internet Draft, Work in Progress, draft-ietf-fax-itudc-??.txt. [MDN] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", Internet Draft, Work in Progress, draft-ietf-receipt-mdn-??.txt. [MIME] N. Borenstein, and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993. [MSG822] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [NOTIFY] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, University of Tennessee, Octel Network Services, January 1996. [PIPE] N. Freed, A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995. [REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, Octel Network Services, January 1996. [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for Immediate Delivery", Internet Draft, Work in Progress, draft-ietf-fax-smtp-session-??.txt. [SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extensions for Message Size Declaration", RFC 1870, United Nations University, Innosoft International, Inc., November 1995. [SMTP] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [SUBMISSION] R. Gellens, H. Alvestrand, "Message Submission and Relay", Internet Draft, Work in Progress, draft-gellens-submit-??.txt. [TIFF-F] G. Parsons, J. Rafferty, "Tag Image File Format (TIFF) - Application F", Internet Draft, Work in Progress, draft-ietf-fax-tiff-??.txt. [TIFF] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-tiffplus-??.txt. [VPIM] G. Vaudreuil, G. Parsons, "Voice Profile for Internet Mail - version 2", Internet Draft, Work in Progress, draft-ema-vpim-??.txt. [WIDE] K. Toyoda, H. Ohno, J. Murai, "WIDE Message-based Fax over the Internet", Internet Draft, Work in Progress, draft-ietf-fax-wide-??.txt. [RFC1893] Ehanced status codes. [POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [WIDE2] K.Toyoda, H. Ohno, J. Murai, "Facsimile over Internet Mail", , November 1997. 13. Acknowledgments Many thanks to Graham Klyne, who provided a number of careful reviews of this document. This document is based on the work of various other authors, including Make Lake and Dave Crocker, who supplied [T.IFax1], Kiyoshi Toyoda, Hiroyuki Ohno, Jun Murai, who supplied [WIDE2], and G. Vaudreuil and G. Parsons, who supplied [VPIM]. 14. Copyright Copyright (C) The Internet Society 1997. 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 implmentation 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. 15. Appendix - Example Fax Message The following message is a full-featured, all-options-enabled message addressed to two recipients. To: 2145551212@vm1.mycompany.com To: "Parsons, Glenn, W." 2145551234@VM1.mycompany.com From: "Vaudreuil, Greg" 2175552345@VM2.mycompany.com Date: Mon, 26 Aug 93 10:20:20 CST MIME-Version: 1.0 ... 16. Authors' Addresses Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 USA Fax: +1 415 812 4333 EMail: masinter@parc.xerox.com Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA Phone: +1 408 457 5200 Fax: +1 408 457 5208 EMail: dwing@cisco.com