Internet Fax Working Group Larry Masinter Internet Draft Xerox Corporation December 30, 1997 Dan Wing Expires in six months Cisco Systems draft-ietf-fax-fpim-01.txt Extended Mode of Facsimile Using 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. 1. Introduction This document contains a number of experimental facilities; as such, it is not an official product of the IETF FAX working group, but records some of the possible enhancements to the simple service described in [SERVICE]. This version is being made available document the options being considered, so that they might be used as the basis for experimentation. As an Experimental protocol, it is inappropriate for this specification to be used as a basis for products or other formal standards without the appropriate additional review. [FAXREQ] defines the basic terminology and goals for the full operational service of Fax over the Internet. [SERVICE] defines a simple mode of transmission of facsimile documents using Internet mail. This document extends the capabilities in [SERVICE] to provide for full functionality and advanced capabilities with a suitable operating environment, such as when the sender and recipient can communicate directly, or when appropriate features are supported by intermediate mail relays. The phrase "Extended Internet Facsimile" (EIFax) is used to denote this specification, and a "EIFax agent" is a component or device that complies with this specification. This specification frequently distinguishes between the role of sender and recipient; "EIFax sender" and "EIFax recipient" are used accordingly to denote complient sender and recipient agents. 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]. Different requirements may apply to different participants. The intent in designing this specification is to require ("MUST") those items that are required to insure interoperability, and to strongly recommend ("SHOULD") those items that are important for satisfying the user requirements for facsimile over the Internet. 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. 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 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. 2.1.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. 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]. Mail to these mailboxes MAY be directed to a special telephone number or routed to another email address. 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. Message Headers Internet Mail and MIME messages contain header fields. These headers supply, for example, information such as the sender, the list of recipients, the date of the message, the type of content, 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. Internet mailing list software and mail redirection systems might modify or 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 <fax=+16508124333@fax.xerox.com> EIFax offramps MAY use the From address to identify the source of the message; 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.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. EIFax messages MAY include a Sender header, which can be used by EIFax offramps in a generated cover sheet. 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, or processed by mailing lists or mail gateways. A fax offramp MAY use both the RCPT TO routing information and additional information in the message headers to create a cover sheet for a fax message. 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 report the time the message was sent. 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]. 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. 3.5 Received In Internet mail, 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 a compliant Mail Transfer Agent. Information in this header is useful for debugging. This header is required per section 5.2.8 of [RFC1123]. EIFax recipients MAY cause the Received headers of incoming messages to be printed for fax messages. For example, this might be a configuration option, might occur be signaled when there is a mismatch between From address and the received headers, upon first receipt of a message from a given source, when the transmission is not signed or authenticated, or as a matter of course. For messages that are delayed in delivery, the Received headers are useful for diagnosing the source of the delay. 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. 3.7 Disposition-Notification-To, Disposition-Notification-Options In Internet mail, these headers indicates a request that a notification be generated by the receiving user agent [MDN]. The role of message disposition notifications and delivery confirmation within EIFax is described in section 7 (Confirmation). 3.8 Message-ID In Internet mail, the Message-ID header contains a globally unique message identifier. EIFax message senders MUST generate a valid Message-ID field. 4. Cover Sheets Fax offramps MAY use the contents of the message headers to form a cover page, in addition to any cover page included in the document body. EIFax recipients MUST provide a mechanism to allow the display of mail headers, including Received header fields, e.g., as a way of diagnosing misdirected mail or tracing the source of unwanted fax messages. Doing this requires some care. 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. 5. 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. 5.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 section 8). 5.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. 5.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. 5.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. 5.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]. 5.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) 5.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. 5.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]. 6. Transport 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. 6.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) 6.2 Standard SMTP protocol elements The elements of SMTP are defined in RFC 821. This section points out appropriate use of these elements in EIFax. 6.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). 6.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. 6.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]. Extension recommendation --------------- ----------- [RFC1891] Delivery notifications SHOULD request, SHOULD support [RFC1830] Binary MIME MAY request, MAY support [CAPS] Capabilities request/response SHOULD request, SHOULD support [SESSION] Immediate delivery SHOULD request, MAY support [RFC2197] Pipelining MAY request, SHOULD support [RFC1870] Size estimates MAY request, MAY support [RFC1845] Checkpoint/Restart MAY request, MAY support [RFC2034] Enhanced Error Codes MAY request, SHOULD support Each of these is explained below. 6.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 section 7 (Confirmation). 6.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. 6.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. 6.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. 6.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. 6.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. 6.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. 6.3.7 Enhanced Error Codes This extension is recommended for any SMTP participant. This allows better status to be returned to the sender. 6.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. 7. Confirmation 7.1 delivery and disposition: background In traditional facsimile, the sending terminal receives a confirmation when the receiving terminal has finished processing the incoming fax. In Internet mail, however, the two functions of "delivery" and "disposition" are separated. Internet mail has two notification mechanisms: "delivery status notifications" [RFC1891] and "message disposition notifications" [MDN]. These mechanisms differ: a) how they are requested: Delivery status notifications are requested within the SMTP protocol using SMTP extensions [RFC1891] [FAXDSN], while disposition notifications are requested by including a Disposition-Notification-To header in the message [MDN]. b) when they are reported: Delivery status is reported when a message is delivered to some repository or end-point under the control of the recipient. Disposition notification [MDN] is provided when the message is disposed of by the recipient user, either manually or automatically. c) which agent reports them: Delivery status is reported by the mail transport mechanism, while disposition is reported by the end mail user agent. d) what form the reports take: Both DSNs and MDNs are sent in a "multipart/report". DSNs use "report-type=delivery-status"; MDNs use "report-type=disposition-notification". 7.2 EIFax requirements for confirmation Because the two functions might both be useful for fax users, an EIFax sender MAY request either or both of delivery status notification and/or disposition notifications, depending on their configuration and user requirements. An EIFax recipient SHOULD follow the recommendtations in [MDN] for handling of requests for disposition notification; EIFax recipients that are SMTP servers SHOULD support [RFC1891] and [FAXDSN], in order to accomodate the user experience of immediate confirmation of fax delivery in the "direct connect" case. For security and privacy, special care must be taken with the implementation of message disposition notification; the security considerations of [MDN] recommend that no disposition notification be sent without the user's explicit acknowledgment. An EIFax offramp, however, MAY automatically send a MDN after forwarding a fax to a traditional fax terminal. NOTE: The "SHOULD" requirement is intended to strongly recommend the support of delivery notification, because it is required to support the traditional user experience of "facsimile", at least according to most accounts. If there are valid operational reasons for not supporting this capability, implementation is not required. For example, a product that never will have SMTP delivery directly to a server that would support delivery status notifications might justifiably never request one. However, many current SMTP servers implement delivery status notification, and it is a Proposed Standard. 7.3 Using Delivery Status vs. Disposition Notification The decision between requesting delivery status notifications and message disposition notifications is difficult. The value of disposition notifications is that they can provide end-to-end confirmation in all Internet mail environments, even when there has been no deployment of [RFC1891] capable SMTP servers. This is most important with the recipient is an IFax device (with limited format capabilities) which is a POP client. Using only delivery status notification does not provide a way to indicate, for example, that the format sent is not acceptable, since the delivery notification will have been sent as soon as the message is stored. However, in the case where the sender and recipient are connected by a delivery-notification-capable infrastructure, the case for delivery status notification is much stronger primarily because DSNs are more reliable than MDNs. In the case of "direct connect" the fact that _other_ SMTP servers haven't deployed [RFC1891] is irrelevant, since no other servers are involved beyond the sender and the recipient. This is likely to be a common operational mode, since it will apply for both intranet users (e.g., intra-company fax) or for dial-up users with IFax devices connecting via an Internet Service Provider to a distant Internet offramp. 8. Capabilities Knowing the capabilities, preferences and characteristics of recipients is useful to a sender in preparing an appropriate message. The general regime and requirements for content negotiation in Internet protocols is described in [CONSCEN]. In general, it is useful to know several orthogonal aspects of facsimile recipients: paper size, image resolution, data formats, compression schemes. In some situations, it might be desirable to allow, as EIFax messages, additional document representation methods, compression schemes, or even page description languages. In Internet mail, file formats are expressed as Internet media types ("image/tiff", "application/postscript", etc.). Other elements of recipient preferences and capabilities may be described with content "features" [FEATREG],[FEATMED]. 8.1 EIFax base level operation For reliability, an EIFax sender SHOULD NOT send a message with higher capabilities than it is 'known' that the recipient can handle. The knowledge of a recipients capabilities may be manually configured, or conveyed by any of the (optional) facilities described in this section. EIFax recipients MAY be assumed to accept all media types listed as "MUST" under "Accept" in Section 5 (Content-Types). In addition, an EIFax sender MAY use "multipart/alternative" to send more than one rendition of the same document, e.g., a lower and a higher resolution; this might be used if no information about the recipient is known, as with the 'first fax' sent to a given single recipient. If no other information is known and "multipart/alternative" is not used, the EIFax sender SHOULD restrict the message content type to those that are REQUIRED in section 5 (Content-Types). 8.2 Fax specific "features" This document defines the "TIFF" feature in the Internet Media Features registry [FEATREG] as a way of simply specifying different profiles of TIFF [TIFF]. Thus, the feature tag TIFF=M corresponds to the feature of accepting "image/tiff;application=M". 8.3 Mechanisms for making capabilities known Senders may maintain a directory of recipient addresses and corresponding capabilities, or, in some situations, may request capabilities prior to transmission. This subsection lists several optional and required methods by which recipients can make capabilities known to senders, and by which senders can request capabilities. [[The extensions to MDN described in this section will be released in a separate Internet Draft]] 8.3.1 A "Capabilities" extension field of message/disposition-notification In store and forward email, it is useful to piggy-back the capabilities of a recipient on top of the message disposition notification. This is a simple and inexpensive way that frequent fax correspondents can aquire information about the capabilities of other EIFax elements, without additional overhead beyond that necessary for the original transmission and confirmation. This can be accomplished simply by using an extension to the mechanism defined in [MDN] for disposition notification. The standard for message disposition notifications includes an extension mechanism. New "extension fields" can be defined. This document defines the "capabilities" extension field. The "capabilities" extension field provides a way for a recipient to indicate the recipient's capabilities in the context of a message disposition notification. The value of the "capabilities" extension field contains a comma-separated list of features [FEATREG]. An EIFax recipient SHOULD include a capabilities extension field whenever it sends a message disposition notification. 8.3.2 The "Capabilities" disposition-notification-option An EIFax sender MAY include a "Disposition-Notification-Options" header (in addition to a Disposition-Notification-Request) as a way of indicating that the sender wishes the recipient to return the recipients capabilities in addition to the notification. This specification defines and registers the disposition notification parameter of "Capabililities", e.g., an EIFax sender may include Disposition-Notification-To: <sender> Disposition-Notifications-Options: Capabilities=optional 8.3.3 Using the Capabilities SMTP extension [CAPS] defines an SMTP extension by which an EIFax sender (or any Internet mail sender) may request information as to the capabilities of a recipient prior to the transmission of the image. 8.3.4 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. [[ DNS record for capabilities has limited applicability: a) single machine has DNS record, b) offramp will do downgrading ]] 9. Security The basic security considerations for Internet Fax are described in [SERVICE]. The mechanisms for disseminating capabilities of recipients is subject to additional security concerns. 10. Operational Requirements and Limitations This section describes operational requirements for several elements and agents, and the limitations expected for such devices. 10.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. 10.2 Offramp requirements <<this section should summarize requirements for offramps, it is incomplete>> 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". 10.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. 10.4 IFax recipients 10.5 Limitations of Internet Mail The following are limitations of Internet Mail agents that were considered in designing this protocol. 10.5.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. 10.5.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. 10.5.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. 11. 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. Recipients must have some way of tracing otherwise unauthenticated messages Denial of service attacks, spamming are significant problems which must be attacked in any S&F internet mail system. 12. IANA considerations This document makes several additions to the IANA registry: <<this section should summarize all new registrations that require IANA actions.>> 13. 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. 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 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. 15. References [CAPS] D. Wing, N. Joffe, "SMTP Service Extension for Capabilities Exchange", Internet Draft, Work in Progress, draft-ietf-fax-smtp-capabilities-??.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, <draft-ietf-http-negotiate-scenario-02.txt> [FEATREG] K. Holtman, A. Mutz, "Feature Tag Registration Procedures", July 1997, <draft-ietf-http-feature-reg-02.txt>. [FEATSCEN] K. Holtman, A. Mutz, "Feature Tag Scenarios", July 1997, <draft-ietf-http-feature-scenarios-01.txt>. [FEATMED] L. Masinter, "Features for Media Display", November 1997, <draft-masinter-media-features-00.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, draft-ietf-receipt-mdn-??.txt. <<approved for Proposed Standard>> [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", <draft-ietf-fax-tiffplus-03.txt>. [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, <draft-ietf-fax-tiff-05.txt>. [VPIM] G. Vaudreuil, G. Parsons, "Voice Profile for Internet Mail - version 2", <draft-ema-vpim-06.txt>. (Updates [RFC 1911]). 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 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 <fax=+1-650-812-4333@offramp.xerox.com> Message-Id: <199509200019.12345@offramp.xerox.com> Subject: Disposition notification To: Fax +1 555 555 1212 <fax=+1-555-555-1212@spammer.com> 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 <fax=+1-650-812-4333@offramp.xerox.com> 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 <fax=+1-650-812-4333@offramp.xerox.com> Message-Id: <199509200019.12345@offramp.xerox.com> Subject: Fax failure To: Fax +1 555 555 1212 <fax=+1-555-555-1212@spammer.com> 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 <fax=+1-650-812-4333@offramp.xerox.com> 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 ...
Datatracker
Report a datatracker bug
draft-ietf-fax-fpim-01
None
| Document | Document type |
Expired Internet-Draft
(fax WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors |
Larry M Masinter
,
Dan Wing
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |