23 The Message Handling System (MHS) The message handling system (MHS) is a concept developed by ITU-T that is intended to lead to the interconnectivity of all different types of message conveying systems, e.g. telephone, telex, facsimile, electronic mail, etc. MHS sets out a simple model of basic interconnection between systems. As it does so it defines a new dictionary of standard terms and jargon to describe the various phases of a communication. In places it may even seem trivial, but the careful definition is worthwhile if it will solve today’s incompatibilities. This chapter seeks to explain the model, unravel the jargon and describe the initiatives that will result. 23.1 THE NEED FOR MHS It is commonplace today for a wide variety of telecommunications technologies to be provided in the same office. Often a number of technologies provide similar but separate means for conveying identical information, but many users still employ more than one of the methods. Telex, facsimile and electronic mail all provide means of transferring text or documents. One or other of the different devices may be favoured to convey information to a given destination, depending on the facilities available at the far end, for despite the commonality of each of the different methods of document transfer, they are mutually incompatible and will not interwork. MHS defines a simple model of the procedure needed for documents to be passed electronically in a store-and-retrieve fashion between a wide range of different types and makes of office business machines (e.g. word processor, facsimile machine, teletype, maybe even the telephone as well). In time, the model will lead on to the development of communication standards, interfaces and equipment needed so that machines of dissimilar types may intercommunicate. 23.2 THE CONCEPT OF MHS The underlying assumption on which MHS is founded is that during any period of communication only the information content of a message is important. The corollary 413 Networks and Telecommunications: Design and Operation, Second Edition. Martin P. Clark Copyright © 1991, 1997 John Wiley & Sons Ltd ISBNs: 0-471-97346-7 (Hardback); 0-470-84158-3 (Electronic) 414 THE MESSAGE HANDLING SYSTEM (MHS) is that the means of message conveyance is immaterial, and the format of the information (e.g. facsimile, telex, electronic mail, etc.) may be changed between the originating and destination stations. Thus the originator need not worry about whether a compatible facsimile or telex machine is available at the destination, because MHS will provide conversion to the required format. ITU-T’s recommendation X.400 defines a model of a message handling (MH) service, provided by means of a message handling system (MHS). The MH service allows the conveyance of messages across a network on a store-and-forward or store-and-retrieve basis. Thus information between sender and recipient can be sent without interrupting the recipient from his current activities: the message is dealt with when it is convenient. This is important in computing activities if the receiving machine is already busy. It is also important for human recipients who might be away from their desks. Much like a postal system, messages may be posted into the system at any time of day and will be delivered to the recipient’s mailbox. The recipient is free to sort through the incoming mail at any time of day, and as soon as an item is accepted by the designated recipient, automatic confirmation of receipt can be despatched back to the sender. This eliminates any possible concern about whether the recipient has seen a given item. 23.3 THE MHS MODEL The MHS model provides a design aid to the development of networks providing message handling services. It is based upon the principles of the International Organiza- tion for Standardization (ISO) open systems interconnection (OSI) model (as described in Chapter 9). Like OSI, MHS is a layered model with general-purpose application. Unlike the OS1 model, only higher layer functions are described in the MHS model. In fact, the MHS model is functionally equivalent to the OS1 layer 7, or application layer. Any realization of a higher layer protocol of the OS1 Model relies on implementation also of the underlying layers. The message handling system is no exception. The MHS defines the format of messages that may be sent between end points and the procedure for doing so. It does not state any particular physical or electrical means of conveyance. Thus any information which may be represented in binary code may be conveyed on a MHS. Equally, any network capable of carrying the information and conforming to OS1 layers 1-6 will do. The network must 0 establish the transport service (OS1 layers 1-4). Suitable protocols in conjunction with any of the telephone, packet-switched data, LAN or leased line networks will do 0 establish a session for reliable transfer of messages (OS1 layer 5) but MHS uses a null presentation (data syntax) layer (OS1 layer 6) Figure 23.1 shows how MHS operates to provide a service to users within a message handling environment. All the functions within this environment need to be standard- ized. For this purpose the model defines a number of terms, as follows. The two basic functions of MHS are the user agent (UA) and the message transfer agent (MTA). These are not usually distinct pieces of equipment in their own right, but a number of these functions may be contained within a single physical piece THE MHS MODEL 415 MH environment I I I I , Message transfer system UA UA i l Figure 23.1 Functional model of MHS. MH, message handling; UA, user agent; MTA, message transfer agent. (Courtesy ITU - derived from Figure l/X.400) of equipment. The user agent (UA) function is undertaken by a personal computer (or similar piece of office equipment) which converts the user’s message into a standard form, suitable for transmission. Having done the conversion, the user agent submits the message to the local message transfer agent (MTA). The message is conveyed via a number of MTAs. Collectively called the message transfer system to the recipient’s MTA. This is called the message transfer function. Each MTA is usually a mainframe computer or other device capable of storing and forwarding information. Interconnec- tion of the UA to MTA and between the MTAs may use any type of network which provides the functions of OS1 layers 1-6. The two services provided by message handling systems are called the inter-personal message service (IPMS) and the message transfer service (MTS). These correspond to the services provided by the user agent and the message transfer agent, respectively, as Figure 23.2 demonstrates. Figure 23.2 shows three different implementations of user agent (UA). This underlines the point that the user agent is only a conceptual function, which can be implemented in a number of ways provided that it interacts with the MTA function in the standard fashion. The three different implementations of user agents shown in Figure 23.2 are 0 a user agent within a computer or word processor; the IPMS provided by this machine is utilized by a dumb (asynchronous) computer terminal 0 an intelligent terminal, within which the user agent function is contained 0 an interworking device, interfacing an existing telematic (text based) network (telex or facsimile, etc.) to one of the MTAs The end-users of a MHS may be either persons or computer applications. Users may be either originators or recipients of messages. Messages are carried between originator 416 THE MESSAGE HANDLING SYSTEM (MHS) IPMS User Dumb MTS computer terminal (Computer or ‘intelligent’ word processor 1 terminal telematic other \ service , User Figure 23.2 Message transfer (MTS) and interpersonal message service (IPMS) and recipient in a sealed electronic envelope. Just as with the postal equivalent, the envelope provides a means of indicating the name of the recipient, and of making sure it reaches the right address with the contents intact. In addition further information may be added to the envelope for special delivery needs. For example, a confidential mark- ing could be added to ensure that only the named addressee may read the information. The basic structure of all messages in X.400 is thus an envelope, with a content of information. The content is the information sent by an originating user agent (UA) to one or more recipient user agents (UAs). This simple message structure is shown in Figure 23.3. MHS defines three different types of envelope (although all three are very similar in structure). These are called the submission envelope, the relaying envelope and the (Content ) ( Envelope 1 Dear Joc BLa BIa Bla Bla . + Yours, Figure 23.3 Basic message structure in MHS. (Courtesy of ITU ~ derived from Figure 2/X.400) LAYERED REPRESENTATION OF MHS 417 delivery envelope. The submission envelope contains the information prepared by the UA, and is labelled with the information that the MTS will need to convey the message, including the address and any markings such as conJirmed delivery and priority. This envelope is submitted by the user agent (UA) to the message transfer agent (MTA). On reaching the MTA, the content of the message is transferred to a relaying envelope for relay through the message transfer system to the destination MTA. Finally the message is delivered to the recipient's user agent in a delivery envelope. In reality, the envelopes are simply some extra data, sent in a standard format, as a sort of package around the users real message. All three types of envelope are very similar in structure, though slightly different information is pertinent in each case. 23.4 LAYERED REPRESENTATION OF MHS As with the OS1 reference model, it is easy to conceive MHS as consisting of functional layers for which 0 similar functions are grouped in the same layers 0 interactions between layers are minimal 0 interactions within the layers are supported by one or more distinct peer protocols The principles of layered protocols were covered in Chapter 9, where the OS1 model and peer protocols are described. In particular, MHS comprises two functional layers, as shown in Figure 23.4, and as MHS itself resides at layer 7 of the OS1 model so these two layers are sub-functional layers of OS1 layer 7. A number of new terminologies are introduced by Figure 23.4 and need explanation. The two layers of MHS are the user agent layer (UAL) and the message transfer layer (MTL). These are the layers in which the user agents and message transfer agents operate. The user agent layer comprises user agent entities (UAEs) and an interacting protocol, called P,. The protocol P, governs the content, format, syntax and semantics UA M TA M TA UA User agent layer ( UAL 1 Pc (e.g. P2 1 UAE UAE I + Message transfer layer (MTL) SDE 5; p3 L SDE * " * MTAE h MTAE submission Relay Dellvery Figure 23.4 Layered representation of MHS. (Courtesy of ITU - derived from Figures 12 and 13/X.400) 418 THE MESSAGE HANDLING SYSTEM (MHS) to be used when transferring information between the two user agents. (P, stands for content protocol). A particular type of content protocol is called P2, and is also known as the interpersonal messaging protocol. It is covered by ITU-T’s recommendation X.420. The user agent entity is the capability, within the user agent which is required to convert the base information into the form demanded by P, (or P2). The message transfer layer (MTL) comprises submission and delivery entities (SDEs), message transfer agent entities (MTAEs) and interacting protocols called mes- sage transfer protocol (or PI), and the submission and delivery protocol (or P3). The submission and delivery entity (SDE) is the part of the user agent that places the information (or content) provided by the user agent entity (UAE) into the submission envelope. The envelope is then addressed using the protocol P3. The message transfer agent entity (MTAE) is the functional part of the message transfer agent (MTA) which relays the message in the relaying envelope. The message transfer protocol, PI, is used to perform the message relay. Finally the message is delivered to the destination SDE in the delivery envelope, using protocol P3. The full messaging sequence is thus as follows. 1. The user agent entity (UAE), which is a functional part of the user agent (UA), assists the user to compose the content of the message in P2 (or some other P,) format. 2. The submission and delivery entity (SDE), also a functional part of the user agent, envelopes and addresses the message, and then submits it to the message transfer agent entity (MTAE) using P3 protocol. 3. The message transfer agent entity (MTAE), which is a functional part of the message transfer agent, re-envelopes the message in a PI relaying envelope, and relays it in a store and forward fashion via the MTAEs of other MTAs, until reaching the destination MTA. For the relay, protocol PI is used. 4. The destination MTAE returns the message to its P3 envelope and delivers it to the SDE of the destination UA, which removes the envelope. 5. The UAE part of the destination UA reformats the information to the original style and conveys it to the user. As an aside, it is interesting to note the difference between the 1984 and 1988 versions of the P3 protocol, even though this is now largely history, because it exemplifies how initial versions of standards may not be completely reliable, even though published. Whereas CCITT’s 1984 version contained a version of P3 protocol which was a store-and-forward protocol, this had the weakness that it had no way of preventing an MTA from attemp- ting to forward a message to a UA, such as a personal computer, which might have been switched off at the time. In that case the message would be lost. By 1988, the CCITT recommendation for the P3 protocol had been advanced to P3+ as a store-and-retrieve protocol. In the later version, the message is retained by the destination MTA until the recipient user agent chooses to retrieve it. THE STRUCTURE OF MHS MESSAGES AND MHS ADDRESSES 419 23.5 THE STRUCTURE OF MHS MESSAGES AND MHS ADDRESSES Let us now consider the structure of MHS messages and the structure of messages which are used to support the inter-personal message service (IPMS). Figure 23.5 shows the imaginary nested structure of a message, sent in reality as a long stream of binary coded data. This structure is apparent also in Figure 23.5, although some other parts of the message are also shown. The content may be either user information, such as text, facsimile diagrams, etc., formatted in the P2-style as heading and body, or it can take the form of a status report. A status report is a special type of message required for the correct functioning of UAEs. A status report may be used, for instance, to convey receipt confirmation messages. The heading of the message characterizes the user information with elements such as ‘subject’, ‘to’, and ‘copy’. The body is the text and diagrams. The content of the message must be formatted using a content protocol, P,. One type of content protocol already discussed is the P2 inter personal messaging protocol. If required, however, a different type of content protocol can be specially developed for a given application. The envelope of a message carries the address of the recipient. ITU-T recommenda- tion X.400 suggests that the address should be one of the following: a unique identifier of entirely numeric characters; this is called a primitive name, and indicates the destination user agent in terms of its country, its management domain (explained below), and a unique customer number a unique name-style identifier, correctly called a descriptive name, comprising a personal name, an organization name and the name of an organizational unit I I I Envelope I L r I l Figure 23.5 Message structure for IPMS. (Courtesy of ITU - derived from Figure 21X.420) 420 THE MESSAGE HANDLING SYSTEM (MHS) All addresses in MHS must be unique, and denote exactly one user. An example of a primitive name might be a number such as 12345926, etc. By contrast an example of a descriptive name is ‘The chairman of the XYZ company’ The scope for using descriptive names is helpful to human users, who no longer have to remember arbitrary numbers for calling their friends or close associates. However, the name must be sufficient for the message handling system to recognize the user uniquely. A name such as ‘the floor cleaner of the XYZ company’ will not do as a descriptive name, unless the XYZ company only has one floor cleaner. 23.6 MHS MANAGEMENT DOMAINS A management domain might be a complete MHS network, or it may comprise a small number of MTAs owned and run by a single organization. A management domain might be a large company’s private MHS network, or a network run by the public telephone company. The two types of domain are called, respectively, a private management domain (PRMD) and an administration management domain (ADMD). Figure 23.6 illustrates the management domains concept, and shows the interconnection of a num- ber of different domains. The use of management domains allows the addresses in each domain to be allocated independently of addresses in other domains. Thus the same address ‘The chairman’ may be used to apply to two different people, being the individual users of separate companies’ MHS networks. Figure 23.6 reflects the different examples encountered in real life, where some public telecommunications operators may provide only message transfer (i.e. network) facilities while others provide customer premises equipment as well. Interconnection between all the management domains is by standard PI (message transfer) protocol. I l I r 1 [ UA I I I I I I U A _1 _ r -1 r 1 [ UA IMTA H UA 1 I CRMDI _I I AOMDZ I I PRMDZ Figure 23.6 Administration and private management domains MHS AND THE OS1 DIRECTORY SERVICE 421 23.7 MHS AND THE OS1 DIRECTORY SERVICE So that the MHS may deliver messages to the correct recipients, it needs to 0 validate the address names of originators and recipients (originator/recipient, or OIR name) 0 determine the necessary call routing, and finally 0 determine whether data format, or code conversion is required A large quantity of reference information, giving details and addresses of all the users, is required so that, first, the sender can address the message correctly to the intended recipient; and, second, so that the UA and MTA can determine where this person is and so deal with the message accordingly. The information needed is drawn from the OSI directory service which is prescribed by ITU-T recommendations in the X.500 series. These recommendations lay out a standard structure in which information may be held in a database, and they provide for a standard method of enquiry (see Chapter 29). Besides determining the correct routing paths for MHS messages, the service can also be used to answer users’ directory enquiries. A widely held view is that large scale corporate and international interconnection of electronic mail and other messaging devices cannot take place using the X.400 standard until the X.500 directory service has been fully defined and widely realized. 23.8 MESSAGE CONVERSION AND CONVEYANCE USING MHS MHS is intended to recognize all of the standard binary codes (e.g. telex, facsimile, etc.) and provide for translation between them by interaction with the OS1 presentation layer (layer 6). In the case of a telex machine using the message conversion capabilities of a message handling system to send a message to a facsimile machine, MHS would convert from telex characters into a facsimile message format. In time, some people hope that even speech to text conversion may be possible. So far, however, not all translation functions are understood and further technical development will be required before we have a system which provides for all types of translation. The standard codes understood by MHS include 0 text in IA5 computer code (international alphabet no. 5) 0 telex (international alphabet no 2, or IA2) 0 facsimile 0 digitalized voice 0 word processor formats There is no restriction on the number of different types of code which may be used in a single message. Thus messages of mixed text, facsimile diagrams and even voice can 422 THE MESSAGE HANDLING SYSTEM (MHS) be sent, although there may of course be a limitation on what the receiving device will comprehend. Early application of MHS by companies and other users is to convey documents in electronic form. A prime user of the standard X.400 protocols will be to interconnect today’s incompatible electronic mail systems. In addition MHS has provided the foundation for a new era of paperless trading between companies, called EDI (electronic data interchange). In this environment it is invaluable for large scale distribution of documents, for rapid confirmation of receipt, and for delivery of messages in electronic form, allowing subsequent processing if necessary. 23.9 SETTING UP A MESSAGE HANDLING SYSTEM Figure 23.7 illustrates a practical implementation of a message handling system, showing the items of equipment that the user may be familiar with. Figure 23.7 shows a network comprising a personal computer, a mainframe computer and another mainframe computer. The message handling system is only a small func- tion, but one which each of the computers must be capable of performing. The MHS itself is a small amount of software in each computer, and so invisible to the user. The personal computer on the left of Figure 23.7 has within it communication software which performs a user agent function, as well as the functions of OS1 layers 1-6. The physical network connecting it to the message transfer agent (MTA), which resides in the mainframe computer in the centre of the figure, is a packet-switched network. In the jargon of MHS the personal computer is said to be an SI-system, because it comprises only a user agent entity (UAE) and a submission and delivery entity (SDE) but no message transfer agent entity. In contrast, the mainframe computer shown in the centre of Figure 23.7 is the main ‘databank’ of the MHS system. It comprises only a message transfer agent entity (MTAE) together with communication software supporting the functions of OS1 layers 1-6. The MTAE performs the function of relaying message between user agents (UAs), and when necessary it stores messages for later retrieval by recipient UAs. As this mainframe computer contains a MTAE, it is called, in MHS jargon, an S2-system. The computer S1 system S2 system S3 system Personal computer -0-D Packet network Mainframe Mainframe computer computer and terminals Figure 23.7 Physical example of MHS realization