Diverse Information Types

The is the report of Project Group Number 5 - on Diverse Information Types. The subjects detailed in this report are as follows:-

This section of the project was completed by :-
Brian Mulcair, Darach Ennis, Rudiger Kaatz, Owen O'Flaherty, Louis Ryan and Henry Bradley


There is a lot of support on the internet for graphics information types. Most browsers allow JPEG and GIF files to be viewed 'inline', but support others through using MIME, and allowing them to be viewed with external 'helper' applications... However, there are a lot of considerations in choosing 'the right graphics format' for the job. This portion of the 'Support for Diverse Information Types' Group is concerned with graphics information types, where they are best used, and how they are supported, on the internet, as it is today, and how support may develop in the future...



The 2 most popular and most widely supported graphics information types; JPEG and GIF, are supported by most or all WWW browsers, and are the current internet 'standard' inline Graphics Formats.


JPEG stands for the Joint Photographic Experts Group

JPEG is designed for compressing either full-color or gray-scale images of natural, real-world scenes. It is ideally suited to compressing photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or line drawings.

JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with. JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness. Thus, JPEG is intended for compressing images that will be looked at by humans.

With JPEG 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 applications such as indexing image archives. 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.

Another important aspect of JPEG is that decoders can trade off decoding speed against image quality, by using fast but inaccurate approximations to the required calculations, in order that quite fast speedups can be obtained by some JPEG decoders.


GIF stands for the

When GIF and TIFF with LZW image file formats were first implemented, the LZW algorithm was thought to be in public domain. This, however, is not true. Unisys Corporation is the owner of United States patent number 4,558,302 and corresponding foreign patents. For a long time, Unisys Corporation did absolutely nothing to enforce the patent, [...enough time for GIF to acquire widespread acceptance and usage!!!], but in 1994 it came to an agreement with Compuserve, the copyright holder of the GIF specific implementation, that GIF developers have to license LZW from Unisys. Hence the myriad of shareware programs which no longer support GIF.

Their Advantages and Disadvantages.

The Future.


FIF stands for the Fractal Information Format LINK
This is a proprietary image format copyright to Iterated Systems Inc. [All Rights Reserved].It is a lossy image compression type, similar to those used in MS Multimedia titles.

The great advantage of FIF is that it creates very small binary files, which are ideal for the WWW. FIF would not be ideal for Medical Imaging, where exact duplication is required, but as a general purpose graphics format, its great advantage is in its small binary size. The compression achieved by FIF makes it an image type which can be transported quickly across the internet, due to its small size... Especially important when the bi-monthly phone bill is a major concern to 'low impact' WWW users.

Unfortunately not much technical information is available about FIF, although trial versions of Iterated Systems 'Fractal Imager' and 'Fractal Viewer' can be downloaded from their WWW site. The Fractal Imager supports a wide number of common Graphics Information types which can be converted to FIF to save space. This is especially important in large image archival WWW sites.


PNG stands for 'Portable Network Graphics'. It is a moraly sound replacement for the GIF format, which developers must pay royalties to provide support for, although users may use it freely. This is not a problem with most proprietary information formats, however, GIF was considered 'public-domain' and so was the 'LZW' algorithm developed by Unisys, which GIF employs, but it wasn't to be...

PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement for GIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.


Independant JPEG Group's V6.0a of their Free (JFIF-compliant) JPEG Software.

The Independant JPEG Group's JPEG FAQ.


Boutell Internet-Draft PNG V1.0 Specification. [June 10 1996]

Documenation received with the FIF-Imager and Viewer Software by Iterated System's Inc. ('95 - '96)


Netscape plug-ins extend Netscape Navigator to include a wide range of interactive and multimedia capabilities. Plug-ins are software modules that are seamlessly integrated into Navigator, appearing simply as supplemental capabilities. By accessing and implementing plug-ins, Netscape Navigator becomes your platform for the Internet.

Plug-ins offer a rich variety of functions and features to enhance and increase the functionality and compatibility of Navigator. Plug-ins have been used as:

The utilization of plug-in technology is constantly expanding beyond current applications, as demonstrated by the growing list of independent software vendors who are creating new and innovative plug-ins.

Plug-ins can be installed by running a setup program supplied with the plug-in. Plug-ins reside on the local hard drive and are detected by Navigator when it starts up. When Navigator encounters data handled by a plug-in (either embedded in an HTML page or in a separate file), it loads the appropriate plug-in and gives it access to all or a part of a window. The plug-in remains active until the associated page or file is closed.

Plug-ins are dynamic code modules, native to a specific platform on which Netscape Navigator runs. The primary goal of the plug-in API is to allow existing platform dependent code to seamlessly integrate with and enhance Navigator's core functionality by providing support for new data types. The plug-in API is designed to provide the maximum degree of flexibility and be functionally equivalent across all platforms.

With the current version of the Plug-in API, plug-ins are capable of:

Plug-ins can have one of two modes of operation: embedded or full-page. An embedded plug-in is a part of a larger HTML document, and is loaded by Navigator when the document is displayed. The plug-in is then visible as a rectangular subpart of the page. Embedded plug-ins are generally used for multimedia images relating to text in the page, such as Macromedia Shockwave.

A full-page plug-in is not part of an HTML page and is loaded by Navigator when the user opens a file of a MIME type registered by a plug-in, by clicking a URL to the file, dragging the file to the Navigator's icon, or opening the file from within Navigator. The loaded plug-in completely fills the Navigator page. Full-page plug-ins are commonly used for document viewers, such as Adobe Acrobat.

Netscape Plug-ins communicate with Navigator via an Application Programming Interface (API). Two types of functions make up the Plug-in API: plug-in methods and Netscape methods. Plug-in methods are functions that you implement in your plug-in and are called by Netscape; Netscape methods are functions implemented by Netscape that your plug-in may call. For clarity, the names of all plug-in functions begin with "NPP_", while all Netscape functions begin with "NPN_".

In general, all API functions operate identically on all platforms. However, there are several functions, notably NPP_HandleEvent and NPN_MemFlush, whose operation is platform-specific. All platform-specific differences are described in the documentation for the individual functions.

Unless otherwise stated, ownership for all API function parameters remains with the caller and values are valid only for the duration of each call. For example, if Netscape passes your plug-in a string, your plug-in should make its own copy of the string if you need to reference the string after returning from that function. If you pass Netscape a string or buffer, you are responsible for freeing the memory allocated for the data; Netscape will make its own private copy of the data if necessary.

Declarations for all API functions as well as definitions of all types and structures used in the API functions are found in the file npapi.h. Since most functions return an error value of type NPError, definitions for error code values are included in npapi.h as well.

The plug-in API is organized by type of method. Within each section, the functions are listed alphabetically.

Here are some examples


Deletes a specific instance of a plug-in and returns an error value.

NPP_Destroy is called when a plug-in instance is deleted, typically because the user has left the page containing the instance, closed the window, or quit the application.


Provides global initialization for a plug-in, and returns an error value.

This function is called once when a plug-in is loaded, before the first instance is created. You should allocate any memory or resources shared by all instances of your plug-in at this time. After the last instance has been deleted, NPP_Shutdown will be called, where you can release any memory or resources allocated by NPP_Initialize.

NPError NPP_Initialize(void)


Notifies an instance of a new data stream and returns an error value.

NPError NPP_NewStream(NPP instance, NPMIMEType type, NPStream *stream, NPBool seekable, uint16* stype);

General Instructions For Creating A Plug-In

Creating a Navigator plug-in is a two-step process. First, you download and decompress the sample source code. Then, you make the necessary changes and write the required code in the files provided. Finally, you test your plug-in by creating an HTML document.

Once you have completed the implementation of your plug-in, you can test it by creating an HTML document and embedding the plug-in object. Then to load the plug-in, simply display the page in Navigator.

This SDK includes complete step-by-step instructions for creating a plug-in. Because the process is slightly different depending on the platform you are working on, make sure to follow the steps for the appropriate environment.

Document Formats

When considering document formats distributed electronically the ability of the document to contain diverse information types with high quality presentation and also to faithfully represent what was originally designed are paramount. The second ability is particularly important if we are dealing with documents which are to be used for commerce. If a document is to be treated as a legally binding document or to be admissable as proof in a court of law it must be the original and provable to be so or a copy which faithfully represents the original. With electronic distribution the copying and modification of documents is easily achieved while accurately rendering the same document on different platforms isnt, hence there are some major challenges and opportunities for the development of document formats which can cope with these requirements. A document format adhereing to the following would be suitable for commerce (given that it was acceptable to the legislators).

Current Formats

Adobe Acrobat - PDF ( Portable Document Format) You will require the Acrobat reader to view any of the links in this section - click on the button below to setup Acrobat 3 on your machine.

Adobe developed PDF from Postscript to provide an accurate page layout scheme for documents which are to be viewed on many platforms. PDF was specifically designed for use on the web and its latest incarnation seamlessly integrates into browsers and provides links to other pages. PDF in inheriting from Postscript provides an excellent level of platform independence which is essential in any good document format.PDF supports Unicode characters thus providing multi-character set support, unfortunately there are no security or revision marking mechanisms intrinsic to the format though these features may be added by third party software or a later release.Click here for a full techincal description of the PDF format. Here is a web magazine entirely produced in PDF format.

Adobe - Postscript

Postscript was developed in the mid-eighties as a high precision page layout scheme. Postscript is not so much a data format as a programming language where objects render themselves onto a canvas, this allows Postscript interpreters to render a file onto any 'canvas' such as a screen or a page with a high degree of accuracy. Postscript includes support for images, line drawings and multiple font types but it does not include multi-character set support except through the use of specific fonts. Due to its text based nature Postscript files are bulky and inefficient, there is no support for embedded links or any security or revisioning. Postscript will remain a useful standard for the distribution of documents for publication but it has limited uses in the commercial world. Here is an overview of Postscript and a more technical discuusion of the format.


While currently dominating the distributable electronic document world there are some very serious limitations inherent in the protocol which prevent it being a useful document standard. There is no direct support for pages in a html file, its mechanisms are designed to provide a layout scheme for placing text and objects on a canvas of arbitrary size and to provide interlinking of documents. HTML will continue to be useful in Web 'page' layout but will probably be superceded by a more sophisticated and sompact format such as PDF unless there are major revisions. Heres a link to the W3 Consortium which manages the HTML standard.

MS-WORD and other Word Processing formats.

It seems suprising that Microsoft has not tried to impose MS-Word as a de facto standard for exchanged documents or developed it so that it would be suitable for such a task, although it supports revisions and a low level of password protection it does not provide a good level of platform independence and can render very differently on different machines. The same can be said for most of the major WP formats.

Sound & Video

The World-Wide-Web, originally envisaged as a system for accessing remote ASCII text, has since developed, largely thanks to advancements in network speed, into a base from which many diverse media types may be accessed. In the last year, we have been witnessing major progress in the integration of two more media types, namely audio and video.

For instance, the Web is now used as an interface to Internet telephones and videophones, i.e. for applications that allow people to talk and see each other in real-time on the Internet. Web-based audio/video-on-demand, i.e. access to stored audio and video resources, also became much more practical due to the advent of "streaming protocols" which replace the standard Web transport protocol http when audio and video data must be transferred. Agreement must be reached between client and server about how they exchange content information. Many hypertext systems qualify as "hypermedia" systems because they handle media other than plain text. Examples are graphics, video and sound clips, object-oriented graphics definitions, marked-up text, etc.

For visions like the Web replacing television to become a reality, several extensions to Web technology are required. The protocol used on the Web today (http) is known to be unsuitable for transmitting data with real-time constraints like audio and video. An audio/video-enhanced Web should integrate RTP (Real Time Transport Protocol), a protocol developed by the Internet standardisation body (the IETF), with participation of Moreover, authors of Web-based multimedia presentation must be able to express the notion of time and the synchronization between different media. Finally, appropriate URL schemes must be defined in order to be able to establish hyperlinks to audio and video resources.

Current Common Usage

Through the use of MIME types, WWW browsers such as Netscape are informed of the type of media they are instructed to access. Netscape, for example, maintains a list of these types, and the default method it is to use to handle the media. (This may be accessed by selecting General Preferences from the Options menu of the Netscape toolbar you are using.)

For example, video files of type Quicktime may be played via an external viewer, or may be saved to disk. Wave files may also be listened to after downloading via external applications such as 'xplay' or may be saved for future use. Hence, the author of a web page captures audio and video information using tools provided on his particular platform, and stores the resulting files on a Web server. Clients use HTTP to access these files and spawn external player programs to manipulate them. This is a cumbersome and patchy way of incorporating multimedia services on the WWW, and it is only very recently that effective means of delivering a useful multimedia service via the Web have emerged.

The switch between http and a real-time protocol is currently achieved by a method which is tiresome to set up for the end-users. The method is based on MIME-types and helper applications. This problem can be solved by defining a URL scheme for both stored and real-time (MBone or phone) streaming data analagous to URL schemes for ftp, news, etc.

The major current alternatives to the simple expedient of full downloading before usage are as follows:

Integrating a streaming protocol into the Web

The previous section has shown that HTTP is in many cases unsuitable for retrieving a sound or video file, because it results in a very high response time. For these reasons, most of today's well-known products that add sound (e.g. RealAudio [http://www.realaudio.com]) and video (e.g. VDOlive [http://galileo.dv.com/Mag/Jul96/VDOF/VDO1.html]) to the Web fo not use HTTP to retrieve their files. Instead, they use a protocol based on UDP (User Datagram Protocol). The goal of such a "streaming protocol" is to start the output of the file as soon as possible, ie. as soon as enough data of the file has arrived. Moreover, these also use very compact sound and video formats.

However, a protocol must be found that does not use TCP in combination with a web browser using HTTP (and hence TCP.) Simply put, a way must be found to start with HTTP when the user clicks on a link, and then switch to a streaming protocol as soon as the transmission of the sound or video file starts.

A basic idea for a solution is to add a second client/server pair to the system. An example of this is shown below:

	----------------		------------------
	|    Web       |		|    Web	 |
	|   Client     |     HTTP       |   Server       |
	|	       |----------------|		 |
	----------------		------------------
	----------------		------------------
	|  Video/Sound |		|   Video/Sound  |
	|    Helper    |   Streaming    |     Server     |
        |              |    Protocol    |		 |
	|              |----------------|		 |
	----------------		------------------

          Client machine		 Server Machines (separate)

The user machine (at left) runs two independent programs. The Web client provides the functionality usually associated with such a tool, such as displaying Web pages. The helper is reponsible for playing out sound or video files, and for running the streaming protocol with a server for sound or video. Moreover, the helper often also implements functions like fast forward, stop and pause that are well known from CD players / tape recorders.

It must be noted that the user is not even aware of the fact the he not using the Web client directly for accessing the sound file. User interface techniques such as plug-ins may be used to integrate the user interface of the sound/video player with the user interface of the Web client. However, this integration only takes place on the user interface level. The browser reserves a screenspace on the current Web page, and it is up to the helper program to manage this space. Behind the scenes, however, two different programs are executed.

RTP - The Real Time Transport Protocol

While great advances in this field have been made, as described on previous pages, there will always be a need for standardisation if there is to be a firmly-rooted future for real-time multimedia. To this end, the Real-Time Streaming Protocol (RTP) (Schulzrinne, Casner, Frederick & Jacobson, 1996) has been developed for the last four years by the IETF, which is the primary standardisation body of the Internet. It has been standardised as recently as RFC 1889 (request-for-comments 1889). It has been adopted by Netscape for its 'Live Media' proposal, and Microsoft also announced support for this protocol.

RTP specifies a set of headers that allow realization of stand requirements occurring in many multimedia applications (Internet telephony, videoconferencing, etc). It does not, however, standardize any sound or video formats. Therefore, RTP can be used for transmitting standardized formats such as GSM or DVI for sound and H.621 or MPEG for video as well as for transmitting proprietary sound/video formats.

Extensive experience with this protocol has been gathered in experiments over the Mbone (Multicast Backbone) where RTP has been put to use for transmissions ranging from IETF meetings (Casner, 1992) over space shuttle starts to a live concert of the Rolling Stones, the sublime to the ridiculous.

The basic structure of an RTP system consists of a sender and one or more receivers. This protocol is run between end-systems, ie. between the computers sending and receiving sound and video data. The protocol contains two different types of packet: RTP packets, which contain the media data transmitted by the sender, and RTCP (Real Time Control Protocol) packets, which mostly contain information about the quality of service transmission that arrives at the receiver. A transmission is referred to as an RTP stream.

RTP foresees that each source (camera, microphone) is assigned its own, independent stream. In other words, in a videoconference between two partners, four RTP streams would be opened: two for transmitting the sound of each of the participants, and two more for transmitting their video streams. RTP streams belonging together are referred to as an RTP session. The alternative would be to map the different sources onto a single network stream (multiplexing). However, this makes the system's implementation more difficult. Moreover, multiplexing makes it is impossible to receive only one of the streams in a session consisting of multiple streams, e.g. to select only the audio without the video in a videoconference.

As we can see from the presence of potentially multiple receivers, RTP has been designed to be usable in a multicast setting, e.g. in a videoconference having multiple participants. This introduced additional problems that had to be solved in RTP such as how to avoid that the sender gets overloaded with the RTCP packets sent by a big number of receivers. We will not describe the multicast case in this description of RTP, since it is not yet used prominently for Web based sound and video applications.

For the latest information on RTP, try the following site

MIME, what is that?


MIME stands for Multipurpose Internet Mail Extensions, a specification for formatting non-ASCII messages so that they can be sent over the Internet. Many e-mail clients now support MIME, which enables them to send and receive graphics, audio, and video files via the Internet mail system. MIME supports messages in character sets other than ASCII.
The HTTP protocol used for the World Wide Web uses the MIME Content-Type specification to identify the nature of documents and files sent to HTTP client software (browsers).
Many of the capabilities offered by MIME have been available without it, either through extensions to RFC-822 (more about RFC-xxx in handling) such as the Content-Type field, or through non-standard mechanisms like UUEncode. What MIME does is define a structured, comprehensive system for identifying the nature and encoding of an e-mail message's body in a standard manner. This standard fits neatly within the previously defined standards which are used by many thousands of users and sites around the world today, offering users greatly expanded features without breaking existing mail transportation systems.


e-mail MIME test form
A Complex Multipart Example


The basic Internet standard for message format, defined in RFC-822 and the Simple Mail Transport Protocol (SMTP), defined in RFC-821, is very restricted:

To overcome these restrictions MIME defines new header fields and a way of decoding 8-bit data in 7-bit ASCII text.

New Header Fields

MIME defines the following new header fields:
  1. MIME-Version which uses a version number to declare that a message conforms to the MIME standard.
  2. Content-Type, which can be used to specify the type and subtype of data in the body of a message and to fully specify the encoding of such data. It includes also a subtype option. The seven Content-types specified are:
    1. Text - to represent textual information in a number of character sets.
    2. Image - for transmitting still image (picture) data.
    3. Audio - for transmitting audio or voice data.
    4. Video - for transmitting video or moving image data.
    5. Message - for encapsulating a mail message.
    6. Multipart - to combine several body parts, possibly of different types of data, into a single message.
    7. Application - to transmit application data or binary data.
  3. Content-Transfer-Encoding, which specifies how the data is encoded to allow it to pass through mail transports having data or character set limitations.
  4. Content-ID (optional), which enables labeling bodies, thus allowing one body to reference another.
  5. Content-Description (optional), which enables associating descriptive information with a body.

Why Encoding Is Necessary

Many Content-Types that could usefully be transported by e-mail are represented, in their "natural" format, as 8-bit character or binary data. Such data cannot be transmitted over some transport protocols, such as, which restricts mail messages to 7-bit ASCII data with lines no longer than 1000 characters.

MIME provides two mechanisms for re-encoding such data into 7-bit short-line format. The Content-Transfer-Encoding header field indicates the mechanism used to perform such an encoding.


The current specifications for the format of e-mail and its transfer on the Internet were defined almost 13 years ago. As e-mail has become more widely used, and the range of activities it can be and is used for has grown, so has the need to extend the capabilities of the basic e-mail message. In June 1992 Borenstein and Freed published RFC-1341 , which defines Multipurpose Internet Mail Extensions, or MIME. MIME defines a standard method for extending the capabilities of the RFC 822 e-mail message without breaking those delivery systems which are based only on RFC 821 and 822 specifications. It also makes use of a number of extensions to e-mail which have been added in the interim, such as the standard for message encapsulation and the Content-Type header field.


MIME has been carefully designed as an extensible mechanism, and it is expected that the set of content-type/subtype pairs and their associated parameters will grow significantly with time. Several other MIME fields, notably including character set names, are likely to have new values defined over time.
Beyond giving e-mail users greatly expanded features, the MIME standard also provides elements which can be applied to other protocols. For example the application of MIME to the Usenet article structure seems obvious, given that structure's close compatibility with RFC-822.

Links, references

PC Webopaedia - MIME
This page describes the term 'MIME' and lists other pages on the Web where you can find additional information.
MIME documents
This page provides links to the Requests for Comments on the Mechanisms for Specifying and Describing the Format of Internet Message Bodies and Message Header Extensions for Non-ASCII Text documents.
Technical overview of MIME
This article, from NCT Web Magazine, provides a technical overview of MIME.
This page provides links to several usenet newsgroup FAQs for MIME.
Yahoo's MIME directory
This is Yahoo's directory of links to MIME.

Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions):
Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993.

RFC 1521 -- A Complex Multipart Example

What follows is the outline of a complex multipart message. This message has five parts to be displayed serially: two introductory plain text parts, an embedded multipart message, a richtext part, and a closing encapsulated text message in a non-ASCII character set. The embedded multipart message has two parts to be displayed in parallel, a picture and an audio fragment.

      MIME-Version: 1.0
      From: kaatzr@tcd.ie;
      To: Donal.OMahony@cs.tcd.ie;
      Subject: A multipart example
      Content-Type: multipart/mixed;
      This is the preamble area of a multipart message.
      Mail readers that understand multipart format
      should ignore this preamble.
      If you are reading this text, you might want to
      consider changing to a mail reader that understands
      how to properly display multipart messages.
         ...Some text appears here...
      [Note that the preceding blank line means
      no header fields were given and this is text,
      with charset US ASCII.  It could have been
      done with explicit typing as in the next part.]
      Content-type: text/plain; charset=US-ASCII
      This could have been part of the previous part,
      but illustrates explicit versus implicit
      typing of body parts.
      Content-Type: multipart/parallel;
      Content-Type: audio/basic
      Content-Transfer-Encoding: base64
         ... base64-encoded 8000 Hz single-channel
             mu-law-format audio data goes here....
      Content-Type: image/gif
      Content-Transfer-Encoding: base64
         ... base64-encoded image data goes here....
      Content-type: text/richtext
      This is <bold><italic>richtext.</italic></bold>
      <smaller>as defined in RFC 1341</smaller>
      <nl><nl>Isn't it
 Content-Type: message/rfc822
      From: (mailbox in US-ASCII)
      To: (address in US-ASCII)
      Subject: (subject in US-ASCII)
      Content-Type: Text/plain; charset=ISO-8859-1
      Content-Transfer-Encoding: Quoted-printable
         ... Additional text in ISO-8859-1 goes here ...

Return to Project Title Page