Integrated Multimedia Message Standards

Integrated Multimedia Message Standards

Let us review some of the Integrated Multimedia MessageStandards in detail.

Vendor Independent Messaging (VIM)

VIM interface is designed to facilitate messaging between VIM. enabled electronic mail systems as well as other applications. The VIM interface makes mail and messages services available through a well defined interface.

A messaging service enables its clients to communicate with each other in a store-and-forward manner. VIM-aware applications may also use one-or-more address books.

Address  books  are  used  to  store  information  about  users,  groups,  applications,  and  so  on.  VIM

Messages:

VIM defines messaging as a stored-and-forward method of application-to-application all program-to-program data exchange. The objects transported by a messaging system are caIled messages. The message, along with the address is sent to the messaging system. The messaging system providing VIM services accept the responsibility for routing and delivering the message to the message container of the recipient.

Message Definition:

Each message has a message type. The message type defines the syntax of the message and the type of information that can be contained in the message.

A VIM message consists of message header. It may contain one or more message items. The message header consists of header attributes: recipient address, originator address, time/date prior

A message item is a block of arbitrary-sized (means any size) data of a defined type. The contents of the data block are defined by the data-item type.

The actual items in a message and its syntax and semantics are defined by the message type. The message may also contain file attachments. VIM allows the nesting of messages; means one message may be enclosed in another message.

A VIM message can be digitally signed so that we can ensure that the message 'received is without any modification during the transit.

Mail Message: It is a message of a well-defmed type that must include a message header and may include note parts, attachments, and other application-defined components. End users can see their mail messages through their mail programs.

Message Delivery: If message is delivered successfully, a delivery report is generated and send to the sender of the message if the sender requested the d~livei-y report. If a message is not delivered, a non-delivered report is sent to the sender.

A message that delivered will be in a message container will be marked as 'unread', until the recipient open and read it.

Message Container: Multiple users or applications can access one message container. Each message in a message container has a reference number associated with it for as long as the message remains stored in the message container.

VIM Services: The VIM interface provides a number of services for creating and mailing a message. Some of them are:

.:. Electronic message composition and submission.

.:. Electronic message sending and receiving.

.:. Message extraction from mail system.

.:. Address book services.

MAPI Support (Multimedia Application Programmable Interface)

MAPI provides a layer of functionality between applications and underlying messaging systems. The primary goals of MAPI are: Separate client applications from the underlying messaging services. Make basic mail enabling a standard feature for all applic·ations. Support message-reliant workgroup applications.

MAPI Architecture: MAPI Architecture provides two perspectives (i) A client API

(ii) A service provider interface. The Client API provides the link between the client applications andMAPI. The service provider interface links MAPI to the messaging system.

The two interfaces combine to provide an open architecture such that any messaging application can use any messaging service that has a MAPI driver. MAPI drivers are provided by microsoft or third party developers.

Telephony API (TAPI)

TAPI standard has been defined by Microsoft and Intel. The telephone can be used for reading e-mail as well as for entering e-mail messages remotely.

X 400 Message Handling Service

The CCITT X 400 series recommendations define the OSI message handling system, (MHS).

The MHS describes a functional model that provides end users the ability t6 send and receive electronic messages. In the as I, an end user is an originator. He composes and sends messages.

Receiver is the one who receives messages. A User Agent (UA) is an entity that provides the end user function for composing and sending messages and for delivering messages. Most user agent implementations provide storage of mail, sorting directories, and forwarding.

A Message Transfer Agent (MTA) forwards messages from the originator UA to another MT A. A number of MTAs are combine to form Message transfer System (MTS).

The MTAs in an MTS provide message routing services at intermediate nodes in a WAN.

Figure below shows the overall X 400 architecture and the relationships between the components.

X·500 Directory System Standards

The X·500 is the joint International Standard Organization

CCITT standard for a distributed directory system that lets users store information such as addresses and databases on a local server and easily query, exchange, and update that information in an interoperable networked environment.

The X 500 directory structure is described in the CCITT standard known as Data Communications Network Directory, Recommendations X·500-X·521, 1988.

5 X·500 Directory System Architecture

Directory System Agents carryout updates and management operations. X ·500 defines a structured information model, an objectoriented model and database schema.

The X ·500 architecture is based on a number of models, as follow'>:

The information model: It specifies the contents of directory entries, how they are identified, and the way in which they are organized to form the directory information base.

The Directory model: It describes the directory and its users, the functional model for directory operation, and the organization of the directory. .

The security model: It specifies the way in which the contents of the directory are protected from unauthorised access and authentication methods for updates.

The X 500 directory system is designed to be capable of spanning national and corporate boundaries.

X 500 Directory System Components: All information in an X 500 database is organized as entries in the Directory-Information Base(DlB). The directory system provides agents to manipulate entries in the DIB.

X 500 directories consist of the following basic components:

1.     Diretory Information Base (DIB); The DIB contains information about users, applications, resources and the configuration of the directory that enables servers to locate one another.

2.     Directory User Agents (DUA): A DUA issues inquiry and update requests, and accesses directory information through the directory access protocol.

3.Directory Service Agents (DSAs): DSAs cooperate with one another to resolve user requests over a distributed network. They interact through a specialized protocol called a directory system protocol.