Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 1614


Network Access to Multimedia Information

Part 2 of 3, p. 24 to 54
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 24 
3. Existing Systems

   This chapter describes some existing distributed information systems
   in sufficient detail to reveal how they handle multimedia data, and
   analyses how well they meet the requirements outlined in the
   preceding chapter.

3.1. Gopher

   The Internet Gopher is a distributed document delivery service.  It
   allows a neophyte user to access various types of data residing on
   multiple hosts in a seamless fashion.  This is accomplished by
   presenting the user with a hierarchical arrangement of nodes and by
   using a client-server communications model.  The Gopher server
   accepts simple queries, and responds by sending the client a node
   (usually called a document in this context).

   Client software is available for a large number of systems,

        o UNIX (character terminals)

        o X windows

        o Apple Macintosh

        o MS DOS

Top      Up      ToC       Page 25 
        o NeXT

        o VM/CMS

        o VMS

        o OS/2

        o MVS/XA

   Servers are available for systems such as:

        o UNIX

        o VMS

        o Apple Macintosh

        o VM/CMS

        o MVS

        o MS DOS

   Gopher was developed at the University of Minnesota.

   Gopher User Image

   A Gopher client offers an interface into "gopherspace", which appears
   to the user as a hierarchy of menus and document nodes, similar in
   some ways to a file system hierarchy of directories and files.
   Selecting an entry from a menu node causes a further menu to appear,
   or causes a document to be retrieved and displayed.

   As well as "ordinary" document nodes, Gopher has "search nodes" when
   one of these is selected from a menu, the user is prompted for one or
   more words to search on.  The result of the search is a "virtual"
   menu, containing entries for document nodes (within some subset of
   gopherspace) which match the search.  A special type of Gopher search
   server called "veronica" provides access to a database of all
   directory nodes in gopherspace.  This allows a user to construct a
   virtual menu of all Gopher menu items containing a particular word.
   WAIS databases may also be located at Gopher search nodes, since some
   Gopher servers understand the format of WAIS index files.

Top      Up      ToC       Page 26 
   Gopher Protocol

   Gopher uses a client-server paradigm.  The Gopher protocol runs over
   a reliable data stream service, typically TCP, and is fully defined
   in RFC 1436.  The following paragraphs give an overview which is
   sufficient for understanding how multimedia data is handled in

   A Gopher client opens a TCP connection to a Gopher server (defined by
   machine name and TCP port number), and sends a line of text known as
   the "selector" to request information from the server.  The server
   responds with a block of data, and then closes the connection.  No
   state is retained by the server.  A null (empty) selector tells the
   Gopher server to return its "root" menu node, containing pointers to
   other information in gopherspace.

   A menu is returned from a Gopher server as a sequence of lines of
   text, each corresponding to one entry in the menu.  Each line (which
   is sometimes called a "Gopher reference") contains the following
   data, which can be used by the client software to retrieve and
   display the corresponding node in gopherspace.

      o    A single character which identifies the type of the node.
           Possible values of this type ID are given below.

      o    A human-readable string which is used by the client software
           when it displays the menu entry to the user.

      o    The selector which should be used by client software to
           retrieve the node.  It is treated as opaque by the client

      o    The domain name of the host on which the node is held.

      o    The port number to use for the TCP connection.

   A document node is sent by a Gopher server simply as lines of text
   terminated by a dot on a line by itself, or as raw binary data, with
   the end of the data indicated by the server closing the TCP
   connection.  The choice depends on the type of node.

   The currently-defined type IDs are as follows:

        0       Node is a file.

        1       Node is a directory.

        2       Node is a CSO phone book server.

Top      Up      ToC       Page 27 
        3       Error.

        4       Node is a BinHexed Macintosh file.

        5       Node is DOS binary archive of some sort.

        6       Node is a UNIX uuencoded file.

        7       Node is a search server.

        8       Node points to a text-based telnet session.

        9       Node is a binary file.

        T       Node points to a TN3270 connection.

   Some experimental IDs are also in use:

        s       Node contains -law sound data.

        g       Node contains GIF data.

        M       Node contains MIME data.

        h       Node contains HTML data.

        I       Node contains image data of some kind.

        i       In-line text type.

   The process for defining new data types and corresponding IDs is not

   Gopher+ Protocol

   The Gopher+ protocol is an extension of the Gopher protocol.  Gopher+
   is defined informally in [4].  It is designed to be downwards
   compatible with the original protocol, so that old Gopher clients may
   access Gopher+ servers (without being able to take advantage of the
   new facilities), and Gopher+ clients may access old Gopher servers.
   Gopher+ is still at the experimental stage, and is liable to change.

   The most important new feature is the introduction of "attributes"
   associated with individual nodes.  The client may retrieve the
   attributes of a node instead of the node contents.  Attributes
   defined so far include:

Top      Up      ToC       Page 28 
    INFO               Contains the Gopher reference of the node.

    ADMIN              Contains administrative information, including
                       the mail address of the server administrator and
                       the last-modified date of the node.  Mandatory.

    VIEWS              Contains a list of one or more "view
                       descriptors", each of which describes an
                       alternate view of the node.  For instance, an
                       image node may contain a TIFF view, a GIF view,
                       a JPEG view, etc.  The client software (or the
                       user) may choose which view to retrieve.  The
                       size of the view is also (optionally) available
                       in this attribute.  The Gopher+ Attribute
                       Registry (see below) defines the permitted view

    ABSTRACT           This attribute contains a short description of
                       the item.  It may also include a Gopher
                       reference to a longer abstract, held in a
                       separate Gopher node.

    ASK                This attribute is used for the interactive query
                       extension. The interactive query facility in
                       Gopher+ is used to obtain information from a
                       user before retrieving the contents of a node.
                       The client fetches the ASK attribute, which
                       contains a list of questions for the user. His
                       or her responses to those questions are sent
                       along with the selector to the server, which
                       then returns the contents of the node.  This
                       facility could be used as a very simple way of
                       querying a database, for instance.  Using the
                       interactive query facility to supply a password
                       for access control purposes is not a good idea -
                       there are too many opportunities for

   The University of Minnesota maintains a registry of Gopher+ attribute
   types.  For the VIEWS attribute, the registry contains a list of
   permitted view types.  Note that these view types have a similar
   function to the type identifier described in the preceding section.

   The general format of a Gopher+ view descriptor is:

      xxx/yyy zzz: <nnnK>

Top      Up      ToC       Page 29 
   where xxx is a general type-of-information advisory, yyy is what
   information format you need understand to interpret this information,
   zzz is a language advisory (coded using POSIX definitions), and nnn
   is the approximate size in bytes.  Possible values for xxx include
   text, file, image, audio, video, terminal.

   (It now appears that the University of Minnesota Gopher Team accepts
   the need to be consistent in the use of type/encoding attributes with
   the MIME specification.  The Gopher+ Type Registry may thus
   eventually disappear, together with the set of xxx/yyy values it
   currently contains.)

   No view descriptors for directory nodes are currently registered.

   In order to make use of the information available in attributes, it
   is necessary to fetch the attributes before fetching the contents of
   a node.  Gopher+ provides a way of fetching the attributes for each
   entry in a menu at the same time as the menu is retrieved.  This
   saves having to establish two successive TCP connections to fetch a
   single document, at the expense of some additional client software

   Gopher Publishing

   The procedure for making data available using the Unix Gopher server
   "gopherd" is very straightforward.  The hierarchical nature of the
   Unix file system closely matches the Gopher concept of menus and
   documents.  The gopherd program exploits this - Unix directories are
   represented as Gopher menu nodes, and Unix files as Gopher document
   nodes.  The names of directories and files are the entries in Gopher
   menus.  This can lead to awkward file names containing spaces, so
   gopherd provides an aliasing mechanism (the \.cap directory) to get
   round this.

   To represent menu entries pointing to Gopher nodes on other servers,
   special "link" files (starting with a dot) are used.

   The type ID for a document node is determined from the extension of
   its Unix filename.  If a client requests a file containing a shell
   script, the script is executed and the output returned to the client.

   The Gopher+ version of gopherd is similar, but the .cap directory is
   replaced by a configuration file gopherd.conf.  This file is used to
   specify administration attributes, and the mapping between filename
   extensions and view descriptors.  Some limited access control (based
   on the client's IP address/domain name) is also provided by the
   Gopher+ version of gopherd.

Top      Up      ToC       Page 30 
   Published Non-text Data

   There is already some useful non-text data published on Gopher almost
   exclusively image data.  See for example the Vatican Library
   Exhibition at the University of Virginia Library, the ArchiGopher at
   the University of Michigan, the weather machine at the University of
   Illinois.  Some of these are described in the User Requirements
   chapter of this report.

   There seem to be rather fewer sound archives in gopherspace, but
   interested users may access the Edinburgh University Computing
   Service Gopher server on, where the Testing Area
   contains 20 or 30 short audio files in Sun audio format.  Note - the
   availability of this archive is not guaranteed.


   The main factor in favour of Gopher is its widespread penetration.
   There are over 1000 Gopher servers world-wide.  This popularity is
   due in part to the ease of setting up a Gopher server and making
   information available on it, particularly on a Unix platform.


   It is unfortunate that the relatively well-defined MIME types were
   not adopted in Gopher+.  As mentioned above, this may yet happen,
   although there appear to be reasons for keeping the set of MIME types
   small whereas Gopher requires a wide range of types to offer to
   clients.  The latest word is that the MIME registry will be expanded
   to include the types which the Gopher+ developers want.

   Gopher is inflexibly hierarchical in nature.  Hypertext or hypermedia
   it is not - links to other nodes from within document nodes are not
   possible.  There is a suggestion in the Gopher+ specification that
   alternate views of directory nodes could be used to provide some kind
   of hypermedia capability, but this does not yet exist, and it is
   unlikely that it could be made to work as easily as the WWW hypertext

   There is no access control at the user level - anyone can retrieve
   anything on a Gopher server.  There is no provision for charging for

3.2. Wide Area Information Server

   The Wide Area Information Server (WAIS) system allows users to search
   for and retrieve information from databases anywhere on the Internet.
   WAIS uses a client-server paradigm, and client and server software is

Top      Up      ToC       Page 31 
   available for a wide range of platforms.  Client applications are
   able to retrieve text or other media documents stored on the servers,
   by specifying keywords.  The server software searches a full-text
   index of the documents, and returns a list of documents containing
   the keywords (ranked according to a heuristic algorithm).  The client
   may then request the server to send a copy of any of the documents
   found.  Relevant documents can be fed back to a server to refine the
   search.  Successful searches can be automatically re-run, to alert
   the user when new information becomes available.

   WAIS was developed by Thinking Machines Corporation of Cambridge,
   Massachusetts, in collaboration with Apple Computer Inc., Dow Jones
   and company, and KPMG Peat Marwick.  The WAIS software has been made
   freely available; however Thinking Machines has announced that they
   will stop support for their publicly-distributed WAIS as of version
   8b5.1.  Future support and development of the publicly-distributed
   WAIS has been taken over by CNIDR (Clearinghouse for Networked
   Information Discovery and Retrieval) in the USA.  Future CNIDR
   releases will be called FreeWAIS.  A new company, WAIS Inc, has been
   formed by Thinking Machines to take over commercial exploitation of
   the Thinking Machines WAIS software.

   WAIS server software is available for the following platforms:

        o       UNIX

        o       VAX/VMS

   Client software is available for the following platforms:

        o       UNIX (versions for X, Motif, Open Look, Sun View)

        o       NeXT

        o       Macintosh

        o       MS DOS

        o       MS Windows

        o       VAX/VMS

   There are currently over 400 WAIS databases available on the
   Internet.  WAIS is also the basis of some commercial information
   services on private networks.

Top      Up      ToC       Page 32 
   WAIS User Image

   In order to ask a question, the user must first select one or more
   databases in which to look for the answer.  (The list of all
   available databases is available from a number of well-known sites.)
   The next step is to enter one or more keywords as the basis of the
   search.  The search will return a list of documents (the "result
   set") which contain any of the keywords.  Each document is given a
   ranking (a number between 1 and 1000) which indicates how relevant to
   the user's question the server believes the document to be.  The size
   of each document is also shown in the list.  The user may limit the
   size of the result set - the default limit is typically 40 documents.

   The user may then choose to retrieve and display one or more
   documents from the list.  Alternatively, he or she may designate one
   or more documents in the list as "relevant", and perform another
   search to find "more documents like this".  This is called "relevance

   The user may retrieve general information about the database, and may
   examine the catalogue of all documents in the database.  There is
   also a "database of databases", which may be searched to identify
   WAIS databases which may be relevant to a subject.

   WAIS Protocol

   The user interface (client) talks to the server using an extended
   version of a standard ANSI protocol called Z39.50.  This is now
   aligned with the ISO SR (Search and Retrieval) protocol for
   bibliographic (library) applications, which is part of OSI.  The
   present WAIS protocol does not utilise a full OSI stack - APDUs are
   transferred directly over a TCP/IP connection.  The WAIS protocol is
   described in [5].

   WAIS does not, at this time, implement the full Z39.50-1992
   specification - in particular, WAIS does not permit Boolean searches
   (e.g., "find all documents containing 'chalk' and 'cheese' but not
   'green'").  However, Boolean search capability is being added to the
   FreeWAIS implementation.  There are facilities in the Z39.50 protocol
   for access control and charging, but these are not currently
   implemented in WAIS.

   The WAIS extensions to Z39.50 are mainly to provide the relevance
   feedback capability.

   Note that the Z39.50 protocol is not stateless - the result set may
   in some circumstances be retained by the server for the user to
   further refine or refer to.  However, the subset of Z39.50 used by

Top      Up      ToC       Page 33 
   current WAIS implementations mean that server implementations may be

   Document type is determined by the server from information in the
   database index (see below), and is sent to the client as part of the
   result set.

   WAIS Publishing

   The first step in preparing data for publishing in a WAIS database is
   to use the 'waisindex' utility.  This takes a set of text files, and
   produces an index file which contains an occurrence list of words of
   three or more letters in every file.  This index file is used by the
   WAIS server software to resolve search requests from clients.

   The 'waisindex' utility indexes files in a wide range of text
   formats, as well as postscript and image files in various encodings
   (only the file name is indexed for image files).  Some of the text
   formats involve a file as being treated as a collection of documents
   for the purposes of WAIS access.  Note that there appears to be no
   formal "registry of types" - just whatever the waisindex program
   supports.  There is no distinction between media type and encoding

   Published Non-text Data

   There is relatively little non-text data available in WAIS databases.

      o    URL=wais:// is a database of
           TIFF images from the Connection Machine.

      o    URL=wais://
           pathology is a database of histo-pathological images and
           documentation on mammalian endocrine tissue.

      o    URL=wais:// contains GIF images
           from NASA planetary probe missions, together with their
           captions.  The presence of the caption index information
           makes it difficult to construct a search which returns
           images in the result set increasing the maximum result set
           size may help.


   WAIS is ideally suited for its intended purpose of searching
   databases of textual information on the basis of keywords.  It
   appears to have the potential to satisfy the requirements of some of
   the "database" category of applications mentioned in Chapter 1.

Top      Up      ToC       Page 34 

   WAIS is not (and does not pretend to be) a general-purpose
   information system, as Gopher and WWW are.  WAIS does not have
   hyperlinking, and offers a purely flat structure.

   A limitation which is particularly apparent is the way that the
   current version of FreeWAIS indexes non-text files - using only the
   filename!  However, it does seem that simply changing the indexing
   program to allow a list of keywords to be attached to non-text files
   would suffice to allow sensible indexing of non-text data.  The
   commercial (WAIS Inc) version of WAIS allows several files to be
   associated together for indexing and retrieval purposes.
   Furthermode, the UCSF Centre for Knowlege Management is modifying the
   FreeWAIS code to support the indexing of multiple content types.  The
   document returned by WAIS will be an HTML document containing
   pointers to the multimedia data.  Contact
   for further information.

   WAIS is not a fully-featured query/response protocol such as SQL.  It
   has no concept of fields, or numeric data types.

   It appears to be impossible to retrieve a document from its catalogue
   entry in many of the existing databases.

3.3. World-Wide Web

   The World-Wide Web project (also known as WWW or W3), started and
   driven by CERN, is a large-scale distributed hypertext system.  It
   uses the standard client-server paradigm, with client "browser"
   software responsible for fetching and displaying data.  Originally
   aimed at the High Energy Physics community, it has spread to other

   Browser software is available for a large number of systems

        o       Line-mode dumb terminal.

        o       Terminal with Curses support

        o       Macintosh

        o       X/Motif

        o       X11

        o       PC/MS Windows

Top      Up      ToC       Page 35 
        o       NeXT

   There is server software available for:

        o       VM mainframes.

        o       UNIX

        o       Macintosh

        o       VMS

   WWW User Image

   The WWW world consists of nodes (usually called documents) and links.
   Links are connections between documents: to follow a link, a reader
   clicks with a mouse on a word in the source document, which causes
   the linked-to document to be retrieved and displayed.  (On systems
   without a mouse, the user types a number instead.)

   Indexes are special documents which, rather than being read, may be
   searched.  To search an index, a reader supplies keywords (or other
   search criteria).  The result of a search is a "virtual" document
   containing links to the documents found.  All documents, whether
   real, virtual or indexes, look similar to the reader.

   The WWW addressing mechanism means that an interface to Gopher and
   anonymous FTP information sources may be established, in a way which
   is transparent to the user.  Thus, the whole of gopherspace is part
   of the Web.  Transparent gateways to other systems, including Hyper-G
   and WAIS, are also available.


   All nodes on the Web are addressed using the "Universal [or Uniform]
   Resource Locator" (URL) syntax, defined in [6].  This is an Internet
   Draft produced by the IETF URL Working Group.

   A URL is a name for an object (which may be a document or an index)
   on the Internet.  It has the general form:

      <scheme> : <path> [ # <anchorid> ]

   The <scheme> identifies an access protocol or method for the object.
   Some of the schemes are HTTP (the native WWW protocol), anonymous
   FTP, Andrew file system, news, WAIS, Gopher.  The <path> component
   locates the document in a way significant for the access method.

Top      Up      ToC       Page 36 
   Thus for instance for anonymous FTP, the path includes the fully
   qualified domain name of the host on which the document resides, and
   the directory and file name under which it may be found.  For some
   schemes, the <path> may include a search string (or combination of
   strings) which is used to address a "virtual" object formed by
   searching an index of some kind.  The HTTP, WAIS and Gopher schemes
   can use search strings, which usually follow the rest of the path,
   separated from it by a ?.

   The optional <anchorid> is used for addressing within an object.  Its
   interpretation is not defined in the URL specification.

   "Partial" URLs may be specified.  These are used within a document on
   the Web to refer to another "nearby" document - for instance to a
   document in another file on the same machine.  Certain parts of the
   URL (e.g., the scheme and machine name) may be omitted, according to
   well-defined rules.  This makes it much easier to move groups of
   documents around, while maintaining the links within and between

   A URL locates one and only one object on the Internet.  However, more
   than one URL may point to the same object.  Given two URLs, it is not
   in general possible to determine whether they refer to the same
   object.  Furthermore, there is no guarantee that a single URL will
   refer to the same object at different times (the object may change
   incrementally, or it may be completely replaced with something
   different, or it may indeed be removed).


   HTTP (HyperText Transfer Protocol) is the protocol employed between
   server and client.  It is defined in [7].  The protocol is currently
   being revised (see the Future Developments section below), and will
   eventually be proposed as an Internet standard.

   The original protocol is extremely simple, and requires only a
   reliable connection-oriented transport service, typically TCP/IP.

   The client establishes a connection with the server, and sends a
   request containing the word GET, a space, and the partial URL of the
   node to be retrieved, terminated by CR LF.  The server responds with
   the node contents, comprising a text document in the Hypertext Markup
   Language (HTML).  The end of the contents is indicated by the server
   closing the connection.

Top      Up      ToC       Page 37 

   HTML (HyperText Markup Language) is the way in which text documents
   must be structured if they are to contain links to other documents.
   Non-HTML text documents may of course be made available on the Web,
   but they may not contain links to other documents (i.e., they are
   leaf nodes), and they will be displayed by browsers without
   formatting, probably using a fixed-width font.  Like HTTP, HTML is
   also undergoing enhancement, but the original version is defined in
   [7], and is being submitted as an Internet draft.

   HTML is an application of SGML (Standard Generalized Markup
   Language).  It defines a range of useful tags for indicating a node
   title, paragraph boundaries, headings of several different levels,
   highlighting, lists, etc.  Anchors are represented using an <A> tag.

   For instance, here is an example of HTML containing an anchor:

   The HTTP protocol implements the WWW <A NAME=13
   HREF="../../Administration/DataModel.html">data model</A> .

   The location of the anchor is the text "data model".  It is a source
   anchor, with a target given by the URL in the HREF attribute, so the
   text would appear highlighted in some way in a client's window, to
   indicate that clicking on it would cause a hyperlink to be traversed.
   It is also a target anchor, with an anchor ID given by the NAME
   attribute.  A source anchor referring to this target would specify
   #13 at the end of the node's URL.  Traversing a hyperlink to this
   node would cause the entire node to be retrieved, but the target
   anchor text would be displayed in some emphasised way - for instance
   if the retrieved text is displayed in a scrolling window, it might be
   positioned such that the target anchor appears at the top of the

   Another attribute of the <A> element, TYPE, is also available, which
   is intended to describe the nature of the relationship modelled by
   the link.  However, this is not in extensive use, and there appears
   to be no registry of the possible values of such types.

   Future Developments

   HTTP and HTML are currently being extended in a backward-compatible
   way to add multimedia facilities.  [8] describes the HTTP2 protocol.
   The revised HTML is defined in [9].  Both documents are subject to
   change (and indeed the HTML2 specification has changed substantially
   during the preparation of this report).

Top      Up      ToC       Page 38 
   The revised HTML contains many enhancements which are useful for
   multimedia support.  Some of the most relevant are listed below.

      o    "Universal Resource Numbers" are a proposed system for
           unique, timeless identifiers of network-accessible files
           presently being designed by IETF Working Groups.  URNs must
           be distinguished from URLs, which contain information
           sufficient to locate the document. URNs may be allocated to
           nodes and may be represented in source anchors.  This saves
           client software from retrieving a copy of something it
           already has - allowing sensible caching of large video
           clips, for instance.  The disadvantage is that when
           something is changed and given a new URN, the source anchors
           of all links which point to it must be changed (and the URNs
           of these documents must therefore be changed, and so on).
           Therefore, it makes sense to allocate URNs only to very
           large documents which change rarely, and not to the
           documents which reference them.

      o    The title of a destination document may be included as
           anattribute of a source anchor.  This allows a client to
           display the title to the user before or during retrieval,
           and also allows data which does not itself contain a title
           (e.g., image data) to be given one.

      o    There is provision for in-line non-text data (e.g., images,
           video, graphics, mathematical equations), which appears in
           the samewindow as the main textual material in the node.

      o    The concept of the relationship expressed by a hyperlink is
           expanded.  Both source and target anchors may contain
           relation attributes which point forwards and backwards
           respectively. Possible relationships include "is an index
           for", "is a glossary for", "annotates", "is a reply to", "is
           embedded in", "is presented with".  The last two are useful
           for multimedia - for instance, the "embed" relationship
           could cause a retrieved image to be fetched and embedded in
           the display of a text node, and the "present" relationship
           could cause a sound clip to be automatically retrieved and
           presented along with a text node.

   The HTTP2 protocol maintains the same stateless
   connect/request/response/close procedure as the current HTTP
   protocol.  Data is transferred in MIME-shaped messages, allowing all
   MIME data formats (including HTML) to be used.  As well as the GET
   operation, HTTP2 has operations such as:

Top      Up      ToC       Page 39 
    HEAD               Fetch attribute information about a node
                       (including the media type and encoding)


                       These allow nodes to be checked out for updating
                       and checked back in again, and new nodes to be
                       created.  New node data is supplied in MIME
                       shape with the request.

   The request from the client can contain a list of formats which the
   client is prepared to accept, user identification, authorisation
   information (a placeholder at present), an account name to charge any
   costs to, and identification of the source anchor of the hyperlink
   through which the node was accessed.

   The response from the server may contain a range of useful attributes
   (e.g., date, cost, length - but only for non-text data).  The server
   may redirect the query, indicating a new URL to use instead.  It may
   also refuse the request because of authorisation failure or absence
   of a charge account in the request.

   The protocol also contains a mechanism which is designed to allow the
   server to make an intelligent decision about the most appropriate
   format in which to return data, based on information supplied in the
   request by the client.  This may for instance allow a powerful server
   to store the uncompressed bitmap of an image, but to compress it on
   request using an appropriate encoding, according to the decoding
   capabilities announced by the client.

   An HTTP2 server and client are currently under test.  Some HTML2
   features are already fitted to the XMosaic browser.


   The Mosaic project, located at the US National Centre for
   Supercomputing Applications (NCSA) at the University of Illinois, is
   developing a networked information system intended for wide-area
   distributed asynchronous collaboration and hypermedia-based
   information discovery and retrieval.  Mosaic, which is specifically
   oriented towards scientific research workers, has adopted the World
   Wide Web as the core of the system, and the first Mosaic software to
   appear was the XMosaic WWW client for UNIX with X.  Other clients of
   similar functionality are under development for the Apple Macintosh
   and the PC with Windows.

   The capabilities of the XMosaic browser include:

Top      Up      ToC       Page 40 
      o    Support for NCSA's Data Management Facility (DMF) for
           scientific data.

      o    Support for transferring data with other NCSA tools such
           asCollage, using NCSA's Data Transfer Mechanism (DTM).

      o    The ability to "check out" documents for revision, and to
           check them back in again.

      o    Local and remote annotation of Web documents.

   Future planned functionality includes:

      o    In-line non-text data (in addition to images).

      o    Information space graphical representation and control.

      o    Hypermedia document editing.

      o    Information filtering.

   NCSA intends to make the entire Mosaic system publicly available and

   The XMosaic browser was used extensively for finding and retrieving
   information used to prepare this report.

   Web Publishing

   Making a web is as simple as writing a few SGML files which point to
   your existing data. Making it public involves running the FTP or HTTP
   daemon, and making at least one link into your web from another. In
   fact,  any file available by anonymous FTP can be immediately linked
   into a web. The very small start-up effort is designed to allow small

   At the other end of the scale, large information providers may
   provide an HTTP server with full text or keyword indexing. This may
   allow access to a large existing database without changing the way
   that database is managed. Such gateways have already been made into
   Digital's VMS/Help, Technical University of Graz's "Hyper-G", and
   Thinking Machine's WAIS systems.

   There are a few editors which understand HTML - for instance on UNIX
   and on the NeXT platform.

Top      Up      ToC       Page 41 
   Published non-text data

   See the multimedia demo node on:

   This contains links to images, sound, movies and postscript media
   types.  The media type is determined by the filename extension in the
   URL specification of the target node.  The (XMosaic) client uses this
   to invoke a separate program appropriate for displaying the media
   type, or in some cases it can be displayed embedded within the source
   document.  The latter method uses an <IMG> tag, which is part of


   WWW is a hypertext system and its underlying technology is thus
   richer than Gopher.  The use of SGML, which is of increasing
   importance in hypermedia systems, allows a great deal of
   expressiveness and structure, and enables text to be presented in an
   attractive way.  The facilities for multimedia data in the extended
   versions of HTTP and HTML are excellent.  It also seems that QOS and
   management issues identified in Chapter 2 are to some degree catered
   for in these extensions.


   There is no indication in the source anchor of the media type of the
   destination node, or of its size (this has been ruled out on the
   argument that the information is likely to degrade with time).  It is
   necessary to perform a HEAD request (in HTTP2) to deduce this.

   Link source anchors must be in text documents, so non-text nodes must
   be leaf nodes.  However, with HTML2 using the <IMG> tag, an embedded
   bitmap may be used as a source anchor, and the position of the mouse
   click within the image is passed to the server, which can then choose
   to return a different document depending on where in the image the
   mouse was clicked.

   WWW is much less prevalent than Gopher, partly because of an
   (erroneous?) perception that setting up an HTTP server is more
   complex than setting up a Gopher server.  There are only about 60
   servers world-wide; however the growth in the use of WWW is much
   faster than the growth in the use of Gopher.  The availability of
   sophisticated WWW clients such as XMosaic is fuelling this growth.

Top      Up      ToC       Page 42 
3.4. Evaluating Existing Tools

   This section compares the capabilities of the Gopher, WAIS and
   WorldWide Web systems (abbreviated as GWW) to the informal
   requirements defined in section 2.3.


   The table below gives the names of the most important client software
   for each of GWW on the three most important platforms of interest.
   WWW is the weakest, with clients for the Macintosh and the PC still
   under development.  The main PC Gopher client is "PC Gopher III",
   which is a DOS program, not a Windows program.

    CLIENTS      Gopher          WAIS                WWW

    Macintosh    TurboGopher     WAIStation          (No name)
                                                     (beta version

    PC with      HGopher (two    WAIS for            Cello (beta
    Windows      others also     Windows, WAIS       version
                 available)      Manager             available),
                                                     Mosaic (beta due

    UNIX with X  Xgopher,        XWAIS               XMosaic

   At present, multimedia support in most of these clients (where it
   exists) is limited to the invocation of external "viewer" programs
   for particular media types.  The exception is XMosaic, which supports
   in-line images in WWW documents.

   Media Types

   The GWW tools can all handle multiple media types well.

      o    Text is very well supported by all three tools.  WWW offers
           facilities for displaying "richer" text, supporting
           headings, lists, emphasised text etc., in a standardised way.

      o    Image data is also well supported, using either external
           viewers (e.g., the TurboGopher client software on a Macintosh
           might invoke the JPEGView program to display an image); or
           in-line display within a text document (WWW with XMosaic on

Top      Up      ToC       Page 43 
      o    There is little direct support for application-specific
           data, but most systems allow data of a nominated type to be
           passed to an external viewer or editor program.  This tends
           to be a function of the client software rather than being
           built in to the protocol or server.  There has been
           discussion in the WWW community about using TeX for
           representing mathematical equations, and about providing
           "panels" within a text document where a separate application
           could render its application-specific data (or indeed any
           data which can be represented spatially).  This latter
           suggestion fits well with the OLE (Object Linking and
           Embedding) approach used in Microsoft Windows.

      o    Sound can be supported through the external "viewer"
           concept. Some platforms don't have readily-available
           "viewers" with "tape recorder"-style controls for replaying.
           There is no single commonly-accepted sound encoding format.

      o    Video data can be handled using external viewers.  MPEG and
           QuickTime are the most common encodings.

   One essential capability of a client/server protocol is the ability
   for the client to determine the type of a node (and a list of
   available encodings) before downloading it.  WAIS and Gopher transfer
   this information in the result set and menu respectively.  WWW
   clients currently determine this information either from analysing
   the URL of a target node, or by the occurrence of the <IMG> tag.  The
   new WWW HTTP2 protocol allows the media type and encoding of a node
   to be determined through a separate interaction with the server.

   The GWW systems all use different methods for expressing type and
   encoding.  WAIS does not distinguish the encoding from the media
   type.  WWW is moving to the MIME type/encoding system.  Gopher does
   not distinguish type and encoding, but Gopher+ does, and is also
   moving to the MIME type/encoding system.


   Only the WWW system has hyperlinks.  Source anchors may be text,
   images, or points within an image.  Target anchors may be entire
   nodes of any media type, or points within (with HTTP2, portions of)
   text nodes.

   Gopher+ could potentially be enhanced to include hyperlinks, but
   there seems to be no development effort going towards this - those
   who need hyperlinking are using WWW.

Top      Up      ToC       Page 44 
   Gopher menus can be constructed to allow alternative views of
   gopherspace.  For instance, a geographically-organised menu tree of
   gopherspace is in place, but a parallel subject-based menu tree could
   be added as an alternative way of access to the same data.  (There
   are in fact moves to set this up.)  Since WWW offers a superset of
   Gopher functionality, these comments also apply to the Web.  In fact,
   the Web already has a rudimentary subject tree.

   In both Gopher and WWW, non-textual data may be used in different
   information structures without having to maintain more than one copy.


   There is little support in GWW for controlling the presentation of
   non-text data.

      o    Backdrops are not supported by GWW.

      o    Buttons are supported in a limited way - typically, a node
           is retrieved by clicking on a highlighted text phrase, or on
           an entry in a list.  In XMosaic, bitmap images can be used
           as buttons. However, there is no support for different
           styles of button.  Client software may have generic
           navigation buttons (e.g., "Back", "Next", "Home") which are
           always available and don't form part of a node.

      o    Synchronisation in space is not supported by GWW, except
           that WWW supports contextual synchronisation of images using
           the <IMG> tag.

      o    Synchronisation in time is not supported by GWW.


   WAIS supports keyword searching, and is very well suited for that
   task.  The Gopher+ protocol could potentially support multimedia
   database querying applications through the ASK attribute, but there
   is as yet no server implementation which supports such database
   applications.  In the WWW project, there are ongoing discussions on
   how best to extend HTML to cope with database query applications - an
   <INPUT> tag has been suggested - but no consensus has yet emerged.

   Both Gopher and WWW can make use of WAIS-type keyword searching:
   either by incorporating WAIS code into the server (enabling WAIS
   index files to be searched); or through WAIS gateways, which run
   searches on remote WAIS servers in response to queries from non-WAIS

Top      Up      ToC       Page 45 

   XMosaic allows users to make text (or on some platforms, audio)
   annotations to any text node.  The annotations appear at the end of
   the text display..  They are held locally - other users of the node
   do not see the annotations (but a recently added facility allows
   globally-visible annotations held on an "annotation server").  Text
   annotations may include hyperlinks to other nodes (provided the user
   knows how to use HTML).  Other clients do not provide such

   There is a move to add an "email" address notation to URL.  This
   would allow WWW client software to invoke a mail program when a user
   selects an anchor with such a URL.

   There are plans to allow WWW users to delineate a rectangular area of
   interest within an image for use in an HTTP request.

   There is no support in GWW clients for interacting with sequences of
   images in the way described in section 2.3.6.

   Quality of Service

   The user expectations for responsiveness mentioned in section 2.3.7
   are difficult to meet with currently-deployed wide-area network (or
   even LAN) technology, particularly for voluminous multimedia data.
   None of the GWW systems currently exploit the emerging isochronous
   data transfer capabilities of protocols such as RTP and technologies
   such as ATM.  None of them make serious attempts to alleviate the
   problem in other ways (except for WWW, which defines some mechanisms
   in HTTP2 for format negotiation based on size and available bandwidth


   The following table shows the support for three key management
   facilities in the GWW systems.  The first two facilities require
   support in the client/server protocol, the third requires support in
   the server, but depends on authentication being available.

                        Gopher         WAIS          WWW

    Access control      No             No1           Yes, in
    and                                              HTTP2

Top      Up      ToC       Page 46 
    Charging support    No             No            Yes, in

    Monitoring for      No             No            No
    statistical and


   1. "Access-control-facility" is a feature of Z39.50 which is not used
   by the current WAIS implementations.

   Scripting Requirements

   None of the GWW systems have facilities for the execution of scripts
   by the client, because of security issues (it would be too easy for a
   malicious "trojan" script to be executed).  Gopher and WWW servers
   have the ability for a UNIX script to be run by the server, with the
   script output returned to the client.  Scripting as understood in the
   context of stand-alone multimedia applications does not exist in GWW.

   Bytestream Format

   None of the three GWW systems use a bytestream format for
   interchanging collections of material.  There has been some talk
   about setting up a system akin to the "Trickle" mail server, for
   retrieving single document nodes from GWW using mail.  Such a system
   has been implemented for WWW.

   Authoring tools

   Gopher is sufficiently simple to set up that no special authoring
   tools are required.  WAIS requires only an indexing program (as
   discussed in section 3.2) for preparing material for publication.

   WWW, because it uses a sophisticated authoring language (HTML),
   benefits from the availability of authoring tools.  There are HTML
   editors for UNIX (using the tk toolkit) and the NeXT system.  There
   are no authoring tools designed specifically for exploiting the
   multimedia capabilities of WWW, mainly because these capabilities are
   still evolving.

Top      Up      ToC       Page 47 
4. Research

   This section describes some current research projects in the area of
   distributed hypermedia information systems.

4.1. Hyper-G

   Hyper-G [10] is an ambitious distributed hypermedia research project
   at a number of institutes of the IIG (Institutes for Information-
   Processing Graz), the Computing and Information Services Centre of
   the Graz University of Technology, and the Austrian Computer Society.
   It is funded by the Austrian Ministry of Science. It combines
   concepts of hypermedia, information retrieval systems and
   documentation systems with aspects of communication and
   collaboration, and computer-supported teaching and learning.

   Unlike WWW, Hyper-G supports bi-directional links.  This enables
   users to see which other documents reference the one they are using,
   and also allows the system to avoid dangling pointers when a linkedto
   document is deleted.  Another difference from WWW is that links are
   kept separately from their source and target nodes, to allow easy
   linking of read-only documents and for ease of link maintenance.  In
   addition to manually defined links, Hyper-G supports automatic static
   and dynamic (i.e., view-time) generation and maintenance of links.

   Hyper-G has a concept of generic "structures" - an additional layer
   of relationships imposed on (and orthogonal to) the web of documents
   and links.  A document can be part of more than one structure, and
   structures may be hierarchically related.  Types of structure

      o    "Clusters" are a set of documents which are all

      o    "Collections" are unordered sets of documents or other
           structures, and can be used as query domains or to construct
           gopher-like menus.

      o    "Paths" are ordered sets of documents or structures, which
           must be visited sequentially.

   One application of the structure concept is the provision of "guided
   tours" through the information space.

   In addition to hypernavigation, the collection hierarchy and guided
   tours, another strategy for interaction with the system is the use of
   database queries.  Two kinds of query are supported: keyword
   searching in a user-defined list of databases; and collection

Top      Up      ToC       Page 48 
   specific form-filling queries.  In the latter case, the answer to the
   query may appear dynamically as the form is filled out.

   Four modes of user identification are supported: "identified", where
   a userid is publicly associated through name and address information
   with a particular individual; "semi-identified", where a userid is
   associated by the system with an individual, but the user is only
   known to other users through a pseudonym; "anonymously identified",
   where the userid is not associated by the system with any individual;
   and "anonymous", where there is no userid (or a generic userid such
   as "guest").  Possible operations in the system depend on the user's
   mode of identification.  Users may access the system in any desired
   mode, and switch to other modes only when necessary.

   Hyper-G contains specific support for multilingual documents and
   document clusters.  Users may specify an ordered list of preferred
   languages, for instance.  There are plans to experiment with
   automatic translation programs.

   Integration of other, external, systems such as WWW into Hyper-G in a
   seamless manner is possible.

   Hyper-G is in use as a CWIS within Graz Technical University.  Client
   software is available for UNIX workstations from DEC, HP, SGI, and
   SUN.  The system is still in an experimental state, but it has been
   used by about 200 students as part of a course on the social impact
   of information technology.

4.2. Microcosm

   Microcosm [11] is an open hypermedia system developed at the
   University of Southampton.  It is implemented on the PC under MS
   Windows, and versions for the Apple Macintosh and for UNIX with X are
   under development.

   Microcosm consists of a number of autonomous processes which
   communicate with each other by a message-passing system.  Information
   about hyperlinks between documents is stored in a link database, or
   "linkbase", and is not stored in the documents themselves.  This has
   the advantages that:

      o    Links to and from read-only documents (perhaps stored on CD-
           ROM) are possible.

      o    Documents need undergo no conversion process to be imported
           into the system - they can still be viewed and edited using
           the original application which created them, without the
           link information getting in the way.

Top      Up      ToC       Page 49 
      o    It is as easy to establish links to and from non-text
           documents as text documents.

   In Microcosm, the user interacts with a "viewer" program for a
   particular media type.  Such programs may be specifically written for
   use with Microcosm (about 10 such viewers have been written for a
   number of common media types and encodings); or they may be a program
   adapted for use with Microcosm (the programmability of Microsoft Word
   for Windows has allowed it to be so adapted); or it may even be a
   program with no knowledge of Microcosm.

   The user selects an object (e.g., a piece of text) in the viewer, and
   requests Microcosm to perform an action with the object - typically
   to follow a link to another document.  This may involve executing
   another viewer to display the target document.

   Microcosm link source anchors may be specific (denoting a unique
   point in a particular document), local (denoting any occurrence of a
   particular object in a particular document) or generic (denoting any
   occurrence of an object in any document).  Target anchors may specify
   specific objects within a document.  Other link styles are
   textretrieval links (looking up a full-text index , as WAIS does),
   and relevance links to a set of documents using similar vocabulary to
   the source document (again, similar to WAIS's relevance feedback).

   Links may be created by readers as well as by authors.  Dynamically
   computed links may be added to the permanent linkbase for later use.
   A history of link traversal is maintained, and "guided tours" may be
   established through the system which allow the reader to stray from
   and return to the tour.

   Microcosm viewers operate by sending messages to the Microcosm
   system.  In MS Windows, these messages are transferred using DDE
   (Dynamic Data Exchange); in the Apple Macintosh version Apple Events
   are used, and sockets are used on UNIX.  For viewers which are not
   Microcosm aware, the user must transfer the selected object to the
   system clipboard before being able to follow a link from it.

   Networking support in Microcosm is currently under development.
   Components of Microcosm may be distributed to multiple machines there
   is not necessarily a concept of "client" and "server".

   There are problems with the Microcosm approach, common to systems
   which maintain link information separately from documents, and which
   use external viewers.

Top      Up      ToC       Page 50 
      o    Documents move and change, thus invalidating links.
           Microcosm datestamps links to help to detect (but not
           correct) such problems.

      o    It is not always clear what links are available to be
           followed from a document, since the viewer program is
           unaware of the contents of the linkbase.

      o    It is not always possible to indicate the object within a
           document which is the target anchor of a link.  Many viewers
           automatically show the start of the document (e.g., a word
           processor), or perhaps the entire document (e.g., a picture
           viewer).  The user has no way of knowing which part of the
           target document the link just followed points to.

   Microcosm may be viewed as an integrating hypermedia framework - a
   layer on top of a range of existing applications which enables
   relationships between different documents to be established.

   Microcosm is currently being "commercialised".

4.3. AthenaMuse 2

   AthenaMuse 2 (AM2) is an ambitious distributed hypermedia authoring
   and presentation system under development by the AthenaMuse Software
   Consortium based at MIT.  It is based on the earlier AM1 system
   developed as part of MIT's Project Athena.  The first version of AM2
   is scheduled for January 1994, and will be "pre-commercial software",
   with a fully-commercialised version due about 6 months later.  Both
   the educational and commercial sectors are the intended market.  The
   system will initially be based on X and UNIX workstations, but
   PC/Windows will also be supported in a second phase.  Apple Macintosh
   support has a lower priority.

   The specifications of AM2 are available in [12].  Some of the key
   points are:

      o    AM2 will support import and export of application from and
           tostandard forms.  The project is watching standards such as
           HyTime, MHEG and ODA.

      o    Several "application themes", or frequently-occurring
           collections of functionality, are viewed as useful.  These
           are as follows:

           Application Theme                         Interactive?
           Presentation of multimedia data           No
           Exploration of a rich multimedia          Yes

Top      Up      ToC       Page 51 
           Simulation of a real-world scenario       Partially
           Communication of real-time                No
           information to the user
           Authoring                                 Yes
           Annotation of material                    Yes

      o    "Interface templates" allow a multimedia application to make
           use of a common format for presenting a range of content.
           This is similar to the "backdrop" concept mentioned in
           section 2.3.4.

      o    A range of link types will be supported.

      o    Media content editors and interface/application editors for
           structuring will be provided.  A third class of editor, the
           "hypermedia notebook", will allow readers to excerpt and
           annotate media from AM2 applications.

   The project is developing multimedia network services, including the
   transmission of digital video, using a client-server paradigm.

4.4. CEC Research Programmes

   Some of the research programmes sponsored by the Commission for the
   European Community (CEC) contain apparently relevant projects. [1]
   has further details of some of these projects.

   RACE programme

   The RACE programme is outlined in [13], which should be consulted for
   further information about the projects described below.  The RACE
   programme targets the industrial, commercial and domestic sectors,
   and results are not necessarily directly applicable to the research
   and academic community.  RACE project numbers are given.

    RACE Phase I projects, which have mostly completed:

    R1038  MCPR - Multimedia Communication, Processing and
           Representation. This project developed a demonstrator
           multimedia system with communications capability for travel

    R1061  DIMPE - Distributed Integrated Multimedia Publishing
           Environment. The project designed and implemented interim
           services for compound document handling, and defined a
           distributed publishing architecture.

Top      Up      ToC       Page 52 
    R1078  European Museums Network. This project aimed to demonstrate
           interactive navigation through a pool of multimedia museum
           objects, using ISDN as the communications network.

    RACE Phase II projects:

    R2008  EuroBridge.

           Aims to demonstrate multi-point multimedia applications
           running over DQDB, FDDI and ATM test networks.

    R2043  RAMA - Remote Access to Museum Archives

           This project follows on from R1078.

    R2060  CIO - Coordination, Implementation and Operation of
           Multimedia Services.

           One aspect of this project is JVTOS - a "Joint Viewing and
           Teleoperation Service".  This aims to integrate standard
           multimedia applications running on a range of heterogeneous
           machines into a cooperative working environment, allowing
           individuals to view and interact with multimedia data on
           colleague's machines.

   ESPRIT Programme

   The ESPRIT research programme is outlined in [14], which should be
   consulted for further information about the projects listed below.
   ESPRIT project numbers are given.

    28     MULTOS - A Multimedia Filing System

           This project, which ran from 1985 to 1990, developed a
           client/server system for filing and retrieval of multimedia
           documents using the ODA interchange format standard (ODIF).

    5252   HYTEA - HyperText Authoring

           This project, which runs from 1991 to 1994, aims to develop
           a set of authoring tools for large and complex hypermedia

    5398   SHAPE - Second Generation Hypermedia Application Project

           This project is developing a portable software environment
           comparable to a CASE tool intended to facilitate the
           realisation of complex hypermedia applications.

Top      Up      ToC       Page 53 
    5633   HYTECH - Hypertextual and Hypermedial Technical
           Documentation This project, which ran from 1990-1991, was to
           assess the feasibility of hypermedia technology and to
           devise needed extensions to it in order to support
           applications dealing with technical documentation

    6586   PEGASUS - Distributed Multimedia Operating System for the
           1990s This project is aimed at the design of an operating
           system architecture for scalable distributed multimedia
           systems and the development of a validating prototype, the
           design and implementation of a distributed complex-object
           service and a global name service, the development of
           mechanisms for the creation, communication and rendering of
           fully digital multimedia documents in real time and in a
           distributed fashion, and the design and implementation of an
           application for the system: a digital TV director.

    6606   IDOMENEUS - Information and Data on Open Media for Networks
           of Users.  This project, which started January 1993, brings
           together workers in the database, information retrieval,
           networking and hypermedia research communities in the
           development of an "ultimate information machine".  It "will
           coordinate and improve European efforts in the development
           of next-generation information environments capable of
           maintaining and communicating a largely extended class of
           information on an open set of media".  Because of the close
           match between the subject of the IDOMENEUS project and the
           RARE WG-IMM, it is recommended that RARE establish a liaison
           with this project.

4.5. Other

   Some other research projects of less immediate relevance are listed
   below.  Some of these projects are described further in [1].

      o    Xanadu is a project to develop an "open, social hypermedia"
           distributed database server, incorporating CSCW features.
           It has been in existance for many years and has been funded
           by a number of companies.  The current status of this
           project is not known, and although iminent availability of
           alpha-test versions has been announced more than once, no
           software has been delivered.

      o    CMIFed [15] is an editing and presentation environment for
           portable hypermedia documents being developed at CWI,
           Amsterdam, NL. It is based on the "Amsterdam Model" of

Top      Up      ToC       Page 54 
           hypermedia [16], which is an extension of the Dexter
           hypertext reference model incorporating "channels" for media
           delivery and synchronisation constraints.

      o    Deja Vu [17] is a proposed "intelligent" distributed
           hypermedia application framework.  It is intended as a
           vehicle for research in the areas of: hypermedia systems,
           object-oriented programming, distributed logic programming,
           and intelligent information systems.  Proposed techniques
           for use in the Deja Vu framework include "inferential
           links", defined automatically according to predefined rules.
           A scripting language for use both by information providers
           and users is planned.  This project is at a very early
           (proposal) stage, and as yet relatively little software has
           been developed.  Deja Vu is intended principally as a
           research framework rather than as a service tool.

      o    Demon is a project at Bellcore, US,  investigating the
           network requirements of near-term residential multimedia
           services.  The project is designing and implementing an
           experimental application which serves the needs of casual
           multimedia users.

      o    InfoNote is a distributed, multiuser hypermedia system from
           Japan, implemented on a NEC EWS4800 running UNIX and X.
           InfoNote has an editor which can create Japanese texts,
           figures, and raster images.  The same windows are used both
           for editors and browsers. The functionality of the window
           can be changed at any time if data is not write-protected.

      o    MADE - Multimedia Application Demonstration Environment - is
           a project at British Telecom's research laboratory which
           centres on the use of the developing MHEG standard to access
           a multimedia object server.  The server platform is a Sun
           SPARCstation with an object-oriented database package
           (ONTOS).  Audio, video, text and graphical media types are
           covered.  The University of Kent is working on a sub-
           project: "Multi-user Indexing in a Distributed Multimedia

      o    Zenith aimed to establish a set of principles to assist
           designers and developers of object management systems
           intended for distributed multimedia design environments.
           The project implemented a prototype generalised multimedia
           object management system.

Next RFC Part