tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 1614


Network Access to Multimedia Information

Part 3 of 3, p. 55 to 79
Prev RFC Part


prevText      Top      Up      ToC       Page 55 
5. Standards

5.1. Structuring Standards

   This section describes some of the important standards for providing
   hyperstructure to multimedia data.


   SGML (Standard Generalized Markup Language - ISO 8879) is a
   metalanguage for defining markup notations for text.  SGML is used to
   write Document Type Definitions or DTDs, to which individual document
   instances must conform.  It finds application in a wide and
   increasing range of text processing applications.

   The relevance of SGML to distributed hypermedia systems is
   surprisingly high, mainly because of the great expressive power of
   SGML, and its ability to handle non-textual data using "external
   entities" and "notations".

      o    The World-Wide Web is an SGML application with its own DTD.

      o    The important HyTime hypermedia structuring standard (see
           below) is based on SGML.

      o    The forthcoming MHEG hypermedia structuring standard (see
           below) has an SGML encoding.

      o    SGML has been used in research hypermedia systems - for
           example Microcosm.

      o    SGML is used in some commercial hypermedia systems - for
           example DynaText.

      o    SGML is of increasing importance for academic publishing

   It was interesting to note that at a recent (CEC-sponsored) workshop
   on Hypertext and Hypermedia standards, most of the speakers were
   conversant with and supportive of the use of SGML for such systems.

   A related standard which may become important for SGML on networks is
   SDIF (SGML Data Interchange Format - ISO 9069).  This standard
   specifies how an SGML document, which may exist in a number of
   separate files of different media types, may be encoded using ASN.1
   into a single bytestream.  The entity structure is preserved, so that
   the bytestream may be decoded by the recipient into the same set of

Top      Up      ToC       Page 56 

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

   HyTime is based on SGML.  It is not itself an SGML DTD, but provides
   constructs and guidelines ("architectural forms") for making DTDs for
   describing Hypermedia documents.  For instance, the Standard Music
   Description Language (SMDL: ISO/IEC Committee Draft 10743) defines a
   (meta-)DTD which is an application of HyTime.  In fact, HyTime
   started as an attempt to produce a markup scheme for music publishing

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

      o    association of objects within documents with hyperlinks

      o    placement and interrelation of objects in space and time

      o    logical structure of the document

      o    inclusion of non-textual data in the document

   An "object" in HyTime is part of a document, and is unrestricted in
   form - it may be video, audio, text, a program, graphics, etc.  The
   terminology used in HyTime (and in this section) thus differs
   slightly from the terminology used in the rest of this report.  A
   HyTime object corresponds roughly to a node as defined in section
   1.2, and a HyTime document is a hyperdocument in the terminology of
   this report.

   HyTime consists of six modules, which are very briefly and
   selectively described below:

      o    Base module.  This provides facilities required by other
           modules, including a lexical model for describing element
           contents; facilities for identifying policies for coping
           with changes to a document, or traversing a link ("activity
           tracking"); and the ability to define "container entities"
           which can hold multiple data objects.  This last was added
           to the HyTime standard at a late stage, at the instigation
           of Apple Computers Inc, as a "hook" for their Bento
           specification [18].

Top      Up      ToC       Page 57 
      o    Measurement module.  This allows for an object to be located
           in time and/or space (which HyTime treats equivalently), or
           any other domain which can be represented by a finite
           coordinate space, within a bounding box called an "event",
           defined by a set of coordinate points.  Coordinates may be
           expressed in any units (predefined units include
           femtoseconds, fortnights, millenia, angstroms, Northern feet
           and lightyears!).

      o    Location Address module.  In addition to the fundamental
           ability of SGML to identify and refer to elements, this
           module provides a special "named location address"
           architectural form which can be used to refer indirectly to
           data which spans elements, or which is located in external
           entities.  Data may also be addressed indirectly through the
           use of "queries", which return addresses of objects within
           some domain which have properties matching the query.  A
           "HyQ" notation is provided for defining the query.

      o    Hyperlinks module.  Two basic types of hyperlink are
           defined: the contextual link (clink) has two anchors, one of
           which is embedded in a document to explicitly denote the
           anchor location; and the independent link (ilink) which may
           have more than two anchors, and which does not require the
           anchors to be embedded in the document. ilinks thus allow
           hyperlink information to be maintained separately from
           document content.

      o    Scheduling module.  This specifies how events in a source
           finite coordinate space (FCS) are to be mapped onto a target
           FCS.  For instance, events on a time axis could be projected
           onto a spatial axis for graphical display purposes, or a
           "virtual" time axis as used in music could be projected onto
           a physical time axis.

      o    Rendition module.  This allows for individual objects to be
           modified before rendition, in an object-specific way.  One
           example is modification of colours in image so that it can
           be displayed using the currently-selected colour map on a
           graphics terminal, or changing the volume of an audio
           channel according to a user's requirements.

   It is not envisaged that a hypermedia application would need to use
   the entire range of HyTime facilities.  An application designer is
   able to choose appropriate HyTime architectural forms, and to add
   application-specific constraints to them.  The designer may also of
   course use non-HyTime SGML elements and attributes, but these aspects
   of the application can't be understood by a "HyTime engine".  Even in

Top      Up      ToC       Page 58 
   the absence of a HyTime engine, the HyTime architectural forms
   provide a useful base of ideas from which a hypermedia system
   designer may wish to work.

   The role of a HyTime engine is not specified in the standard, but
   essentially it is a (sub)program which recognises HyTime constructs
   in document instances and performs application-independent processing
   on them.  For instance, it could interact with multimedia network
   servers to resolve and access hyperlink anchors.  A commercial HyTime
   engine (HyMinder) is under development by TechnoTeacher in the US,
   and the Interactive Multimedia Group at the University of
   Massachusetts - Lowell (contact is also
   working on a HyTime engine (HyOctane).

   The Davenport group (a loose consortium of interested companies and
   individuals) is producing a series of standards on hypermedia which
   further constrain the HyTime architectural forms.  One example is the
   SOFABED module [19], which standardises the representation of certain
   kinds of navigational information - tables of contents, indexes and

   HyTime was envisaged as an interchange format rather than as a format
   for directly-executable hypermedia applications.  It is therefore
   very expressive, but may be difficult to optimise for run-time

   An attempt has been made [20] to adapt the hyperlink structure in
   WWW's existing HTML DTD to comply with HyTime's clink architectural
   form.  This requires changes to WWW document instances as well as to
   browser software, and in the absence of any immediate benefit it has
   found little favour with the WWW community.  However, it is possible
   that HTML2 will use some aspects of HyTime.

   It is recommended that any further RARE work on networked hypermedia
   should take account of the importance of SGML and HyTime.


   MHEG stands for the Multimedia and Hypermedia information coding
   Experts Group, also known as ISO/IEC JTC1/SC29/WG12 (it used to come
   under SC2).  This group is developing a standard "Coded
   Representation of Multimedia and Hypermedia Information Objects" (ISO
   CD 13522, or CCITT T.171), commonly called MHEG.  The standard is to
   be published in two parts - part 1 being the base notation,
   representing objects using ASN.1, and part 2 being an alternate
   notation which uses SGML.  Part 1 has nearly (June 1993) achieved CD
   status, and is intended to reach full IS in 1994.  Part 2 is intended
   to reach the CD stage in late 1993.

Top      Up      ToC       Page 59 
   MHEG is suited to interactive hypermedia applications such as on-line
   textbooks and encyclopaedia.  It is also suited for many of the
   interactive multimedia applications currently available (in
   platformspecific form) on CD-ROM.  MHEG could for instance be used as
   the data structuring standard for a future home entertainment
   interactive multimedia appliance.  Telecommunications operators are
   interested in MHEG for providing interactive multimedia services
   across ISDN.

   To address such markets, MHEG represents objects in a non-revisable
   form, and is therefore unsuitable as an input format for hypermedia
   authoring applications: its place is perhaps more as an output format
   for such tools.  MHEG is thus not a multimedia document processing
   format - instead it provides rules for the structure of multimedia
   objects which permits the objects to be represented in a convenient
   "final" form with the aim of direct presentation.

   The MHEG draft standard is expressed in object-oriented terms.  The
   main object classes are outlined briefly below.

      o    Content class.  A content object contains the encoded
           (monomedia) information to be presented, along with
           attributes which identify the type of information and the
           encoding method, and mediaspecific attributes such as fonts
           used, sampling rate, image size, etc.

      o    Selection class and Modification class.  The user may
           interact with MHEG objects which inherit interactive
           behaviour from these classes.  (The MHEG object model
           supports multiple inheritance.)

      o    Action class.  Two types of action may be applied to
           objects: projection, which controls how objects are
           rendered; and status actions which affect the state of

      o    Link class.  MHEG hyperlinks connect a "start" object with
           one or more "end" objects.  Links consist of a set of
           conditions relating to the state of the start object, and a
           set of actions which are carried out when these conditions
           are satisfied.  Links also define the spatio-temporal
           relationships between objects.

      o    Script class.  Script objects are used to describe more
           complex interobject linkages (e.g., multiple-source links).
           MHEG does not define a scripting language - instead it
           provides a formalism for encapsulating scripts which may be
           executed by an external program (see SMSL below).

Top      Up      ToC       Page 60 
      o    Composite class.  Related objects may be grouped together
           into a single composite object (recursively).  The
           relationships between content objects within a composite
           object are determined by link and script objects which also
           are members of the composite object.

      o    Descriptor class.  Descriptor objects contain general
           information about sets of interchanged objects, so that a
           target system can ensure it has adequate resources to run
           the hypermedia application represented by the object set.

   The relationship between HyTime and MHEG has not yet been fully
   established.  One possible relationship [21] is that an MHEG
   application could be the output of a compilation process which used
   an equivalent HyTime document as input.  This approach would benefit
   both from the expressive power of HyTime and the run-time efficiency
   of MHEG.  However, it has yet to be shown that this is feasible,
   since the capabilities of HyTime and MHEG do not completely overlap.

   There seems to be relatively little interest in or awareness of MHEG
   within the Internet community, which is only just beginning to be
   aware of HyTime.  In view of the draft nature of the MHEG standard,
   this report recommends that RARE should not invest substantial effort
   in MHEG at this time.  However, particularly in view of the interest
   in it shown by PTTs, a watching brief should be kept on MHEG, as it
   may well be relevant in the future.


   The Open Document Architecture standard (ODA - ISO 8613 or T.140) is
   a compound document interchange format designed for transferring
   documents between open systems.  It is able to represent documents in
   both a formatted form and a processable (i.e., revisable) form, thus
   allowing both the content and the printed appearance of the document
   to be unambiguously transferred.

   In addition to text data, ODA supports graphics and image data.  A
   revised version to be published in 1993 will support colour.  Future
   developments include support for audio content (underway) and video
   content (planned).  An interface to MHEG is also planned.

   ODA differs from SGML in that the former concerns itself with the
   physical appearance of the document, while SGML deliberately avoids
   doing so.  SGML concerns itself with semantic markup, and can be used
   to describe a wide range of data and document architectures.  ODA has
   a more limited concept of a document.

Top      Up      ToC       Page 61 
   Hypermedia extensions to ODA (HyperODA) are underway.  The extensions
   will support:

      o    References to data held externally to the document (similar
           to SGML's external entities?).

      o    Non-linear structures, using contextual and independent
           hyperlinks based on the HyTime model.

      o    Temporal relationships between document components (e.g.,
           sequential, parallel, cyclic, duration, start delay).

   HyperODA is not being developed in competition to HyTime or MHEG its
   purpose is to add hypermedia features to ODA rather than to be a
   completely general framework for hypermedia applications.

   Bearing in mind that:

      o    the HyperODA extensions are still under development;

      o    in some senses ODA can be seen as a competitor to SGML,
           which has greater presence in the hypermedia world;

      o    there seems to be a lack of enthusiasm for ODA in the
           Internet community (the IETF WG on piloting ODA has

      o    Adobe's newly-released Acrobat technology (described below)
           will have a significant effect on the marketplace;

   this report recommends that ODA should not form a basis for
   investment in networked hypermedia technology by RARE.


   PREMO (Presentation Environment for Multimedia Objects) is a new work
   item in ISO/IEC JTC1/SC24 (the graphics standards subcommittee).  An
   initial draft [22] exists, and the schedule calls for a CD by June
   1994, a DIS by June 1995, and the final IS by June 1996.

   PREMO addresses the construction of, presentation of, and interaction
   with multimedia objects.  It specifies techniques for creating
   audiovisual interactive single and multiple media applications.  It
   is consistent with the principles of the Computer Graphics Reference
   Model (CGRM, ISO 11072), and is defined in object-oriented terms.

   It is not clear how PREMO relates to HyTime and MHEG.  Although these
   standards are listed in section 2 (References) of the initial draft,

Top      Up      ToC       Page 62 
   they appear not to be mentioned in the text.  The wisdom of
   developing what appears to be yet another structuring standard for
   multimedia data is doubtful.

   The PREMO work is not sufficiently advanced to permit a judgement of
   its usefulness in satisfying the requirements under discussion.


   Adobe, Inc. has introduced a new format called Acrobat PDF, which it
   is putting forward as a potential de facto standard for portable
   document representation.  Based on the Postscript page description
   language, Acrobat PDF is also designed to represent the printed
   appearance of a document (which may include graphics and images as
   well as text.  Unlike postscript however, Acrobat PDF allows data to
   be extracted from the document.  It is thus a revisable format.  It
   includes support for annotations, hypertext links, bookmarks and
   structured documents in markup languages such as SGML.  PDF files can
   represent both the logical and the formatting structure of the

   Acrobat PFD thus appears to offer very similar functionality to ODA.
   Adobe's successful Postscript de facto standard profoundly influenced
   information technology - it is possible that if successful, Acrobat
   PDF will be almost as important.  RARE should be aware of this
   technology and its potential impact on multimedia information

5.2. Access Mechanisms

   This section describes some standards which are useful in providing
   network access to multimedia data.  Of course, there are many
   multimedia transport protocols, which this report does not attempt to
   describe (see [1] for further information).  The protocols mentioned
   below are search/retrieve protocols which were not mentioned in [1].

   Multimedia Extensions to SQL

   A new work item in ISO (ISO/IEC JTC1 N2265) to extend the SQL
   standard to include multimedia data is expected to be approved
   shortly.  Initially this work will concentrate on developing a
   framework, and on free text data.  Support for non-text data will be
   added later, using a separate part of the standard for each media

   The expected timescale for this standardisation work is lengthy (part
   1 - the framework - is targeted for completion in 1996).

Top      Up      ToC       Page 63 
   There are suggestions that this standard could be used as a query
   language in conjunction with the HyQ query component of the HyTime


   DFR is the Document Filing and Retrieval system, specified in ISO
   10166-1 and ISO 10166-2.  It is intended for office automation
   applications, and falls within the Distributed Office Applications
   (DOA) model of ISO 10031-1.  DFR has design similarities to the ISO
   Directory and to the X.400 Message Store, and it is likewise part of

   DFR defines a Document Store, which provides a service to a DFR User
   over an OSI protocol stack incorporating ROSE (and optionally RTSE).
   A document in the Document Store may have a number of attributes
   associated with it, including pointers to related documents.  There
   is support for multiple versions of the same document, and for
   hierarchical groups of documents.  The access protocol supports
   searching for documents based on their attributes.  DFR itself does
   not restrict the content of documents in any way, but the natural
   partner to DFR is the ODA standard for document content.

   It is not clear that DFR offers significantly more useful
   functionality than is available from other, simpler access protocols
   already in use on the Internet.

5.3. Other Standards

   This section briefly describes other standards in this area and
   discusses their relevance.


   MIME (Multipurpose Internet Mail Extensions) is a mechanism for
   transferring multimedia information in an RFC822 mail message.  STD
   11, RFC 822 defines a message representation protocol which specifies
   considerable detail about message headers, but which leaves the
   message content as flat ASCII text.  RFC 1341 redefines the format of
   message bodies to allow multi-part textual and non-textual message
   bodies to be represented and exchanged without loss of information.
   Because RFC 822 said very little about message content, RFC 1341 is
   largely orthogonal to (rather than a revision of) RFC 822.

   MIME provides facilities to include multiple objects in a single
   message, to represent text in character sets other than US-ASCII, to
   represent formatted multi-font text messages, to represent non
   textual material such as images and audio fragments, and generally to

Top      Up      ToC       Page 64 
   facilitate later extensions defining new types of Internet mail for
   use by co-operating mail agents.  It does not define any structure to
   allow relationships between body parts within a message to be

   For the purposes of the requirements considered by this report, the
   relevance of MIME is that it separates media type from media
   encoding, and that it defines a procedure for registering values of
   these attributes.

   The MIME construct of chief interest is the "Content-Type" field.
   This contains a MIME "type" and "subtype", and any "parameters" which
   further qualify the subtype.  The register of MIME content-types is
   maintained by the Internet Assigned Numbers Authority (IANA). Content
   types defined in the MIME standard itself include:

Top      Up      ToC       Page 65 
    Type            Subtype       Parameters    Meaning

    text            plain         charset       Plain text

                    richtext      charset       Text with SGML-like
                                                markup for

    image           jpeg                        JPEG File Interchange

                    gif                         Graphics Interchange

    audio           basic                       8-bit -law 8kHz PCM

    video           mpeg

    application     ODA           profile       Open Document
    (used                         (Document     Architecture
    for                           Application   document.
    application                   Profile)

                    octet-        name (e.g.,   General binary data
                    stream        filename);    such as an arbitrary
                                  type (for     binary file.

                    postscript                  Document in

   Private experimental values of types and subtypes starting with X may
   be used between consenting adults without registration with IANA.

   MIME also defines a "Content-Transfer-Encoding" field, which is used
   to specify an invertible mapping between the "native" encoding of a
   media type and a representation that may be readily exchanged using
   7bit mail transfer protocols.

   WWW's HTTP2 protocol makes use of MIME media type and encoding
   attributes, and also uses MIME's message format for retrieving data

Top      Up      ToC       Page 66 
   from the server.  It is the first MIME application to utilise the
   8bit Content-Transfer-Encoding, which essentially means no encoding.


   SMSL is the Standard Multimedia Scripting Language.  It is a proposed
   new work item for ISO/IEC JTC1/SC18/WG8 (HyTime) and JTC1/SC29/WG12
   (MHEG).  The functional requirements are expected to be completed in
   1994, and the coding scheme completed in 1995.

   SMSL is designed as an open language with a similar purpose to
   existing vendor-specific scripting languages such as Macromind's
   "Lingo", Kaleida's "Script/X", and Gain's "GEL".  The intention is to
   offer an intermediate open multimedia scripting language which could
   be used both for interchange purposes, and for controlling the
   presentation of HyTime or MHEG multimedia structures.  Several
   different approaches to defining SMSL have been suggested, including
   using the ANDF (Architecture-Neutral Distribution Format) approach,
   and basing SMSL on SGML or on the Scheme language.

   The SMSL work is not sufficiently advanced to permit a judgement of
   its usefulness in satisfying the requirements under discussion.
   However, it is interesting to note that despite the descriptive power
   of HyTime and MHEG, there is still perceived to be a role for
   procedural scripting.


   The CCITT is defining a set of Audio Visual Interactive Services
   (AVIs), intended for offering to domestic and business consumers over
   a national network (e.g., by PTTs).  These services will be specified
   as T.17x recommendations, and will include MHEG.  These services
   would also make use of the SMSL work.

   Insufficient information is available about this area to allow its
   relevance to be judged.

5.4. Trade Associations

   This section mentions some trade associations which are involved in
   standards making in the multimedia area.

   Interactive Multimedia Association

   The Interactive Multimedia Association (IMA) is an international
   trade association with over 250 members, representing a wide spectrum
   of multimedia industry players.  Members include Apple, Microsoft,
   MIT CECI (the developers of AthenaMuse 2), 3DO, and many other

Top      Up      ToC       Page 67 
   important market actors.

   In 1989, the IMA initiated a "Compatibility Project", tasked with
   developing technical solutions to the cross-platform compatibility
   problem.  The Project has published two important documents:

      o    "Recommended Practices for Multimedia Portability" [23]
           outlines a specification for a common interface to be used
           by interactive video delivery systems.  It has been adopted
           by the US Military as part of Military Standard 1379.

      o    "Recommended Practices for Enhancing Digital Audio
           Compatibility in Multimedia Systems" [24] defines four
           standard digital audio data types and four sampling rates
           (from low-end -law 8kHz mono encoding, up through ADPCM
           modes to CD-quality 44kHz 16-bit stereo).

   Work is continuing to produce further recommendations on other

   The Compatibility Project has now initiated a procurement process by
   publishing three Request for Technology (RFT) documents, defining the
   requirements of a platform-independent interactive multimedia system,
   including networking requirements.  The RFTs cover "Multimedia System
   Services", a "Scripting Language for Interactive Multimedia Titles",
   and "Multimedia Data Exchange".  An "Architecture Reference Model"
   for cross-platform desktop and distributed multimedia systems
   provides the framework for these RFTs, which are pragmatic documents
   outlining the technical requirements for time-based media handling in
   detail.  Note that relatively little is said about non-time-based

   A first reading of the Multimedia Data Exchange RFT reveals that the
   Apple Bento standard [18] and the Microsoft/IBM RIFF format [25] both
   influenced the development of this document.  The selected system may
   well be based on one or both of these technologies.

   A joint response to the Multimedia System Services RFT has been
   received from HP, IBM and Sun.  Two responses to the Scripting
   Languages RFT have been received - from Kaleida (Script-X) and Gain
   Technology (GEL).  Two partial responses to the Multimedia Data
   Exchange RFT have been received from Apple (Bento) and Avid (Open
   Media Framework).

   Responses to the RFTs are currently being analysed by the IMA, and
   the result will be announced in November 1993.  The specifications
   which will eventually result from this process will be important for
   future commercial multimedia products.  It is important that the

Top      Up      ToC       Page 68 
   community keep a watching brief on the IMA Compatibility Project and
   its possible implications for distributed multimedia applications on
   the Internet.

   Multimedia Communications Forum

   The Multi-Media [sic] Communications Forum (MMCF) is a recently
   formed (June 1993) trade consortium whose initial members include
   IBM, National Semiconductor, Apple, Siemens and AT&T.  Intended to
   complement the work of the IMA, the MMCF plans to develop guidelines
   and recommendations for the industry to help ensure "end-to-end
   network interconnectivity of multimedia applications, workstations
   and devices".  They also plan to provide input to standards bodies.

   It is still too early to say whether this forum will succeed.  If the
   IMA Compatibility Project specifications, when they are published,
   leave networking issues open, then MMCF could have an important role
   to play.  It is recommended that RARE consider becoming an Observing

   Member ($350 US pa), entitling it to attend general and annual MMCF
   meetings (but not committee meetings), and to receive minutes and
   other general papers (but not working documents); with the prospect
   of becoming an Auditing Member ($1200 US pa) later if relevant.

   Multimedia Communications Community of Interest

   This is a very new organisation formed at a meeting in France in June
   1993.  Its charter is to promote the use of applications which let
   people in different locations view documents, images, graphics and
   full-motion video on a PC screen.  The remit includes CSCW aspects.
   Members of the organisation include IBM, Intel, Northern Telecom,
   Telstra (Australia), BT, France Telecom and DB Telekom.  The
   companies plan field trials of multimedia services in 1Q94.

6. Future Directions

6.1. General Comments on the State-of-the-Art

   Distributed hypermedia systems are now emerging from the research
   phase into the experimental deployment stage.  Every project team
   (and standards committee), almost without exception, hopes for their
   system to become the de facto standard for hypermedia.

   As we've seen, Gopher and WWW already offer multimedia capability,
   but they are still largely oriented to the use of external viewers
   for non-text nodes.  This "unintegrated" approach is in contrast to
   typical stand-alone multimedia applications, where the presentation
   of related information in different media is tightly integrated.  The

Top      Up      ToC       Page 69 
   in-line image feature of XMosaic and the new version of HTML
   currently under development may represent the start of a move towards
   greater integration of different media in such distributed hypermedia

   Three important factors in the design of distributed hypermedia
   systems appear to emerge from the preceding chapters of this report.
   They can each be formulated in terms of distinctions between two
   aspects of the system.

      o    A common and apparently fruitful approach to hypermedia
           systems is to distinguish the content from the
           hyperstructure.  Standards work clearly distinguishes
           between these concepts, with standards such as MPEG, JPEG,
           G.72x, etc, for content; and HyTime or MHEG for structure.
           Currently-deployed systems also make this distinction, most
           obviously in Gopher, where the structure/content split maps
           onto the server filesystem's directory/file split.  In a
           similar way, the ability to maintain hyperlink information
           separately from data is perceived in hypermedia research
           circles as a "good thing".  Research systems such as
           Microcosm and Hyper-G do this, and HyTime with its ilink
           element also supports it.  WWW does not support this, but
           requires link anchors to be edited into source data.  There
           are problems with this approach, however - see the section
           on Microcosm for details.

      o    A useful approach to content is to distinguish the media
           type from the media encoding.  The MIME standard (used by
           HTTP2) illustrates how this can be done, and Gopher+ employs
           a similar system.

      o    The distinction between data and protocol is also important
           for some systems.  WWW for instance has clearly separate
           protocol (HTTP) and data (HTML) specifications.  However,
           Gopher+ is specified without making this distinction.  (The
           original Gopher system is very simple and arguably has no
           need for such separation.)

   The most significant mismatches between the capabilities of
   currentlydeployed systems and user requirements are in the areas of
   presentation and quality of service.  Adding flexibility in
   presentation capabilities to WWW or Gopher should be possible without
   any major change to the protocols (although it may require changes to
   data formats).  Such capabilities could result from the progress
   towards greater integration of media types presaged above.  However,
   improving QOS is significantly more difficult, as it may require
   changes at a more fundamental level.  The following section outlines

Top      Up      ToC       Page 70 
   some possible solutions to this problem.

6.2. Quality of Service

   Meeting the responsiveness requirement is certainly the key factor
   for the acceptance of networked multimedia information systems in the
   user community.  To reiterate the requirement given in a previous

      o    For simple actions such as "next page", tolerable delays are
           of the order of 0.2s.

      o    For more complex actions such as "search for documents
           containing this word", then a tolerable delay is of the
           order of 2s.

      o    Users tend to give up waiting for a response after about

   There are several methods which may alleviate the problem of poor
   responsiveness (or cause the user to revise his or her expectations
   of responsiveness!), some of which are described below.

      1.   Give clues that fetching a particular item might be time-
           consuming - simply quoting the size (and/or location) may be
           sufficient. WAIS and some Gopher clients already quote the

      2.   Display a "progress" indicator while fetching data.

      3.   Allow the user to interact with other, previously fetched
           information while waiting for data to be retrieved.  The
           inability to do this is an annoying limitation of XMosaic.
           It can be difficult to implement, except on a multi-threaded
           operating system such as OS/2 or Windows NT.

      4.   Allow several fetches to be performed in parallel.  Again,
           multithreading support makes this easier.  This technique is
           less likely to be useful if all the nodes being requested
           come from the same server.
      5.   Pre-fetch information which the client software believes the
           user will wish to see next.  This requires some "hints" in
           the data about which nodes might be good candidates for pre-

      6.   Cache information locally.  The use of Universal Resource
           Numbers (see the section on WWW) is relevant for managing

Top      Up      ToC       Page 71 
      7.   Where multiple copies of the same information are held in
           different network locations, fetch the "nearest" copy.  This
           is sometimes known as "anycasting", and is a more general
           case of local caching.  The proposed URN-to-URL resolution
           service [26] could be used to support this.

      8.   When retrieving a document, the client should be able to
           display the first part of the document to the user.  The
           user can then start to read the document while the system is
           still downloading it.  Alternatively, the user may decide
           that the document is not relevant and abort the retrieval.

      9.   Offer multiple views of image or video data at different
           resolutions and therefore sizes.  This enables the user to
           select a balance between speed of retrieval and data
           quality.  Gopher+ and HTML2 both support this.

      10.  Future high-speed networks and protocols (ATM, RTP) will
           allow real-time display of isochronous data.  Information
           systems should be able to take advantage of this.

   A useful description of the problem is given in [27].  This paper
   rightly contends that the view, held by many hypermedia researchers
   and implementors, that the network is simply a transparent data
   highway which needs no special consideration in application design,
   is wrong.  It is argued that:

               "the very same structural characteristics that may make
               a multimedia document appealing to the end user are the
               characteristics that are extremely helpful during
               dynamic network performance optimisation".

   This is a particularly relevant statement considered in the light of
   suggestion 5 above.

6.3. Recommended Further Work

   To meet the needs of applications such as those described in section
   2.1, the community must seek where possible to adapt and enhance
   existing tools, not to build new ones.  There is now an opportunity
   for RARE to stimulate and encourage this process of adaptation and
   enhancement, and the following subsections outline a strategy for

Top      Up      ToC       Page 72 
   Selecting a System

   In order to have the greatest effect, RARE should concentrate its
   efforts on only one of the existing tools.  Candidate technologies
   are those already outlined: Gopher, WWW, WAIS, Hyper-G, Microcosm and
   AthenaMuse 2.

   It is recommended that RARE should select the World-Wide Web to
   concentrate its efforts on.  The reasons for this decision are as

      o    Flexibility.  The rich yet straightforward design of WWW,
           with its clearly separable components (HTML, URL and HTTP),
           means that it is a very flexible basis on which to develop
           distributed multimedia applications.

      o    Existing efforts.  The WWW implementor community is already
           discussing and designing extensions to HTML (HTML2),
           intended (among other things) to support multimedia.  There
           is clearly much interest in this area, and RARE efforts
           could complement existing work.

      o    Hyperlinks.  A clear requirement of many applications is the
           availability of hyperlinking, which WWW supports well.

      o    Integrated solution.  Because WAIS, Gopher and Hyper-G (as
           well as anonymous FTP servers) may all be accessed from Web
           clients, WWW serves as an important integrating tool for
           information services. It is important that distributed
           multimedia applications, which require extensive support in
           the client software, should be based on a technology "close
           to" such integrated clients.

      o    Penetration and growth.  Although Gopher far surpasses WWW
           in the number of servers available, the rate of growth in
           WWW usage is greater than that of Gopher.  There is an
           increasing realisation in the community that Gopher is over-
           simplistic for many purposes, and a corresponding increase
           in interest in WWW.

      o    Attention to QOS issues.  There is already an awareness in
           the WWW community of the need for achieving an appropriate
           QOS, and a mechanism has already been proposed in HTTP2 to
           alleviate the problem.

      o    Standardisation.  The WWW team is taking standardisation of
           the existing WWW system components seriously.  The URL
           format has already been published as an Internet draft (and

Top      Up      ToC       Page 73 
           has been adopted as an important component of the proposed
           Internet integrated information infrastructure), and the
           current version of HTML is about to follow suit.  The use of
           SGML as the basis of HTML complies with the perceived
           importance of SGML for hypermedia in general (and also fits
           in with RARE's approach of adopting appropriate open

      o    Software status.  CERN has recently placed the WWW code
           developed by it into the public domain.  This is unlike all
           the other candidate technologies, which all have
           restrictions on who can do what with the code.  In the case
           of Gopher, these restrictions are already causing some
           commercial users to look at other options.

   WWW has two significant disadvantages, both of which are being

      o    Restricted choice of client software.  At present, Apple
           Macintosh and PC/MS Windows clients are available in beta
           form only.  By contrast, there are more than one well-tested
           Gopher clients available for these platforms.

           However, other WWW clients for the Mac and MS Windows are in
           the pipeline.

      o    There is a perception in the community that making
           information available over HTTP is difficult, and that it
           must be put into HTML.

           However, it is possible to put plain-text, non-HTML
           documents onto the Web.  Such documents of course cannot
           contain links.

           Furthermore, WYSIWYG HTML text editors are available, to
           ease the pain of writing HTML.

   The main disadvantages of the other systems are:

      o    Gopher is designed for simplicity, and therefore lacks the
           flexibility of WWW.  In particular its structure is too
           inflexibly hierarchical and it does not have hyperlinks.
           Its main advantage is its very heavy penetration.  However,
           because of the WWW approach to accessing data using other
           protocols, all of gopherspace is part of the Web.  Any Web
           client should be able to be a gopher client too.

Top      Up      ToC       Page 74 
           It is neither envisaged that Gopher will go away, nor that
           it won't be used for multimedia data.  However, Gopher is
           unlikely to be used for more sophisticated multimedia
           applications such as academic publishing, interactive
           multimedia databases and CAL, because of the above-mentioned

      o    WAIS is a specialised tool, and will certainly form part of
           the overall solution, particularly for database-type
           applications.  It is not a general solution for distributed
           hypermedia applications.

      o    AthenaMuse 2 is commercially-oriented: it is clear that
           academic and research users will have to pay to use the
           software.  Its level of use is thus very unlikely to be as
           great as publiclyavailable systems such as WWW.  Moreover,
           it does not support all the required platforms.

      o    Microcosm network support is still in early stages, limited
           at present to the PC/Windows platform.  If it can be shown
           to perform adequately over a network, if it is capable of
           scaling to global levels, and if the advantages of
           maintaining link information separately from documents are
           found clearly to outweigh the consequent difficulties, it
           may become important in the future. Microcosm's authors need
           to ensure that the commercialisation of Microcosm does not
           hinder its adoption by the academic community.

      o    Hyper-G is more difficult to dismiss.  It is still in a
           relatively early stage of development, but appears to have
           many of the necessary features.  Its main disadvantages are:
           (a) the lack of penetration outside the University of Graz -
           the author is aware of only one other site using it; and (b)
           it is currently limited to UNIX only.  The author believes
           that, given WWW's head start in terms of deployment, and the
           current progress in adding multimedia facilities to it, WWW
           stands a much better chance than Hyper-G of being accepted
           as the de facto standard for distributed multimedia
           applications on the Internet.

   Directions for RARE

   Earlier in this report, it was noted that the most important areas
   where effort was needed were (a) provision of facilities for the
   integrated presentation of multimedia data (including synchronisation
   issues); and (b) ensuring adequate responsiveness.

Top      Up      ToC       Page 75 
   Bearing this in mind, it is recommended that RARE should invite
   proposals and (subject to funding being available) subsequently
   commission work to:

      1.   Develop conversion tools from commercial authoring packages
           to WWW, and establish authoring guidelines for authors who
           wish to use the conversion tools.  This is a significant and
           high-profile development aimed at enabling sophisticated
           multimedia applications to run over the network.  (Authoring
           guidelines will be necessary to enable authors to fit in
           with the Web's way of doing things, and to document features
           of the authoring package which should be avoided because of
           conversion difficulties.)

      2.   Implement and evaluate the most promising ways of overcoming
           the QOS problem.  This is an essential task without which
           interactive distributed multimedia applications cannot
           become a reality.  Some possibilities have already been
           outlined in the preceding chapter.

      3.   Implement a specific user project using these tools, in
           order to validate that the facilities being developed are
           truly relevant to actual user requirements.  It may be that
           partner funding from the selected user project would be

      4.   Use the experience gained from 1, 2 and 3 to inform and
           influence the further development of HTML2 and HTTP2 to
           ensure that they provide the required facilities.

      5.   Contribute to the development of the WWW clients
           (particularly the Apple Macintosh and PC/MS Windows clients)
           in terms of their multimedia data handling facilities.

   Although it is strictly speaking outside the remit of this report
   (since it is not specifically concerned with multimedia data), it is
   noted that the rapid growth of WWW may in the future lead to problems
   through the implementation of multiple, uncoordinated and mutually
   incompatible add-on features.  To guard against this trend, it may be
   appropriate for RARE, in coordination with CERN and other interested
   parties such as NCSA, to:

      6.   Encourage the formation of a consortium to coordinate WWW
           technical development (protocol enhancements, etc).

Top      Up      ToC       Page 76 
7. References

      [1]         "A Survey of Distributed Multimedia Research,
                  Standards and Products", ed. C. Adie, January 1993
                  (RARE Technical Report 5).

      [2]         "The Dexter Hypertext Reference Model", F. Halasz and
                  M. Schwartz, NIST Hypertext Standardisation Workshop,
                  January 1990.

      [3]         "Response Time and Display Rate in Human Performance
                  with Computers", B. Shneiderman, Comp. Surveys 16,

      [4]         "Gopher+: Proposed Enhancements to the Internet
                  Gopher Protocol", B. Alberti, F. Anklesaria, P. Linder,
                  M. McCahill, D. Torrey, Summer 1992.

      [5]         "WAIS Interface Protocol", F. Davies, B. Kahle, H.
                  Morris, J. Salem, T. Shen, R. Wang, J. Sui and M.
                  Grinbaum, April 1990.

      [6]         "Uniform Resource Locators", T. Berners-Lee, March
                  1993.  URL=

      [7]         "The HTTP Protocol as Implemented in W3", T. Berners-
                  Lee, January 1992.

      [8]         "Protocol for the Retrieval and Manipulation of
                  Textual and Hypermedia Information", T. Berners-Lee,
                  1993.  URL=

      [9]         "Hypertext Markup Language (HTML)", T Berners-Lee,
                  March 1993. URL=

      [10]        "Hyper-G: A Universal Hypermedia System", F. Kappe and
                  N. Sherbakov, March 1992. URL=ftp://iicm.tu-

Top      Up      ToC       Page 77 
      [11]        "Towards an Integrated Information Environment with
                  Open Hypermedia Systems", H. Davis, W. Hall, I. Heath,
                  G. Hill, Proceedings of the ACM Conference on
                  Hypertext, Milan 1992, p181-190.

      [12]        "The AthenaMuse 2 Functional Specification", L.
                  Bolduc, J. Culbert T. Harada, J. Harward, E.
                  Schlusselberg, May 1992.

      [13]        "Research and Technology Development in Advanced
                  Communications Technologies in Europe: RACE '92",
                  CEC, March 1992.  Available from:

      [14]        "Esprit Programme Synopses", CEC, October 1992.  In
                  seven volumes.  Available from

      [15]        "CMIFed: A Presentation Environment for Portable
                  Hypermedia Documents", G. van Rossum, J. Jansen, K. S.
                  Mullender, D. C. A. Bulterman, Amsterdam 1993 (also
                  presented at ACM Multimedia 93 conference).

      [16]        "The Amsterdam Hypermedia Model: extending hypertext
                  to support real multimedia", L. Hardman, D. C. A.
                  Bulterman, G. van Rossum, Amsterdam 1993

      [17]        "Deja-Vu Distributed Hypermedia Application
                  Framework", A. Eliens.

      [18]        "Bento Specification", J. Harris and I. Ruben, Apple
                  Computer Inc, August 1992.

      [19]        "Davenport Advisory Standard for Hypermedia (DASH),
                  Module I: Standard Open Formal Architecture for
                  Browsable Hypermedia Documents (SOFABED)", ed S. R.
                  Newcomb and V. T. Newcomb.

      [20]        Article in comp.text.sgml newsgroup, 24 May 1993, by
                  Eliot Kimber (

Top      Up      ToC       Page 78 
      [21]        "Emerging Hypermedia Standards" B. Markey, Multimedia
                  for Now and the Future (Usenix Conference
                  Proceedings), June 1991.

      [22]        "Initial Draft PREMO (Presentation Environment for
                  Multimedia Objects", ISO/IEC JTC1/SC24 N847, November

      [23]        "Recommended Practices for Multimedia Portability",
                  Release 1.1 October 1990, Interactive Multimedia
                  Association, 3 Church Circle, Suite 800, Annapolis,
                  MD 21401-1993, USA.

      [24]        "Recommended Practices for Enhancing Digital Audio
                  Compatability in Multimedia Systems", Release 3.00
                  1992, Interactive Multimedia Association, 3 Church
                  Circle, Suite 800, Annapolis, MD 21401-1993, USA.

      [25]        "RIFF Tagged File Format", Microsoft Inc, 1992.

      [26]        "A Vision of an Integrated Internet Information
                  Service", C. Weider and P. Deutsch, March 1993,
                  Work in Progress.

      [27]        "Delivering Interactive Multimedia Documents over
                  Networks", S. Loeb, IEEE Communications Magazine, May

      [28]        "A Status Report on Networked Information Retrieval:
                  Tools and Groups", ed. J. Foster, G. Brett and P.
                  Deutsch, March 1993.

Top      Up      ToC       Page 79 
8. Security Considerations

   Security issues are not discussed in this memo.

9. Author's Address

   Chris Adie
   Edinburgh University Computing Service
   University Library
   George Square
   Edinburgh EH8 9LJ
   United Kingdom

   Phone: +44 31 650 3363
   Fax:   +44 31 662 4809