- Email: [email protected]
Office communications
Office communications J Stanley McConnell* and CarI-Uno Manros t detail OSI protocol standardization work for office communication systems
A short overview of the Open Systems Interconnection protocol standards related to office communications, covering approved and ongoing standardization work in the International Organization for Standardization, the Consultative Committee on International Telephone and Telegraph, and the European Computer Manufacturers' Association, is given. The relationship between office communications and the OSI Reference Model is discussed, and the Distributed Office Architecture Model is presented, establishing a common set of guidelines and requirements to be observed in the development of distributed office applications. The principal applications of this class are then described in turn, including those dealing with Message Handling, Document Filing, Document Printing and Remote Data Access. The supportive Referenced Data Transfer and Directory applications are also discussed, as are security considerations as they relate to distributed office applications. The paper concludes with a discussion of plans for future standardization activities.
Keywords: office information systems, Open Systems Interconnection, distributed office communications, standardization In general, there are two levels of functionality needed to provide meaningful office automation services to a user. Both of these levels are the subject of standardization. The first level consists of the peer-to-peer protocols, as defined in the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) 7-Layer model. These protocols primarily perform the transportation of information between co-operating systems, and usually contain instructions from the sending partner to the receiving partner on how to route the information, e.g. the Message Transfer protocol used in the Message Handling application (see below). *Xerox Corporation, Business Products and Systems Group, ESM8-03, 230S Utah Avenue, El Segundo, CA 90245, USA tSiemens AG, Otto Hahn Ring 6, [3-8000, Munich 40, FRG
This paper describes the first level standards further, while various data object format standards, such as ODA I, Standard Page Description Language (SPDL)2 and Standard Generalized Markup Language (SGML) 3 are discussed elsewhere in this special issue. This paper describes the first level standards further, while various data object format standards, such as ODA I, Standard Page Description Language (SPDL)2 and Standard Generalized Markup Language (SGML) 3 are discussed elsewhere in this special issue.
OFFICE COMMUNICATIONS/OSl RM RELATIONSHIP The office applications are located in the Application Layer (Layer 7) of the OSl Basic Reference Model (RM) 4. A further refined description of the Application Layer is given in the OSI Application Layer Structure (ALS) document s, which covers such topics as the relationship between distributed information processing and OSl communication services, as well as the OSl service and protocol structure in the Application Layer. The importance of this document for office communications is due to the definition of some of the fundamental concepts and terms which are being used in the latest communication standards for office applications. A few of these terms need to be explained here as a background to descriptions of the applications which follow (explanations have been simplified -- see ISO texts for formal definitions): • Application Context: can be described as a'complete' Application Layer protocol. • Application Service Element: a module, or subset, of a complete Application Layer protocol. Several Application Service Elements get combined into one Application Context. • Application Association: an instance usage of an Application Context. • Application Entity: the communication aspect of a
0140-3664/89/020061-08 $03.00 © 1989 Butterworth & Co (Publishers) Ltd vol 12 no 2 april 1989
61
partner in an Application Association. This is sometimes referred to as a 'stub' outside the standardization groups.
DISTRIBUTED OFFICE APPLICATIONS MODEL The overall approach to office applications, from a communications point of view, is described in the Distributed Office Applications Model (DOAM) document 6. Some of the more important concepts from that paper are described here. Office applications are typically distributed, otherwise they would not use communication protocols in the first place. However, this distribution can occur at two different levels. First, a user has a workstation which usually offers a number of local services such as an editor and some local filing facilities. Other more complex or resource-hungry services may be provided in a more powerful server system, which is a shared resource for several workstations. The workstation is then considered to be a client system to the server system. The two systems contain application entities, which communicate over a client-server protocol, also called an access protocol. An access protocol is called asymmetric because of the fact that the client partner and the server partner have different capabilities, and have different tasks to perform, e.g. it is meaningless for the server to ask the client to perform tasks which can only be performed by the server (see Figure 1). Second, servers of the same type may need to communicate among themselves in order to perform a desired task. This is done by means of a server-to-server protocol, also called a system protocol. An example can be given from the Directory application, where different
Data-object-formatI~ specification
User I~
X-server ............
t ...................
t ......
Application Application -entity X_access_protocoLApplication -entity ASEs(I) ASEs(2) Presentati°n Layerlayers and other
T
Presentation-association T
Figure 1. OSl communication between an X-client and an X-server. (1) This set of Appfication-Service-Elements implements the functions required by an x-client for communication with an x-server using the x-accessprotocol (2) This set of Application-Service-Elements implements the functions required by an x-server for communication with an x-client using the x-accessprotocol
62
Directory System Agents (DSA) (servers) store their part of the total directory information. One DSA can forward an enquiry which originated from a Directory Access Protocol (DAP) request, to other DSAs to find the desired answer using the Directory System Protocol (DSP). In addition to these model concepts, the DOAM document specifies a number of other requirements which will ensure a 'common style' for all distributed office applications. The more important of these are: • The requirement to specify all protocols using the Abstract Syntax Notation One (ASN.1) 7 and the associated encoding 8. • The requirements to specify all application services using the Abstract Service Definition Conventions9. This approach uses a number of ASN.1 macros to define the service aspects in a top-down manner. The definition starts by describing the overall service objects. Each object is then defined to have a number of ports, each offering a set of services. For each port a number of abstract-operations and associated abstract-errors are defined, including the definition of all data types that are used in the abstract-operations and abstract-errors. The whole idea behind this approach, which is an alternative to the methods described in the OSI Service Conventions 1° document, is to eliminate any redundancy between the service and the protocol definitions, i.e. all the data type definitions from the service definition can be re-used in the protocol specification. Note that the services described by the Abstract Service Convention are not limited to the pure OSI aspects, but may also cover local non-OSl &spects, e.g. as shown bythe Interpersonal Messaging service in the Message Handling application. • The recommendation to use the ASN.1 macro ATTRIBUTE (defined in the ISO Directory document 11) to describe many of the elements that can occur as parameters in abstract-services and protocols. This brings advantages in the overall protocol design and simplifies any future extensions. Attributes defined for one application can be re-used in other applications without re-definition. • The requirement to use the Association Control Service Element (ACSE) 12 as part of all Application Contexts. The ACSE offers certain OSI services used at association establishment time, and also contains parameters which specify the requirements on services in the OSI Presentation Session and Transport Layers. • The requirement that all access protocols, and optionally system protocols, shall use the Remote Operations Service Element (ROSE)13. ROSE consists of a notation and the associated protocol to describe application protocols, and is especially well suited for, but not limited to, access protocols. It makes use of a number of ASN.1 macros. The Remote Operations model uses a simple pattern for communication: one of the communication partners, usually the client, starts an operation by sending an Invoke to the other partner, usually the server. The partner responds, after having executed the operation, by sending back either a Resu/t or an Error (or in some cases a Reject). Adherence to this simple method has so far proved to be quite feasible, and the documentation of such protocols, especially in combination with the use of the Abstract Service Definition Conventions, is clear and concise.
computer communications
• The option to use the Reliable Transfer Service Element (RTSE)I4, either alone or in combination with the ROSE. RTSE, which is mandatory for the Message Transfer Protocol, contains a number of rules on how to make proper use of the OSI Presentation and Session Layer services to guarantee that an information object, such as a message, does not get lost as a result of communication errors. The RTSE ensures that each application-protocol-data-unit (e.g. sections of a message) is transferred completely between Application Entities exactly once, or that the sending Application Entity is wamed of an exception. This may sound simple enough, but is in effect rather complex. • The option to use the Reference Data Transfer (RDT) facility1 s, which is a generalized server-server protocol intended primarily to assist users in transferring documents between servers of different kinds, e.g. between a file server and a print server.
MESSAGE HANDLING APPLICATION The attempt to develop a standardized Message Handling System (MHS) was pursued by the European Computer Manufacturers' Association (ECMA), the ISO and the Consultative Committee on International Telephone and Telegraph (CClTr) during the early 1980s. Although the different solutions were reasonably close from a functional point of view, the X.400 series of recommendations from 1984 (Red Book) quickly found the greatest acceptance in the marketplace. During the latest CCITT study period (1985-1988) a close cooperation between the three organizations has taken place, which has resulted in common text documents for the 1988 version of the X.400 series of recommendations (Blue Book) and the ISO/Intemational Electrotechnicai Commission (IEC) Message Oriented Text Interchange System (MOTIS)9' 16-21. ECMA published the standard ECMA-122 as an interim solution for a Mailbox Access Protocol during this period, aimed as a companion standard to the 1984 CCITT X.400 series of recommendations. The following text on MHS describes the joint CCITT/ISO versions dated 1988. The message handling application allows users to send electronic mail worldwide to recipients in publicly as well as privately managed message handling domains. A user (human or software package) is represented in the MHS by a User Agent (UA). From a communication viewpoint the UA is the originator of a message that is sent to one or more other UA's, which are the final recipients of the message. Message TransferAgents (MTA) perform the actual transfer of messages, in a store-and-forward manner, that may be performed through several relaying steps between MTAs. An optional further system component is a Message Store (MS), whose prime responsibility is to act as a recipient buffer between an MTA and a UA. The core service offered in MHS is the Message Transfer Service (MTS) Transfer Protocol (also called P1), which passes messages between MTAs. This is the serverserver or system protocol of MHS. UAs and MSs are, in cases where they are not co-located with the MTA, communicating with their associated MTA over the MTS Access Protocol (also called P3). In the case where a UA uses a MS as its recipient buffer, the UA communicates with the MS over the MS Access Protocol (also called P7). Note that the MS has a client role in relation to the MTA, but a server role in relation to the UA (see Figure 2).
vol 12 no 2 april 1989
~ M
~ MTS Access -~i M~ ~ r o t o c o l P3 S Access I
I
~
~ - - - ' ~ ~ . ,~ ~ I I i,^ I," MI:~ ~ccess [ u~ ] Protocol p3
Figure 2.
~-~ MTS Transfer ~ . ' P1 l~r°'°C°l
1988 Message Handling System model
The message handling application as currently standardized offers two levels of service. The core service is the MTS, and is responsible for the actual transfer of a message from the originating domain to the recipient domain. The information needed for this transfer is stored in the form of an 'envelope' in the P1 protocol; the actual message 'content' is transparent to the MTS (with a few exceptions, such as when conversion of the content has been requested). The other level is the so-called Interpersonal Messaging System (IPMS), which in effect specifies one type of content (for historical reasons referred to as P2, though from an OSI viewpoint it is a format rather than a protocol), which can be transported by the MTS. The IPMS content allows a number of different document types (called body part types in IPMS), e.g. facsimile and teletex formats, and recently ODA formats, to be included, in any combination, as parts of one message. The IPMS content is constructed in such a way that new document formats can easily be added. In addition, it will be possible to define completely new content types, which are independent of the IPMS content, giving a further level of extensibility for future needs. Some of the more important 1988 MHS extensions, apart from the introduction of the MS and its Access Protocol, are the support for Distribution Lists, the addition of an Access Unit (AU) for Physical Delivery of messages, and the addition of protocol elements to carry information to support Secure Messaging requirements. Work started at the CCITT during 1988 to create a new content-type for MHS specifically designed to carry Electronic Data Interchange information.
DOCUMENT FILING AND RETRIEVAL The need for a generalized filing capability in the distributed office environment is being addressed by the Document Filing and Retrieval (DFR) application, currently under development by ISO and ECMA. Work began on this subject about two years ago in ECMA (TC32-TG5), while the ISO/IEC began a parallel effort a year later (JTCl/SC18/WG4). The two standardization activities are now proceeding in close alignment. Target completion dates call for a stable ECMA draft in June 1989, with ratification by the ECMA General Assembly in December 1 9 8 9 - - t h e ISO version is expected to become an international standard in October 1990. At the beginning of the ECMA work, an analysis was conducted to determine specific functional and architecturai requirements for this type of application in the distributed office. At that time, Subcommittee (SC) 21/ Working Group (WG) 5 was completing File Transfer Access and Management (FTAM) 22, to satisfy distributed
63
filing requirements found in the more traditional data processing applications. Accordingly, F-rAM was investigated as a candidate for the distributed office environment, particularly with regard to its applicability to the perceived document filing needs. It became clear, however, that FTAM differed significantly from the required architectural model, and did not offer the functionality deemed necessary for the distributed office application; FTAM was therefore dropped from further consideration as the primary filing tool in the distributed office. Another closely related standardization activity is underway in CCITT Study Group VIII, under the name Document Transfer and Manipulation (DTAM). This work was initially focused on the videotex application area, but was broadened subsequently to address the more general topic of the transfer and manipulation of documents conforming to the ODA 23.As with FTAM, architectural and functional differences have ruled out DTAM as an altemative to DFR in the distributed office. This is not to say that DTAM and FTAM have been totally dismissed from the distributed office environment, or that opportunities for synergy among the three related development efforts are not being explored. Liaison activities are currently underway among the principal organizations, aimed at identifying potential overlaps, and attempting to align the applications wherever feasible. In particular, one goal of this effort is to align the storage model to render it possible to use any of the protocols to access a document stored by either of the others. DFR addresses the need to store and manage office documents and groups of documents in such a way that they can be retrieved easily for subsequent use. The current work is limited to an access protocol from a DFR client (e.g. a workstation) to some particular DFR server (e.g. a mainframe). A DFR server-to-server protocol may be a future extension. A document is stored in a named Document Store (DS). The DS can be accessed by different clients, and can therefore serve as a shared storage place for documents needed by several people in an office. DFR always stores, retrieves and transfers documents as complete units, treating the documents as transparent objects. Thus, DFR can successfully deal with any type of data object without regard for content or structure (this is one of the main characteristics that differentiates DFR from FTAM and DTAM). Each document may have any number of attributes associated with it, some standard, some user-defined. These attributes can serve a number of different purposes, but more importantly they can aid in selecting documents or groups of documents for subsequent retrieval. This is similar to the Message Store part of MHS, which allows a user to specify a number of attributes and selection criteria to find a particular document or groups of documents in the storage. Documents in the DS can be grouped together in a hierarchical fashion. In effect, the two types of objects that can be found in the DS are documents and groups. The group objects are used to 'staple' together documents and/or groups of documents. This permits an implementation to combine documents into more complex objects which may be visible to the human user as folders, filedrawers, etc. To the office-specific semantics belong the different
64
types of references that the DS can build up and maintain. By means of references, a document can be designated a member of a number of different groups, even though the document itself is stored in the DS only once. A reference may be internal, in which case the document is actually stored in the same DS, or extemai, indicating that the document is stored elsewhere (e.g. in a different DS, or even a conventional file cabinet). Among the operations that a DFR client can invoke are those needed to create a new document entry: copy, move or delete a document; list and search for documents; retrieve a document(s); replace a document's content. Most of the operations are also more or less applicable to groups and to document attributes. As far as possible, DFR is being harmonized with the operations and attributes of the corresponding Message Store and Directory protocol elements. Accordingly, the DFR protocol is based on ROSE and uses the Abstract Service concept for description of the services. The attributes for documents stored in a DS will include the corresponding attributes from ODA as a subset. The DFR access protocol is also designed in such a way that it can use the RDT facilities (see below).
DOCUMENT PRINTING APPLICATION Recent years have witnessed the introduction of laser printers and other advanced printing devices that offer a quality of output that was previously available only from commercial printing equipment. Such devices are now appearing in the office environment in ever-increasing numbers, and the advent of the desktop publishing phenomenon has further stimulated this trend. While the cost of such printing devices has dropped dramatically, it is still, in general, not economically justifiable to dedicate a printer to each workstation. Thus, some means of sharing these resources is mandated. To address this situation in the distributed office environment, ECMA began early in 1987 to develop a standard called Document Print Service Description and Print Access Protocol. ISO followed suit a year later with the introduction of a new work item proposal to define a Document Printing Application (DPA). It is expected that the ISO work will closely parallel and complement the ongoing ECMA work. The document printing application may be considered as the final phase in the life-cycle of a document (although, in fact, portions of the cycle may be iterated many times). Figure 3 illustrates this cycle in its simplest form, as a sequence of three phases.
I
.
.
.
.
.
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
-"
Workstation
i
I i
i
. . . . . . . . . . . . .
I
°~"
Print P r i n t Access Protocol
°
I
!
i
Figure 3.
server
i
Document processing sequence
computer communications
The first phase in the sequence involves the input and editing of the document content, e.g. text is typed, graphic material is created, artwork is scanned into the system, etc. At this stage, the document is considered to be in revisable (or processable) form. At some point in the evolution of the document (and perhaps at many points), a printed copy may be desired. Upon user request, then, the electronic document is formatted for printing: all decisions are made relative to placement of text and graphics on pages, and all needed information is inserted to aid the printer in correctly interpreting the document originator's intent. This constitutes phase two of the sequence, and often takes place in the same system as phase one, usually the user's workstation. The final phase begins when the document has been formatted and the user has requested that it be printed on some particular printer. To a workstation user, it will often appear that the latter two phases are one; however, they are separate and distinct activities. Consistent with the DOAM, when the print client (software) receives a request to print from the user (usually a human, but not necessarily), it encodes the necessary parameters, and invokes the print operation to transport the document to a print server. Generally, the document to be printed will be transported to the print server immediately and directly, along with the print operation parameters; alternatively, the print client may provide a reference or pointer to the document, enabling the print server to acquire the document for printing at some later time. In the latter case, the document may be co-located with the print client, or it may, e.g. reside in a DFR DS. The RDT facility (see below) is the primary means for accomplishing this form of document transfer. It is important to note that the print access protocol does not mandate any particular document format. So, while the protocol will be aligned with the SPDL currently being defined in Joint Technical Committee (JTC)-I SC18/WG82, any document format could be used so long as it is supported by the intended print server. This means that de facto standard print formats such as Postscript from Adobe and Interpress from Xerox can be carried transparently by the print access protocol. In addition to the print operation, the print access protocol includes several other operations that a print client may invoke to modify the parameters of a print job, determine the status of a print job or a print server, cancel a job, list jobs, read a server's profile of available features, or read the characteristics of specific resources. Additional operations for print server management are under study. Two guiding principles have been observed in the definition of the access protocols: the perceived needs for flexibility and for extensibility. The access protocol, by design, will recognize that different print servers exhibit a broad range of characteristics and capabilities, and the magnitude of these differences will grow with time. Therefore, while the access protocol will define the principal known or anticipated features that a client might wish to employ in the course of printing a document, the protocol will also include an extension facility to enable implementors to add new printer features in the future, and to provide access to the new features without the need to publish a new protocol standard.
vol 12 no 2 april 1989
The corollary requirement is the need for flexibility in the distributed office environment. The typical office network may include a variety of different printers from different makers havingwidely varied features, capabilities and purposes. To this end, the protocol will enable the client to specify a desired quality of service. In effect, the client will be able to indicate a tolerance level for unavailable resources and features, and will be able to stipulate those aspects of the print request that absolutely must be honoured. Thus, for drafts and other routine printing, the user would normally tell the print server to proceed, even though not all the request parameters could be honoured, e.g. a specified font might not be available at that print server, necessitating the use of a locally available substitute. But in those cases where the printed output must be letter-perfect, the user could stipulate the highest quality of service - - no substitutes allowed.
REMOTE DATABASE ACCESS APPLICATION The Remote Database Access (RDA) service and protocol 24 does not belong to the more specific office applications mentioned in the DOAM document, but has many features in common with the DOAM applications, and can be seen as the link between the new type of office applications covered by DOAM and the more traditional data processing systems, which often use centralized databases to store information common to several applications. RDA uses the same client-server model concept as DOAM, and defines an access protocol which allows clients to access data stored in a database server. The service offered by an RDA database server consists of the feature to open a particular database and then execute database operations on that database. The actual database operations passed in the access protocol are described in a suitable database language. So far, the Structured Query Language (SQL) database language is explicitly supported, but the protocol is designed in such2Sa way that other database languages can be added later. Likewise to the DOAM access protocols, the RDA access protocol is based on the remote operations concept and uses the ROSE. The area in which RDA differs from the applications in the DOAM family is that the higher quality of service levels of RDA make use of the Commitment, Concurrency and Recovery (CCR) mechanism, which is currently under study in ISO/JTC1/SC2126. RDA could provide the base capability for transaction processing applications.
REFERENCED DATA TRANSFER One general type of operation that may be performed frequently in the distributed office environment involves the transfer of some sort of data object from one server to another; e.g. suppose a workstation user wishes to print a copy of a document that currently resides on a DFR Document Store. The user could, of course, retrieve the document file from the Document Store, then transmit the same file to a print server, along with the necessary print operation parameters. This mode of operation is simple in concept, but in the case of large data objects it is inherently inefficient as well, since it requires the object to be transmitted twice over the network to achieve a single objective.
65
A more efficient alternative is offered by RDT, a supportive application that is currently moving through the standardization process. RDT was adopted as an ECMA standard (ECMA-131) in July 1988, and was initially proposed in ISO/IEC JTC1/SC18/WG4 as part two of the DOAM draft proposal 1s. Several national bodies objected to this approach, however, commenting that RDT should be documented and evaluated as a separate standard. Accordingly, the formal definition of RDT has been stripped out of the DOAM draft proposal, and is now being balloted as a new work item. Three parties are involved in any RDT information transfer: an initiator, who requires the transfer to take place; a source, where the information is currently held; and a sink, to which the information is to be transferred. To effect the transfer: 1 The initiator first contacts the source, using the application-specific protocol appropriate to that server, and requests that it prepare toproduce the data object, e.g. to read a document from a Document Store. In response, the source returns an RDT-reference that will serve to identify the object later. 2 The initiator then employs the application protocol of the sink to pass the RDT-reference to that server, with a request to consume the referenced data object, e.g. to fetch and print the document represented bythe RDTreference. 3 Finally, the sink utilizes the RDT protocol to contact the source and request transfer of the referenced data object; when the object has been transferred, the server that has been acting as sink completes the operation specified by the initiator. RDT has the following advantages over the more conventional approach: • only the single RDT service element need be included in the application contexts of two dissimilar servers to enable transfers between them. There is no need for each server to implement the native protocol of each other server with which it might communicate; • data objects to be transferred are transparent to the RDT service element, i.e. no knowledge of content semantics or syntax is required to effect a transfer-thus, RDT can be used in store-and-forward situations, without regard to what is being transferred; • data transfers can be initiated which might not actually take place until later; thus, a print server might defer the transfer of data for its next print job while it completes some time-critical phase of its current job. The RDT facility is expected to receive wide use in the distributed office. The DFR and DPA access protocols are each being developed with the ability to deal with RDT references as one alternative means of identifying data objects, and the RDT facility as an option for effecting data transfers in appropriate produce and consume operations. Existing access protocols are candidates for extension to make use of the RDT facility, with Message Store being an obvious first choice.
DIRECTORY An essential cornerstone of distributed office architecture, the Directory maintains information about different objects in a network. A joint project of ISO and CCITT, ISO
66
/
~r~ \
~-
I
Directory
I
-~".IDirectory I
Figure 4.
/ //
access protocol
"~ "'..
Directory system protocol
I
"'-.
.
.
.
.
I
,
. "
./J
Directory model
International Standard 9594 and the corresponding CCITT Recommendations of the X.500 series were approved by the respective organizations in late 1988. One of the most important uses of the Directory is 'name-to-address mapping', which allows the relationships between network objects and their physical locations (i.e. network addresses) to be dynamic. By means of the Directory, OSI networks can be 'selfconfiguring' in the sense that objects can be added or removed from a network, or their locations changed, without affecting the operation of the network itself. A corollary benefit accrues from a naming structure that enables users to refer to network objects by user-friendly names rather than by some arcane string of digits, or the like. The Directory (see Figure 4) is actually a set of open systems which cooperate to hold and make available a logical database of information about a set of objects in the real world. The information held in the Directory is known collectively as the Directory Information Base (DIB). Each user of the Directory, whether a person or a computer program, is represented by an applicationprocess called a Directory User Agent (DUA). Similarly, a Directory System Agent (DSA) is an application-process which is part of the Directory and whose role is to provide access to the DIB. The Directory has been defined in such a way that it can be distributed along both functional and organizational lines. Accordingly, the DSA may access the DIB on behalf of either a DUA or another DSA. It is because of this feature that users may view the Directory as a single unified whole, while the DIB, and the DSA access points, may actually be distributed widely, and in fact the underlying physical implementations may differ greatly. The DIB is composed of (directory) entries, each of which is a collection of information about one object. Each entry is made up of attributes, each with a defined type and one or more values. The types of attribute which are present in a particular entry are dependent on the class of object which the entry describes. The entries of the DIB are arranged in the form of atree, where the vertices represent the entries. Entries higher in the tree (nearer the root) will often represent objects such as countries or organizations, while entries lower in the tree will represent people or application processes. Every entry has a distinguished name, which uniquely and unambiguously identifies the entry (as well as the entries superior to it in the tree). Provision is also made for objects to have aliases, alternative names which may be used to facilitate searching and simplify access to objects. The Directory Service is realised in two Directory protocols, both based on the notation and conventions of ROSE: • The Directory Access Protocol (DAP) defines the
computer communications
exchange of requests and outcomes between a DUA and DSA. The protocol elements contained in a DAP implementation provides the user with the ability to interrogate the Directory in a number of ways, and to add, remove, or modify entries in the Directory. • The Directory System Protocol (DSP) defines the exchange of requests and outcomes between two DSAs, and includes those protocol elements required to chain a request from one DSA to another, and to relay the outcome back to the original requestor. It is this protocol that enables the Directory to be distributed. Due to the impending close of the CCITT 1985-1988 study period, the working version of the Directory had to be finalized before all of the desired functionality had been incorporated. Hence, a number of additions are planned, and work has already begun on them in the ISO. In the meantime, it is expected that local implementations will develop some of these features to fill an interim need (some of these potential local additions are suggested in the new standard, ISO 9594) 11.
SECURITY The awareness that office applications also need to be secure in order to be acceptable to a wider audience, and for general use, has increased considerably during the last few years. The only security feature offered in the MHS standard from 1984 was the ability to send encrypted information within an Interpersonal Message. A number of comments and proposals since then has led to a whole range of security features being included in the 1988 MHS version. The MHS security features are described in general in ISO DIS 10021 part 217 with the related data definitions in part 4 Is. The groups of security services now offered in MHS are: • • • • • • •
Origin authentication Secure access management Data confidentiality Data integrity Non-repudiation Message security labelling Security management
It should be pointed out that the MHS application as such does not define the local functions needed to realize these security features; what is offered as part of the new MHS standard is the transportation of security-related protocol elements within the MHS services and protocols, which is needed by the security modules. MHS also uses an authentication service offered by the Directory standard 11. This authentication service, which is based on a 'public key' method to check on authentication, is designed so that not only the Directory itself, but also other applications, can make use of the service as a common tool for authentication. Directory has also included some of the other security features defined for MHS. Most of the security parameters are passed between the communication partners during the association establishment phase, but some are used on the operation level, i.e. in each protocol interchange. The new DOAM applications that are currently under
vol 12 no 2 april 1989
development will draw on the experience from the MHS and Directory standards, and will introduce corresponding security features relevant to their applications. A general model concept for security is presented in ECMA TR/46, and in an addendum to the OSI Reference Model 4. Further work on general security issues is planned in ECMA and ISO/IEC over the next few years.
FUTURE W O R K As formal results of the joint CCITT and ISO activities during the CCITT Study period 1985-1988, CCITT Recommendations and corresponding international standards will be published during 1989 for ACSE, ROSE, RTSE, ASN.1 addenda, Presentation, Message Handling and Directory. Other projects which are expected to progress from the Draft Proposals (DP) to the Draft International Standard (DIS) stage in ISO/IEC during 1989, and to international standard stage in 1990, are DOAM, RDT, DFR and RDA. New projects which will start in 1989 and possibly reach the draft proposal or draft addendum stage in ISO/IEC during 1989 are DPA, additions to MHS-MOTIS to include logging functions for Message Store, additions to MHS-MOTIS to include a new content-type for Electronic Data Interchange, and additions to Directory to include various extensions which could not be finalized in 1988. Other projects which will start in ISO/IEC or CCITT during 1989, but with probable completion dates later than 1989, are additions to MHS-MOTIS to include a new content-type for file transfer, voice mail, bulletin boards and message-based computer conferencing, additions to MHS-MOTIS to make use of RDT, further additions to Directory, and general standards for security.
REFERENCES* 1 Hunter, R, Kaijser, P and Nielsen, F 'ODA: a document architecture for open systems' Comput. Commun. Vol 12 No 2 (April 1989) pp 69-79 2 Robinson, P I and Slrasen, S M 'Standard Page Description Language' CompuL Commun. Vol 12 No 2 (April 1989) pp 85-92 3 Smith, I M 'Standard Generalized Markup Language and related standards' CompuL Commun. Vol 12 No 2 (April 1989) pp 80-84 4 0 S l Reference Model and OSI Reference M o d e l Part 2: Security architecture (ISO 7498-1 and 2) (1984) 5 0 S I Application Layer Structure (ISO/IEC IS 9545) (1989) 6 Distributed Office Applications Model: General Model (ISO DP 10031-I) (1989) 7 Specification of AbstractSyntax Notation One (ASN.1) and ASN.1 Extensions (ISO 8824 and 8824 Addendum 1) (1987) 8 Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.7) and ASN.1 Extensions (ISO 8825 and 8825 Addendum 1) (1987) 9 MOTIS: Abstract Service Definition Conventions (ISO/IEC IS 10021-3) (1989) *Draft Proposals(DP),Draft InternationalStandards(DIS)and Technical Reports (TP0 are available from the International Organization for StandardizationCentralSecretariat,I rue de Varemb~,CasePostale56, CH-1211 Geneva20, Switzerland
67
10 OSl Service Conventions (ISO TR 8509) (1987) 11 The Directory- Overview of Concepts, Model and Services, The Directory- Models, The DirectoryAbstract Service Definition, The Directory--Procedures for Distributed Operation, The DirectoryProtocol Specifications, The Directory -- Selected Attribute Types, The Directory--Selected Object Classes, and The Directory- Authentication Framework (ISO/IEC 9594-I to 8) (1989) 12 Service definition for the Association Control Service Element (ISO DIS 8649) (1989) 13 Remote Operations: Model, Notation and Service Definition and Remote Operations: Protocol Specifications (ISO/IEC 9072-I and 2) (1989) 14 Reliable Transfer: Model and Service Definition and Reliable Transfer: Protocol Specification (ISO/IEC 9066-1 and 2) (1989) 15 Distributed Office Applications Model: Referenced Data Transfer (ISO/IEC DP 10031-2) (1989) 16 MOTIS: System and Service Overview (ISO/IEC IS 10021 -I ) (1989) 17 MOTIS: Overall Architecture (ISO/IEC DIS 10021-2) (1989) 18 Message Transfer System: Abstract Service Definition and Procedures (ISO/IEC DIS 10021-4) (1989) 19 MOTIS: Message Store: Abstract Service Definition (ISO/IEC DIS 10021-5) (1989) 20 MOTIS: Protocol Specification (ISO/IEC DIS 10021-6) (1989) 21 MOTIS: Interpersonal Messaging System (ISO/IEC DIS 10021-7) (1989) 22 File Transfer, Access and Management--General Introduction, File Transfer, Access and Managem e n t - The Virtual Filestore Definition, File Transfer, Access and Management -- The File Service Definition and File Transfer, Access and Management -- The File Protocol Specification (ISO/IEC 8571-I to 4) (1989) 23 Open Document Architecture (ODA) and Interchange Format T.410 Series Recommendations, CCII-I-, Geneva, Switzerland (1988) 24 Remote Database Access (ISO DP 9579) (1989)
68
25 Database language SQL (ISO DP 9579) (1989) 26 ServiceDefinition for the Commitment, Concurrency and Recovery Element (ISO DIS 9804) (1989) J
Stanley
McConnell
received his BA and MS degrees in applied mathematics from San Jose State University, California, in 1958 ahd 1959 respectively. He has been active in the development of office systems for the past ten years, including the Xerox Star workstation and network ..... systems, and a variety of electronic printing products. Mr McConnell is currently Manager of Print Service Architecture at Xerox Corporation, and is editor of the emerging ISO and ECMA standard, Document Printing Application.
CarI-Uno Manros received his degree in business administration, data processing and pedagogics from Stockholm University,Sweden. He currently works in the Systems Architecture Department of the Communication and Information Systems Group at Siemens AG, Munich, FRG. Over the last five years he has been involved with a number of standards projects related to office automation. He has carried out liaison between the CCI TTand ISO on message handling, and was active in the joint CCIT-r-ISO project on directory systems. Mr Manros is convenor of ECMA TC32-TG5 on distributed office applications.
computer communications
A short overview of the Open Systems Interconnection protocol standards related to office communications, covering approved and ongoing standardization work in the International Organization for Standardization, the Consultative Committee on International Telephone and Telegraph, and the European Computer Manufacturers' Association, is given. The relationship between office communications and the OSI Reference Model is discussed, and the Distributed Office Architecture Model is presented, establishing a common set of guidelines and requirements to be observed in the development of distributed office applications. The principal applications of this class are then described in turn, including those dealing with Message Handling, Document Filing, Document Printing and Remote Data Access. The supportive Referenced Data Transfer and Directory applications are also discussed, as are security considerations as they relate to distributed office applications. The paper concludes with a discussion of plans for future standardization activities.
Keywords: office information systems, Open Systems Interconnection, distributed office communications, standardization In general, there are two levels of functionality needed to provide meaningful office automation services to a user. Both of these levels are the subject of standardization. The first level consists of the peer-to-peer protocols, as defined in the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) 7-Layer model. These protocols primarily perform the transportation of information between co-operating systems, and usually contain instructions from the sending partner to the receiving partner on how to route the information, e.g. the Message Transfer protocol used in the Message Handling application (see below). *Xerox Corporation, Business Products and Systems Group, ESM8-03, 230S Utah Avenue, El Segundo, CA 90245, USA tSiemens AG, Otto Hahn Ring 6, [3-8000, Munich 40, FRG
This paper describes the first level standards further, while various data object format standards, such as ODA I, Standard Page Description Language (SPDL)2 and Standard Generalized Markup Language (SGML) 3 are discussed elsewhere in this special issue. This paper describes the first level standards further, while various data object format standards, such as ODA I, Standard Page Description Language (SPDL)2 and Standard Generalized Markup Language (SGML) 3 are discussed elsewhere in this special issue.
OFFICE COMMUNICATIONS/OSl RM RELATIONSHIP The office applications are located in the Application Layer (Layer 7) of the OSl Basic Reference Model (RM) 4. A further refined description of the Application Layer is given in the OSI Application Layer Structure (ALS) document s, which covers such topics as the relationship between distributed information processing and OSl communication services, as well as the OSl service and protocol structure in the Application Layer. The importance of this document for office communications is due to the definition of some of the fundamental concepts and terms which are being used in the latest communication standards for office applications. A few of these terms need to be explained here as a background to descriptions of the applications which follow (explanations have been simplified -- see ISO texts for formal definitions): • Application Context: can be described as a'complete' Application Layer protocol. • Application Service Element: a module, or subset, of a complete Application Layer protocol. Several Application Service Elements get combined into one Application Context. • Application Association: an instance usage of an Application Context. • Application Entity: the communication aspect of a
0140-3664/89/020061-08 $03.00 © 1989 Butterworth & Co (Publishers) Ltd vol 12 no 2 april 1989
61
partner in an Application Association. This is sometimes referred to as a 'stub' outside the standardization groups.
DISTRIBUTED OFFICE APPLICATIONS MODEL The overall approach to office applications, from a communications point of view, is described in the Distributed Office Applications Model (DOAM) document 6. Some of the more important concepts from that paper are described here. Office applications are typically distributed, otherwise they would not use communication protocols in the first place. However, this distribution can occur at two different levels. First, a user has a workstation which usually offers a number of local services such as an editor and some local filing facilities. Other more complex or resource-hungry services may be provided in a more powerful server system, which is a shared resource for several workstations. The workstation is then considered to be a client system to the server system. The two systems contain application entities, which communicate over a client-server protocol, also called an access protocol. An access protocol is called asymmetric because of the fact that the client partner and the server partner have different capabilities, and have different tasks to perform, e.g. it is meaningless for the server to ask the client to perform tasks which can only be performed by the server (see Figure 1). Second, servers of the same type may need to communicate among themselves in order to perform a desired task. This is done by means of a server-to-server protocol, also called a system protocol. An example can be given from the Directory application, where different
Data-object-formatI~ specification
User I~
X-server ............
t ...................
t ......
Application Application -entity X_access_protocoLApplication -entity ASEs(I) ASEs(2) Presentati°n Layerlayers and other
T
Presentation-association T
Figure 1. OSl communication between an X-client and an X-server. (1) This set of Appfication-Service-Elements implements the functions required by an x-client for communication with an x-server using the x-accessprotocol (2) This set of Application-Service-Elements implements the functions required by an x-server for communication with an x-client using the x-accessprotocol
62
Directory System Agents (DSA) (servers) store their part of the total directory information. One DSA can forward an enquiry which originated from a Directory Access Protocol (DAP) request, to other DSAs to find the desired answer using the Directory System Protocol (DSP). In addition to these model concepts, the DOAM document specifies a number of other requirements which will ensure a 'common style' for all distributed office applications. The more important of these are: • The requirement to specify all protocols using the Abstract Syntax Notation One (ASN.1) 7 and the associated encoding 8. • The requirements to specify all application services using the Abstract Service Definition Conventions9. This approach uses a number of ASN.1 macros to define the service aspects in a top-down manner. The definition starts by describing the overall service objects. Each object is then defined to have a number of ports, each offering a set of services. For each port a number of abstract-operations and associated abstract-errors are defined, including the definition of all data types that are used in the abstract-operations and abstract-errors. The whole idea behind this approach, which is an alternative to the methods described in the OSI Service Conventions 1° document, is to eliminate any redundancy between the service and the protocol definitions, i.e. all the data type definitions from the service definition can be re-used in the protocol specification. Note that the services described by the Abstract Service Convention are not limited to the pure OSI aspects, but may also cover local non-OSl &spects, e.g. as shown bythe Interpersonal Messaging service in the Message Handling application. • The recommendation to use the ASN.1 macro ATTRIBUTE (defined in the ISO Directory document 11) to describe many of the elements that can occur as parameters in abstract-services and protocols. This brings advantages in the overall protocol design and simplifies any future extensions. Attributes defined for one application can be re-used in other applications without re-definition. • The requirement to use the Association Control Service Element (ACSE) 12 as part of all Application Contexts. The ACSE offers certain OSI services used at association establishment time, and also contains parameters which specify the requirements on services in the OSI Presentation Session and Transport Layers. • The requirement that all access protocols, and optionally system protocols, shall use the Remote Operations Service Element (ROSE)13. ROSE consists of a notation and the associated protocol to describe application protocols, and is especially well suited for, but not limited to, access protocols. It makes use of a number of ASN.1 macros. The Remote Operations model uses a simple pattern for communication: one of the communication partners, usually the client, starts an operation by sending an Invoke to the other partner, usually the server. The partner responds, after having executed the operation, by sending back either a Resu/t or an Error (or in some cases a Reject). Adherence to this simple method has so far proved to be quite feasible, and the documentation of such protocols, especially in combination with the use of the Abstract Service Definition Conventions, is clear and concise.
computer communications
• The option to use the Reliable Transfer Service Element (RTSE)I4, either alone or in combination with the ROSE. RTSE, which is mandatory for the Message Transfer Protocol, contains a number of rules on how to make proper use of the OSI Presentation and Session Layer services to guarantee that an information object, such as a message, does not get lost as a result of communication errors. The RTSE ensures that each application-protocol-data-unit (e.g. sections of a message) is transferred completely between Application Entities exactly once, or that the sending Application Entity is wamed of an exception. This may sound simple enough, but is in effect rather complex. • The option to use the Reference Data Transfer (RDT) facility1 s, which is a generalized server-server protocol intended primarily to assist users in transferring documents between servers of different kinds, e.g. between a file server and a print server.
MESSAGE HANDLING APPLICATION The attempt to develop a standardized Message Handling System (MHS) was pursued by the European Computer Manufacturers' Association (ECMA), the ISO and the Consultative Committee on International Telephone and Telegraph (CClTr) during the early 1980s. Although the different solutions were reasonably close from a functional point of view, the X.400 series of recommendations from 1984 (Red Book) quickly found the greatest acceptance in the marketplace. During the latest CCITT study period (1985-1988) a close cooperation between the three organizations has taken place, which has resulted in common text documents for the 1988 version of the X.400 series of recommendations (Blue Book) and the ISO/Intemational Electrotechnicai Commission (IEC) Message Oriented Text Interchange System (MOTIS)9' 16-21. ECMA published the standard ECMA-122 as an interim solution for a Mailbox Access Protocol during this period, aimed as a companion standard to the 1984 CCITT X.400 series of recommendations. The following text on MHS describes the joint CCITT/ISO versions dated 1988. The message handling application allows users to send electronic mail worldwide to recipients in publicly as well as privately managed message handling domains. A user (human or software package) is represented in the MHS by a User Agent (UA). From a communication viewpoint the UA is the originator of a message that is sent to one or more other UA's, which are the final recipients of the message. Message TransferAgents (MTA) perform the actual transfer of messages, in a store-and-forward manner, that may be performed through several relaying steps between MTAs. An optional further system component is a Message Store (MS), whose prime responsibility is to act as a recipient buffer between an MTA and a UA. The core service offered in MHS is the Message Transfer Service (MTS) Transfer Protocol (also called P1), which passes messages between MTAs. This is the serverserver or system protocol of MHS. UAs and MSs are, in cases where they are not co-located with the MTA, communicating with their associated MTA over the MTS Access Protocol (also called P3). In the case where a UA uses a MS as its recipient buffer, the UA communicates with the MS over the MS Access Protocol (also called P7). Note that the MS has a client role in relation to the MTA, but a server role in relation to the UA (see Figure 2).
vol 12 no 2 april 1989
~ M
~ MTS Access -~i M~ ~ r o t o c o l P3 S Access I
I
~
~ - - - ' ~ ~ . ,~ ~ I I i,^ I," MI:~ ~ccess [ u~ ] Protocol p3
Figure 2.
~-~ MTS Transfer ~ . ' P1 l~r°'°C°l
1988 Message Handling System model
The message handling application as currently standardized offers two levels of service. The core service is the MTS, and is responsible for the actual transfer of a message from the originating domain to the recipient domain. The information needed for this transfer is stored in the form of an 'envelope' in the P1 protocol; the actual message 'content' is transparent to the MTS (with a few exceptions, such as when conversion of the content has been requested). The other level is the so-called Interpersonal Messaging System (IPMS), which in effect specifies one type of content (for historical reasons referred to as P2, though from an OSI viewpoint it is a format rather than a protocol), which can be transported by the MTS. The IPMS content allows a number of different document types (called body part types in IPMS), e.g. facsimile and teletex formats, and recently ODA formats, to be included, in any combination, as parts of one message. The IPMS content is constructed in such a way that new document formats can easily be added. In addition, it will be possible to define completely new content types, which are independent of the IPMS content, giving a further level of extensibility for future needs. Some of the more important 1988 MHS extensions, apart from the introduction of the MS and its Access Protocol, are the support for Distribution Lists, the addition of an Access Unit (AU) for Physical Delivery of messages, and the addition of protocol elements to carry information to support Secure Messaging requirements. Work started at the CCITT during 1988 to create a new content-type for MHS specifically designed to carry Electronic Data Interchange information.
DOCUMENT FILING AND RETRIEVAL The need for a generalized filing capability in the distributed office environment is being addressed by the Document Filing and Retrieval (DFR) application, currently under development by ISO and ECMA. Work began on this subject about two years ago in ECMA (TC32-TG5), while the ISO/IEC began a parallel effort a year later (JTCl/SC18/WG4). The two standardization activities are now proceeding in close alignment. Target completion dates call for a stable ECMA draft in June 1989, with ratification by the ECMA General Assembly in December 1 9 8 9 - - t h e ISO version is expected to become an international standard in October 1990. At the beginning of the ECMA work, an analysis was conducted to determine specific functional and architecturai requirements for this type of application in the distributed office. At that time, Subcommittee (SC) 21/ Working Group (WG) 5 was completing File Transfer Access and Management (FTAM) 22, to satisfy distributed
63
filing requirements found in the more traditional data processing applications. Accordingly, F-rAM was investigated as a candidate for the distributed office environment, particularly with regard to its applicability to the perceived document filing needs. It became clear, however, that FTAM differed significantly from the required architectural model, and did not offer the functionality deemed necessary for the distributed office application; FTAM was therefore dropped from further consideration as the primary filing tool in the distributed office. Another closely related standardization activity is underway in CCITT Study Group VIII, under the name Document Transfer and Manipulation (DTAM). This work was initially focused on the videotex application area, but was broadened subsequently to address the more general topic of the transfer and manipulation of documents conforming to the ODA 23.As with FTAM, architectural and functional differences have ruled out DTAM as an altemative to DFR in the distributed office. This is not to say that DTAM and FTAM have been totally dismissed from the distributed office environment, or that opportunities for synergy among the three related development efforts are not being explored. Liaison activities are currently underway among the principal organizations, aimed at identifying potential overlaps, and attempting to align the applications wherever feasible. In particular, one goal of this effort is to align the storage model to render it possible to use any of the protocols to access a document stored by either of the others. DFR addresses the need to store and manage office documents and groups of documents in such a way that they can be retrieved easily for subsequent use. The current work is limited to an access protocol from a DFR client (e.g. a workstation) to some particular DFR server (e.g. a mainframe). A DFR server-to-server protocol may be a future extension. A document is stored in a named Document Store (DS). The DS can be accessed by different clients, and can therefore serve as a shared storage place for documents needed by several people in an office. DFR always stores, retrieves and transfers documents as complete units, treating the documents as transparent objects. Thus, DFR can successfully deal with any type of data object without regard for content or structure (this is one of the main characteristics that differentiates DFR from FTAM and DTAM). Each document may have any number of attributes associated with it, some standard, some user-defined. These attributes can serve a number of different purposes, but more importantly they can aid in selecting documents or groups of documents for subsequent retrieval. This is similar to the Message Store part of MHS, which allows a user to specify a number of attributes and selection criteria to find a particular document or groups of documents in the storage. Documents in the DS can be grouped together in a hierarchical fashion. In effect, the two types of objects that can be found in the DS are documents and groups. The group objects are used to 'staple' together documents and/or groups of documents. This permits an implementation to combine documents into more complex objects which may be visible to the human user as folders, filedrawers, etc. To the office-specific semantics belong the different
64
types of references that the DS can build up and maintain. By means of references, a document can be designated a member of a number of different groups, even though the document itself is stored in the DS only once. A reference may be internal, in which case the document is actually stored in the same DS, or extemai, indicating that the document is stored elsewhere (e.g. in a different DS, or even a conventional file cabinet). Among the operations that a DFR client can invoke are those needed to create a new document entry: copy, move or delete a document; list and search for documents; retrieve a document(s); replace a document's content. Most of the operations are also more or less applicable to groups and to document attributes. As far as possible, DFR is being harmonized with the operations and attributes of the corresponding Message Store and Directory protocol elements. Accordingly, the DFR protocol is based on ROSE and uses the Abstract Service concept for description of the services. The attributes for documents stored in a DS will include the corresponding attributes from ODA as a subset. The DFR access protocol is also designed in such a way that it can use the RDT facilities (see below).
DOCUMENT PRINTING APPLICATION Recent years have witnessed the introduction of laser printers and other advanced printing devices that offer a quality of output that was previously available only from commercial printing equipment. Such devices are now appearing in the office environment in ever-increasing numbers, and the advent of the desktop publishing phenomenon has further stimulated this trend. While the cost of such printing devices has dropped dramatically, it is still, in general, not economically justifiable to dedicate a printer to each workstation. Thus, some means of sharing these resources is mandated. To address this situation in the distributed office environment, ECMA began early in 1987 to develop a standard called Document Print Service Description and Print Access Protocol. ISO followed suit a year later with the introduction of a new work item proposal to define a Document Printing Application (DPA). It is expected that the ISO work will closely parallel and complement the ongoing ECMA work. The document printing application may be considered as the final phase in the life-cycle of a document (although, in fact, portions of the cycle may be iterated many times). Figure 3 illustrates this cycle in its simplest form, as a sequence of three phases.
I
.
.
.
.
.
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
-"
Workstation
i
I i
i
. . . . . . . . . . . . .
I
°~"
Print P r i n t Access Protocol
°
I
!
i
Figure 3.
server
i
Document processing sequence
computer communications
The first phase in the sequence involves the input and editing of the document content, e.g. text is typed, graphic material is created, artwork is scanned into the system, etc. At this stage, the document is considered to be in revisable (or processable) form. At some point in the evolution of the document (and perhaps at many points), a printed copy may be desired. Upon user request, then, the electronic document is formatted for printing: all decisions are made relative to placement of text and graphics on pages, and all needed information is inserted to aid the printer in correctly interpreting the document originator's intent. This constitutes phase two of the sequence, and often takes place in the same system as phase one, usually the user's workstation. The final phase begins when the document has been formatted and the user has requested that it be printed on some particular printer. To a workstation user, it will often appear that the latter two phases are one; however, they are separate and distinct activities. Consistent with the DOAM, when the print client (software) receives a request to print from the user (usually a human, but not necessarily), it encodes the necessary parameters, and invokes the print operation to transport the document to a print server. Generally, the document to be printed will be transported to the print server immediately and directly, along with the print operation parameters; alternatively, the print client may provide a reference or pointer to the document, enabling the print server to acquire the document for printing at some later time. In the latter case, the document may be co-located with the print client, or it may, e.g. reside in a DFR DS. The RDT facility (see below) is the primary means for accomplishing this form of document transfer. It is important to note that the print access protocol does not mandate any particular document format. So, while the protocol will be aligned with the SPDL currently being defined in Joint Technical Committee (JTC)-I SC18/WG82, any document format could be used so long as it is supported by the intended print server. This means that de facto standard print formats such as Postscript from Adobe and Interpress from Xerox can be carried transparently by the print access protocol. In addition to the print operation, the print access protocol includes several other operations that a print client may invoke to modify the parameters of a print job, determine the status of a print job or a print server, cancel a job, list jobs, read a server's profile of available features, or read the characteristics of specific resources. Additional operations for print server management are under study. Two guiding principles have been observed in the definition of the access protocols: the perceived needs for flexibility and for extensibility. The access protocol, by design, will recognize that different print servers exhibit a broad range of characteristics and capabilities, and the magnitude of these differences will grow with time. Therefore, while the access protocol will define the principal known or anticipated features that a client might wish to employ in the course of printing a document, the protocol will also include an extension facility to enable implementors to add new printer features in the future, and to provide access to the new features without the need to publish a new protocol standard.
vol 12 no 2 april 1989
The corollary requirement is the need for flexibility in the distributed office environment. The typical office network may include a variety of different printers from different makers havingwidely varied features, capabilities and purposes. To this end, the protocol will enable the client to specify a desired quality of service. In effect, the client will be able to indicate a tolerance level for unavailable resources and features, and will be able to stipulate those aspects of the print request that absolutely must be honoured. Thus, for drafts and other routine printing, the user would normally tell the print server to proceed, even though not all the request parameters could be honoured, e.g. a specified font might not be available at that print server, necessitating the use of a locally available substitute. But in those cases where the printed output must be letter-perfect, the user could stipulate the highest quality of service - - no substitutes allowed.
REMOTE DATABASE ACCESS APPLICATION The Remote Database Access (RDA) service and protocol 24 does not belong to the more specific office applications mentioned in the DOAM document, but has many features in common with the DOAM applications, and can be seen as the link between the new type of office applications covered by DOAM and the more traditional data processing systems, which often use centralized databases to store information common to several applications. RDA uses the same client-server model concept as DOAM, and defines an access protocol which allows clients to access data stored in a database server. The service offered by an RDA database server consists of the feature to open a particular database and then execute database operations on that database. The actual database operations passed in the access protocol are described in a suitable database language. So far, the Structured Query Language (SQL) database language is explicitly supported, but the protocol is designed in such2Sa way that other database languages can be added later. Likewise to the DOAM access protocols, the RDA access protocol is based on the remote operations concept and uses the ROSE. The area in which RDA differs from the applications in the DOAM family is that the higher quality of service levels of RDA make use of the Commitment, Concurrency and Recovery (CCR) mechanism, which is currently under study in ISO/JTC1/SC2126. RDA could provide the base capability for transaction processing applications.
REFERENCED DATA TRANSFER One general type of operation that may be performed frequently in the distributed office environment involves the transfer of some sort of data object from one server to another; e.g. suppose a workstation user wishes to print a copy of a document that currently resides on a DFR Document Store. The user could, of course, retrieve the document file from the Document Store, then transmit the same file to a print server, along with the necessary print operation parameters. This mode of operation is simple in concept, but in the case of large data objects it is inherently inefficient as well, since it requires the object to be transmitted twice over the network to achieve a single objective.
65
A more efficient alternative is offered by RDT, a supportive application that is currently moving through the standardization process. RDT was adopted as an ECMA standard (ECMA-131) in July 1988, and was initially proposed in ISO/IEC JTC1/SC18/WG4 as part two of the DOAM draft proposal 1s. Several national bodies objected to this approach, however, commenting that RDT should be documented and evaluated as a separate standard. Accordingly, the formal definition of RDT has been stripped out of the DOAM draft proposal, and is now being balloted as a new work item. Three parties are involved in any RDT information transfer: an initiator, who requires the transfer to take place; a source, where the information is currently held; and a sink, to which the information is to be transferred. To effect the transfer: 1 The initiator first contacts the source, using the application-specific protocol appropriate to that server, and requests that it prepare toproduce the data object, e.g. to read a document from a Document Store. In response, the source returns an RDT-reference that will serve to identify the object later. 2 The initiator then employs the application protocol of the sink to pass the RDT-reference to that server, with a request to consume the referenced data object, e.g. to fetch and print the document represented bythe RDTreference. 3 Finally, the sink utilizes the RDT protocol to contact the source and request transfer of the referenced data object; when the object has been transferred, the server that has been acting as sink completes the operation specified by the initiator. RDT has the following advantages over the more conventional approach: • only the single RDT service element need be included in the application contexts of two dissimilar servers to enable transfers between them. There is no need for each server to implement the native protocol of each other server with which it might communicate; • data objects to be transferred are transparent to the RDT service element, i.e. no knowledge of content semantics or syntax is required to effect a transfer-thus, RDT can be used in store-and-forward situations, without regard to what is being transferred; • data transfers can be initiated which might not actually take place until later; thus, a print server might defer the transfer of data for its next print job while it completes some time-critical phase of its current job. The RDT facility is expected to receive wide use in the distributed office. The DFR and DPA access protocols are each being developed with the ability to deal with RDT references as one alternative means of identifying data objects, and the RDT facility as an option for effecting data transfers in appropriate produce and consume operations. Existing access protocols are candidates for extension to make use of the RDT facility, with Message Store being an obvious first choice.
DIRECTORY An essential cornerstone of distributed office architecture, the Directory maintains information about different objects in a network. A joint project of ISO and CCITT, ISO
66
/
~r~ \
~-
I
Directory
I
-~".IDirectory I
Figure 4.
/ //
access protocol
"~ "'..
Directory system protocol
I
"'-.
.
.
.
.
I
,
. "
./J
Directory model
International Standard 9594 and the corresponding CCITT Recommendations of the X.500 series were approved by the respective organizations in late 1988. One of the most important uses of the Directory is 'name-to-address mapping', which allows the relationships between network objects and their physical locations (i.e. network addresses) to be dynamic. By means of the Directory, OSI networks can be 'selfconfiguring' in the sense that objects can be added or removed from a network, or their locations changed, without affecting the operation of the network itself. A corollary benefit accrues from a naming structure that enables users to refer to network objects by user-friendly names rather than by some arcane string of digits, or the like. The Directory (see Figure 4) is actually a set of open systems which cooperate to hold and make available a logical database of information about a set of objects in the real world. The information held in the Directory is known collectively as the Directory Information Base (DIB). Each user of the Directory, whether a person or a computer program, is represented by an applicationprocess called a Directory User Agent (DUA). Similarly, a Directory System Agent (DSA) is an application-process which is part of the Directory and whose role is to provide access to the DIB. The Directory has been defined in such a way that it can be distributed along both functional and organizational lines. Accordingly, the DSA may access the DIB on behalf of either a DUA or another DSA. It is because of this feature that users may view the Directory as a single unified whole, while the DIB, and the DSA access points, may actually be distributed widely, and in fact the underlying physical implementations may differ greatly. The DIB is composed of (directory) entries, each of which is a collection of information about one object. Each entry is made up of attributes, each with a defined type and one or more values. The types of attribute which are present in a particular entry are dependent on the class of object which the entry describes. The entries of the DIB are arranged in the form of atree, where the vertices represent the entries. Entries higher in the tree (nearer the root) will often represent objects such as countries or organizations, while entries lower in the tree will represent people or application processes. Every entry has a distinguished name, which uniquely and unambiguously identifies the entry (as well as the entries superior to it in the tree). Provision is also made for objects to have aliases, alternative names which may be used to facilitate searching and simplify access to objects. The Directory Service is realised in two Directory protocols, both based on the notation and conventions of ROSE: • The Directory Access Protocol (DAP) defines the
computer communications
exchange of requests and outcomes between a DUA and DSA. The protocol elements contained in a DAP implementation provides the user with the ability to interrogate the Directory in a number of ways, and to add, remove, or modify entries in the Directory. • The Directory System Protocol (DSP) defines the exchange of requests and outcomes between two DSAs, and includes those protocol elements required to chain a request from one DSA to another, and to relay the outcome back to the original requestor. It is this protocol that enables the Directory to be distributed. Due to the impending close of the CCITT 1985-1988 study period, the working version of the Directory had to be finalized before all of the desired functionality had been incorporated. Hence, a number of additions are planned, and work has already begun on them in the ISO. In the meantime, it is expected that local implementations will develop some of these features to fill an interim need (some of these potential local additions are suggested in the new standard, ISO 9594) 11.
SECURITY The awareness that office applications also need to be secure in order to be acceptable to a wider audience, and for general use, has increased considerably during the last few years. The only security feature offered in the MHS standard from 1984 was the ability to send encrypted information within an Interpersonal Message. A number of comments and proposals since then has led to a whole range of security features being included in the 1988 MHS version. The MHS security features are described in general in ISO DIS 10021 part 217 with the related data definitions in part 4 Is. The groups of security services now offered in MHS are: • • • • • • •
Origin authentication Secure access management Data confidentiality Data integrity Non-repudiation Message security labelling Security management
It should be pointed out that the MHS application as such does not define the local functions needed to realize these security features; what is offered as part of the new MHS standard is the transportation of security-related protocol elements within the MHS services and protocols, which is needed by the security modules. MHS also uses an authentication service offered by the Directory standard 11. This authentication service, which is based on a 'public key' method to check on authentication, is designed so that not only the Directory itself, but also other applications, can make use of the service as a common tool for authentication. Directory has also included some of the other security features defined for MHS. Most of the security parameters are passed between the communication partners during the association establishment phase, but some are used on the operation level, i.e. in each protocol interchange. The new DOAM applications that are currently under
vol 12 no 2 april 1989
development will draw on the experience from the MHS and Directory standards, and will introduce corresponding security features relevant to their applications. A general model concept for security is presented in ECMA TR/46, and in an addendum to the OSI Reference Model 4. Further work on general security issues is planned in ECMA and ISO/IEC over the next few years.
FUTURE W O R K As formal results of the joint CCITT and ISO activities during the CCITT Study period 1985-1988, CCITT Recommendations and corresponding international standards will be published during 1989 for ACSE, ROSE, RTSE, ASN.1 addenda, Presentation, Message Handling and Directory. Other projects which are expected to progress from the Draft Proposals (DP) to the Draft International Standard (DIS) stage in ISO/IEC during 1989, and to international standard stage in 1990, are DOAM, RDT, DFR and RDA. New projects which will start in 1989 and possibly reach the draft proposal or draft addendum stage in ISO/IEC during 1989 are DPA, additions to MHS-MOTIS to include logging functions for Message Store, additions to MHS-MOTIS to include a new content-type for Electronic Data Interchange, and additions to Directory to include various extensions which could not be finalized in 1988. Other projects which will start in ISO/IEC or CCITT during 1989, but with probable completion dates later than 1989, are additions to MHS-MOTIS to include a new content-type for file transfer, voice mail, bulletin boards and message-based computer conferencing, additions to MHS-MOTIS to make use of RDT, further additions to Directory, and general standards for security.
REFERENCES* 1 Hunter, R, Kaijser, P and Nielsen, F 'ODA: a document architecture for open systems' Comput. Commun. Vol 12 No 2 (April 1989) pp 69-79 2 Robinson, P I and Slrasen, S M 'Standard Page Description Language' CompuL Commun. Vol 12 No 2 (April 1989) pp 85-92 3 Smith, I M 'Standard Generalized Markup Language and related standards' CompuL Commun. Vol 12 No 2 (April 1989) pp 80-84 4 0 S l Reference Model and OSI Reference M o d e l Part 2: Security architecture (ISO 7498-1 and 2) (1984) 5 0 S I Application Layer Structure (ISO/IEC IS 9545) (1989) 6 Distributed Office Applications Model: General Model (ISO DP 10031-I) (1989) 7 Specification of AbstractSyntax Notation One (ASN.1) and ASN.1 Extensions (ISO 8824 and 8824 Addendum 1) (1987) 8 Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.7) and ASN.1 Extensions (ISO 8825 and 8825 Addendum 1) (1987) 9 MOTIS: Abstract Service Definition Conventions (ISO/IEC IS 10021-3) (1989) *Draft Proposals(DP),Draft InternationalStandards(DIS)and Technical Reports (TP0 are available from the International Organization for StandardizationCentralSecretariat,I rue de Varemb~,CasePostale56, CH-1211 Geneva20, Switzerland
67
10 OSl Service Conventions (ISO TR 8509) (1987) 11 The Directory- Overview of Concepts, Model and Services, The Directory- Models, The DirectoryAbstract Service Definition, The Directory--Procedures for Distributed Operation, The DirectoryProtocol Specifications, The Directory -- Selected Attribute Types, The Directory--Selected Object Classes, and The Directory- Authentication Framework (ISO/IEC 9594-I to 8) (1989) 12 Service definition for the Association Control Service Element (ISO DIS 8649) (1989) 13 Remote Operations: Model, Notation and Service Definition and Remote Operations: Protocol Specifications (ISO/IEC 9072-I and 2) (1989) 14 Reliable Transfer: Model and Service Definition and Reliable Transfer: Protocol Specification (ISO/IEC 9066-1 and 2) (1989) 15 Distributed Office Applications Model: Referenced Data Transfer (ISO/IEC DP 10031-2) (1989) 16 MOTIS: System and Service Overview (ISO/IEC IS 10021 -I ) (1989) 17 MOTIS: Overall Architecture (ISO/IEC DIS 10021-2) (1989) 18 Message Transfer System: Abstract Service Definition and Procedures (ISO/IEC DIS 10021-4) (1989) 19 MOTIS: Message Store: Abstract Service Definition (ISO/IEC DIS 10021-5) (1989) 20 MOTIS: Protocol Specification (ISO/IEC DIS 10021-6) (1989) 21 MOTIS: Interpersonal Messaging System (ISO/IEC DIS 10021-7) (1989) 22 File Transfer, Access and Management--General Introduction, File Transfer, Access and Managem e n t - The Virtual Filestore Definition, File Transfer, Access and Management -- The File Service Definition and File Transfer, Access and Management -- The File Protocol Specification (ISO/IEC 8571-I to 4) (1989) 23 Open Document Architecture (ODA) and Interchange Format T.410 Series Recommendations, CCII-I-, Geneva, Switzerland (1988) 24 Remote Database Access (ISO DP 9579) (1989)
68
25 Database language SQL (ISO DP 9579) (1989) 26 ServiceDefinition for the Commitment, Concurrency and Recovery Element (ISO DIS 9804) (1989) J
Stanley
McConnell
received his BA and MS degrees in applied mathematics from San Jose State University, California, in 1958 ahd 1959 respectively. He has been active in the development of office systems for the past ten years, including the Xerox Star workstation and network ..... systems, and a variety of electronic printing products. Mr McConnell is currently Manager of Print Service Architecture at Xerox Corporation, and is editor of the emerging ISO and ECMA standard, Document Printing Application.
CarI-Uno Manros received his degree in business administration, data processing and pedagogics from Stockholm University,Sweden. He currently works in the Systems Architecture Department of the Communication and Information Systems Group at Siemens AG, Munich, FRG. Over the last five years he has been involved with a number of standards projects related to office automation. He has carried out liaison between the CCI TTand ISO on message handling, and was active in the joint CCIT-r-ISO project on directory systems. Mr Manros is convenor of ECMA TC32-TG5 on distributed office applications.
computer communications