                   Common Messaging Calls 2.0
                     Background Information

                          August 1995

---------------------------------------------------------------------
Introduction

This backgrounder introduces XAPIA's CMC 2.0, the Common Messaging Call
Application Program Interface (API) version 2.0. It describes the standard
and why it was developed, and answers some common questions. The full
standard may be found on CompuServe (GO GENCOM, in the XAPIA area) and
will shortly be available on the Electronic Messaging Association (EMA)
worldwide web page (http://www.ema.org/).

CMC 2.0 is an enhancement of the first version of the CMC API, published in
June 1993. This new version extends the messaging-aware application
support in the original document with support for messaging-reliant
applications.

Messaging-aware applications can function quite satisfactorily as
stand-alone applications, but which might connect to a messaging service
to provide enhanced functionality. An example would be a word processing
or spreadsheet application that provides a Send command on the File menu.
The original CMC interface (also known as "Simple CMC" or "Simple MAP") is
quite adequate to the task of supporting messaging-aware applications.
Simple CMC is incorporated into CMC 2.0.

By contrast, messaging-reliant applications are inherently dependent on the
existence of a messaging service. Examples are Electronic Data Interchange
(EDI), information distribution applications, conferencing/collaboration
applications, and some calendaring applications and distributed databases.
Messaging-reliant applications use messaging as a store-and-forward analog
of a LAN: messages are used to variously distribute and accept shared
data, request services and receive responses to those requests.

CMC 2.0 specifies a high-level messaging API that can be supported by most
messaging services deployed today (and all the leading providers of
LAN-based messaging were active participants in its definition).

The specification has two intended audiences, messaging service developers
who wish to support the Common Messaging Call API and application
developers who wish to understand the implementation-independent features
of the API. Messaging service providers will find the document complete
and are invited to participate in a reference implementation effort just
getting underway [contact Steve Griesmer, AT&T, at 908/949-4328 or
sjg@arch4.att.com]. Messaging service providers may choose to extend CMC
2.0 using a convention described within the specification document, and
application developers should ask their messaging service providers for
any additional documentation describing such extensions.

---------------------------------------------------------------------
CMC Specification Components

CMC 2.0 provides a set of high-level functions for messaging-enabled
applications to send and receive electronic messages. The specification
runs to almost 400 pages. While that may sound intimidating, in fact the
document is lengthy in the interest of clarity and detail, and is quite
well-factored -- it is by no means necessary to read all of it in order to
understand a point of interest. Included in the specification are

* A powerful, flexible, extensible object model for accessing a broad
collection of objects, containers, and properties. The object model allows
the functional interface to be quite spare, flattening the learning curve
for messaging implementors and application implementors. The object model
borrows heavily from a common approach which is actually independent of
messaging and is available in various application frameworks.

* Comprehensive and detailed class specifications using the object model to
describe common messaging abstractions, thus providing a common language
for messaging service providers and messaging-reliant application
providers

* A relatively small number of generic functions, most of them tied to the
object model

* Extensive error return codes, carefully documented, to cover a wide
variety of potential exception conditions

* Sample code to assist message-reliant application providers

* Sample bindings (to X.400 MTA) as an implementation guide to messaging
service providers

* End-user platform bindings (DOS, Windows 3.1, Windows NT, Macintosh,
OS/2, UNIX SVR4)

* An extension mechanism to allow messaging system providers to add value
to CMC in a natural, consistent fashion

---------------------------------------------------------------------
Industry Context

The intent of CMC 2.0 is to be as generic as possible. Unique among
messaging APIs, CMC is vendor-independent with respect to end-user
platform, messaging provider, and operating system provider. The object
model also encourages a "low-chat" exchange between application and
messaging provider, rendering CMC 2.0 particularly well-suited for use
with satellite, wireless, and other high-latency media as well as for LAN
and WAN

In the highly-competitive messaging industry, it is important to recognize
that there is simultaneously divergence as competing vendors seek to
differentiate their products, and convergence as the most popular
innovations are matched by competitors. CMC provides the common point for
the industry where convergence is recognized and made explicit, while the
extension capability hosts divergence in such a way that application
providers can take ready advantage.

In addition, CMC provides a common point for industry groups to add value
to multiple platforms in a compatible way. A notable example is the CMC
2.0 Multimedia (voice-messaging) Extensions group led by Steve Griesmer of
AT&T (results expected late 1995).

---------------------------------------------------------------------
CMC Related to Other Standards

CMC 2.0 is 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/MIME
(RFC822/RFC1521) as well as proprietary message formats and protocols.
This is achieved through generic definition of capabilities common to most
messaging protocols, plus a mechanism for defining extensions, which can
be used to invoke protocol-specific services.

The interface is also independent of the operating system and underlying
hardware used by the messaging service.

Another important consideration in the design of CMC 2.0 is to enable
simple application actions to be taken with a minimum number of function
calls, while at the same time supporting more complex actions. To achieve
these often conflicting objectives, the CMC API has two interfaces: a
Simple CMC interface and a Full CMC interface. The Simple CMC interface
provides a minimum number of function calls needed to send or receive a
message by messaging-aware applications, and is a minor refinement of the
original CMC specification of 1993. The Full CMC provides a more complete
set of function calls in order to provide for more robust message-reliant
applications.

CMC 2.0 is designed to be complementary to existing XAPIA-X/OPEN API's such
as the XMHS and XMS API.

The CMC interface is designed to allow a 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 which 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 defines the common mapping between Simple CMC and the X.400 message
store protocol.

* 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.

* XAPIA expects to define a common mapping between CMC and SMTP/MIME later
in 1995 or early in 1996.
 
 =========================================================
 From the 'New Product News' Electronic News Service on...
 AOL (Keyword = New Products) and Delphi (GO COMP PROD)
 =========================================================
 This information was processed from data provided by the
 company/author mentioned. For additional details, please
 contact them directly at the address/phone# indicated.
 Trademarks are the property of their respective owners.
 =========================================================
 All submissions for this service should be addressed to:
 BAKER ENTERPRISES,  20 Ferro Dr,  Sewell, NJ  08080  USA
 Email: rbakerpc@delphi.com  -or- RBakerPC (on AOL/Delphi)
 =========================================================
