communications

Messaging standards and IBM’s SNA by BOB WILLMOTT

R ecent standardization has paved the way for large-scale inter- connection of many previously

isolated electronic messaging systems and services. Public message transfer and the inter-personal messaging services (IPMS) based on these will become a reality in the near future. In

response to this, system vendors are adapting their products to take advan- tage of these services and enable construction of multivendor systems. The potential total community for IPMS services extends to the currently-defined telematic services (telex, teletex, fax, videotex) and those proprietary electronic mail systems adapted to the standards. This is given the possible telex

connection, a very large existing

‘critical mass’ of users. Many poten- tial users of IPMS currently use such vendors’ terminals and systems.

Abstract: Communications standards are leading the way CO large-scale interconnection of many previously isolated messaging services. Message handling standards are a part of this movement. Each vendor has its own products which can be compared with international standards. IBM’s SNA products, for example, can be mapped onto intewtational standards, but there are many problems still to be resolved.

Keywords: data processing, computer communications, messaging services, message handling, standards.

Bob Willmott is with Logica Communications and Electronic Systems Ltd.

This paper examines one such vendor’s current product palette and its relationship to message handling.

Message handling standards

The fundamental requirement of elec- tronic messaging is the transportation and delivery of textual documents. This has hitherto been practically achieved in various ways such as telex, and more recently by teletex and electronic mail services such as Telecom Gold, Geisco, Easylink etc, each offering different services and characteristics. These differences in- hibit interconnection. For this reason the electronic messaging services have long been seen as ripe for integration and has been the subject of standards activity to achieve this.

The CCITT X.400 series recom- mendations for message handling systems, based on early developments by IFIP WG 6.5, are now available. They cover interconnection of com- plete messaging services (interdomain connection).

This has been paralleled by re- quirements of office automation system vendors to rationalize and further integrate their own product palettes, to interface to X.400 and to

enable interworking between office automation systems of different vendors. Some vendors, ECMA and user communities are working to pro- duce IS0 standards, message-orien- ted text interchange systems (MOTIS), which, while compatible with CCITT X.400 for the purposes of interworking, have certain exten-

sions allowing configuration of multi- vendor private messaging systems. This will provide a solution to the well-known problem of establishing a unified messaging system within an organization with many diverse office automation systems which would otherwise be isolated from each other. MOTIS is currently at the draft inter- national standard stage and is ex- pected to become a full international standard in 1987.

Note that the term ‘MHS’ is applied both to CCITT MHS and IS0 MOTIS throughout this document.

Characteristics of MHS

The basic characteristics of messaging as defined by MHS and MOTIS are:

Store-and-forward transport of documents.

Asynchronous message submission and delivery. This means that message-originating and recipients’

terminals need not be simulta- neously active; the originator can submit messages at a convenient time; a recipient can choose to collect messages at any later time from the service. Delivery of one submitted docu- ment to multiply-addressed recipients. Conversion of message content to a form suitable to the recipient terminal.

MHS services Both CCITT MHS and IS0 MOTIS provide two distinctly separate sets of

~0128 no 7 September 1986 0011-684X/86/070361-08$03.00 0 1986 Butterworth & Co (Publishers) Ltd. 361

services. The first, referred to as the message transfer service (MTS), pro- vides a general-purpose asynchronous store-and-forward, multiaddressed

message delivery service. Although it is transparent in nature, (it being able to carry any form of document, data or collection of bits), it offers an optional message content conversion for documents in certain predefined forms such as teletex, fax, IA5.

The second service defined in the standards is the inter-personal

messaging service (IPMS). It is the only one of many possible distinct applications of the basic message transfer service described above. IPMS provides a style of communica- tion between people in the form of a set of fields to be completed and read by originating and recipient users respectively. Each is tagged with an identity enabling a controlled screen formatting at the recipient systems and enabling the recipient system to act automatically on some fields.

Each of these services is composed of a set of ‘service elements’, which are instructions the user can issue to the message transfer and IPMS. These individual service elements are listed in Table 1 and detailed further in the X.400 recommendation,

Techniques of MI-IS

Figure 1 is the functional model of a message transfer system, showing the relationship between its active com-

ponents. The central group of mess- age transfer agents (MTAs) cooperate to transfer messages from originators to recipients. This constitutes the

message transfer service. Users are represented to the service

by user agents one per end user. These are in the outer rectangle. A user agent (UA) performs ail pro- cesses necessary to submit and take delivery of messages on behalf of the user and may additionally provide local services such as text editors and

filing. Terminals, workstations and users

362 data processing

communications

Message handling

environment User

+’

I

MTS +

UA

UA

Key UA:

MTA:

User agent

Message transfer agent

Interaction

Figure I. Functional model of MHS

accessing the MHS are considered to be outside the MHS, i.e. in the user environment. They must interface to MHS through a user agent.

Naming Each user agent has a unique address within the message transfer service. This address, known as an originator/ recipient (OR) name, is interpreted by each MTA in turn to decide which MTA or UA shall receive the message next. This is incremental routing. Several name forms are defined, an

example of one is shown in Figure 2.

Collections of message transfer agents, together with their user agents

being operated by a single organiza- tion, are called management domains. Broadly, domains run by PTTs are referred to as administration man- agement domains, and those run by other organizations for inhouse use are called private management domains.

MHS does not specify any particu- lar type of terminal for use with the services. Indeed, its very concept is

Country name UK Administration domain name British Telecom Private domain name Logica Organization CES Organizational unit OS1 Centre Per:sonal name Bob Willmott

1

Figure 2. Defining name forms

~0128 no 7 September 1986

based on the principle that no terminal types should be excluded from the service. A consequence of this is that an access method must be developed, together with access methods and protocols for each type of terminal wishing to use MHS.

Currently, the following two MHS access mechanisms are specified:

l teletex access is defined in CCITT REC X.430. It describes the sub- mission and delivery of messages from existing teletex terminals.

l access to the MTS from a remote UA. This is the submission/ delivery entity as defined in CCITT X.41 1 and will apply more generally to personal computers, micros and workstations.

MHS is located in the application layer of the open systems interconnec-

tion (OSI) reference model. Figure 3 shows MHS in relation to the other six layers and indicates the internal layer structure of the MHS applica- tion. The lower of these layers pro- vides the message transfer service by means of MTAs. These relay mess- ages towards their destination UA using the PI protocol. The Pl pro-

tocol is the ‘envelope’ of the message and carries delivery information, addresses of re$ipients and other instructions to the MTS.

The I’3 protocol is an interactive protocol carrying much the same in- formation as Pl, but which operates between an MTA and a remote UA. P3 supports the submission and de- livery of messages between the UA and an MTA.

The second layer contains the UAs. These provide the IPMS. IPMS UAs communicate with each other using the P2 protocol.

Associated standards

MHS operates in conjunction with two other associated sets of standards. OS1 and office document architec- tures (ODA).

363

c

MHS <

Management

and

directories

ODIF

IPMS UAE

MTAE

i Document

B= content ODIF

4 P2 !, IPMS

User agent layer UAE

Message Pl transfer

MTAE

Case I RTS

Presentation

Session

Transport

Network

Data link

Physical

Figure 3. Layered model of 0% and MHS

Relation to OSI The message transfer agents within the MTS pass P2 message traffic (in Pl envelopes) to each other using OS1 services and protocols. As far as the mechanics of the MTS is concerned, 0% provides the ‘plumbing’ - the direct interconnection of MTAs using a reliable, controlled data communi- cations channel with a predefined language and synchronization. MHS makes direct use of the OS1 session and presentation layer services.

The ODAs are a set of IS0 standards concerned with the contents of the messages transported. In principle, ODA is a language in which it is possible to describe a document in a canonical form (the office document interchange format (ODIF)). Docu-

ments for distribution are trans-

formed as necessary from their local representation, which may be a re- visable form and is dictated by the local technology, into this canonical form before dispatch. Documents received in this form must undergo a similar inverse transformation to be- come presentable and processable on the recipient’s system, which may be of a totally different kind.

ODA allows the expression of both logical and layout document struc- tures. It can also handle many different types of textual representa- tion such as character coded, fax, and sound.

Current status of MHS The basic CCITT X.400 recommen- dations were ratified in 1984. They are now being progressed in several ways:

l Corrections are being made to the base recommendations in the areas of the access protocols and the way in which the MTS makes use of the OS1 service.

l The recommendations have been

the subject of ‘functional standar- dization’ to define more closely preferred sets of service elements for minimum implementations, to define more closely the services used in OS1 for messaging and to provide a set of pragmatic con- straints on content and length of individual protocol field lengths. Such a program of functional stan- dardization, undertaken by the Council for European Norms and Council for European Electrical Norms (CENICENELEC) in Europe, has resulted in the A3211 document for MHS.

l New applications for MHS such as

364 data processing

communications

group communications (coordina- programs) of documents and data. tion of several persons in textual They form a set of tools for distri- communication), teleconferencing, buted applications and computing.

interworking with the postal This has all been achieved through a system, telemetry and trade data unified applications programming interchange are candidates for interface, the advanced program/ standardization on the basis of the program communications interface message transfer service. (APPC) .

The recommendations are not quite sufficient to be able to establish a system and need complementing with various other standards and services:

SNA itself provides all the basic

mechanisms of data communications to applications programs together with facilities to manage and con- figure the SNA data transport net- work. This is functionally similar to the lower layers of OSI. Figure 4 shows the IBM architecture.

A directory service is to be used for

‘directory enquiry type services as well as providing information to the MTS itself. Standards and recommendations for parts of this should be available in 1988. There are many facets of operation of a messaging service which will be made easier with the availability

of standards for management of such things as routing tables, soft- ware loading and monitoring etc. IS0 is making some general pro- gress with this for OSI, but no work has yet been done on MHS in particular. This is of consequence to the construction of multivendor domains and may inhibit their

successful d.evelopment.

IBM technology

Recent announcements of enhance- ments to SNA products have moved IBM’s products nearer to the services offered by OS1 and MHS.

These enhancements are embodied in SNA. They are logical unit 6.2 (LU 6.2) and SNA distribution services (SNADS). These are complemented by document interchange architecture (DIA) and document content archi- tecture (DCA), which have been available for some time. These form the basis of IBM’s offerings in messaging and office systems.

IBM office system products now encompass the transfer (DIA), content (DCA), storage (library func- tions) and processing (by transaction

Those portions of SNA which are of direct impact on the messaging are LU 6.2, SNADS and DIA.

LU 6.2 services

LU 6.2 provides for communication between two or more application transaction programs.

Within LU 6.2 there are several transaction services, two of which are considered more closely here.

Document interchange architec- ture (DIA). DIA offers a single applications program interface to direct message transfer (terminal- to-terminal), store-and-forward message transfer (using SNADS

Application I programs i DCA

_----_-_-___---_--

T’ ’ ’

DIA Transaction --------

services SNADS ___-----

Presentation services

Data flow control

LU 6.2

Transmission control

I Path control I

link control I

I Physical control I

Figure 4. IBM architecture

service) and store and retrieve message transfer (mailbox) using DIA library services. Each docu- ment is associated with a document profile describing its purpose, content, access rights and a list of those to whom it has been distri- buted. The library can be used in store and retrieve transfer of documents between users at the same location, and in store-and- forward or direct transfers between users at different locations.

SNA Distribution service (SNADS). SNADS provides a

basic mechanism for store-and- forward, asynchronous delivery of documents and other forms of data

between application transaction programs. SNADS offers only three basic services: o distribution data (to a list of

recipients), 0 distribute status (of distribu-

tion) , o receive distribution (from a

SNADS distribute data).

OSI equivalents

IBM’s SNA, including parts of LU 6.2 and APPC, provides a function- ally similar service to the OS1 presen-

tation service, session service and parts of the common application service elements (CASE), such as commitment, concurrency and re- covery i.e. layers l-6 of OSI.

These products enable a simpler mapping between the IS0 world and the IBM world at the level of the application itself where the gateway can appear as an application layer relay. On the face of it, messages passed through SNA can be ‘un- wrapped’, content converted, placed in an OSIiMHS envelope and for- warded using OSIiMHS or vice versa.

Message transfer service equivalents

The MHS MTS is roughly compar- able to the services of IBM’s SNADS used in conjunction with DIA. This

~0128 no 7 September 1986

also offers a multiaddressed, asyn- chronous, store-and-fo~ard delivery of textual documents through office system nodes. SNADS could be used to support the IPMS service within IBM systems.

It is also capable, by extension, of becoming a more general service to other types of IBM application, such as JES, CICSiIMS, etc, potentially replacing and rationalizing different application-specific, communications programs, supporting different IBM application environments.

Office document architecture e~u~~a~ents

Document content architecture (DCA) is a common language for encoding IBM document contents. The language allows definition of physical and logical layout as well as some presentation attributes, such as font. DCA currently only deals with IBM specific forms; some extension is required to cope with body parts foreign to IBM.

IBM’s DCA can be seen as roughly comparable to OSI’s office document architecture. Mapping between the two document encodings can be performed, but only in a limited fashion for text-revisable documents. Because it is essentially a language for describing documents, it can also encode forms. There is therefore no reason why DCA, in conjunction with APPC, could not be used to emulate the IPMS service for interworking with the CCITTiISO world.

Naming and addressing

IBM’s SNADS relies on a two-level, hierarchical numbering scheme based on its internal office system structure to identify office system nodes and individual users. It consists of office system identity plus user number.

The addressing structure within IBM office products is very different to the multilevel MHS addressing structure. An algorithmic mapping is probably not possible. Therefore

these two forms require a mapping implementation choices. The choices procedure at any gateway, in the form made were: of a directory of equivalents between IBM internal address and its X.400 l no attempt to provide mapping at representation for messages arriving the lower OS1 layers, i.e. use of an into the IBM system. This will re- application layer relaying gateway, quire a very large directory in some * use of SNADS and DIA to map cases. The inverse mapping (i.e. ex- onto the MTS, pressing every MHS address in IBM * use of the document profile to carry form) is inconceivable. It would re- some MTS and IPMS functions, quire that the entire X.400 com- l use of DCA to encode the docu- munity be ‘equated’ to IBM internal ment content only, representation to allow IBM users to l UAs implemented remotely from specify external users in the IBM the gateway. format. It will therefore be necessary to allow IBM users to specify external The gateway looks fike an IBM office IPMS participants in X.400 form and system node to the IBM system, but to convey this information from the like an MTA to the MHS. Documents user to the gateway. are transferred over SNA between

IBM user and gateway, are then

Service element mapping decoded, converted into MHS envelopes and relayed further using

Table 1 shows the closest possible MHS and OSI. This type of gateway

mapping of service elements between is illustrated in Figure 5a.

MHS MTS/IPMS and IBM products. From Table 1 it can be seen that the

It is evident that while there is much gateway mapping will not conform to

similarity, several of the essential the CENKENELEC functional stan-

services must be provided by exten- dard at several points.

sion to IBM products. A direct map- Default settings at the gateway

ping is not possible. cannot be used with the MTS and

In conclusion, while the standards IPMS service elements since there is a

bodies are producing standard requirement to have these set, and

services which are of global signifi- presented to, the end user accurately.

cance, IBM’s concern seems to be to The implications of this are that a

provide generic services and systems fuller mapping will require some IBM

for distributed processing from which internal modification to DIA and LU

these specific applications such as 6.2 or possibly special applications

MTSIPMS can be built. The DIA/ p ro g ramming to allow IBM end users

DCA toolbox for distributed applica- access to the MTS and IPMS services.

tions looks a likely instrument for A gateway implementation alone is

this. This strategy will make gateway- not going to be sufficient for the task.

ing between OS1 and IBM plausible This enhancement will require

for messaging, but it will not neces- definition of extra protocols to convey

sarily be simple. IPMS and MTS service elements between end users and the gateway.

Approach to an MTSlIPMS This is illustrated in Figure 6.

gateway

A more detailed analysis of MHSi Dangers of multiple mappings

IBM compatibility issues can be based In Table 1, a particular gateway on the individual MHS service mapping choice has been taken - in elements. fact it is just one of many possibilities.

Table 1 gives the outcome of a Another choice might have been to gateway for a particular selection of implement IPMS purely in DCA, not

366 data processing

IBM Gateway MHS

&vice

MHS-IPMS

I

Figure Sa. A gateway giving particular implementation choices f

Gateway MHS

Message transfer service

t

DCA ODA

t

Figure Sb. Alte~at~ve gate~lu~~

IBM 4

IBM (IPMS) b c

IBM (MTS) b c

Gateway MHS

v P2

- Pl

1

J

Figure 6. IBM’s internal protocols. IBM (IPMS) a is IBM’s internal carrier protocol for II’MS. ‘a’ and ‘b’ represent two possible sets of ~nte~al protocols

utilizing the current document profile (illustrated in Figure 5b) or to locate the UAs in the gateway and use traditional terminal access methods between IBM user and gateway. There are several disadvantages here:

these ‘special mappings’ will not contribute to integration of services within IBM’s systems,

it is also perfectly feasible that another implementor of gateways (for another IBM product or third party mapping) will choose a different mapping.

This has four consequences. First, the service and interface

perceived by the end user will be

different in each case. This difference need not be very great before a distortion in the expected and

perceived services of users on both sides of the gateway becomes visible.

Second, the IBM internal protocol will be different in each case. Here is potential confusion as access could be made via several differing gateways using different IBM internal

protocols. Third, there is the possibility that

messages may traverse several

different types of gateway and incur a functional loss at each.

Last, it is not likely that the map- pings lead to an easy interconnection of the various existing IBM office products such as DISOSS and PROFS.

These are a significant danger to the ultimate quality of IPMS services and its acceptance by users. It should be avoided at all costs.

Conclusions

Mappings between vendors products and the OSI-MHS servi.ces are pos- sible in varying degrees, dependent

on mapping choices taken and amount of internal modification. One of the more serious problems will be with the mapping of internal IBM

~0128 no 7 september 1986 367

communications

naming/addressing conventions to the X.400 standard forms.

A simple gateway approach is not sufficient since the service elements of MHS need to be carried through directly to end users. Either the underlying operating systems services

must be modified or special applica- tion programs must be developed to work in conjunction with the gate- ways. Either way, protocols must be defined between user and gateway. It is preferable that the former route is taken.

As IBM’s product palette stands at the moment, a minimal mapping to the MTS and IPMS is possible with- out major effort, but this mapping is not sufficient to conform to the CENi CENELECCEPT minimum re- quirements.

Independent mappings at gateways dependent on application packages could achieve a full MTSIPMS func- tionality, but would shape the terminal users’ interface and system internal communications in a particular way. If IBM were to intro- duce its own enhancements and gate-

way, these independent mappings

might not only have differing user interfaces, but might well multiply the gateway ‘service element loss’ where messages traverse two or more gateways or have the choice of two or more gateways.

The problems outlined so far are based only on IBM’s products. Similar conclusions might have been reached with any one of a dozen other vendors with similar results. Each of these other vendors is going to pro-

vide a similar gateway which may introduce yet more service element loss. Each, in turn, will want to act as the ‘universal’ gateway for other

vendors equipment in multivendor environments.

Clearly, the danger is that the resultant quality of service and func- tionality derived from these multiple

mappings of the MTS and IPMS may be unacceptable. This can be avoided

only by strict adherence to the func- tional standards service elements sub-

sets, and possibly by further, exact definition of the meaning of each IPMS service element perceived by the end users.

For these reasons, specification and

use of the CENCENELECCEPT functional standards is highly recom- mended both for vendors and pro- curers as a minimum requirement. Unfortunately, current functional standards do not specify minimum requirements and exact semantics of

services at the end-user interface. This is perhaps a necessary further step of standardization if IPMS is to

reach its full value and scope of use. It is a matter for consideration in any procurement.

References

A range of technical guides on OS1 may be obtained in the UK from the DTI Information Technology Stan- dards Unit, and from the BSI Sales Department, Linford Wood, Milton Keynes, MK14 6LE, UK. 0

Logica Communications and Electronic Systems Ltd, 64 Newman St, London WlA 4SE, UK.

368 data processing