IETF Internet fax WG Graham Klyne Internet draft Integralis Technology Ltd. 1 May 1998 Expires: 1 November 1998 Scenarios for Internet fax capability exchange 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 made obsolete 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 (C) 1998, The Internet Society Abstract The simple mode for Internet fax described in [1] relies on transmission of documents using a minimum feature set to achieve interoperability between sender and receiver. Proposals for extended Internet fax [2,3] aim to provide for transmission of enhanced documents (e.g. higher resolutions, colour) by employing mechanisms to identify recipient capabilities to the sender, in the same fashion as traditional Group 3 fax [4]. This memo describes some of the scenarios for capability exchange in Internet fax, taking account of the particular nature and goals of the application [5], with a view to informing the debate over what mechanisms should be used for this purpose. Klyne [Page 1] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange Table of contents 1. Introduction.............................................2 1.1 Terminology ..........................................3 1.2 Structure of this document ...........................3 1.3 Discussion of this document ..........................3 1.4 Amendment history ....................................4 1.5 Unfinished business ..................................4 2. Capability exchange issues in Internet fax...............4 3. Scenarios................................................5 3.1 User scenarios .......................................6 3.2 Deployment scenarios .................................7 3.3 Traditional facsimile scenarios ......................9 3.3.1 Summary of T.30 DIS frame........................9 3.3.2 Fax polling......................................9 4. Implementation notes.....................................10 4.1 Identification of capabilities .......................10 4.2 Denotation of capabilities ...........................10 4.3 Mechanisms for capability exchange ...................10 5. Security considerations..................................11 6. Copyright................................................12 7. Acknowledgements.........................................12 8. References...............................................12 9. Author's address.........................................15 1. Introduction The simple mode for Internet fax described in [1] relies on transmission of documents using a minimum feature set to achieve interoperability between sender and receiver. Proposals for extended Internet fax [2,3] aim to provide for transmission of enhanced documents (e.g. higher resolutions, colour) by employing mechanisms to identify recipient capabilities to the sender. Traditional facsimile employs a system of capability identification, built in to the underlying facsimile transmission protocol [4], so that documents can be transmitted with quality greater than is provided by the base format capability common to all facsimile machines. A number of suggestions have been made [7,9, and others not formally published] to provide similar facilities for facsimile data transmitted using Internet e-mail. But, because Internet e-mail is quite different to traditional facsimile transmission technologies, the mechanisms used must be different. Klyne [Page 2] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange This memo describes some of the scenarios for capability exchange in Internet fax, taking account of the particular nature and goals of the application [5], with a view to informing the debate about what mechanisms should be used for this purpose. 1.1 Terminology Terminology used in this document that is specific to Internet fax is taken from [5]. 1.2 Structure of this document The main part of this memo addresses the following areas: Section 2 discusses some of the technical issues that make provision of traditional facsimile capability identification somewhat problematic in Internet e-mail, and contrasts the features of traditional fax transport mechanisms with Internet e-mail that make this so. Section 3 describes some scenarios for capability exchange in Internet fax, from the viewpoints of system users, deployment and traditional facsimile service offerings. Section 4 discusses some general concepts that might have a bearing on how capability identification might be implemented for Internet fax. 1.3 Discussion of this document Discussion of this document should take place on the Internet fax mailing list hosted by the Internet Mail Consortium (IMC): Please send comments regarding this document to: ietf-fax@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org". To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-fax/ To unsubscribe from the ietf-fax mailing list, send a message to "ietf-fax-request@imc.org" containing the message 'unsubscribe'. Klyne [Page 3] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange 1.4 Amendment history 00a 31-Mar-1998 Document initially created. 00b 01-May-1998 Minor updates based on feedback received. Update references. Extended security considerations section. 1.5 Unfinished business . Add new scenarios identified by ongoing debate and review. . Complete the T.30 scenarios with input from T.30 experts. 2. Capability exchange issues in Internet fax Technical differences between the Internet e-mail SMTP transport [11] and the facsimile T.30 transmission protocol [4] that tend to dictate different approaches to capability exchange are: . SMTP is a store-and-forward protocol, which means that the sender of a message is generally disengaged from the message transfer process at the time final delivery is accomplished. T.30, on the other hand, is a session mode protocol in which the transmitter of a message is directly involved in the process until final delivery is accomplished and signalled back to the sender. (There is a proposal to provide a session mode capability in SMTP [10], but in its present form even this may be forced to fall back to store-and-forward mode in some circumstances.) Because SMTP is a store-and-forward protocol, there may be arbitrary delays in the transfer of a message . Being a store-and-forward Internet protocol, SMTP can service occasionally connected correspondents; thus there is no requirement or expectation for the ultimate recipient to be accessible at the time a message is sent. Traditional facsimile, on the other hand, relies on the fact that telephone devices are always physically connected to the network and available to receive calls (except when they are busy). A related consideration is that SMTP senders do not have to be concerned with the possibility that the recipient is busy at the time a message is sent. But the next-hop MTA may be unavailable for a variety of reasons, so some system of retries is required. Klyne [Page 4] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange . In T.30, the sender of a message connects directly to and interacts with the receiver. Using SMTP, this is not generally the case and an indeterminate number of intermediate relays (MTAs) may be involved in the transmission process. The capabilities of these intermediate systems is not generally known or knowable. . T.30 is a binary protocol; i.e. protocol elements and data are represented as arbitrary bit streams. SMTP on the other hand is a text-based protocol, and all protocol elements and data must be represented in a stream of US-ASCII text; this imposes restrictions on the way that protocol elements are coded. (Similar restrictions also apply to the data in SMTP, but these restrictions are generally made transparent through the use of MIME transfer encoding of message data.) . In general, there are significant per-message call setup and volume-related transmission costs associated with traditional facsimile. When using SMTP, there are generally no per-message or volume-related transmission costs. (This is a simplification, and there are exceptions in both cases, but holds widely enough to be a good working model.) . Traditional facsimile calls are placed using a dedicated physical connection, and while that connection is in use for one message transfer it cannot be used for any other purpose. SMTP message transfers can share a physical connection between several different activities. This has implications for possible concurrent use of multiple services or capability acquisition mechanisms. 3. Scenarios In this section, scenarios are presented from three different perspectives: . User scenarios: capability identification scenarios based on the resulting message transfer behaviour that would be visible to a user of the system. . Deployment scenarios: based on the effect that capability identification has on the way that messages flow through the network infrastructure. Klyne [Page 5] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange . Traditional facsimile scenarios: based on capability exchange behaviours which have come to be associated with Group 3 facsimile. This section examines various commonly-used capability identification mechanisms present in T.30 [4] and considers their applicability to the Internet e-mail environment. In all cases, the goal is to provide interoperability between sender and receiver of a message; i.e. to achieve a message transfer which can be processed by the recipient, or to advise the sender that a desired transfer is not possible. 3.1 User scenarios These scenarios focus on issues of presentation quality, as evidenced by media features and a recipient's capability to handle them. Many of the scenarios may extend to non-media capabilities (e.g. encryption, language). . Sender wishes to send a simple low-resolution monochrome image, per "simple mode" [1]. This should always be sent regardless of any capability exchange mechanisms available or employed. . Sender wishes to send a high-resolution monochrome image, but the information content would still be useful if sent at a lower resolution. No capability information about the receiving system is known or available. The sender has two options: (a) send the image at reduced quality only, or (b) send a multipart/alternate containing full quality and reduced quality [12]. . Sender wishes to send a high-resolution monochrome image, but the information content would still be useful if sent at a lower resolution. Capability information of dubious reliability about the receiving system available, suggesting that the recipient can handle the full quality. The sender's options are the same as above, but there is greater reason to send both formats. Sending the high-quality image only is probably not a good idea (see security considerations). . Sender wishes to send a high-resolution monochrome image. Available and trusted capability information indicates that the receiving system is known or available to handle this format. The image can be sent at full quality only. . Sender has a high quality colour image (e.g. promotional literature) which needs to be sent at full quality to be of any use. In the absence of any capability information, the sender may either (a) send the message and hope, or (b) take steps to acquire the receiver's capabilities. Klyne [Page 6] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange Having capability information of dubious reliability indicating that the recipient can handle the image, the same options are available but there is probably greater reason to send the image straight away. Having capability information of dubious reliability which indicates that the recipient cannot handle the image, the sender might follow either of the options suggested above, but possibly with greater preference for acquiring capabilities before sending the message. Alternatively, he might give up and not send the message at all (probably not a good idea). . Sender has an original document in different formats each requiring a different set of enhanced recipient capabilities for optimum display. One of the formats would also provide usable information to a recipient with minimum capabilities, per [1], but the other would provide optimum display for a recipient with the required capabilities. Depending upon available capability information the sender has options to send (a) the best format, (b) the not-so-good format which will display with minimum capabilities, (c) both formats. In all the above cases, the sender's choice may be modified by the cost of transmitting the message, which in turn will depend upon the size of the various possible message formats and the ultimate destination. For example, he may decline to send a multi-Megabyte presentation graphic which would incur international offramp charges without knowing that the recipient could process that data. 3.2 Deployment scenarios This section discusses deployment scenarios, which have a bearing on the kind of negotiation or capability identification mechanisms that could prove useful. . Corporate mail and Internet fax server with access to corporate address book and fax offramp systems. Such a system might conduct authoritative capability identification on behalf of the users in its address book, with the idea that messages for users that might be delivered by e-mail or fax transmission can be handled. . A combination of SMTP session mode and capability identification extensions [9, 10] could provide a capability identification mechanism that operates via the Internet to provide G3 fax like negotiation. In this scenario, security concerns about privacy and accuracy of information are heightened, and these would need be addressed in some way. Klyne [Page 7] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange . Capabilities can be sent with message disposition notification (per [7]). Some form of capability information would be available after a message had been sent to a given destination, but might become stale if messages are sent infrequently to that recipient. This has associated security concerns. Addressing the security concerns discussed in [7] will go some way to addressing these. . Capabilities can be sent with outgoing messages (e.g. per [13,14]), to be used in any return message. These, too, can become stale. Also, for communication between send-only and receive-only systems, the capability information is of little use (unless the receiving system can lodge it in some common area for use by related sending systems). . Capabilities might be cached on an MTA server which is close to the recipient of a message and which can be made readily and immediately available to sending parties. (Information held closer to the receiving system is likely to be more reliable than more remote information.) . Multiple copies (multipart/alternate) could be sent to an intervening MTA, which could then conduct negotiation on the sender's behalf to select the best version to deliver. . Format-converting gateways might be used to accept a variety of formats which the receiver does not recognize. Declared receiver capabilities would also include conversion capabilities of the gateway. This may introduce secondary security concerns if message integrity/authentication mechanisms are being employed. . Capability identification can be used for Internet-to-Internet, Internet-to-GSTN (via an offramp gateway) and GSTN-to-Internet (via an onramp gateway). In the onramp/offramp cases, capability information would relate to the gateway's ability to accept data and pass it on in a form usable by the ultimate addressee, rather than necessarily indicating the addressee's capabilities. . Hunt groups: a given recipient address (phine number, etc.) may connect to any of several receiving systems in a "hunt group". If different systems in the group have different capabilities, a possibility exists for capability identification information from one exchange to cause a sending system to send unusable data in a subsequent message transmission. Klyne [Page 8] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange 3.3 Traditional facsimile scenarios 3.3.1 Summary of T.30 DIS frame The following paraphrases an analysis of bits in the T.30 DIS frame with a view to their relevance to capability identification, which was posted to the IETF-FAX discussion list: . The DIS bits up to about bit 45 are mainly concerned with resolution, compression, width and size capabilities etc. Things like transmission speed and scan line time capabilities are not relevant in a store and forward environment, but would be dealt with by the off-ramp transmitter. Special image characteristics of the receiver cannot be so dealt with and are best known in advance via negotiations. Thus, DIS 1-45 are covered by [20], or are irrelevant to Internet fax capability identification. . Bits 47-64 deal with polling, sub-addressing, password, non-image data (including BFT) and alternative negotiation methods. Polling is discussed in a separate section below. Sub-addressing can be handled by conversion to the format described in [16,17] at the onramp and offramp gateways. Non-image transfer is logically handled by MIME encapsulation [18,12], though there are some issues about mapping Object Ids (used by the Group 3 fax binary file envelope T.434 [19] Security presents some real problems because of the impossibility of passing a secured message through a gateway (which by the nature of T.30 and SMTP must convert the data content in some way) without possessing the relevant security keys. [[Identify T.30 capability/negotiation options in greater detail, and relevance to Internet fax operations]] 3.3.2 Fax polling Polling raises the following issues: (a) identifying whether or not polling is available (or, strictly following the Group 3 facsimile model, to determine if data is available to be polled), (b) content selection for polled data, and Klyne [Page 9] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange (c) whether or not polling is required and appropriate in the context of Internet fax (given the alternate methods available), and the mechanisms appropriate for performing polling. It has been noted that although polling is commonly performed with Group 3 facsimile, it is often used for special applications and performed using special purpose features rather than the standard T.30 facilities for this purpose. 4. Implementation notes To define a deployable system for capability exchange in Internet fax, the following issues must be addressed: 4.1 Identification of capabilities The specific capabilities which can be exchanged must be identified (or at least, some initial set). The Group 3 facsimile protocol, T.30 [4], defines a number of such capabilities, identified by bits in the DIS frame and in other protocol frames. A number of features related to media type and capability are identified in [20]. This document has, by design, a high degree of overlap with media features identified by T.30. It may be desirable to also provide some higher-level identification of capabilities, such as general support for Internet fax. 4.2 Denotation of capabilities A way to represent capabilities carried within the SMTP protocol must be defined. The limitations of SMTP suggest that a textual format should be used (as opposed to the binary formats used for T.30). 4.3 Mechanisms for capability exchange Mechanisms for capability exchange (i.e. carrying capability information between correspondents) fall into two broad categories: . Connected, using some form of direct client/server enquiry protocol (e.g. LDAP [15], T.30 frames [4], SMTP capabilities [9]). Klyne [Page 10] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange . Disconnected, carried by SMTP as message data (e.g. MDN extensions [7], vCard with message [13,14]). This does not address the ever-present possibility of using any kind of out-of-band mechanism to supply information about a recipient to the sending agent (e.g. user input). 5. Security considerations The following are primary security concerns for capability exchange mechanisms: . Unintentional disclosure of private information through the announcement of capabilities or user preferences. . Disruption to system operation caused by accidental or malicious provision of incorrect capability information. . Use of a capability identification mechanism might be used to probe a network (e.g. by identifying specific hosts used, and exploiting their known weaknesses). Security considerations relevant to Internet fax are discussed further in [1,5]. The most contentious security concerns are raised by mechanisms which automatically send capability identification data in response to a query from some unknown system. Use of directory services (based on LDAP [15], etc.) seem to be less problematic because proper authentication mechanisms are available. Mechanisms which provide capability information when sending a message are less contentious, presumably because some intention on the part of the person whose details are disclosed to communicfate with the recipient of those details can be inferred. This does not, however, address spoofed supply of incorrect capability information. The use of format converting gateways may prove probelmatic because such systems would tend to defeat any message integraty and authenticity checking mechanisms that are employed. Klyne [Page 11] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange 6. 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. 7. Acknowledgements The ideas in this document came from a meeting with particular contributions from James Rafferty, Larry Masinter, Richard Shockey. Further ideas have been taken from postings to the IETF-FAX mailing list. 8. References [1] "A Simple Mode of Facsimile Using Internet Mail" K. Toyoda, H. Ohno J. Murai, WIDE Project D. Wing, Cisco RFC 2305 March 1998 Klyne [Page 12] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange [2] "Extended Facsimile Using Internet Mail" Larry Masinter, Xerox Corporation Dan Wing, Cisco Systems Internet draft: Work in progress, March 1998 [3] "Procedures for the Transfer of Facsimile Data via Internet Mail" D. Crocker, Internet Mail Consortium Internet draft: Work in progress, October 1997 [4] ITU Recommendation T.30: "Procedures for document facsimile transmission in the General Switched Telephone Network" International Telecommunications Union, 1996 [5] "Terminology and Goals for Internet Fax" Larry Masinter, Xerox Corporation Internet draft: Work in progress, March 1998 [6] "Extensions to Delivery Status Notifications for Fax" Dan Wing, Cisco Systems Internet draft: Work in progress, November 1997. [7] "Using Message Disposition Notifications to Indicate Supported Features" Dan Wing, Cisco Systems Internet draft: Work in progress, March 1998 [8] "Operational Guidelines for Fax over SMTP" Larry Masinter, Xerox Corporation Dan Wing, Cisco Systems Internet draft: Work in progress, March 1998 [9] "SMTP Service Extension for Capabilities Exchange" Dan Wing, Neil Joffe, Cisco Systems Internet draft: Work in progress, November 1997 [10] "SMTP Service Extension for Immediate Delivery" Dan Wing, Neil Joffe, Cisco Systems Larry Masinter, Xerox Corporation Internet draft: Work in progress, February 1998 Klyne [Page 13] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange [11] RFC 821, "Simple Mail Transfer Protocol" J. Postel, Information Sciences Institute, University of Southern California August 1982. [12] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media types" N. Freed, Innosoft N. Borenstein, First Virtual November 1996. [13] vCard - The Electronic Business Card Version 2.1 Internet Mail Consortium URL: September 1996. [14] vCard MIME Directory Profile Frank Dawson, Lotus Development Corporation Tim Howes, Netscape Communications Internet draft Work in progress: April 1998. [15] RFC 2251, "Lightweight Directory Access Protocol (v3)" M. Wahl, Critical Angle Inc. T. Howes, Netscape Communications Corp. S. Kille, Isode Limited December 1997. [16] RFC 2303, "Minimal PSTN address format in Internet Mail" C. Allocchio, GARR-Italy March 1998. [17] RFC 2304, "Minimal FAX address format in Internet Mail" C. Allocchio, GARR-Italy March 1998. [18] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Internet message bodies" N. Freed, Innosoft N. Borenstein, First Virtual November 1996. [19] ITU-T Recommendation T.434, "Binary file transfer format for the telematic services" International Telecommunications Union July 1996 Klyne [Page 14] Internet draft 1 May 1998 Scenarios for Internet fax capability exchange [20] "Media Features for Display, Print, and Fax" Larry Masinter, Xerox Corporation Koen Holtman, TUE Andy Mutz, Hewlett Packard Dan Wing, Cisco Systems Internet draft: Work in progress, March 1998 9. Author's address Graham Klyne Content Technologies Ltd Forum 1 Station Road Theale Reading, RG7 4RA United Kingdom Telephone: +44 118 930 1300 Facsimile: +44 118 930 1301 E-mail: GK@ACM.ORG Klyne [Page 15]