Distributed Multimedia Survey: Standards: (Part-2)

CCITT/ISO standards

• F.700
• G.711
• G.721
• G.722
• G.725
• H.221
• H.242
• H.261
• H.320
• HyTime
• IIF
• JBIG
• JPEG
• MHEG
• MPEG
• ODA
• T.80
• X.400
• G.723
• G.726
• G.727
• G.728
• G.764
• G.765
• H.200
• H.241
• H.243
• T.120

Name: F.700

Reference: F.711 - F740

Version: 1992

Sponsoring body: CCITT

Status: To be ratified at March 1993 CCITT Plenary.

Brief description: Audiographic, Videotelephony and Videoconference service standards.

Detailed description: The individual recommendations are as follows:

F.711 Audiographic Conference Teleservice for ISDN

F.720 Videotelephony Services General

F.721 Videotelephony Teleservices for ISDN

F.722 Videotelephony Services General

F.730 Videoconference Service General

F.732 Broadband Videoconference Services

F.740 Audiovisual Interactive Services (AVIS)

Products:

Further information:

Date of entry: 19 January 1993

Name: G.711

Reference: G.711

Version: B (1988)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: Pulse Code Modulation (PCM) of voice frequencies

Detailed description: 64 kbit/s 8kHz 8-bit PCM audio encoding.

Products:

Further information:

Date of entry: 15 December 1992

Name: G.721

Reference: G.721

Version: B (1988)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: 32 kbit/s adaptive differential pulse code modulation (ADPCM) for audio encoding.

Detailed description:

Products:

Further information:

Date of entry: 15 December 1992

Name: G.722

Reference: G.722

Version: B (1988)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: 7 KHz audio encoding within 64 kbit/s

Detailed description:

Products:

Further information:

Date of entry: 15 December 1992

Name: G.725

Reference: G.725

Version: B (1988)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: System Aspects of the use of 7 kHz audio codec within 64 kbit/s

Detailed description:

Products:

Further information:

Date of entry: 15 December 1992

Name: H.221

Reference: H.221

Version: R1 (12/90)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices.

Detailed description: Defines a frame structure for audiovisual teleservices in single or multiple B or H0 channels or a single H11 or H12 channel which makes the best use of the characteristics and properties of the audio and video encoding algorithms, of the transmission frame structure and of the existing recommendations. It offers several advantages:

It takes into account Recommendations G.704, X.301/I.461, etc. It may allow the use of existing hardware and software.

It is simple, economic and flexible. It may be implemented on a single microprocessor using well known hardware principles.

It is a synchronous procedure. The exact time of a configuration change is the same in the transmitter and the receiver.

It needs no return link for audiovisual signal transmission, since a configuration is signalled by repeatedly transmitted codewords.

Very secure in case of transmission errors, since the code controlling the multiplex is protected by double-error correcting code.

Allows synchronisation of multiple 64 kbit/s or 384 kbit/s connections and the control of the multiplexing of audio, video, data and other signals within the synchronised multiconnection structure in the case of multimedia services such as videoconferencing.

It can be used in multipoint configurations, where no dialogue is needed to negotiate the use of a data channel.

It provides a variety of data bit-rates (from 300 b/s up to almost 2 Mb/s) to the user.

Closely related to H.261 & H.242. Supersedes H.220

Products: Codecs from BT, GPT, Picturetel, Videotel & others

Further information:

Date of entry: 10 December 1992

Name: H.242

Reference: H.242

Version: N (12/90)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: Audiovisual communication using digital channels up to 2 Mbit/s

Detailed description: Recommendation H.242 should be associated with Recommendations G.725, H.221 and H.230.

A number of applications utilising narrow (3 kHz) and wideband (7 kHz) speech together with video and/or data have been identified, including high quality telephony, audio and videoconferencing (with or without various kinds of telematic aids), audiographic conferencing and so on. More applications will undoubtedly emerge in the future.

To provide these services, a scheme is recommended in which a channel accommodates speech, and optionally video and/or data at several rates, in a number of different modes. Signalling procedures are required to establish a compatible mode upon call set-up, to switch between modes during a call and to allow for call transfer.

Some services will require only a single channel, which could according to the procedures in Recommendation H.242 be B (64 kbit/s), H0 (384 kbit/s), H11 (1536 kbit/s) or H12 (1920 kbit/s). Other services will require the establishment of two or more connections providing B or H0 channels: in such cases the first established is called hereafter the initial channel while the others are called additional channels.

All audio and audiovisual terminals using G.722 audio coding and/or G.711 speech coding or other standardised audio codings at lower bit rates should be compatible to permit connection between any two terminals. This implied that a common mode of operation has to be established for the call. The initial mode might be the only one used during a call or, alternatively, switching to another mode can occur as needed depending on the capabilities of the terminals. Thus, for these terminals an in-channel procedure for dynamic mode switching is required.

Recommendation H.242 develops these considerations and describes recommended in-channel procedures.

Products: Codecs from BT, GPT, Picturetel, Videotel & others.

Further information: Closely related to H.261 & H.221. Supersedes H.220

Date of entry: 25 November 1992

Name: H.261

Reference: H.261

Version: R1 (12/90)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: Video Codec for Audiovisual Services at p x 64 kbit/s

Detailed description: Recommendation H.261 describes the video coding and decoding methods for the moving picture component of audiovisual services at the rate of p x 64 kbit/s, where p is in the range 1 to 30. It describes the video source coder, the video multiplex coder and the transmission coder.

This standard is intended for carrying video over ISDN - in particular for face-to-face videophone applications and for videoconferencing. Videophone is less demanding of image quality, and can be achieved for p=1 or 2. For videoconferencing applications (where there are more than one person in the field of view) higher picture quality is required and p must be at least 6.

H.261 defines two picture formats: CIF (Common Intermediate Format) has 288 lines by 360 pixels/line of luminance information and 144 x 180 of chrominance information; and QCIF (Quarter Common Intermediate Format) which is 144 lines by 180 pixels/line of luminance and 72 x 90 of chrominance. The choice of CIF or QCIF depends on available channel capacity - eg QCIF is normally used if p<3.

The actual encoding algorithm is similar to (but incompatible with) that of MPEG. Another difference is that H.261 needs substantially less CPU power for real-time encoding than MPEG. The algorithm includes a mechanism which optimises bandwidth usage by trading picture quality against motion, so that a quickly-changing picture will have a lower quality than a relatively static picture. H.261 used in this way is thus a constant-bit-rate encoding rather than a constant-quality, variable-bit-rate encoding.

Products: H.261 codecs have been implemented in VLSI and are now built in to commercially available codec equipment.

Further information: Document available on line on:

src.doc.ic.ac.uk:/doc/ccitt-standards/ccitt/1992/h

See also "Overview of the p*64 kbit/s Video Coding Standard", M. Liou, Communications of the ACM, April 1991.

Date of entry: 15 December 1992

Name: H.320

Reference: H.320

Version: N (12/90)

Sponsoring body: CCITT

Status: Recommendation currently in force

Brief description: Narrow Band Visual Telephone systems and terminal equipment

Detailed description: Recommendation H.320 covers the technical requirements for narrow-band visual telephone services defined in H.200/AV.120-Series Recommendations, where channel rates do not exceed 1920 kbit/s.

Note - It is anticipated that Recommendation H.320 will be extended to a number of Recommendations each of which would cover a single videoconferencing or videophone service (narrow-band, broadband, etc.). However, large parts of these Recommendations would have identical wording, while in the points of divergence the actual choices between alternatives have not yet been made; for the time being, therefore, it is convenient to treat all the text in a single Recommendation.

The service requirements for visual telephone services are presented in Recommendation H.200/AV.120-Series; video and audio coding systems and other technical set aspects common to audiovisual services are covered in other Recommendations in the H.200/AV.200-Series.

Products:

Further information:

Date of entry: 15 December 1992

Name: HyTime

Reference: ISO 10744

Version: 1992

Sponsoring body: ISO (JTC1/SC18/WG8)

Status: International Standard

Brief description: SGML-based standard for hypermedia documents.

Detailed description: HyTime (Hypermedia/Time-Based Structuring Language) is a standardised infrastructure for the representation of integrated, open hypermedia documents. It was developed principally by ANSI committee X3V1.8M, and was subsequently adopted by ISO.

The HyTime standard specifies how certain concepts common to all hypermedia documents can be represented using SGML. These concepts include:

association of objects within documents with hyperlinks

Placement and interrelation of objects in space and time

logical structure of the document

inclusion of non-textual data in the document

An "object" in HyTime is part of a document, and is unrestricted in form - it may be video, audio, text, a program, graphics, etc.

SGML (Standard Generalized Markup Language: ISO 8879) is a metalanguage which is used to specify document markup schemes called Document Type Definitions (DTDs). HyTime is not itself a DTD, but provides constructs and guidelines for making DTDs for describing Hypermedia documents. For instance, the Standard Music Description Language (SMDL: ISO/IEC Committee Draft 10743) defines a DTD which is an application of HyTime.

HyTime consists of six modules:

Base module. This provides facilities required by other modules, including "xenoforms" for specifying application-defined expressions, and identification of policies for coping with changes to a document - "activity tracking".

Finite Coordinate Space module. This allows for an object to be scheduled in time and/or space (which HyTime treats equivalently) within a bounding box called an "event".

Location Address module. This specifies how to identify locations of document objects by name, by coordinate location, or by semantic construct.

Hyperlinks module. Five different types of hyperlink are provided for.

Event Projection module. This specifies how events in a source Finite Coordinate Space (FCS) are to be mapped onto a target FCS.

Object Modification module. This allows for individual objects to be modified before rendition, in an object-specific way.

Products: A public-domain SGML parser (ARC SGML) is available. TechnoTeacher (address below) are producing a HyTime engine. Sema Group are also understood to be developing a HyTime product.

Further information:

There are FTP sites at:

ftp://ftp.ifi.uio.no/SIGhyper

mailer.cc.fsu.edu:pub/sgml

The following articles are useful:

"The HyTime Hypermedia/Time-based Document Structuring Language", S. Newcomb, N. Kipp and V. Newton, Communications of the ACM, p67, November 1991.

"Emerging Hypermedia Standards" B. Markey, Multimedia for Now and the Future (Usenix Conference Proceedings), p59, June 1991.

See also newsgroup comp.text.sgml

Date of entry: 20 January 1993

Name: IIF

Reference: ISO 12087-3

Version:

Sponsoring body: ISO (JTC1/SC24/WG7)

Status: Draft International Standard

Brief description: Image Interchange Facility

Detailed description: The Image Interchnage Facility (IIF) is part of the first International Image Processing and Interchange Standard (IPI), which is under elaboration by ISO/IEC JTC1/SC24. It comprises both a data format definition and a gateway functional specification.

The main component of the IIF is the definition of a data format for exchanging arbitrarily structured image data. The IIF defines a format that can be used across application boundaries and that can easily be integrated into international communication services. Besides the definition of a file format, there are definitions of parsers, generators, and format converters to enhance open image communication.

The IIF approach clearly distinguishes between the image structure (a data type-oriented description of the image), image attributes (expressing colourimetric and geometric semantics), the sequential data organisation (managing data partitioning and periodicity organisation), and the data encoding/compression. The syntax specification and the data encoding of syntax entities use ASN.1 and the Basic Encoding Rules respectively. For the compressed representation, the following standards are referenced: JBIG, facsimile Group 3 and 4, JPEG, and MPEG.

Besides the data format specification, the IIF also encompasses functionality for generating and parsing image data, for compressing and decompressing, and for the exchange of image data between the application program, the Programmer's Imaging Kernel System (PIKS), which is Part 2 of the IPI standard, and storage/communication devices. This functionality is located in the so-called IIF Gateway. The IIF gateway controls the import and export of image data to and from applications, as well as to and from the PIKS.

The IIF may serve as a future image content architecture of the Open Document Architecture (ODA).

Work is going on to develop a (multimedia) electronic mail application on top of X.400, using IIF.

Products:

Further information: "ISO/IEC's image interchange format", C. Blum and G. R. Hofmann, SPIE Proceedings Vol. 1659, San Jose, p130 February 1992.

IIF editor:

Date of entry: 15 December 1992

Name: JBIG

Reference:

Version:

Sponsoring body: ISO

Status:

Brief description: Binary image encoding standard

Detailed description: JBIG is a lossless compression algorithm for binary (one bit/pixel) images. The intent of JBIG is to replace the current, less effective group 3 and 4 fax algorithms.

JBIG models the redundancy in the image as the correlations of the pixel currently being coded with a set of nearby pixels called the template. An example template might be the two pixels preceding this one on the same line, and the five pixels centred above this pixel on the previous line. Note that this choice only involves pixels that have already been seen from a scanner.

The current pixel is then arithmetically coded based on the eight-bit (including the pixel being coded) state so formed. So there are (in this case) 256 contexts to be coded. The arithmetic coder and probability estimator for the contexts are actually IBM's (patented) Q-coder. The Q-coder uses low precision, rapidly adaptable (those two are related) probability estimation combined with a multiply-less arithmetic coder. The probability estimation is intimately tied to the interval calculations necessary for the arithmetic coding. JBIG actually goes beyond this and has adaptive templates.

You can use JBIG on grey-scale or even colour images by simply applying the algorithm one bit-plane at a time. You would want to recode the grey or colour levels first though, so that adjacent levels differ in only one bit (called Gray-coding). This works well up to about six bits per pixel, beyond which JPEG's lossless mode works better. You need to use the Q-coder with JPEG also to get this performance.

Products:

Further information: There is a description of the Q-coder as well as the ancestor of JBIG in the November 1988 issue of the IBM Journal of Research and Development. This is a comprehensive set of five articles that describe the Q-coder and a bi-level image coder that uses the Q-coder.

Date of entry: 3 December 1992

Name: JPEG

Reference:

Version:

Sponsoring body: CCITT | ISO (JTC1/SC2/WG10)

Status: Committee Draft

Brief description: Compression Standard for continuous-tone still images

Detailed description: JPEG is a standardised image compression mechanism. JPEG stands for Joint Photographic Experts Group, the original name of the committee that wrote the standard. JPEG is designed for compressing either full-colour (24 bit) or gray-scale digital images of "natural" (real-world) scenes. JPEG does not handle black-and-white (one bit/pixel) images, nor does it handle motion picture compression.

JPEG is "lossy", meaning that the image you get out of decompression isn't quite identical to what you originally put in. The algorithm achieves much of its compression by exploiting known limitation of the human eye, notably the fact that small colour details aren't perceived as well as small details of light-and-dark. Thus, JPEG is intended for compressing images that will be looked at by humans. If you plan to machine-analyse your images, the small errors introduced by JPEG may well be a problem for you, even if they are invisible to the eye.

A useful property of JPEG is that the degree of lossiness can be varied by adjusting compression parameters. This means that the image maker can trade off file size against output image quality. You can make extremely small files if you don't mind poor quality; this is useful for indexing image archives, making thumbnail views or icons, etc etc. Conversely, if you aren't happy with the output quality at the default compression setting, you can jack up the quality until you are satisfied, and accept lesser compression.

Although it handles colour files well, it is limited in handling black-and-white and files with sharp edges (files come out very large). The processing costs, even on up-to-date computers, is also high.

Products: Many products now use this algorithm. There is free JPEG source code available from the Independent JPEG group, at many FTP sites.

Further information: Independent JPEG group at jpeg-info@uunet.uu.net. JPEG software and file specifications are available from several FTP sites, including ftp.uu.net:/graphics/jpeg.

See the article on JPEG in Communications of the ACM, April 1991. The article is also available at the above FTP site.

Date of entry: 21 December 1992

Name: MHEG

Reference: T.170 | ISO

Version:

Sponsoring body: CCITT | ISO (JTC1/SC2/WG12)

Status: Committee Draft

Brief description: Standard for hypermedia document representation.

Detailed description: MHEG stands for the Multimedia and Hypermedia Information Coding Experts Group. This group is developing a standard "Coded Representation of Multimedia and Hypermedia Information", commonly called MHEG. The standard is likely to be published in two parts - part one being object representations and part two being hyperlinking.

MHEG is suited to interactive hypermedia applications such as on-line textbooks and encyclopaedia. It is also suited for many of the interactive multimedia applications currently available (in platform-specific form) on CD-ROM. MHEG could for instance be used as the data structuring standard for a future home entertainment interactive multimedia appliance.

To address such markets, MHEG represents objects in a non-revisable form, and is therefore unsuitable as an input format for hypermedia authoring applications: its place is perhaps more as an output format for such tools. MHEG is thus not a multimedia document processing format - instead it provides rules for the structure of multimedia objects which permits the objects to be represented in a convenient form (eg video objects could be MPEG-encoded). It uses ASN.1 as a base syntax to represent object structure, but allows for the use of other syntax notations - an SGML syntax is also specified.

MHEG objects (which may be textual information, graphics, video, audio, etc) may be of four types:

Input object (ie a user control such as a button or menu)

Output object (eg graphics, audio visual display, text)

Interactive object (a "composite" object containing both input and output objects)

Hyperobject ( a "composite" object containing both input and output objects, with links between them).

MHEG supports various synchronisation modes, for presenting output objects in these relationships.

It will be some time before MHEG reaches IS status. Its future will then depend on market requirements and trends.

Products: None as yet, but British Telecom have developed a demonstration application called MADE - see the Research section of the survey.

Further information: See "Emerging Hypermedia Standards" B. Markey, Multimedia for Now and the Future (Usenix Conference Proceedings) June 1991.

"Standardizing Hypermedia Information Objects", F. Kretz and F. Colaïtis, IEEE Communications Magazine, p60, May 1992.

Date of entry: 30 November 1992

Name: MPEG

Reference: ISO 11172

Version: MPEG I

Sponsoring body: ISO (JTC1/SC2/WG11)

Status: Committee Draft

Brief description: Standard for compressed video and audio

Detailed description: MPEG (Moving Pictures Expert Group) is the name of the ISO committee which is working on digital colour video and audio compression, and by extension the name of the standard they have produced.

MPEG defines a bit-stream representation for synchronised digital video and audio, compressed to fit into a bandwidth of 1.5 Mbit/sec. This corresponds to the data retrieval speed from CD ROM and DAT, and a major application of MPEG is the storage of audio visual information on this media. MPEG is also gaining ground on the Internet as an interchange standard for video clips.

The MPEG standard is the three parts - video encoding, audio encoding, and "systems" which includes information about the synchronisation of the audio and video streams. The video stream takes about 1.15 Mbit/s, and the remaining bandwidth is used by the audio and system data streams.

MPEG video encoding starts with a fairly low-resolution (352 x 240 pixels x 30 frames/s in the US; 352 x 288 x 25 frames/s in Europe) video picture. RGB pixel information is converted to chrominance/luminance and a complex, lossy compression algorithm is applied. The algorithm takes the time axis as well as spatial axes into account, so a good compression ration is achieved when the picture is relatively unchanging (and vice versa). The compressed data contains three types of frames: I (intra) frames are coded as still images; P (predicted) frames are deltas from the most recent past I or P frame; and B (bidirectional) frames are interpolations between I and P frames. I frames are sent once every 10 or 12 frames. Reconstructing a B frame for display requires the preceding and following I and/or P frames, so these are sent out of time-order.

Substantial computing power is required to encode MPEG data in real time - perhaps several hundred MIPS to encode 25 frames/second. Decoding is not quite so demanding.

The quality of MPEG-encoded video has been compared to that of a VHS video recording.

MPEG II is under development. MPEG II is designed to offer higher quality at a bandwidth of between 4 and 10 Mbit/s. This is too fast for playback from CD using today's technology.

Products: Phillips have developed an MPEG decoder chip, which will go into their CD-I product range.

Xing Technology Corp (California, USA) offer video capture and encode/decode hardware and software for PCs which uses MPEG and JPEG.

Ingenieurbuero Gatz und Hartmann (Berlin, Germany) offer a PC video input board and an off-line MPEG encoding program. Maximum video clip length is 20s (limited by 32Mb of expanded memory in the PC).

Optibase Inc (California, USA) have board-level products for PCs, called MPG-1000 (codec), MPG-2000 and MPG-2100 (playback only)

There are freeware MPEG software decoder/players for DOS, MS Windows and X windows - see FTP sites below for details.

Further information: A FAQ for MPEG is available from Frank Gadegast (phade@cs.tu-berlin.de).

Anonymous FTP sites are:

phoenix.oulu.fi:pub/mpeg

toe.cs.berkley.edu:pub/multimedia/mpeg

A useful description of MPEG is "MPEG: A Video Compression Standard for Multimedia Applications", D. Le Gall, Communications of the ACM, April 1991.

Date of entry: 30 November 1992

Name: ODA (Office [Open] Document Architecture and Interchange Format)

Reference: T.410 | ISO 8613 (Parts 1 to 8)

Version: 1989

Sponsoring body: CCITT | ISO (JTC1/SC18/WG3)

Status: Recommendation currently in force | International Standard

Brief description: ODA standard is concerned with the open interchange of documents

Detailed description: Note: the current version of ISO 8613 names the standard as Office Document Architecture and Interchange Format, while CCITT recommendations refer to "Open" rather than "Office".

The ODA standards are part of a group of related standards concerned with documents, their content and how they may be conveyed between systems. SGML (Standard Generalized Markup Language) and various related standards are other members of this group.

Through the standards, a wide range of documents, from simple text-only documents such as office memoranda and letters, to complex documents such as technical reports may be encoded. These complex documents may contain text, raster graphics, computer graphics and may well require complex layout specifications.

The ODA standards support a very wide range of features and tend to be abstract in nature, hence industry experts have clarified the concept by defining Document Application Profiles (DAPs). These subsets provide support for document interchange between similar systems, which have a more restricted range of features. These DAPs will be published as ISO standards known as International Standardised Profiles (ISPs).

The current target for ODA implementors is seen as the open interchange of mixed-content 'word processor' documents. The future for ODA is not as limited as this might suggest, as a number of major suppliers are known to have products under development. However, strong support for SGML and SDIF (SGML Data Interchange Format) is lacking, reflecting the fact that few SGML suppliers are associated with OSI.

Some history:

Jun 1989 ODA standards published.

Mar 1991 Formation of ODA Consortium to sponsor an ODA toolkit. Members are Bull, DEC, IBM, ICL, Siemens and Unisys.

Jun 1991 Several addenda and more than 20 technical corrigenda now approved. Will be published in 1992 as revised version of standards.

Jun 1991 Drafts for "HyperODA" (extensions to ODA to support hypermedia applications) and API to support document manipulation functions for use in interactive applications.

Oct 1991 New draft for "HyperODA" was produced. New part of standard was discussed for audio content. Group dealing with conformance testing considered ballot comments on TR 10183-Technical Report on ISO 8613 Implementation Testing.

Jan 1992 EWOS ODA expert group meet to discuss ISPs and ODAs relationship with other standards (CGM, raster graphics standards and EDI)

May 1992 SC18 Plenary deals with:- CCITT collaborative work, SGML/ODA interworking and imaging.

July 1992 EWOS SGML/ODA convergence team reports.

A development programme is underway which will result in major enhancements to ODA being agreed in 1992/3. These being progressed by full collaboration between ISO/IEC and CCITT and will extend both the content (audio, spreadsheets, colour, business graphics, specialist notations) and structural features (annotations, hypermedia support, complex tabular layout, document access and manipulation support, revision accountancy) of ODA.

Products: ODA Consortium has announced a set of APIs that will form the foundation of the ODA toolkit. Products at varying levels of implementation are available (or planned) from: British Telecom, Bull HN, DEC, IBM, Olivetti, Rank Xerox, Sema Group, Sequent, Siemens and Unisys.

Further information: Contact ODA Consortium on +32 2 774 9623

Date of entry: 18 December 1992

Name: T.80

Reference: T.80 to T.83

Version: N (09/92)

Sponsoring body: CCITT

Status: Recommendations currently in force

Brief description:

Detailed description: The following standards are all related. The titles suggest that they may be the CCITT versions to the ISO JBIG/JPEG documents.

T.80 Common components for image compression and communication - basic principles.

T.81 Digital compression and encoding of continuous tone still images.

T.82 Progressive compression techniques for bi-level images.

T.83 Compliance testing.

Products:

Further information:

Date of entry: 15 December 1992

Name: X.400

Reference: X.400 | ISO 10021 (Parts 1-7)

Version: CCITT-1984,1988,1992 | ISO/IEC-1990

Sponsoring body: CCITT | ISO

Status: Recommendation currently in force | International Standard

Brief description: Standard for the exchange of multimedia messages by store-and-forward transfer.

Description: The aim of the X.400 standards is to provide an international service for the exchange of electronic messages without restriction on the types of encoded information conveyed.

Work on X.400 began in 1980 within CCITT and resulted in the publication of the 1984 Recommendations, which still forms the basis of many of the products available today. Since then CCITT formed a collaborative partnership with ISO for the further development of the technology and published technically aligned text in 1988 (1990 in ISO) for the first major revision of X.400.

The 1988 version of the standards rectified many of the serious deficiencies of the 1984 version and introduced a variety of significant new services (including security, distribution list management, and the Message Store). Versions published since 1988 contain minor enhancements and bug fixes, but are firmly based on the 1988 version.

Message handling technology is complex; as well as the sheer technical difficulties involved, as a global service it has had to take account of political, commercial, legal, and historical realities. Some issues which are dependent on national telecommunications regulation are not covered by the International Standards and are addressed by national standards.

The relatively poor penetration of X.400 messaging has been caused by a variety of factors. The heavy investment in developing 1984 products has lead to considerable resistance to change, regardless that global interconnectivity is severely constrained in 1984 products, and that 1984-1988 interworking degrades the quality of service offered. Paradoxically it is the attempt to recoup the investment in 1984 products which is impeding the introduction of 1988 products that are essential for a highly functional global messaging service.

X.400 makes a clear distinction between message envelope, which controls the message transfer process, and message content, which is passed transparently from originator to recipient. Hence any type of encoded information may be exchanged without loss or corruption. The most common content-type in use is the Interpersonal-messaging content-type; this format divides content into two parts: heading and body. Heading fields (with labels such as 'from', 'to', and 'subject') convey standard items of information. The message body consists of one or more body parts, each of which may contain a different type of encoded information.

A number of body part types are defined as 'basic' in X.400: IA5Text, Teletex, Voice, G3Facsimile, G4Class1, Videotex, Message, FileTransfer. In addition to these, the ExternallyDefined body part type allows any identified data format to be conveyed, such as word processing and spreadsheet formats. A format is identified by the assignment of a globally unique Object Identifier. Commercial organisations can acquire Object Identifiers at nominal cost from their national standards organisations. Alternatively, the FileTransfer body part type may be used for the transfer of structured and unstructured data.

X.400 has two further features which make it especially suitable for the conveyance of multimedia information. Firstly, the use of ASN.1, which guarantees data transparency and offers a choice of encodings, including a space-optimised "packed encoding". Secondly, the use of the Reliable Transfer Application Service Element provides a very tolerant data transfer mechanism with recovery from connection failure. This is especially important for multimedia messages which are typically large.

There are several work items at various stages of development.

Draft International Standardised Profiles for X.400 have been published and are under ballot. These are more mature than the corresponding draft European Prestandards.

Work on Message Store extensions is currently on PDAM ballot and should be issued for DAM ballot in March 1993.

Work on MHS Management covers a number of topics; most are still at the stage of working drafts.

MHS Routing is progressing slowly, and will require a further round of development before it is sufficiently mature for balloting.

Group communication is currently stalled, mainly due to lack of manpower. However Japan is very interested in the work so rapid progress is possible if Japanese contributors appear.

Products: Many suppliers offer X.400 products, and there have been a number of recent announcements of 1988-based products. The following list (which includes products which don't carry multimedia data) is far from complete:

BiMAIL, CDC MHS/4000, DC-Mail, DG AV/400, EAN, HP X.400, ICL OfficePower, ISOCOR, NAR400, NET400, OSITEL, OSIWare M400, PP, QK-MHS, Retix X.400, Route400, SoftSwitch, Sunlink MHS, UCLA/Mail400, UCOM.X, WhiteMail, X/EM, XT-PP.

The following X.400 gateway products are known:

BanyanMail, DEC All-In-One, Lotus CC:Mail, Microsoft Mail, TeamMail, WP Office, WorldTalk.

Further information: A useful source of information is available on the FTP server at Uni-Erlangen, maintained by Markus Kuhn:

ftp://ftp.uni-erlangen.de//pub/doc/ISO/english

Date of entry: 14 December 1992

Name: G.723

Description: CCITT standard for conversion between G.711 and lower-speed channels.

Name: G.726

Description: Replaces G.721?

Name: G.727

Description: Extension of G.726 for use over G.764

Name: G.728

Description: Coding of Speech at 16 kbit/s using Low-Delay Code Excited Linear Prediction (LD-CELP). Audio encoding for videoconferencing.

Name: G.764

Description: Packetised Voice Protocol

Name: G.765

Description: Associated with G.764

Name: H.200

Description: Audio compression standard (forthcoming).

Name: H.241

Description: Signalling for conferencing.

Name: H.243

Description: Multipoint Video Codec Standard. Probably a draft

Name: T.120

Description: T.121-T.124: Network-independent audio conferencing protocols.

Previous     NEXT