Applications Area Larry Masinter Internet Draft Xerox Corporation April 6, 1998 Dan Wing Expires September 1998 Cisco Systems Operational Guidelines for Fax over SMTP draft-ietf-fax-operation-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes operational guidelines for devices and software which implement fax-over-SMTP [SERVICE]. An device which implements [SERVICE] and this document will be able to exchange capabilities, confirm message receipt, perform immediate delivery, and determine the length of a call. Additionally, some guidelines are introduced to allow for new functions to be added without breaking older implementations. 1. Table of Contents 1. Table of Contents 2. Introduction 2.1. Requirements notation 3. Message Headers 3.1 From 3.2 Sender 3.3 To, Cc 3.4 Date 3.6 Subject 2. Addressing 2.1 Special domain addresses for EIFax mail domains 2.1.1 postmaster@domain 2.1.2 abuse@domain, noc@domain, security@domain 2.2 Source Address for Fax Onramps 3. Cover Sheet Generation 3.1. Received: headers 3.2. Disclosing dial-access strings 3.3. Date 4. Content-Types 4.1 Image data: image/tiff 4.2 multipart/mixed 4.3 text/plain 4.4 message/rfc822 4.5 multipart/alternative 4.6 multipart/signed, multipart/encrypted 4.7 message/delivery-status, message/disposition-notification, 4.8 Other Internet Media types 5. Transport and Confirmation 5.1 EIFax configurations 5.2 Standard SMTP protocol elements 5.2.1 MAIL FROM 5.2.2 RCPT TO 5.3 SMTP extensions 5.3.1 Delivery notifications 5.3.2 Binary MIME 5.3.3 Capability request 5.3.3 Immediate delivery 5.3.4 Pipelining 5.3.5 Size estimates 5.3.6 Checkpoint/Restart 5.3.7 Enhanced Error Codes 5.4 Other transport mechanisms 6. Operational Requirements and Limitations 6.1 Onramp requirements 6.2 Offramp requirements 6.3 IFax sender limitations 6.4 Limitations of Internet Mail 6.4.1 number of recipients 6.4.2 limitations on message size 6.4.3 Limitations on quick delivery and confirmation 7. Security Considerations 8. Acknowledgments 9. Copyright 10. References 11. Authors' Addresses A. Appendix A - Examples A.1 Full fax message A.2 Example disposition notification (with capabilities) A.3 Failure to display A.4 multipart/alternative 2. Introduction This document describes how implementations that are compliant with [SERVICE] can be implemented to also permit full functionality with EIFax implementations. Companion documents are: [FAXREQ] "Requirements for Internet Fax", defines the basic terminology and goals for the Extended Internet Facsimile service of Fax over the Internet. [SERVICE] "A Simple Mode of Facsimile Using Internet Mail" [EIFAX] "Extended Internet Facsimile using Internet Mail", capabilities exchange and delivery confirmation 2.1. Requirements notation 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 [RFC2119]. The intent in designing this specification is to require ("MUST") those items that are required to insure interoperability with devices that implement [EIFAX], and strongly recommend ("SHOULD") those items that are important for satisfying the user requirements for facsimile over the Internet. 3. Message Headers Internet Mail and MIME messages contain header fields. These headers supply, information such as the sender, the list of recipients, the date of the message, the type of content, a list of mailers that have relayed the message, and other information. [[ Except for specialized gateway and mailing list cases, headers do not indicate delivery options for the transport of messages. ]] Internet mailing list software and mail redirection systems might modify, and will often add to the headers of messages that pass through them; for this reason, EIFax systems MUST be able to accept and (at a minimum) ignore headers that are not defined here. Header information should be preserved in some manner to allow debugging and determining a where a message originated from. See section 4 for details. 3.1 From In Internet mail, the From header indicates the originator's (fully qualified) email address. The From address is likely to be used for replies by email users. All EIFax mail MUST be identified with a From field which indicates the source of the message. For the benefit of text mail users, the From field generated by an onramp SHOULD include some text identification of the fact that the user is a fax service, e.g., From: Fax'R'Us Service 3.2 Sender In Internet mail, the Sender header contains the actual address of the originator if the message is sent by an agent on behalf of the author indicated in the From: field. 3.3 To, Cc In Internet mail, the To and CC headers contain the recipient's fully-qualified domain address. Examples: To: fax=+12145551213@mycompany.com To: fax=+12145551213@mycompany.com, dwing@cisco.com Note that the "To" address may not be the same as the delivery address of the recipient(s); this might happen for messages that are forwarded, sent through aliases, processed by mailing lists or mail gateways, or blind carbon copied. 3.4 Date In Internet mail, the Date header contains the date, time, and time zone in which the message was sent by the originator. An EIFax sender system MUST include the Date header. If an EIFax sender cannot provide a Date header (because it lacks a clock and isn't running NTP [RFC1305] or SNTP [RFC2030]), the Date header can be generated using [SUBMIT]. 3.6 Subject In Internet mail, the Subject field is often provided as an indication of the content of the message. Fax onramps and IFax senders SHOULD insert a useful subject header, for the benefit of text-capable recipients. Fax offramps and IFax recipients MAY include a printed representation of the subject line in the generated cover sheet of a message. 2. Addressing In addition to the requirements in [SERVICE], the following additional requirements for addressing are included. 2.1 Special domain addresses for EIFax mail domains Several special email addresses are required or recommended for Internet mail domains [RFC2142]. This section points out the requirements for supporting special email addresses and the application to EIFax. An EIFax sender supplies a return address or an origin address for messages it sends. For example, an EIFax onramp might supply a "From" address of "fax=+nnnnnnn@domain". If "domain" is supported entirely by the same EIFax service ("offramp"), there are additionaly requirements for supporting special email addresses in EIFax devices: address requirement postmaster MUST abuse, noc, security SHOULD non-mail-user SHOULD (if appropriate) These are explained below. "Support" for such special addresses will vary depending on the physical implementation of the EIFax device. Support means that mail sent to the address isn't lost and is handled appropriately, which usually means making the message, in its entirety, available to a human recipient by printing the message on the fax machine's printer, forwarding it to a human's mailbox, or dialing a local fax machine to print the message. 2.1.1 postmaster@domain [RFC822] requires special mailbox named "postmaster" MUST exist on all systems. For a fax offramp, This mailbox is particularly likely to receive text messages (non-MIME, and multipart/report). 2.1.2 abuse@domain, noc@domain, security@domain Fax offramp services which support an entire domain SHOULD support these addresses as defined in [RFC2142]. 2.2 Source Address for Fax Onramps An EIFax sender MUST supply a valid MAIL FROM address for errors, and that address MUST be able to process non-MIME messages and the MIME types text/plain and multipart/report. Fax onramps that serve multiple users or locations MUST synthesize a valid source address, to allow the recipient of a fax to identify the sender and possibly to reply. If generating a valid "From" address based on the fax sender is impossible (caller-ID unavailable), the mailing address of the administrator or service provider MAY be used. 3. Cover Sheet Generation Some of the message headers, such as From, To, CC, Subject, and Data, is intended for presentation to the user. Other headers, such as Received, Content-Type, and Return-Path, are not normally presented to the user and are only useful during troubleshooting or to track abuse. It can often be impossible to determine if a cover page is already included in the message body, so such cover page generation MAY be in addition to any cover page included in the document body. Fax offramps SHOULD use the contents of the user-presentation headers (such as From, Subject, To, CC, possibly others) and the RCPT TO (if available) to generate a cover page. A From: address that includes a telephone number in standard form [FAXADDR] with a canonical telephone number might be able to use that telephone number as the "telphone number of the sender or of the sending fax machine", as is required by some legal authorities. 3.1. Received: headers EIFax recipients MUST provide a mechanism to allow the display of mail headers, including "Received:" header fields, as a way of diagnosing misdirected mail or tracing the source of unwanted fax messages. Such display need not occur on the cover page, but should be available in some manner to a system administrator. It can be problematic for an offramp to include the Received: headers on the cover page. In an interactive Internet mail environment, it is common for the Mail User Agent to hide all but the 'normal' headers, but to offer the ability to display the rest of the mail headers when requested.However, for an offramp or IFax device, once the message has been printed or faxed, it is gone, and the value of these headers for tracking is lost. It is unlikely that users will find configuring options convenient. 3.2. Disclosing dial-access strings Including the RCPT TO, and possible the To: header, on the cover page can cause unintentional disclosure of long-distance dial access strings. To prevent such disclosure, the cover page should only contain telephone numbers that conform to [FAXADDR]. 3.3. Date Note that, for a message that is stored and forwarded through one or more Internet mail transfer agents, the time the message was sent by the message will be different than the time the message is received. An EIFax offramp SHOULD identify the time of fax transmission over the PSTN in addition to, or instead of, the time of origin, in order to satisfy the legal requirement of identifying the date of transmission. 4. Content-Types MIME defines a general mechanism by which many kinds of message bodies may be sent over Internet mail. The content type of a message body is indicated by the "Content-Type" header. A content type label consists of a top level type ("image", "text", "application", etc.), a subtype, and an optional set of parameters and parameter values. New content-types may be registered. Some content types within "message", "multipart" have a special role as structural designators. [SERVICE] defines a minimum level of conformance for Facsimile using Internet Mail. This section lays out the message content types that are required or optional for EIFax over and above those required by [SERVICE], and describes the contexts in which these formats might be sent. The following summary is explained in subsequent sections. Type Sender Recipient image/tiff (minimum F) SHOULD MUST image/tiff (beyond min) SHOULD NOT MAY multipart/mixed MAY MUST multipart/alternative MAY MUST message/rfc822 SHOULD NOT SHOULD multipart/signed MAY MUST accept, SHOULD verify multipart/encrypted MAY MAY message/delivery-status SHOULD (when requested) MUST (return address) message/disposition-notification SHOULD (as appropriate) MUST (return address) multipart/report MAY (when appropriate) MUST (return address) text/plain SHOULD NOT MUST (return address) any other file type MAY (when appropriate) MAY These requirements apply to all EIFax senders and recipients. Note that some 'recipient' requirements apply to the 'return address' supplied by an EIFax sender rather than to all EIFax recipients. 4.1 Image data: image/tiff [SERVICE] requires that all senders accept the minimum subset of the "F" profile of TIFF for Fax [TIFF]. In addition, EIFax recipients SHOULD support the entire range of the "F" profile, and MAY accept other profiles. EIFax senders MUST use the minimum subset of the "F" profile when the capabilities of the recipient are unknown. EIFax senders MAY use other applications of [TIFF] if the capabilities of the recipient are known to include the handling of those applications. See [EIFAX] for a description of how capabilities of the remote system can be learned. 4.2 multipart/mixed EIFax recipients MUST accept multiple message bodies to be concatenated together on display using multipart/mixed. EIFax senders MAY send such messages, as needed; it is allowable for individual pages to be sent as separate image/tiff images within multipart/mixed, although such use is not recommended. Note that unregonized multipart messages, such as multipart/signed, are interpreted as if they were multipart/mixed. 4.3 text/plain EIFax senders SHOULD NOT send plain text messages. That is, EIFax is not intended as a replacement for text messaging. 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 would not be able to properly function. An EIFax recipient MUST accept plain text messages. It might convert the text into the proper format for forwarding (via a text-to-fax converter) or might operate by forward text messages on to another recipient that is more capable, but in all cases, text messages MUST be processed. 4.4 message/rfc822 In Internet mail, a message is often stored, saved, and later forward to another email address. To support the ability to forward EIFax messages to other EIFax recipients, EIFax recipients MUST accept message/rfc822 encapsulated messages, and process them appropriately. 4.5 multipart/alternative In Internet mail, the "multipart/alternative" [RFC2046] construct allows for a sender to send a document in more than one format, within the same message, in the case where the capabilities of the recipient are not known and cannot be discovered. It is inefficient, since the content is repeated multiple times, and is used sparingly. In order to allow for the upgrade of facsimile messages to different capabilities EIFax recipients MUST accept messages using "multipart/alternative",as long as _one_ of the parts is acceptable, and choose (from the enclosed content) one of the alternatives to display or print. While [RFC 2046] specifies that systems SHOULD chose the "best" type, based on the local environment and references, limited memory EIFax recipients MAY handle "multipart/alternative" by interpreting the _first_ acceptable type. An EIFax sender MAY send a "multipart/alternative" that contains *any* media types intermixed, as long as one of the parts is allowable; the alternatives SHOULD appear in an order of _increasing_ faithfulness to the original content, as specified in [RFC2046]. 4.6 multipart/signed, multipart/encrypted In order to promote the use of authentication technology, EIFax recipients MUST accept signed messages, and SHOULD attempt to verify the signature, and indicate success or failure. In order to promote the use of message security, EIFax recipients SHOULD accept encrypted messages. Senders SHOULD be capable of sending encrypted messages to those recipients for which encryption is available. See section 9 (Security) 4.7 message/delivery-status, message/disposition-notification, multipart/report The details of EIFax confirmation are contained in section 7 (Confirmation). Note that section 8 (Capabilities) defines an extension to message/disposition-notifications that allows recording of the recipient's capabilities. Any EIFax sender (or, more accurately, the return address specified by an EIFax sender) MUST be able to accept and automatically process a "multipart/report" message. 4.8 Other Internet Media types EIFax recipients MAY also conditionally accept messages in other formats. That is, there is no restriction that EIFax only be used for TIFF or other MIME types. An EIFax sender SHOULD NOT send media that it does not have some reliable indication that the recipient can accept, but, using capabilities statements, it is possible for an EIFax recipient (Internet mail user, IFax device, offramp) to accept other media types, including "application/postscript", "application/pdf", "image/jpeg", or (if properly labeled) media with proprietary or vendor-specific information, using any registered type [RFC2046]. 5. Transport and Confirmation Data transfer in EIFax is achieved using any acceptable Internet mail transfer mechanism. The typical choice is SMTP, especially between organizations across the Internet. Section 6.1 discusses the various configurations for EIFax senders and recipients. Section 6.2 discusses the use of standard SMTP for Fax. Section 6.3 describes some ESMTP extensions that are recommended for direct SMTP participants, and section 6.4 describes other transport protocols that may be used for fax messaging. 5.1 EIFax configurations EIFax senders (of all types) MAY use simple SMTP with no extensions, deliverying store and forward messages directly to a 'mail drop'. The protocol in [SUBMIT] is an alternative protocol. In addition, EIFax senders of all types MAY directly connect to the final Mail Transfer Agent of the recipient, looking up the recipient's MX DNS entry [RFC974]. EIFax recipients (of all types) MAY be simple Internet mail user agents. The using protocols such as POP [RFC1939] or IMAP [RFC2060]. Alternatively, an EIFax offramp or IFax device with a permanent Internet connection MAY operate as a SMTP server. For delivery to classic fax devices via an offramp (gateway), Internet mail delivery refers to transport to the EIFax offramp, rather than transport to the final, classic fax device. The special case of "direct connection" provides additional opportunities for optimization: the phrase "direct connection" will be used to refer to the case where (a) the EIFax sender implements full mail routing [RFC 874] (b) the recipient is an EIFax offramp or IFax device which implements SMTP (c) a direct connection between the sender and recipient is available (e.g., both on the same local Intranet or both on the public Internet) 5.2 Standard SMTP protocol elements [[ I think SERVICE covered this sufficiently? The elements of SMTP are defined in RFC 821. This section points out appropriate use of these elements in EIFax. 5.2.1 MAIL FROM The MAIL FROM address indicates where errors (bounces) are to be sent. It may not have a relationship to the "From:" or "Sender:" mail headers. The MAIL FROM address is converted to a Return-Path header by the final delivering SMTP server. If the Return-Path is present, it contains the address from the MAIL FROM parameter of the SMTP exchange to which error messages MUST be sent (see [RFC1891] for additional details). 5.2.2 RCPT TO This is the actual recipient. Note that this doesn't necessarily have any relationship to the "To:" or "CC:" message headers. ]] 5.3 SMTP extensions EIFax makes no mandatory requirements for additions or enhancements to the standard Internet Mail environment. However, there are some enhancements to SMTP delivery of mail which provide additional desirable functionality. These enhancements are available as SMTP extensions, as defined in [RFC1869]. SMTP client ----------- Extension recommendation --------------- ----------- [RFC1891] Delivery notifications SHOULD [RFC1830] Binary MIME MAY [CAPS] Capabilities request/response SHOULD [SESSION] Immediate delivery SHOULD [RFC2197] Pipelining MAY [RFC1870] Size estimates MAY [RFC1845] Checkpoint/Restart MAY [RFC2034] Enhanced Error Codes MAY SMTP server ----------- Extension recommendation --------------- ----------- [RFC1891] Delivery notifications SHOULD [RFC1830] Binary MIME MAY [CAPS] Capabilities request/response SHOULD [SESSION] Immediate delivery MAY [RFC2197] Pipelining SHOULD [RFC1870] Size estimates MAY [RFC1845] Checkpoint/Restart MAY [RFC2034] Enhanced Error Codes SHOULD Each of these is explained below. 5.3.1 Delivery notifications This is a standard part of the Internet Mail environment [RFC1891]. The requirements for delivery status notifications in EIFax are discussed in [EIFAX]. 5.3.2 Binary MIME This is an experimental protocol for Internet Mail.[RFC1830] Its use would eliminate the overhead otherwise entailed by the required base64 encoding of the binary image data. The application of Binary MIME is RECOMMENDED for the "direct connect" case, but support of direct connect itself is OPTIONAL. 5.3.3 Capability request This extension is RECOMMENDED only for the "direct connect" case. The capability extensions in [CAPS] allow a SMTP server to tell the sending SMTP 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. If senders are able to generate documents in multiple formats, senders SHOULD implement this option. 5.3.3 Immediate delivery This extension is recommended for the "direct connect" case. The SESSION extension 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. Based on user preferences (for immediate or delayed delivery, for example) EIFax senders MAY attempt to perform immediate delivery, and EIFax recipients SHOULD support immediate delivery. 5.3.4 Pipelining This extension is RECOMMENDED for any SMTP sender or recipient. The pipelining feature reduces the total number of necessary round trip delays in an SMTP transaction. This is especially useful in high-latency networks. Senders SHOULD use pipelining if the recipient supports it, and recipients SHOULD support pipelining. 5.3.5 Size estimates The use of the [RFC1870] 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. An onramp, which is unable to determine how many pages are in a fax, is unable to utilize SIZE. 5.3.6 Checkpoint/Restart The checkpoint/restart features of ESMTP would help onramps keep connections alive. The utility of this feature for fax onramp/offramps is uncertain. 5.3.7 Enhanced Error Codes This extension is recommended for any SMTP participant. This allows more useful status information to be returned to the sender. 5.4 Other transport mechanisms The use of client/server desktop mailbox protocols like IMAP or POP to retrieve EIFax 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. 6. Operational Requirements and Limitations This section describes operational requirements for several elements and agents, and the limitations expected for such devices. 6.1 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. 6.2 Offramp requirements <> Fax offramps SHOULD support [RFC1891], [MDN], and [FAXDSN]. MAY generate cover pages based on message headers. Fax offramps MAY be capable of accepting higher resolution images and converting them into representations that can be accepted by the fax terminals that they are forwarding the message to. Fax offramps MAY support other message formats, such as "application/postscript". [[also see section 6.3, smtp service extensions]] 6.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. IFax machines must either be capable of accepting text/plain messages, or forwarding them to a user's system which *is* capable of accepting such messages. 6.4 Limitations of Internet Mail The following are limitations of Internet Mail agents that were considered in designing this protocol. 6.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. 6.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. Implementers should understand that some mailers will be unable to accept excessively long messages. 6.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 delivers the message to a message repository. 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.) In this case, "delivery" does not indicate that the message has been printed, but only that it is in a repository under the control of the recipient. If the ultimate EIFax recipient then subsequently retrieves and prints the message, the sender's expectation of "confirmation" may not correspond. There is no mechanism to regenerate lost confirmation messages, even when such facilities are deployed. 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 EIFax messages. 7. Security Considerations The requirements for security in Internet Fax are enumerated in [FAXREQ]. Security threats and their countermeasures are described in [SERVICE]. Additional security threats created by new features are described in [EIFAX]. 8. Acknowledgments Many thanks to Graham Klyne and Vivian Cancio, who provided a number of careful reviews of this document, and to Ken Camarro, Robert Rosenberg, George Pajari, Mike Lake, Glen Parsons, Paul Van Schagen and others who supplied many valuable comments. Many of the concepts here were originated in the work of other authors, including Mike Lake, Dave Crocker, Kiyoshi Toyoda, Hiroyuki Ohno, Jun Murai, and the VPIM authors, including G. Vaudreuil and G. Parsons. 9. Copyright 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. 10. References [CAPS] D. Wing, N. Joffe, "SMTP Service Extension for Capabilities Exchange", Internet Draft, Work in Progress, draft-ietf-fax-smtp-capabilities-??.txt. [EIFAX] L. Masinter, "Extended Internet Facsimile using Internet Mail", Internet Draft, Work in Progress, draft-ietf-fax-fpim-??.txt [FAXADDR] C. Allocchio, "PSTN and fax address format in e-mail services", Internet Draft, Work in Progress, draft-ietf-fax-addressing-??.txt. [FAXDSN] D. Wing, "Extensions to Delivery Status Notifications for Fax", Internet Draft, Work in Progress, draft-ietf-fax-dsn-extensions-??.txt [FAXREQ] L. Masinter, "Requirements for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-requirements-??.txt. [CONSCEN] E. Hardie, "Scenarios for the Delivery of Negotiated Content", November 1997, [FEATREG] K. Holtman, A. Mutz, "Feature Tag Registration Procedures", July 1997, . [FEATSCEN] K. Holtman, A. Mutz, "Feature Tag Scenarios", July 1997, . [FEATMED] L. Masinter, "Features for Media Display", November 1997, . [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, draft-ietf-receipt-mdn-??.txt. <> [RFC821] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [RFC822] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC974] C. Partridge. "Mail routing and the domain system", STD ??, RFC 822, January 1986. [RFC1123] R. Braden, "Requirements for Internet hosts - application and support", RFC 1123, October 1989. [RFC1305] D. Mills, "Network Time Protocol (Version 3): Specification, Implementation and Analysis", RFC 1305, March 1992. [RFC1830] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, October 1995. [RFC1845] D. Crocker, N. Freed, A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995. [RFC2197] N. Freed, A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 2197. [RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995. [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996. [RFC1892] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996. [RFC1893] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, January 1996. [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996 [RFC1870] J. Klensin, N. Freed, K. Moore, "SMTP Service Extensions for Message Size Declaration", RFC 1870, November 1995. [RFC1911] G. Vaudreuil, "Voice Profile for Internet Mail", RFC 1911, Feb 1996. [RFC1939] J. Myers, M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2030] D. Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [RFC2049] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2142] D. Crocker, "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997. [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997. [SERVICE] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of Facsimile Using Internet Mail", Internet Draft, Work in Progress, draft-ietf-fax-service-01a.txt, December 1997. [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for Immediate Delivery", Internet Draft, Work in Progress, draft-ietf-fax-smtp-session-??.txt. [SUBMIT] R. Gellens, H. Alvestrand, "Message Submission and Relay", Internet Draft, Work in Progress, draft-gellens-submit-??.txt. [TIFF] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax", . [TIFF-ADOBE] Tag Image File Format, Revision 6.0, Adobe Developers Association, June 3, 1992, ftp://ftp.adobe.com/pub/adobe/devrelations/ devtechnotes/pdffiles/tiff6.pdf, "The TIFF 6.0 specification dated June 3, 1992 specification, Copyright (c) 1986-1988, 1992 Adobe Systems Incorporated. All Rights Reserved." [TIFF-F] G. Parsons, J. Rafferty, "Tag Image File Format (TIFF) - Application F", Internet Draft, Work in Progress, . [VPIM] G. Vaudreuil, G. Parsons, "Voice Profile for Internet Mail - version 2", . (Updates [RFC 1911]). 11. 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 A. Appendix A - Examples A.1 Full fax message The following message is a full-featured, all-options-enabled message addressed to two recipients. << not supplied yet >> A.2 Example disposition notification (with capabilities) Date: Wed, 20 Dec 1997 00:19:00 (EDT) -0400 From: Fax +1 650 812 4333 Message-Id: <199509200019.12345@offramp.xerox.com> Subject: Disposition notification To: Fax +1 555 555 1212 MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615765" --RAA14128.773615765 The message sent on 19 Dec 1997 11:55:00 (EDT) -0400 to was successfully forward to the telephone-based fax number <+1-650-812-4333>. --RAA14128.773615765 content-type: message/disposition-notification Reporting-UA: offramp.xerox.com; Offramp Megabucks Software Original-Recipient: rfc822;fax=+1-650-812-4333@offramp.xerox.com Final-Recipient: fax;+1-650-812-4333 Original-Message-ID: <199509192301.12345@spammer.com> Disposition: automatic-action/MDN-sent-automatically; forwarded Capabilities: tiff=M --RAA14128.773615765 A.3 Failure to display Date: Wed, 20 Dec 1997 00:19:00 (EDT) -0400 From: Fax +1 650 812 4333 Message-Id: <199509200019.12345@offramp.xerox.com> Subject: Fax failure To: Fax +1 555 555 1212 MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615767" --RAA14128.773615767 The message sent on 19 Dec 1997 11:50:00 (EDT) -0400 to failed to forward to the telephone-based fax number <+1-650-812-4333>. --RAA14128.773615765 content-type: message/disposition-notification Reporting-UA: offramp.xerox.com; Offramp Megabucks Software Original-Recipient: rfc822;fax=+1-650-812-4333@offramp.xerox.com Final-Recipient: fax;+1-650-812-4333 Original-Message-ID: <199509192301.12347@spammer.com> Disposition: automatic-action/MDN-sent-automatically; processed, error capabilities="tiff=f,tiff=s,itut=0x1AEEF" --RAA14128.773615765 A.4 multipart/alternative A.5 ...