Document Converter
Breaking the "information interchange barrier"
- Converts representation of character sets, binary files and documents within messages
- Typical applications include:
- conversion of document formats
- encryption
- virus checking (option available)
- migration to new FTBP standards
- Up to 32 different conversions configurable for individual users, gateways and MTAs
- Built-in and user-defined conversions
- Able to construct and insert custom attachments
- Uses Route400 Document Conversion Accelerator for Windows-based conversions
- Available as an option for most Route400 Message Servers
The Route400 Document Converter is an optional component for a Route400
Message Server (MTA). Its function is to determine whether
the structure, format and/or coding of a message, or parts of a message, need to be
converted to another form before delivery to a user or gateway, or transfer to a
different messaging system. It then performs any required conversions itself, or
causes such conversions to be carried out by other software applications under its
control.
Message conversion allows the representation of information transferred within
messages between senders and recipients to be changed in such a way that both
parties are completely unaware of any information format incompatibilities that
may exist between them. This technological capability eliminates the so-called
"information interchange barrier" in messaging systems.
In many cases the conversions are carried out within the Message Server itself.
However, it is sometimes impractical to do this (for example when a UNIX server
needs to perform a conversion using a Windows application). In such cases, the
Route400 Document Conversion Accelerator (DCA)
can be used in conjunction with the Document Converter.
The Route400 Document Converter provides the basis for an Anti-virus Messaging
Firewall when used in conjunction with the Route400
Virus Scanner.
Background
Within messaging systems, information interchange incompatibilities can arise in a number of ways that can readily be dealt with using the Document Converter, for example:
- The sender may use a different word-processor or spreadsheet application from the recipient
- The recipient may be attached to an X.400 messaging system whose software conforms to an earlier or later X.400 specification than that of the sender
- The recipient may not be another X.400 User Agent, but a fax system or fax-based application
- The recipient may only be reachable via the Internet and have restricted text capabilities
- The sender may have used an extended character set that provides richer text features than are available to the recipient
- The sender may wish to transmit a named file within the message. Under the 1984/1988 X.400 specifications there is no standardised method of indicating file specific information and a number of different (ad hoc) representations have been adopted. The standard mechanism (File Transfer Body Part) defined in X.400 (1992) is increasingly being deployed, therefore conversions between all these approaches are required
Architects and managers of large-scale multi-vendor messaging systems will find the Document Converter an essential tool in dealing with the system integration issues described above. In addition, when considering user convenience for information interchange within the messaging network, the Document Converter product is particularly valuable where:
- Users and message-enabled applications require to send messages to both e-mail accessible recipients (via X.400, Internet and proprietary systems) and fax recipients with application-specific attachments (e.g. MS Word documents, PowerPoint graphics or Lotus 1-2-3 spreadsheets) in a single operation
- Organisations do not wish to burden their message users with any difficulties when receiving messages from senders using incompatible messaging systems, applications, character sets, or system platforms
- Organisations need to have plain-text communication with third parties (via X.400, Internet, proprietary systems, fax or telex) but do not wish to be constrained internally by such limitations
Overview
- The conversion system supports up to 32 conversion processors providing both built-in and user-defined conversions
- The built-in conversions are available in order to convert text body parts to specific character encodings, to convert binary body parts (including file specific information) to particular representations and to convert an entire message contents from the X.400 1988 standard form to the 1984 version
- Other conversions are user-defined and are performed by configured software applications, either within the Document Converter server or through the agency of a DCA in another machine. They take body parts of defined types and convert them to new representations
- The conversion system determines which, if any, of the available conversions need to be applied for a particular destination or source. Such conversions may be required for specific (or all) users, for gateways and for links to differing MTAs (for example those within a backbone network and those within other messaging services)
- Data Types are defined in order to recognise the content and purpose of message body parts that might then require conversion to a new form. Some data types are self-evident and built-in (e.g. "IA5 Text", "General Text", "Message Content Type 22"). Others, concerned with binary body parts, for which several different representations or encodings might exist, have to be configured (e.g. The data type "MS Word document" might be recognised as a file with extension ".doc", as an External body part with a defined Object Identifier, or as a specific File Transfer Body Part)
- Built in and user-defined converters are configured to be applied to one or more Data Types. Built-in conversions always produce a result of a pre-determined type. User-defined conversions can determine the type of result that is produced
- A user-defined converter may also be used to insert a fixed or constructed body part into a message. This might be used to insert a standard disclaimer or to warn recipients that the source of a message is considered insecure
- Finally, for all sources and destinations (users, gateways and MTAs) a list of desired conversions is specified
The Document Converter operates as follows:
- A Route400 Message Server (MTA) with the Document Converter option analyses each message passing through it and determines the Data Types of all body parts
- The MTA then determines, from the configured information, which conversions are possible according to the types present
- Finally, the MTA applies, for each of the message sources or destinations independently, any of the possible conversion functions that are appropriate to that address. Depending on the conversion, the operation will be carried out using a function within the Document Converter itself, by executing a configured software application within the message server or by passing the message to a Route400 Document Conversion Accelerator for conversion on another platform
Data-type Analyser
- Determines the character set encoding used in text body-parts: General Text (ISO/IEC 10021:1990 and X.420:1992), ISO6937 (MOTIS 1986), Teletex (X.420 from 1984 onwards) and International Alphabet 5 (IA5) are recognised
- Determines the particular X.400 structure used to represent binary body-parts: Undefined, Undefined with text Manifest, Route400-specific DataFile, External and File Transfer are recognised
- Determines the object identifier of X.400 (1988) External body-parts, taking account of optional parameters, to identify a specific data type
- Searches for file-type identification, where present, in binary body-parts (e.g. .doc, .bmp, .xls file extensions), to identify a specific data type
- Identifies possible conversions based on configured Data Type information
Address Analyser
- Determines all source and destination addresses of every message processed
- For each address, identifies the requested conversions that are configured
- For any address requiring a conversion that has been identified as allowed for any body-parts in the message, performs the configured conversion action on the relevant body-parts
- Specific conversions can be configured for any entities such as users, gateways to the Internet or proprietary mail systems, and MTAs serving other messaging domains
- Default conversion configuration allows a single set of conversions to be applicable to all users on a system
- By use of a suitable message routing plan and configuration of conversion, it is usually possible to carry out conversions in the message server nearest to the message destination
Built-in Conversion
- Ten internal conversion algorithms are built into the Document Converter to translate plain text from one recognised and supported encoding to another, to convert between differently defined binary body-part representations and to convert message contents to make them X.400 (1984) compatible
- The 10 built-in conversions are:
- From any text encoding to General Text
- From any text encoding to ISO6937
- From any text encoding to Teletex
- From any text encoding to IA5
- From any binary representation to Undefined (Bilaterally defined/BP14). This eliminates all identifiers, descriptors and attributes not recognisable by non-Route400 X.400 (1984) systems
- From any binary representation to Undefined, but also adding a new text body part as a manifest containing a list of all the body parts in the message with their properties
- From any binary representation to External
- From any binary representation to File Transfer
- From any binary representation to Route400-specific DataFile
- Content conversion from X.400 1988 to 1984 compatibility (Content type 22 to type 2), usually performed in combination with a 1984 downgrade for the message envelope
User-defined Conversions
- User-defined conversions can provide almost unlimited scope for general purpose operations on message body-parts
- These conversions can be performed by user specific application programs or third-party software packages
- Conversions may be specific to a body part type or generic to all types
- Additional "per-message" conversion may be invoked following any body part conversion, allowing new body parts to be constructed and inserted
- A command line is configured for each user-defined conversion, that specifies the command to be executed, defines the source and result files for conversion and determines how loss of information during conversion is handled
- A utility program, "bppack", is provided to deal with all aspects of ASN.1 encoding of converted body-parts for the integration of user defined and third party applications
- The conversion may be configured to be executed as a command within the message server itself or to be passed over to an associated DCA, if appropriate
- User originated programs can be used for a wide variety of purposes including, for example, body part encryption
- Third-party applications can easily be incorporated, for example to perform virus checking
- For document conversion, third-party format conversion packages such as Word for Word (Mastersoft) and KEYpack (FTP Software) can be used where these are available on the same platform as the Document Converter
- For document conversions that need to run in a Windows 3.1 environment, the Document Converter works in conjunction with an associated DCA
- For Windows application documents requiring transmission via the Route400 Fax Access Unit, conversion to Group 3 fax format can generally be performed using an associated DCA
Technical Requirements
- The Document Converter option is available for Route400 Message Servers on all UNIX, OS/2, Windows 3.1, 3.11, 95 and NT platforms
- All the above Message Servers with Document Converter can make use of a Route400 Document Conversion Accelerator, running on an associated Windows platform
- With Windows 3.1 as the Message Server platform, user-defined conversions must be supported on a separate server by use of the DCA functionality
- Any number of Route400 MTAs in a messaging network may be licensed to run the Document Converter
|