Browse Prior Art Database

Cover Page Technique for an IBM-X.400 Gateway

IP.com Disclosure Number: IPCOM000122152D
Original Publication Date: 1991-Nov-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 128K

Publishing Venue

IBM

Related People

Gering, MF: AUTHOR [+4]

Abstract

The International Telegraph and Telephone Consultative Committee (CCITT) X.400 Recommendations for Message Handling Systems (MHS) define a world-wide standard for electronic mail interchange. To enable users of current systems based on proprietary architectures to exchange messages with X.400 compatible systems, many vendors offer some form of gateway facility which performs a bidirectional conversion between the native system protocols and data streams and those defined by X.400. An inherent limitation of protocol conversions is that they are rarely without loss. The extent of the functional degradation depends on the specific semantic and syntactic mismatches between the respective architectures and protocols.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Cover Page Technique for an IBM-X.400 Gateway

      The International Telegraph and Telephone Consultative
Committee (CCITT) X.400 Recommendations for Message Handling Systems
(MHS) define a world-wide standard for electronic mail interchange.
To enable users of current systems based on proprietary architectures
to exchange messages with X.400 compatible systems, many vendors
offer some form of gateway facility which performs a bidirectional
conversion between the native system protocols and data streams and
those defined by X.400.  An inherent limitation of protocol
conversions is that they are rarely without loss.  The extent of the
functional degradation depends on the specific semantic and syntactic
mismatches between the respective architectures and protocols.

      The present disclosure considers such a gateway solution, whose
function is to map X.400 addresses, protocols and encoded information
types to/from those supported by IBM's Document Interchange
Architecture (DIA) and SNA Distribution Services (SNADS), as
implemented by current IBM products.  It describes a "cover page"
technique for supporting various mandatory X.400 service elements
which could not otherwise be handled by protocol mapping.

      There are a number of protocol elements in incoming X.400
messages which cannot be mapped to corresponding elements in a
DIA/SNADS distribution, but for which support is mandatory in order
to conform to X.400 requirements. Fortunately, most of these service
elements are informational in nature, rather than procedural.  Thus,
the minimum requirement is that this information be presented to the
recipient end user in some reasonable manner (versus being simply
discarded by the protocol conversion process).

      An X.400 Interpersonal Message (IPM) consists of a P1
"envelope" and a P2 "content" (roughly corresponding to SNADS and
DIA, respectively).  The P1 envelope contains addressing and control
information to enable the X.400 Message Transfer System to route and
deliver the message to the recipient User Agents (UAs).  Under
certain conditions, it may be required that some of this information
be made available to the receiving end user.

      The P2 content is composed of a "header" and "body". The header
is a set of fields, or attributes, which characterize the message and
are used in the provision of IPM services.  As stated above, most of
these P2 fields are simply informational, and do not necessarily
require any processing or understanding on the part of the receiving
system beyond presentation to the end user (although more
sophisticated UAs may employ them to provide useful message
management functions).

      The P2 body is the actual data sent by the originator. It
consists of a sequence of one or more "body parts".  Each body part
is a logically independent information object, each of which may be
of a different encoded information type.  A body part may consist of
a "forwarded" IP mess...