Novell is now a part of Micro Focus

Using Messaging APIs

Articles and Tips: article

LARRY MORRIS
Senior Editor
Systems Research Department

01 May 1995


Messaging APIs allow developers to build E-mail interfaces into a variety of applications. The leading programmatic APIs in the E-mail industry are MAPI (from Microsoft), VIM (from a consortium of companies), and CMC (from the X.400 API Association. MAPI 1.0, or Extended MAPI, defines a complete architecture for messaging applications. This architecture defines both messaging clients and messaging services.

Simple MAPI is a subset of Extended MAPI and includes the 12 most common API calls. VIM is an open interface defined by Apple, Borland, IBM, Lotus, MCI, Novell, and Oracle. VIM is a complex API that allows developers to access a wide variety of messaging systems on a wide variety of operating systems. CMC 1.0 is an open standard that is widely supported in the industry. It is a simple API (10 calls) that provides a set of high-level functions for mail-enabled applications to send and receive electronic messages. CMC 2.0 will be a complex API that runs on the same level as MAPI 1.0 and VIM 1.0.

Part 2 of this two-part article will discuss Novell's messaging APIs as well as Novell's overall messaging strategy.

Introduction

E-mail APIs are valuable because developers can use them to build E-mail interfaces into applications. For example, a developer could program a network security application (via an E-mail API) to automatically send a message to the network administrator when an unauthorized attempt is made to access the network. Applications can use E-mail APIs for many different tasks, including looking up addresses, creating messages, and sending messages.

There are two basic types of E-mail APIs: file-format APIs and programmatic APIs. File-format APIs generally allow simple text files to be imported or exported to or from an E-mail system. For example, the ASCII file might include the date, the name of the sender, the recipient's name and address, and the message itself (all of which must follow the format specified by the API). The E-mail system can then import this file, transport it, and export it to the recipient.

In the case of Novell's SMF-71, a prominent file-format API, importing and exporting are not necessary. Instead, NetWare MHS (Message Handling System) regularly scans certain directories and automatically transports files that are compatible with SMF-71.

File-format APIs include the following:

  • Novell's SMF-71 and SMF-70

  • Novell's API Gateway

  • Lotus cc:Mail's Import/Export

  • Microsoft Mail's FFAPI

Programmatic APIs allow applications to communicate directly with an E-mail system using a library of subroutines (which are linked at compile time). Programmatic APIs include the following:

  • CMC

  • MAPI

  • VIM

Along with being file based or program based, E-mail APIs can also be simple or complex, workstation-based or server-based. CMC, for example, is a simple API consisting of approximately 10 functions. VIM, on the other hand, is complex, with approximately 50 functions. MAPI is a workstation API while SMF-71 if a server API.

To further complicate matters, different versions of the same API can be quite different. Simple MAPI, for example, includes a limited number of functions and is quite similar to CMC. Extended MAPI, however, is complex, like VIM. In addition, the soon-to-be-released version of CMC (2.0) is expected to fall into the same category as Extended MAPI and VIM.

The upshot is that E-mail APIs, while undoubtedly valuable to developers, are sometimes difficult to use because of the confusing array of multiple APIs and multiple versions of APIs. The purpose of this DevNote is to give solid introductory information on the leading programmatic E-mail APIs, clarify differences among versions, and tell you how to obtain software development kits (SDKs), specifications, and other information.

This DevNote, which is part 1 of a two-part series, discusses the following APIs:

  • MAPI (Messaging Application Programming Interface), from Microsoft. As noted, true MAPI, or Extended MAPI, is a complex API. Simple MAPI, sometimes called SMAPI, is a subset of Extended MAPI.

  • VIM (Vendor Independent Messaging), a complex API originally developed by Lotus and endorsed by Apple, Borland, and Novell. The current version is VIM 1.0; VIM 2.0 is now in development but has not been officially released.

  • CMC (Common Messaging Call), developed by XAPIA (the X.400 API Association). XAPIA is an open association of companies interested in messaging. Members include Digital Equipment Corp., Hewlett Packard, IBM, Intel, Lotus, Microsoft, Novell, and Oracle. As noted, CMC 1.0 is a simple API, while CMC 2.0 (scheduled for release in mid-1995) is much more complex.

Part 2 of this series will discuss Novell's messaging APIs as well as Novell's overall messaging strategy.

MAPI

Microsoft MAPI 1.0, also known as Extended MAPI, defines a complete architecture for messaging applications. MAPI is a set of functions that applications can use to create, manipulate, transfer, and store messages.The MAPI architecture can be used for such applications as E-mail, scheduling, personal information managers, bulletin boards, and online services (all of which can run on a broad range of platforms). MAPI also offers a common interface that developers can use to build E-mail-enabled applications independently of the underlying messaging system.

MAPI takes its design from the Windows printing model. Just as Windows enables applications to print to several different sources (via a print spooler and independent printer drivers), MAPI enables messaging applications to run with several different messaging services.

The MAPI architecture defines both messaging clients and messaging services. To use a service, a client must first set up a session, which is a specific connection between the client and MAPI based on data included in a profile (which lists configuration information).

Once the session is established, the client can access MAPI services, which fall into three basic categories:

  • Address Books, which might be thought of as telephone directories. These are a collection of one or more lists of message recipients. Each list is known as a container. Custom address books are supported.

  • Message Transports, which transfer messages among clients. MAPI message transports support interaction among a variety of hardware platforms and messaging systems.

  • Message Stores, which organize and store messages and allow them to be accessed. Messages are kept in folders, which are organized hierarchically. In addition, the user can alter messages and then put them back in their folders. A user who received a Microsoft Excel spreadsheet as an OLE object in a message, forexample, could run Excel from within the message, modify the file,and then save the modified file as part of the message.

MAPI Programming Interfaces

As Figure 1 shows, Microsoft offers a variety of programming interfaces for MAPI 1.0, allowing developers in many different development environments to use MAPI.

Figure 1: This shows the OLE Messaging Interface as a layer that is built on top of Extended MAPI 1.0.

The OLE Messaging Library does not provide access to all of the Features of Extended MAPI. For example, it is intended primarily for clients and is not appropriate for service providers.

The following table details the programming interfaces offered for MAPI 1.0.


ProgrammingInterface
Description

MAPI customcontrols

User interfacefor Visual Basic users.

Simple MAPI

Simplifiedinterface containing 12 common API calls.

OLE MessagingLibrary 1.0

Programmableobjects for use by Visual Basic and VBA developers.

CMC

API calls forC and C++ users (described later in thisDevNote)

Extended MAPI

OLE interfacesfor C and C++ programmers.

MAPI Functions

The following is a partial list of MAPI calls:


AddressBooks

OpenEntry

Open a container,user, or distribution list

Address

Display userdialog box for addressing

Details

Display detailsdialog box for a given entry

ResolveName

Find a recipientusing a partial name

CompareEntryIDs

See if twoEntryIDs refer to same object

CreateOneOff

Create EntryIDfor one-off address

RegisterNotification

Obtain notificationswhen book changes

QueryDefaultRecipOpt

Obtain per-recipientoptions for given type

Property MgmtAPIs

Utilized forin-detail property processing

AddressBook Containers

GetContentsTable

Obtain listof container's recipients

GetHierarchyTable

Obtain listof subcontainers

CopyEntries

Copy entriesto a container

CreateEntry

Create newentry in container

DeleteEntries

Delete container,user, or distribution list

Property MgmtAPIs

Utilized forin-detail property processing

PropertyManagement

GetPropList

Obtain a listof available properties

GetProps

Obtain selectedvalues

OpenProperty

Start workingon a property

SetProps

Set value ofselected properties

CopyTo

Copy contentsof current object

SaveChanges

Make changespermanent

DeleteProps

Delete selectedproperty list

Release

Release requiredstorage

GetNamesFromID

Obtain associatednames

GetIDsFromName

Obtain andassign IDs to associated names

GetLastError

Obtain texterror message

MessageStores

OpenEntry

Open folderor message

RegisterNotification

Obtain notificationswhen an object changes

SetReceiveFolder

Define a folderfor incoming messages

GetReceiveFolder

Return wherereceived messages are placed

CompareEntryIDs

See if twoEntryIDs refer to the same object

AbortSubmit

Delete currentmessage from queue

StoreLogoff

Log off frommessage store

Property MgmtAPIs

Utilized forin-detail property processing

Folders

GetHierarchyTable

Obtain infoon subfolders of current folder

GetContentsTable

Obtain summaryinfo on messages in folder

SetSearchCriteria

Define searchcriteria and begin search

GetSearchCriteria

Obtain searchcriteria for a search results folder

OpenEntry

Open a messageor subfolder of current folder

CopyFolder

Move or copya folder into current folder

CopyMessages

Move or copymessages into current folder

CreateFolder

Create newfolder

GetMessageStatus

Check a message'sstatus

SetMessageStatus

Specify 32-bitstatus associated with a message

CreateMessage

Create newmessage

DeleteFolder

Remove subfolderof current folder

DeleteMessages

Remove messagesfrom a folder

SaveContentsSort

Specify defaultcontents sort order for a folder

Property MgmtAPIs

Utilized forin-detail property processing

Messages

GetRecipientTable

Obtain a message'srecipients

GetAttachmentTable

Obtain a message'sattachments

OpenAttach

Open attachment

CreateAttach

Create newattachment

DeleteAttach

Remove attachment

SaveChanges

Save changes to a message

SetReadFlag

Set message-readflag, send report to sender

SubmitMessage

Save changes,mark message ready for sending

PropertyMgmtAPIs

Utilized forin-detail property processing

Attachments

SaveChanges

Save changesto attachment

Property MgmtAPIs

Utilized forin-detail property processing

Simple MAPI

As mentioned, Simple MAPI is a subset of MAPI and contains the 12 most common API calls, as follows:


MAPILogon

Start MAPIsession

MAPILogoff

End MAPI session

MAPIFree

Free memoryallocated by messaging subsystem

MAPISendMail

Send standardmail message

MAPISendDocuments

Send standardmessage via dialog box

MAPIFindNext

Categorizeincoming messages

MAPIReadMail

Read messages

MAPISaveMail

Store messages

MAPIDeleteMail

Delete messages

MAPIAddress

Create setof recipients via dialog box

MAPIDetails

Display addressbook details via dialog box

MAPIResolveName

Change friendlyname to address book entry

Simple MAPI can be found in the Visual Basic MAPI custom control.

Simple MAPI is quite similar to CMC 1.0, and most vendors, including Novell, are encouraging developers to use CMC 1.0 instead. Even Microsoft itself is moving in this direction and includes CMC 1.0 as part of MAPI 1.0.

Microsoft SDKs and Specifications

Simple MAPI is now part of the Windows SDK. Future versions of Windows will include Extended MAPI. To access the Simple MAPI SDK on CompuServe, type GO MSNETWORKS at the CompuServe prompt and move to section 17.

The Microsoft Mail SDK allows C or C++ programmers to access MAPI calls, create custom commands and message types, link and synchronize MS Mail directories with other leading E-mail and messaging systems with FFAPI, and transfer files between messaging systems using FFAPI.

To obtain MAPI documentation and executable files from the Internet, use anonymous ftp to access ftp.microsoft.com. Move to the ADVSYS/MAIL/PCMAIL/DOCS directory and download the following files: MPAI=VR1.ZIP, SMAP=VSE.ZIP, and MAPI=VSD.ZIP.

Microsoft Corp. One Microsoft Way Redmond, WA 98052-6399 Telephone: 800-227-4679

VIM

VIM is an API that allows developers to access a wide variety of messaging systems, including cc:Mail, Notes, and MHS, on a wide variety of OSes, such as DOS, Windows, OS/2, Macintosh, and UNIX.

VIM is an open interface, and the specification is publicly available free of charge. The spec has been defined by members of the VIM consortium and is not controlled by any single company. The members of the VIM consortium are Apple, Borland, IBM, Lotus, MCI, Novell, and Oracle. Many other companies have announced support for VIM.

The goal of the VIM consortium was to establish a standard messaging interface for application developers that is available in all VIM-compliant mail systems as well as to include advanced features that take advantage of specific features in underlying mail systems. Therefore, VIM includes a set of 45 functions that all VIM-compliant mail systems must provide, and an optional set of 10 functions that may not be available in all mail systems.

Applications that have the requirement to run on all VIM-compliant systems have to be designed to use only the minimal set. Applications that want to take advantage of the more advanced, optional features have to check if those functions are supported by the underlying mail system.

Relationship Between VIM and Other Messaging APIs

Apple's OCE (Open Collaborative Environment) is a System 7 extension that offers store-and-forward messaging services, security, and directory services. Apple is implementing VIM on top of OCE.

The small set of MAPI functions that will be available on non-Windows platforms is basically equivalent to VIM's two Simple Messaging Interface (SMI) function calls. The large majority of MAPI calls, the equivalent of VIM's 45 minimal set and 10 optional set, will not be available on non-Windows platforms.

Lotus plans to offer a VIM-to-MAPI integration layer in the absence of Microsoft's support for VIM.

XAPIA APIs are primarily designed for X.400 transport and message-store services, while VIM offers access to a wide variety of transport, store, and delivery services in addition to X.400. Nevertheless, Lotus is a member of both XAPIA and the VIM consortium and is therefore interested in supporting both standards when appropriate. Lotus's cc:Mail Router X.400, for example, supports both XAPIA and VIM APIs.

Just as Extended MAPI incorporates CMC 1.0, the next version of VIM (2.0) will replace the SMI functions with CMC 1.0.

The VIM Framework

VIM makes mail and messaging services available through a well-defined interface. A messaging service enables its clients to communicate with each other in a store-and forware manner. VIM defines messaging as the data exchange mechanism between VIM-aware applications. The underlying messaging system takes care of the routing and delivery of messages within that messaging system. Messages are delivered to a message container. Each VIM-aware application is associated with and has access to tone or more message containers.

A VIM-aware application may have access to one or more address books. Address book services are defined by VIM in a messaging context to support storing information about users, groups, applications, etc., including the location of their message containers. Applications can use the address book services to look up these addresses in order to communicate with them.

VIM Functions


SimpleMessaging Interface

SMISendDocuments

Sends standardmail message via user interface

SMISendMail

Sends a standardmail message

SessionManagement

VIMInitialize

InitializeVIM for this process

VIMQueryCapability

Return implementationfeatures and limits

VIMGetDefaultSessionInfo

Return defaultvalues required for login

VIMOpenSession

Open authenticatedsession

VIMGetEntityName

Get currentauthenticatedd username

VIMCloseSession

End the session

VIMTerminate

Terminate VIMfor this process

VIMStatusText

Return textassociated with a status code

MessageCreation and Submission

VIMCreateMessage

Create newmessage

VIMCreateDerivedMailMessge

Create replyto or forward existing message

VIMSetMessageRecipient

Set value ofmessage header attribute

VIMSetMessageItem

Add an itemto a message

VIMSendMessage

Submit messagefor delivery

VIMCloseMessage

Close messagewithout sending it

MessageContainers

VIMOpenMessageContainer

Open specifiedmessage container

VIMEnumerateMessages

Enumerate messagesin a container

VIMEnumerateMsgAttrValues

Enumerate attributevalues over container

VIMRemoveMessage

Remove messagefrom container

VIMQueryNewMessages

See if newmessages have been delivered to a container

VIMQueryUnreadMailCount

Count unreadmessages in an inbox

VIMExtractMessage

Extract messageand store in a file

VIMOpenExtractedMessage

Open messageextracted with VIMExtractMessage

VIMCloseMessageContainer

Close specifiedmessage container

MessageAccess and Attributes

VIMOpenMessage

Open a messagefor further access

VIMMarkMessageAsRead

Mark a messageasbeing read and send return receipt if appropriate

VIMGetMessageHeader

Get messageheader attributes

VIMEnumerateMessageHeaderAttrs

Get multivaluemessage header attributes

VIMEnumerateMessageItems

List itemsin a message

VIMGetMessageItem

Read an item into a buffer or file

VIMOpenMessageItem

Open an item for reading

VIMReadMessageItem

Read a piece of a message item

VIMCloseMessageItem

Close a message item

VIMEnumerateMessageRecipients

List recipients of a message

VIMOpenNestedMessage

Open a forwarded message

VIMVerifyMessageSignature

Get and verify a message's digital signature

Address Books

VIMEnumerateAddressBooks

Return available address books

VIMOpenAddressBook

Open a named address book

VIMSetCurrentSubtree

Set currentsubtree for hierarchical address book

VIMGetCurrentSubtree

Get currentsubtree for hierarchical address book

VIMEnumerateAddressBookEntries

List entries in address book

VIMCreateAddressBookEntry

Create a new address book entry

VIMMatchAddressBook

Search address book for specified entry

VIMGetABEntryAttributes

Get attributes for address book entry

VIMSetABEntryAttributes

Add or change attributes for address book entry

VIMEnumerateABEntryAttrNames

Get names ofnamed attributes for address book entry

VIMGetABEntryNamedAttributes

Get named attributesfor address book entry

VIMSetABEntryNamedAttributes

Add or changenamed attributes for address book entry

VIMRemoveAddressBookEntry

Remove entry from address book

VIMAddGroupMember

Add member name to a group

VIMRemoveGroupMember

Remove member name from a group

VIMEnumerateGroupMembers

List members of a group

VIMCloseAddressBook

Close address book

VIM 2.0

The specification for VIM 2.0 (also called VIM2) is now in draft form. Changes include the following:

  • Vendor-specific enhancements

  • Clarifications and corrections

  • Gateway development issues

  • IBM VIC calendaring proposal

  • Administrative API enhancements

  • Definition of header files

  • Resolution of multiplatform issues

  • Message container enumeration method

  • Error code for reporting authorization failure

  • Mechanism for sorting messages in a container

  • Technique for displaying/alerting user to new messages

  • Procedure for removing items from message being composed

  • Additional vendor selectors

  • Replacement of SMI calls with CMC 1.0 calls

VIM2 replacement functions include the following:

  • VIM2OpenSession

  • VIM2OpenMessageContainer

New functions for VIM2 include the following:

  • VIM2CreateMessageContainer

  • VIM2RemoveMessageContainer

  • VIM2MoveMessageContainer

  • VIM2EnumerateMessageContainer

  • VIM2SetMessageContainerAttributes

  • VIM2MoveMessage

VIM SDK

The Lotus VIM Developer's Toolkit contains the following:

  • A developer's guide that contains information about Lotus's implementation of VIM and a description of the various VIM functions and parameters

  • Include files with all VIM definitions to be included in the application source code

  • Import libraries, DOS static-link libraries, and DOS object files to be linked with the application object code

  • A Visual Basic runtime DLL

VIM runtime libraries will be an integral part of cc:Mail and Notes products. The first products to bundle the VIM runtime components were cc:Mail for Windows 2.0, cc:Mail for OS/2 WPS 1.0, and Notes 3.0.

Lotus continues to support and enhance Import/Export, a file-based API.

C, C++, and Visual Basic can be used for calling any VIM and SMI function. SMI functions can be accessed by any macro language, including Ami Pro, Excel, and Visual Basic.

The VIM spec is in the public domain and can be obtained from Lotus by calling 800-343-5414.

Online information can be obtained from the cc:Mail BBS--415-691-0401, file area 23, and CompuServe--LOTUSB, Section 11 and LOTUSC, Section 15.

Contact Lotus for further information.

Lotus Developer Relations Group: 800-DEV-RELS, 617-693-4448.

CMC

The Common Messaging Call (CMC) API provides a set of high-level functions for mail-enabled applications to send and receive electronic messages.

CMC is considerably simpler than either Extended MAPI or VIM. In addition, it is an open standard that is widely supported in the E-mail industry.

The interface is designed to be independent of the actual messaging protocol employed between sender and recipient. The interface will support the creation and reception of standard message formats such as X.400 and SMTP (RFC822) as well as proprietary message formats. This is achieved through generic definition of capabilities common tomost messaging protocols, plus a mechanism for defining extensions, which can be used to invoke protocol-specific services.

Another important consideration in the design of this API is to minimize the number of function calls needed to send or receive a message. For example, a mail-enabled application can send a message with a single function call and receive a specific message with two calls.

The CMC API is designed to be complementary to existing XAPIA and X/Open APIs, such as XMHS and XMS.

The CMC interface is designed to allow c common interface over virtually any electronic messaging service. For each CMC implementation, the view/capabilities presented by CMC must be mapped to the view/capabilities of the underlying messaging service.

To maximize interoperability between CMC applications that use similar underlying messaging services, it is critical that a common mapping be defined by the industry segment representing the relevant messaging protocol or interface.

To that end:

  • XAPIA will define the common mapping between CMC and the X.400 protocol, from the perspective of other XAPIA-defined X.400 APIs.

  • Standards bodies, vendors, or vendor groups representing a specific messaging protocol or interface are encouraged to define a common mapping between CMC and the relevant messaging protocol or interface.

To maximize interoperability between CMC applictions that use differing underlying messaging services, it is critical that mapping definitions be designed with such interoperability in mind.

To that end, the following guidelines are offered. This list is not comprehensive.

  • Map message text strings to international character sets, wherever appropriate or possible.

  • Map message attachment types to commonly recognized attachment types, wherever appropriate or possible.

The CMC specification defines the CMC API at two levels of abstraction. It defines a "generic" interface independent of any particular programming language, and a C language interface based on the American National Standard for the C programming language. The generic interface is included to guide the development of other language-specific specifications, such as Pascal.

In order for an implementation of the CMC API to conform to the specification, the implementation must meet the following criteria:

  • All functions and data structures must be implemented as defined. Statements elsewhere in the specification which describe features as optional or with exceptions take precedence over this criterion.

  • The implementation must be able to send and receive at least the CMC IPM message type.

  • Character set support is up to the underlying implementation. Support for an implementation-defined default character set is required. Optionally, other character sets maybe supported. Counted string support is not required.

  • All extensions are optional. Vendors are encouragedto support the CMC-defined standard extension set specified in the CMC spec.

    It is further encouraged that standard extension sets are developed for any proprietary or nonproprietary messaging services for which a CMC interface is provided, to accommodate features specific to that messaging service, and that the extension set be registered with XAPIA.

  • Minimum conformance for an extension set will be defined by the creator of the extension set.

CMC Functions


SendingMessages

cmc_send

Send a mail message

cmc_send_documents

String-based function to send mail

Receiving Messages

cmc_act_on

Perform an action on a message

cmc_list

List summary info on certain messages

cmc_read

Read and return a specified message

Looking Up Names

cmc_look-up

Look up addressing information

Administration

cmc_free

Free memory allocated by messaging service

cmc_logoff

Terminate a session with messaging service

cmc_logon

Establish asession with messaging service

cmc_query_configuration

Determineinfoabout installed CMC service

The CMC 1.0 spec also covers functional architecture, data structures, and programming examples.

Programming Example

The following example shows query configuration, logon, and logoff.

/* local variables used */

CMC_return_code Status;

CMC_boolean  UI_available;

CMC_session_id Session;

/* find out if UI is available with this implementation before starting */

Status = cmc_query_configuration (

         NULL,   /* Default service. */

         NULL,   /* Prompt for username. */

         NULL,   /* Prompt for password. */

         NULL,   /* Default character set. */

         (CMC_ui_id)NULL, /* Default UI ID.  */

         CMC_VERSION, /* Version 1 CMC calls. */

         CMC_LOGON_UI_ALLOWED, /* Use UI to display

                             errors. */

         &Session,  /* Returned session ID. */&
         NULL,   /* No extensions. */

   /* error handling */

 /* Do various CMC calls  */

 /* Log off from the implementation */

 Status = cmc_logoff (

           Session,   /* Session ID.  */

           (CMC_ui_id)NULL, /* No UI will be used.*/

           0,    /* No flags.  */

           NULL);   /* No extensions. */

   /* error handling */

CMC 2.0

CMC version 2.0, also known as Full CMC, is scheduled for release in mid-1995. CMC 2.0 is much more complex than 1.0, as shown by the size of the specifications: the 1.0 spec is 90 pages long while the 2.0 spec is 250 pages long. The list of functions has grown from 10 to more than 40. Full CMC functions fall into the following categories:

  • Composition

  • Enumeration

  • Messaging

  • Stream

  • Name Handling

CMC Specification

The CMC 1.0 specification is available from a variety of sources. On CompuServe it is in the GENCOM forum, XAPIA selection, under the filename CMC_V1.ZIP.

The spec is also posted on the Internet in WinWord format. It is available on ftp.microsoft.com in /DEVELOPR/MAPI. Filenames are as follows:

CMCSPC.PS.ZIP  Postscript

   CMCSPC.README  Readme

   CMCSPC.RTF.ZIP  Rich Text

   CMCSPC.WORD.ZIP Word

Copies of the spec can also be obtained from Omnicom PPI at 800-666-4266, and PSC at 800-268-7737.

Other XAPIA APIs

Other XAPIA APIs include the following:

  • CSA (Calendaring and Scheduling API). Allows calendaring and scheduling capabilities to be integrated into desktop applications such as project management, workflow, and electronic forms.

  • XOM (X/Open Object Management), from X/Open Company Limited and XAPIA. The XOM spec defines the relationship between messaging objects and directory objects. X/Open defines Object Management as "the creation, examination, modification, and deletion of potentially complex information objects."

  • X.400 Gateway API. Programmatic interface allowing messages to pass between a mail-enabled application or a proprietary mail system and an X.400 message service.

  • XDS (API to Directory Services). Programmatic interface to X.500 directory service providers that allows application programs to query the directory system.

  • XMS. Message store API that defines how an application program submits E-Mail messages to and received messages from the X.400 message store.

For more information on XAPIA, send E-mail to Leslie Schroeder in the XAPIA office:

Internet: lschroeder@wynd.net

Bibliography

The following documents were used in preparing this article:

"A Short Tour of Microsoft MAPI," published by Microsoft Corp., not dated.

Common Messaging Call API, Version 1.0, published by the X.400 API Association, Jun. 1, 1993.

Common Messaging Call API, Version 2.0, Draft 7, published by the X.400 API Association, Jan. 30, 1995.

Ferris E-Mail Analyzer, published by Ferris Networks, Inc., Apr. 1994.

Ferris E-Mail Analyzer, published by Ferris Networks, Inc., May 1994.

Microsoft Mail Software Development Kit product brief, published by Microsoft, 1993.

Microsoft Messaging Application Program Interface (MAPI), a white paper published by Microsoft Corp., 1992.

New Riders' Guide to E-Mail and Messaging, by Larry Morris, New Riders Publishing, 1994.

SMF v71 Programmer's Reference, published by Novell Inc., 1992.

"Snappy MAPI: The Messaging Application Programming Interface," by Mark S. Burgess, Data Based Advisor, Feb. 1994, pp. 158-162.

Vendor-Independent Messaging Interface Functional Specification, Version 1.0, published by Apple Computer Inc., Borland International Inc., Lotus Development Corp., and Novell Inc., Mar. 23, 1992.

Vendor-Independent Messaging Interface Functional Specification, Version 2.0 draft, published by Apple Computer Inc., Borland International Inc., Lotus Development Corp., and Novell Inc., May, 1994.

"VIM Developer's Toolkit Q's and A's," published by Lotus Development Corp., Jul. 30, 1993.

XAPIA literature from the X.400 API Association, published 12/94, 1/95, and 2/95.

X/Open OSI-Abstract-Data-Manipulation (XOM) API, CAE Specification, published by X/Open Company Limited and the X.400 API Association, Dec. 1991.

* Originally published in Novell AppNotes


Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates