HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:19:40 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 14 Aug 1998 13:07:00 GMT ETag: "2e6c6a-85ad-35d43674" Accept-Ranges: bytes Content-Length: 34221 Connection: close Content-Type: text/plain IETF Internet fax WG Graham Klyne Internet draft Integralis Technology Ltd. 2 April 1998 Expires: 2 October 1998 Scenarios for Internet fax message confirmation 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] does not provide positive confirmation of message delivery or disposition. There is a widespread view that an important benefit of traditional fax [2] is the fact that it provides a delivery confirmation which is trusted by fax system users. This memo describes some of the options for message confirmation in Internet fax, taking account of the particular nature and goals of the application [3], with a view to informing the debate over what mechanisms should be used for this purpose. Klyne [Page 1] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 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 2. Message confirmation issues in Internet fax..............4 3. Current message confirmation mechanisms..................6 3.1 Group 3 facsimile confirmation .......................6 3.2 Internet e-mail confirmations ........................6 3.2.1 Delivery Status Notifications (DSN)..............6 3.2.2 Message Disposition Notifications (MDN)..........7 3.2.2 Negative confirmations...........................8 4. Confirmation options and scenarios.......................8 4.1 Internet e-mail to e-mail ............................8 4.2 Internet e-mail to fax machine .......................9 4.3 Fax machine to Internet e-mail .......................9 4.4 Summary of scenarios .................................10 4.5 Other mechanisms .....................................12 4.5.1 Direct delivery..................................12 4.5.2 Session mode SMTP extension......................12 4.5.3 Real-time fax image transfer.....................13 5. Security considerations..................................14 6. Copyright................................................14 7. Acknowledgements.........................................15 8. References...............................................15 9. Author's address.........................................17 1. Introduction The simple mode for Internet fax described in [1] does not provide positive confirmation of message delivery or disposition. There is a widespread view that an important benefit of traditional facsimile [2] is the fact that it provides a delivery confirmation which is trusted by fax system users. Proposals for extended Internet fax [4,5,6] aim to provide for both positive and negative confirmation of transmission of fax messages which go beyond the limited negative acknowledgement capabilities of SMTP [7]. This memo describes some of the options for message confirmation in Internet fax, taking account of the particular nature and goals of the application [3], with a view to informing the debate over what mechanisms should be used for this purpose. Klyne [Page 2] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 1.1 Terminology Terminology used in this document that is specific to Internet fax is taken from [3]. 1.2 Structure of this document The main part of this draft addresses four main areas: Section 2 discusses some of the technical issues that make provision of traditional facsimile confirmation 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 discusses some general concepts and mechanisms that might have a bearing on how capability identification might be implemented for Internet fax. Section 4 describes some options for message confirmations in 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'. 1.4 Amendment history 00a 01-Apr-1998 Document initially created. 00b 03-Apr-1998 Add material from IETF meeting discussions. Section 4.4 is new and helps to draw together some key ideas. Klyne [Page 3] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 2. Message confirmation issues in Internet fax Technical differences between the Internet e-mail SMTP transport [7] and the facsimile T.30 transmission protocol [2] that tend to dictate different approaches to capability exchange are: . SMTP separates the functions of message transmission from message preparation and message display. Message transmission is performed by Message Transfer Agents (MTAs), and message preparation and display is handled by Message User Agents (MUAs). The MTA and MUA components of Internet e-mail deal with separate protocol elements: MTAs work with the SMTP protocol [7], where MUAs deal with construction and processing of RFC822 e-mail messages [8]. (MUAs also operate as SMTP clients for the purpose of initiating a message transfer) This separation of message transmission from message processing has a distinct bearing on the forms that a message confirmation can take: one form handled by MTAs is DSN [9], another form handled by MUAs is MDN [10]. Further discussion of these appears later. A receiving MTA can be either a Message Store (MS) or a Gateway to some other kind of messaging system (GW). . 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, 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, and it is not generally possible to provide any kind of confirmation during the protocol session that sends a message. . In traditional facsimile, message delivery and disposition (printing) are often handled at the same time and place: with SMTP, the processes of delivery (e.g. to a POP mailbox) and disposition (e.g. collection and display of message) may be separated in time and space. Klyne [Page 4] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation There are exceptions to this, such as fax machines that receive into memory, and print later. But it is widely held that the "user model" of fax that it is printed as soon as it has been sent. . 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. . 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 to handle confirmation mechanisms is not generally known. . 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 this holds widely enough to be a good working model.) 3. Current message confirmation mechanisms There are two mechanisms currently defined for providing message confirmations in Internet e-mail, neither of which exactly match the traditional Group 3 facsimile confirmation mechanism. 3.1 Group 3 facsimile confirmation Group 3 fax confirmation relies upon a real-time connection from the sender to receiver. As each page of image data is transmitted, a real-time protocol exchange occurs during which the receiver indicates that the page has been received OK. The confirmation generated by the receiving system often, but not always, indicates that the received data has been printed. What it does always indicate is that the data has been received and that the receiving system has all information needed to process and Klyne [Page 5] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation print the data; i.e. that it has accepted responsibility for further processing of the data. There may always be circumstances when a G3 fax confirmation does not guarantee that the intended recipient will see the message. A power failure may destroy the message data stored in the receiving facsimile machine; a printed message may be removed and lost before the intended recipient can see it. But these are unlikely events, and a Group 3 confirmation of receipt is generally a good indication that the recipient will see the message. 3.2 Internet e-mail confirmations It should be noted that, in the Internet e-mail environment, message confirmations are generated only when explicitly requested by the sender of a message. This rule is necessary to ensure that message confirmation loops to not occur. 3.2.1 Delivery Status Notifications (DSN) The request for DSN [9] is carried by the SMTP protocol, and is processed by MTAs. Advantages are: . The sender is guaranteed some kind of response (unless the status notification itself is lost in transit). . The generation of DSN notifications does not depend upon the capabilities of the receiving MUA. Disadvantages are: . End-to-end DSN requires the support of every MTA along the transmission path from sender to recipient. If any one of these MTAs does not support DSN then a notification response is generated at that point which tells the sender how far the message had progressed up to that point, but cannot provide information about its further progress Thus, the information provided by DSN may be of limited value. . Even when DSN is fully supported by all MTAs, the final notification might still not indicate that the message has been delivered to the recipients receiving terminal. When the recipient uses a mailbox protocol (e.g. POP3 [11]) to collect message, MTA delivery is achieved on receipt of the message into a message store serviced by the POP3 server. The recipient still has to collect the message from the mailbox server before he can process it. Klyne [Page 6] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 3.2.2 Message Disposition Notifications (MDN) A request for MDN [10] is carried in the message body where it is hidden from the activities of MTA. The receiving MUA (or gateway) is responsible for generating all responses to an MDN request. Advantages are: . End-to-end confirmation does not depend upon the capabilities of any MTA used to transmit the message. Disadvantages are: . Generation of a response to MDN depends upon the capabilities of the receiving MUA. If it does not recognize the MDN request then no MDN can be generated. . There are a number of important security considerations associated with the use of MDNs, and they may not be generated without the receiving user's consent. For normal e-mail MUAs, this means that a receiving user may prohibit generation of an MDN with no indication of this fact passed back to the sender. The security concerns are with possible disclosure of private information about a user (e.g. an MDN request in a message to a mailing list might be used to gather addresses for spamming), or with disclosure of information about the activities of a user (e.g. the response to an MDN might disclose that the user was connected to the Internet or reading e-mail at a particular time). 3.2.2 Negative confirmations The discussions above address mechanisms for positive message confirmation. For negiative confirmation (reporting of errors on the transmission path), Delivery Status Notifications are required, because there can be no guarantee that an Message Disposition Notification will ever be generated. If a message is lost at any point along the path from sender to delivery point, there is no way for generation of an MDN to be triggered. Thus, in all cases, DSNs must are required for negative message confirmation. Klyne [Page 7] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 4. Confirmation options and scenarios In this section, some options and message confirmation scenarios are suggested. 4.1 Internet e-mail to e-mail (1) (2) (3) (4) +----------+ +---------+ +-----------+ +-----------+ |Sender-MUA|-->--|Relay-MTA|-->--|Receive-MTA|-->--|Receive-MUA| +----------+ +---------+ +-----------+ +-----------+ . DSN end-to-end: with DSN implemented at (2) and (3), provides notification of delivery to (3). If (3) is a mailbox server, no indication of collection by (4) will be returned. . DSN part-way: with DSN implemented at (2) but not at (3), provides indication that the message was delivered to (3), but that no information about any further MTA hops will be provided. . DSN not implemented: with DSN not implemented at (2), the sending MUA knows only that the message was accepted at (2) for onward delivery. . MDN implemented: if (4) implements MDN then an MDN might be generated when the message is received and displayed at (4). But the user at (4) may choose to prohibit generation of MDN. . MDN implemented at receiving Internet Fax (IFAX) device: in this case, it might be possible to relax the conditions regarding automatic generation of MDN, since the security concerns about user privacy may not apply, to provide a dependably confirmation of receipt. 4.2 Internet e-mail to fax machine (1) (2) (3) (4) +----------+ +---------+ +-----------+ +-----------+ |Sender-MUA|-->--|Relay-MTA|-->--|offramp-MTA|-->--|Receive-fax| +----------+ +---------+ +-----------+ +-----------+ . DSN end-to-end: with DSN implemented at (2) and (3), can provides notification of delivery to (4), assuming the offramp uses the T.30 confirmation from (4) to generate a DSN response. . DSN part-way: with DSN implemented at (2) but not at (3), provides indication that the message was delivered to the offramp (3), but that no information about receipt by (4) will be forthcoming. Klyne [Page 8] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation . DSN not implemented: with DSN not implemented at (2), the sending MUA knows only that the message was accepted at (2) for onward delivery, (just like corresponding the e-mail to e-mail case). . MDN implemented: if (3) implements MDN then an MDN can be generated when the fax is delivered to (4), triggered by the T.30 confirmation from (4). This is a situation where the prohibition of automatic MDNs can be relaxed, because they would not disclose information about the recipient which is not available by calling the receiving fax machine directly. 4.3 Fax machine to Internet e-mail (1) (2) (3) (4) +----------+ +----------+ +---------+ +-----------+ |Sender-fax|-->--|Onramp-MTA|-->--|Relay-MTA|-->--|Receive-MUA| +----------+ +----------+ +---------+ +-----------+ . DSN end-to-end: with DSN implemented at (2) and (3), provides notification of delivery to (3). If (3) is a mailbox server, no indication of collection by (4) will be returned. But, the confirmation of delivery received at (2) will be too late to provide a normal T.30 message confirmation back to (1). Confirmation of receipt would have to be provided by a separate out-dial by (2) and fax transmission of a confirmation slip. (The out-dial might be avoided by having the sender-fax poll for confirmation, but this would require a change of behaviour in the installed fax base, so is considered impractical.) The T.30 confirmation received at (1) will indicate only that the fax was received by the onramp, and no more. To do better than this, it will be necessary to find ways of delivering the fax message to (3) within the time constraints imposed by the T.30 protocol. . DSN not implemented: with DSN not implemented at (2), the sending fax machine receives an indication meaning only that the message was accepted at (2) for onward delivery. . MDN implemented: if (2) and (4) implement MDN then an MDN might be generated when the message is received and displayed at (4). But the user at (4) may choose to prohibit generation of MDN. Also, the timing of any confirmation is subject to the same considerations as the end-to-end DSN case described above. Klyne [Page 9] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation . MDN implemented at (2) and a receiving Internet Fax (IFAX) device at (4): in this case, it might be possible to relax the conditions regarding automatic generation of MDN, since the security concerns about user privacy may not apply, to provide a dependably confirmation of receipt. But timing considerations still apply. 4.4 Summary of scenarios The various scenarios touched in the preceding sections can be summarized in four basic scanarios (not including onramp cases): (1) (2) (3) +------+ +----------+ +------------+ |Sender|->-(SMTP)->-|Receive-MS|->-(collect)->-|Receive-USER| +------+ +----------+ +------------+ (A) This is the standard e-mail case where a receiving user collects messages from a message store, using a mailbox protocol such as POP or IMAP, or using some other local collection mechanism. (1) (2) (3) +------+ +----------+ (auto- ) +------------+ |Sender|->-(SMTP)->-|Receive-MS|->-(collect)->-|Receive-IFAX| +------+ +----------+ +------------+ (B) This is an IFAX-to-IFAX case, where the receiving IFAX device collects from a message store using POP or IMAP. In protocol terms this is identical to the case above, but differs in its security implications because the collection of messages is presumed to be done automatically (e.g. on a regular timed basis). (1) (2) +------+ +------------+ |Sender|->-(SMTP)->-|Receive-IFAX| +------+ +------------+ (C) This is a simple IFAX-to-IFAX case using just SMTP. (1) (2) (3) +------+ +----------+ +-----------+ |Sender|->-(SMTP)->-|Receive-GW|->-(GSTN,T.30)->-|Receive-FAX| +------+ +----------+ +-----------+ (D) This case has SMTP delivery to an offramp gateway which in turn delivers to a receiving traditional facsimile machine via GSTN. Klyne [Page 10] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation Analysis of these cases suggests: (A) needs DSN. (B) needs automatically generated MDNs, or an enhanced DSN which can trigger notifcation when a message is collected from the store. (C) can use DSN or automated MDN. (D) can use DSN or automated MDN. Analysis of these cases suggests a possible interpetation of DSN which is very similar to the meaning of Group 3 facsimile coinfirmation, which might be made appropriate to all cases: A positive DSN response means that the message has been delieved to a point from which it requires action on the part of the recipient to collect. 4.5 Other mechanisms This section introduces some additional options which might be used to extend the various scenarios described above. The combination of session mode and direct delivery might be used to provide the closest possible approximation to traditional fax confirmation that can b achieved using MTA-based mechanisms. 4.5.1 Direct delivery If the sending MUA implements direct mail routing, following the procedures described in RFC 974 [13], the problems of intervening MTAs that do not implement required features may be avoided. This approach may be subject to difficulties when trying to cross corporate firewalls, etc. [[QUESTION: can this approach guarantee direct delivery? I understand that DNS MX records may be used to direct all mail to, say, a corporate MTA for content analysis, etc., before it is delivered to the receiving MTA.]] Klyne [Page 11] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 4.5.2 Session mode SMTP extension An SMTP extension for immediate delivery is proposed in [12]. This proposal operates at the MTA level (like DSN), and provides for immediate delivery and confirmation of delivery within a single SMTP protocol session between the sender MUA and first-hop MTA. The immediate delivery and confirmation semantics may be maintained through relay MTAs which support this extension. If the timing constraints of T.30 can be satisfied by the underlying transport mechanisms, this approach offers a possibility for providing a T.30 confirmation which indicates receipt at the receiving MTA. In its present form the overall message transfer may be forced to fall back to store-and-forward delivery if an intervening MTA cannot complete a transfer in session mode, due to the way that SMTP handles responsibility for message delivery. RFC 1047 [14] contains a useful analysis of some of the issues involved. 4.5.3 Real-time fax image transfer If a mechanism other than Internet e-mail is used to transfer fax messages across the Internet, that mechanism can be defined with a confirmation mechanism which mimics the T.30 mechanism. The disadvantage of this approach is that interoperability with Internet e-mail users may be sacrificed. It is conceivable that SMTP and real-time fax transfer mechanisms may be combined to provide mechanisms which provide interoperability with Internet e-mail, but allow message confirmation semantics to more closely match those of T.30. It involves moving the fax gateway functions away from the Internet/GSTN boundary. The simple onramp/offramp scenario is: +---+ +------+ +------+ |G3 |<--(A)-->|On/Off|<--(B)-->|e-mail| |fax| | ramp | |system| +---+ +------+ +------+ || <......GSTN.....>||<.....TCP/IP.......> || where protocol (A) is T.30 over GSTN, and protocol (B) is SMTP- over-TCP/IP (and friends). Klyne [Page 12] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation If the Onramp/Offramp fax gateway functions are separated from the GSTN-TCP/IP boundary, an extended version of this can be envisaged: +---+ +---------+ +-------+ +------+ |G3 |<--(A)-->|Transport|<--(C)-->| Fax |<--(B)-->|e-mail| |fax| |converter| |gateway| |system| +---+ +---------+ +-------+ +------+ || <......GSTN......>||<.....TCP/IP...........................> || In this case, protocol (C) is some form of real-time fax transfer (e.g. tunnelling of T.30 in TCP/IP), and (A)and (B) are as before. 5. Security considerations The following are primary security concerns for message confirmation mechanisms: . Unintentional disclosure of private information, including possible information about a recipient's activity at the time of receipt, caused by automated generation of confirmations. . Disruption to system operation (e.g. message loss), or inappropriate actions taken by the sender, caused by accidental or malicious provision of incorrect message confirmations. . In a mixed Internet/GSTN environment, meeting the costs of any additional telephone calls that might be required to return a message confirmation. Some of the options for message confirmation that are discussed are very much coloured by the concerns for user privacy. Security considerations relevant to Internet fax are discussed further in [1,3]. Klyne [Page 13] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 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, Dan Wing and Dave Crocker. The summary of scenarios section is from a presentation by Larry Masinter. Further ideas have been taken from postings to the IETF-FAX mailing list, and various of the Internet drafts cited below. Klyne [Page 14] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation 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 [2] ITU Recommendation T.30: "Procedures for document facsimile transmission in the General Switched Telephone Network" International Telecommunications Union, 1996 [3] "Terminology and Goals for Internet Fax" Larry Masinter, Xerox Corporation Internet draft: Work in progress, March 1998 [4] "Extended Facsimile Using Internet Mail" Larry Masinter, Xerox Corporation Dan Wing, Cisco Systems Internet draft: Work in progress, March 1998 [5] "Extended MDN for IFAX full mode" Mr Maeda, Canon Inc Internet draft: Work in progress, March 1998 [6] "Procedures for the Transfer of Facsimile Data via Internet Mail" D. Crocker, Internet Mail Consortium Internet draft: Work in progress, October 1997 [7] RFC 821, "Simple Mail Transfer Protocol" J. Postel, Information Sciences Institute, University of Southern California August 1982. [8] RFC 822, "Standard for the format of ARPA Internet text messages" D. Crocker, Department of Electrical Engineering, University of Delaware August 1982. [9] RFC 1891, "SMTP service extension for delivery status notification" K. Moore, University of Tennessee January 1996. Klyne [Page 15] Internet draft 2 April 1998 Scenarios for Internet fax message confirmation [10] RFC 2298, "An Extensible Message Format for Message Disposition Notifications" R Fajman, National Institutes of Health March 1998. [11] RFC 1939: "Post Office Protocol - Version 3" J. Myers, Carnegie Mellon M. Rose, Dover Beach Consulting, Inc. May 1996 [12] "SMTP Service Extension for Immediate Delivery" Dan Wing, Neil Joffe, Cisco Systems Larry Masinter, Xerox Corporation Internet draft: Work in progress, February 1998 [13] RFC 974, "Mail Routing and the Domain System" Craig Partridge, CSNET CIC BBN Laboratories Inc January 1986. [14] RFC 1047, "Duplicate Messages and SMTP" Craig Partridge, CIC at BBN Laboratories February 1988. 9. Author's address Graham Klyne Integralis Technology Ltd Brewery Court 43-45 High Street Theale Reading, RG7 5AH United Kingdom Telephone: +44 118 930 6060 Facsimile: +44 118 930 2143 E-mail: GK@ACM.ORG Klyne [Page 16]