doc: Add RFC documents

1 files changed, 4427 insertions, 0 deletions

diff --git a/doc/rfc/rfc1614.txt b/doc/rfc/rfc1614.txt
new file mode 100644
index 0000000..3ab44d0
--- /dev/null
+++ b/doc/rfc/rfc1614.txt
@@ -0,0 +1,4427 @@
+
+
+
+
+
+
+Network Working Group                                            C. Adie
+Request for Comments: 1614        Edinburgh University Computing Service
+RARE Technical Report: 8                                        May 1994
+Category: Informational
+
+
+                Network Access to Multimedia Information
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This report summarises the requirements of research and academic
+   network users for network access to multimedia information.  It does
+   this by investigating some of the projects planned or currently
+   underway in the community.  Existing information systems such as
+   Gopher, WAIS and World-Wide Web are examined from the point of view
+   of multimedia support, and some interesting hypermedia systems
+   emerging from the research community are also studied.  Relevant
+   existing and developing standards in this area are discussed.  The
+   report identifies the gaps between the capabilities of
+   currentlydeployed systems and the user requirements, and proposes
+   further work centred on the World-Wide Web system to rectify this.
+
+   The report is in some places very detailed, so it is preceded by an
+   extended summary, which outlines the findings of the report.
+
+Publication History
+
+   The first edition was released on 29 June 1993.  This second edition
+   contains minor changes, corrections and updates.
+
+Table of Contents
+
+    Acknowledgements                                                2
+    Disclaimer                                                      2
+    Availability                                                    3
+    0. Extended Summary                                             3
+    1. Introduction                                                10
+      1.1. Background                                              10
+      1.2. Terminology                                             11
+    2. User Requirements                                           13
+      2.1. Applications                                            13
+      2.2. Data Characteristics                                    18
+
+
+
+Adie                                                            [Page 1]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      2.3. Requirements Definition                                 19
+    3. Existing Systems                                            24
+      3.1. Gopher                                                  24
+      3.2. Wide Area Information Server                            30
+      3.3. World-Wide Web                                          34
+      3.4. Evaluating Existing Tools                               42
+    4. Research                                                    47
+      4.1. Hyper-G                                                 47
+      4.2. Microcosm                                               48
+      4.3. AthenaMuse 2                                            50
+      4.4. CEC Research Programmes                                 51
+      4.5. Other                                                   53
+    5. Standards                                                   55
+      5.1. Structuring Standards                                   55
+      5.2. Access Mechanisms                                       62
+      5.3. Other Standards                                         63
+      5.4. Trade Associations                                      66
+    6. Future Directions                                           68
+      6.1. General Comments on the State-of-the-Art                68
+      6.2. Quality of Service                                      70
+      6.3. Recommended Further Work                                71
+    7. References                                                  76
+    8. Security Considerations                                     79
+    9. Author's Address                                            79
+
+Acknowledgements
+
+   The following people have (knowingly or unknowingly) helped in the
+   preparation of this report: Tim Berners-Lee, John Dyer, Aydin Edguer,
+   Anton Eliens, Tony Gibbons, Stewart Granger, Wendy Hall, Gary Hill,
+   Brian Marquardt, Gunnar Moan, Michael Neuman, Ari Ollikainen, David
+   Pullinger, John Smith, Edward Vielmetti, and Jane Williams.  The
+   useful role which NCSA's XMosaic information browser tool played in
+   assembling the information on which this report was based should also
+   be acknowledged - many thanks to its developers.
+
+   All trademarks are hereby acknowledged as being the property of their
+   respective owners.
+
+Disclaimer
+
+   This report is based on information supplied to or obtained by
+   Edinburgh University Computing Service (EUCS) in good faith.  Neither
+   EUCS nor RARE nor any of their staff may be held liable for any
+   inaccuracies or omissions, or any loss or damage arising from or out
+   of the use of this report.
+
+
+
+
+
+Adie                                                            [Page 2]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   The opinions expressed in this report are personal opinions of the
+   author.  They do not necessarily represent the policy either of RARE
+   or of ECUS.
+
+   Mention of a product in this report does not constitute endorsement
+   either by EUCS or by RARE.
+
+Availability
+
+   This document is available in various forms (PostScript, text,
+   Microsoft Word for Windows 2) by anonymous FTP through the following
+   URL:
+
+    ftp://ftp.edinburgh.ac.uk/pub/mmaccess/
+
+    ftp://ftp.rare.nl/rare/pub/rtr/rtr8-rfc.../
+
+    Paper copies are available from the RARE Secretariat.
+
+0. Extended Summary
+
+   Introduction
+
+   This report is concerned with issues in the intersection of
+   networked information retrieval, database and multimedia
+   technologies.  It aims to establish research and academic user
+   requirements for network access to multimedia data, to look at
+   existing systems which offer partial solutions, and to identify
+   what needs to be done to satisfy the most pressing requirements.
+
+   User Requirements
+
+   There are a number of reasons why multimedia data may need to be
+   accessed remotely (as opposed to physically distributing the data,
+   e.g., on CD-ROM).  These reasons centre on the cost of physical
+   distribution, versus the timeliness of network distribution.  Of
+   course, there is a cost associated with network distribution, but
+   this tends to be hidden from the end user.
+
+   User requirements have been determined by studying existing and
+   proposed projects involving networked multimedia data.  It has
+   proved convenient to divide the applications into four classes
+   according to their requirements: multimedia database applications,
+   academic (particularly scientific) publishing applications, cal
+   (computeraided learning), and general multimedia information
+   services.
+
+
+
+
+
+Adie                                                            [Page 3]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Database applications typically involve large collections of
+   monomedia (non-text) data with associated textual and numeric
+   fields. They require a range of search and retrieval techniques.
+
+   Publishing applications require a range of media types,
+   hyperlinking, and the capability to access the same data using
+   different access paradigms (search, browse, hierarchical, links).
+   Authentication and charging facilities are required.
+
+   Cal applications require sophisticated presentation and
+   synchronisation capabilities, of the type found in existing
+   multimedia authoring tools.  Authentication and monitoring
+   facilities are required.
+
+   General multimedia information services include on-line
+   documentation, campus-wide information systems, and other systems
+   which don't conveniently fall into the preceding categories.
+   Hyperlinking is perhaps the most common requirement in this area.
+
+   The analysis of these application areas allows a number of
+   important user requirements to be identified:
+
+      o    Support for the Apple Macintosh, UNIX and PC/MS Windows
+           environments.
+
+      o    Support for a wide range of media types - text, image,
+           graphics and application-specific media being most
+           important, followed by video and sound.
+
+      o    Support for hyperlinking, and for multiple access structures
+           to be built on the same underlying data.
+
+      o    Support for sophisticated synchronisation and presentation
+           facilities.
+
+      o    Support for a range of database searching techniques.
+
+      o    Support for user annotation of information, and for user-
+           controlled display of sequenced media.
+
+      o    Adequate responsiveness - the maximum time taken to retrieve
+           a node should not exceed 20s.
+
+      o    Support for user authentication, a charging mechanism, and
+           monitoring facilities.
+
+      o    The ability to execute scripts.
+
+
+
+
+Adie                                                            [Page 4]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      o    Support for mail-based access to multimedia documents, and
+           (where appropriate) for printing multimedia documents.
+
+      o    Powerful, easy-to-use authoring tools.
+
+   Existing Systems
+
+   The main information retrieval systems in use on the Internet are
+   Gopher, Wais, and the World-Wide Web.  All work on a client-server
+   paradigm, and all provide some degree of support for multimedia data.
+
+   Gopher presents the user with a hierarchical arrangement of nodes
+   which are either directories (menus), leaf nodes (documents
+   containing text or other media types), or search nodes (allowing some
+   set of documents to be searched using keywords, possibly using WAIS).
+   A range of media types is supported.  Extensions currently being
+   developed for Gopher (Gopher+) provide better support for multimedia
+   data.  Gopher has a very high penetration (there are over 1000 Gopher
+   servers on the Internet), but it does not provide hyperlinks and is
+   inflexibly hierarchical.
+
+   Wais (Wide Area Information Server) allows users to search for
+   documents in remote databases.  Full-text indexing of the databases
+   allows all documents containing particular (combinations of) words to
+   be identified and retrieved.  Non-text data (principally image data)
+   can be handled, but indexing such documents is only performed on the
+   document file name, severely limiting its usefulness.  However, WAIS
+   is ideally suited to text search applications.
+
+   World-Wide Web (WWW) is a large-scale distributed hypermedia system.
+   The Web consists of nodes (also called documents) and links.  Links
+   are connections between documents: to follow a link, the user clicks
+   on a highlighted word in the source document, which causes the
+   linkedto document to be retrieved and displayed.  A document can be
+   one of a variety of media types, or it can be a search node in a
+   similar sense to Gopher.  The WWW addressing method means that WAIS
+   and Gopher servers may also be accessed from (indeed, form part of)
+   the Web.  WWW has a smaller penetration than Gopher, but is growing
+   faster.  The Web technology is currently being revised to take better
+   account of the needs of multimedia information.
+
+   These systems all go some way to meet the user requirements.
+
+      o    Support for multiple platforms and for a wide range of media
+           types (through "viewer" software external to the client
+           program) is good.
+
+      o    Only WWW has hyperlinks.
+
+
+
+Adie                                                            [Page 5]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+      o    There is little or no support for sophisticated presentation
+           and synchronisation requirements.
+
+      o    Support for database querying tends to be limited to
+           "keyword" searches, but current developments in Gopher and
+           WWW should make more sophisticated queries possible.
+
+      o    Some clients support user annotation of documents.
+
+      o    Response times for all three systems vary substantially
+           depending on the network distance between client and server,
+           and there is no support for isochronous data transfer.
+
+      o    There is little in the way of authentication, charging and
+           monitoring facilities, although these are planned for WWW.
+
+      o    Scripting is not supported because of security issues
+
+      o    WWW supports a mail responder.
+
+      o    The only system sufficiently complex to warrant an authoring
+           tool is WWW, which has editors to support its hypertext
+           markup language.
+
+   Research
+
+   There are a number of research projects which are of significant
+   interest.
+
+   Hyper-G is an ambitious distributed hypermedia research project at
+   the University of Graz.  It combines concepts of hypermedia,
+   information retrieval systems and documentation systems with aspects
+   of communication and collaboration, and computer-supported teaching
+   and learning.  Automatic generation of hyperlinks is supported, and
+   there is a concept of generic structures which can exist in parallel
+   with the hyperlink structure.  Hyper-G is based on UNIX, and is in
+   use as a CWIS at Graz.  Gateways between Hyper-G and WWW exist.
+
+   Microcosm is a PC-based hypermedia system developed at the University
+   of Southampton.  It can 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.
+   Hyperlinks are maintained separately from the data.  Networking
+   support for Microcosm is currently under development, as are versions
+   of Microcosm for the Apple Macintosh and for UNIX.  Microcosm is
+   currently being "commercialised".
+
+
+
+
+Adie                                                            [Page 6]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   AthenaMuse 2 is an ambitious distributed hypermedia authoring and
+   presentation system under development by a university/industry
+   consortium based at MIT.  It will have good facilities for
+   presentation and synchronisation of multimedia data, strong authoring
+   support, and will include support for networking isochronous data. It
+   will be a commercial product.  Initial versions will support UNIX and
+   X windows, with a PC/MS Windows version following.  Apple Macintosh
+   support has lower priority.
+
+   The "Xanadu" project is designing and building an "open, social
+   hypermedia" distributed environment, but shows no sign of delivering
+   anything after several years of work.
+
+   The European Commission sponsors a number of peripherally relevant
+   projects through its Esprit and RACE research programmes.  These
+   programmes tend to be oriented towards commercial markets, and are
+   thus not directly relevant.  An exception is the Esprit IDOMENEUS
+   project, which brings together workers in the database, information
+   retrieval and multimedia fields.  It is recommended that RARE
+   establish a liaison with this project.
+
+   There are a variety of other academic and commercial research
+   projects which are also of interest.  None of them are as directly
+   relevant as those outlined above.
+
+   Standards
+
+   There are a number of existing and emerging standards for structuring
+   hypermedia applications.  Of these, the most important are SGML,
+   HyTime, MHEG, ODA, PREMO and Acrobat.  All bar the last are de jure
+   standards, while Acrobat is a commercial product which is being
+   proposed as a de facto standard.
+
+   SGML (Standard Generalized Markup Language) is a markup language for
+   delimiting the logical and semantic content of text documents.
+   Because of its flexibility, it has become an important tool in
+   hypermedia systems.  HyTime is an ISO standardised infrastructure for
+   representing integrated, open hypermedia documents, and is based on
+   SGML.  HyTime has great expressive power, but is not optimised for
+   run-time efficiency.  It is recommended that future RARE work on
+   networked hypermedia should take account of the importance of SGML
+   and HyTime.
+
+   MHEG (Multimedia and Hypermedia information coding Experts Group) is
+   a draft ISO standard for representing hypermedia applications in a
+   platform-independent form.  It uses an object-oriented approach, and
+   is optimised for run-time efficiency.  Full IS status for MHEG is
+   expected in 1994.  It is recommended that RARE keep a watching brief
+
+
+
+Adie                                                            [Page 7]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   on MHEG.
+
+   The ODA (Open Document Architecture) standard is being enhanced to
+   incorporate multimedia and hypermedia features.  However, interest in
+   ODA is perceived to be decreasing, and it is recommended that ODA
+   should not form a basis for further RARE work in networked
+   hypermedia.
+
+   PREMO is a new work item in the ISO graphics standardisation
+   community, which appears to overlap with MHEG and HyTime.  It is not
+   clear that the PREMO work, which is at a very early stage, is
+   worthwhile in view of the existence of those standards.
+
+   Acrobat PDF is a format for representing multimedia (printable)
+   documents in a portable, revisable form.  It is based on Postscript,
+   and is being proposed by Adobe Inc (originators of Postscript) as an
+   industry standard.  RARE should maintain awareness of this technology
+   in view of its potential impact on multimedia information systems.
+
+   There are various standards which have relevance to the way
+   multimedia data is accessed across the network.  Many of these have
+   been described in a previous report [1].  Two further access
+   protocols are the proposed multimedia extensions to SQL, and the
+   Document Filing and Retrieval protocol.  Neither of these are likely
+   to have major significance for networked multimedia information
+   systems.
+
+   Other standards of importance include:
+
+      o    MIME, a multimedia email standard which defines a range of
+           media types and encoding methods for those types which are
+           useful in a wider context.
+
+      o    AVIs (Audio-Visual Interactive services) and the associated
+           multimedia scripting language SMSL, which form a
+           standardisation initiative within CCITT (now ITU-TSS) to
+           specify interactive multimedia services which can be
+           provided across telephone/ISDN networks.
+
+   There are two important trade associations which are involved in
+   standardisation work.  The Interactive Multimedia Association (IMA)
+   has a Compatibility Project which is developing a specification for
+   platform-independent interactive multimedia systems, including
+   networking aspects.  A newly-formed group, the Multimedia
+   Communications Forum (MMCF), plans to provide input to the standards
+   bodies.  It is recommended that RARE become an Observing Member of
+   the MMCF.  A third trade association - the Multimedia Communications
+   Community of Interest - has also just been formed.
+
+
+
+Adie                                                            [Page 8]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Future Directions
+
+   Three common design approaches emerge from the variety of systems and
+   standards analysed in this report.  They can be described in terms of
+   distinctions between different aspects of the system:
+
+      o    content is distinct from hyperstructure
+
+      o    media type is distinct from media encoding
+
+      o    data is distinct from protocol
+
+   Distributed hypermedia systems are emerging from the
+   research/development phase into the experimental deployment phase.
+   However, the existing global information systems (Gopher, WAIS and
+   WWW) are still largely limited to the use of external viewers for
+   nontextual data.  The most significant mismatches between the
+   capabilities of currently-deployed systems and user requirements are
+   in the areas of presentation and quality of service (i.e.,
+   responsiveness).
+
+   Improving QOS is significantly more difficult than improving
+   presentation capabilities, but there are a number of possible ways in
+   which this could be addressed.  Improving feedback to the user,
+   greater multi-threading of applications, pre-fetching, caching, the
+   use of alternative "views" of a node, and the use of isochronous data
+   streams are all avenues which are worth exploring.
+
+   In order to address these problems, it is recommended that RARE seek
+   to adapt and enhance existing tools, rather than develop new ones.
+
+   In particular, it is recommended that RARE select the World-Wide Web
+   to concentrate its efforts on.  The reasons for this choice revolve
+   around the flexibility of the WWW design, the availability of
+   hyperlinks, the existing effort which is already going into
+   multimedia support in WWW, the fact that it is an integrating
+   solution incorporating both WAIS and Gopher support, and its high
+   rate of growth compared to Gopher (despite Gopher's wider
+   deployment).  Gopher is the main competitor to WWW, but its
+   inflexibly hierarchical structure and the absence of hyperlinks make
+   it difficult to use for highly-interactive multimedia applications.
+
+   It is recommended that RARE should invite proposals for and
+   subsequently commission work to:
+
+      o    Develop conversion tools from commercial multimedia
+           authoring packages to WWW, and accompanying authoring
+           guidelines.
+
+
+
+Adie                                                            [Page 9]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      o    Implement and evaluate the most promising ways of overcoming
+           the QOS problem.
+
+      o    Implement a specific user project using these tools, to
+           validate that the facilities being developed are truly
+           relevant to real applications.
+
+      o    Use the experience gained to inform and influence the
+           development of the WWW technology.
+
+      o    Contribute to the development of PC/MS Windows and Apple
+           Macintosh WWW clients, particularly in the multimedia data
+           handling area.
+
+   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:
+
+      o    Encourage the formation of a consortium to coordinate WWW
+           technical development.
+
+1. Introduction
+
+1.1. Background
+
+   This study was inspired by the realisation that while some aspects of
+   distributed multimedia technology are being actively introduced into
+   the European research community (for instance, audiovisual
+   conferencing, through the MICE project), other aspects are receiving
+   less attention.  In particular, one category in which there seems to
+   be relatively little activity is providing solutions to ease remote
+   access to multimedia resources (for instance, accessing stored
+   audio/video clips or images, or indeed entire multimedia
+   applications, across the network).  Few commercial products address
+   this, and the relevance of existing standards in this area is
+   unclear.
+
+   Of the 50 or so research projects documented in the recent RARE
+   distributed multimedia survey [1], only about six have a direct
+   relevance to this application area.  Where stated in the survey, the
+   main research effort in these projects is often directed towards the
+   "difficult" problems, such as the transfer of isochronous data and
+   the design and implementation of object-oriented multimedia
+   databases, rather than towards user-oriented issues.
+
+
+
+
+
+Adie                                                           [Page 10]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   This report is concerned with practical issues in the intersection of
+   networked information retrieval, database and multimedia
+   technologies.  It aims to establish actual user requirements in this
+   area, to look at existing systems which offer partial solutions, and
+   to identify what additional work needs to be done to satisfy the most
+   pressing requirements.
+
+1.2. Terminology
+
+   In order to discuss multimedia information systems, we need a
+   consistent terminology.  The vocabulary defined below embodies some
+   of the concepts of the Dexter hypertext reference model [2].  This
+   model is sufficiently general to be useful for describing most of the
+   facilities and requirements of the multimedia information systems
+   described in this report.  (However, the Dexter model does not
+   describe searchable index objects - it is not a database reference
+   model.)
+
+    anchor             An identified portion of a node.  E.g., in a text
+                       node, an anchor might be a string of one or more
+                       adjacent characters, while in an image node it
+                       might be a rectangular area of the image.
+
+    composite node     A node containing data of multiple media types.
+
+    document           Often used loosely as a synonym for node.
+
+    hyperdocument      We refer to a collection of related nodes,
+                       linked internally with hyperlinks, as a
+                       "hyperdocument".  Examples are a database of
+                       medical images and associated text; a module
+                       from a suite of teaching material; or an article
+                       in a scientific journal.  A hyperdocument may
+                       contain hyperlinks to other data which exists in
+                       internally with hyperlinks, as a
+                       "hyperdocument". Examples are a other
+                       hyperdocuments, but can be viewed as largely
+                       self-contained.  It is a highlevel "unit of
+                       authoring", but is not necessarily perceived as
+                       a distinct unit by a reader (although it may be
+                       so perceived, particularly if it contains few
+                       hyperlinks to outside entities).
+
+    hyperlink          Set of one or more source anchors and one or
+                       more target anchors.  Also known simply as a
+                       "link".
+
+
+
+
+
+Adie                                                           [Page 11]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+    isochronous (adjective) Describes a continuous flow of data which
+                       is required to be delivered by the network under
+                       critical time constraints.
+
+    leaf node          A node which contains no source anchors.
+
+    media type         An attribute of data which describes the general
+                       nature of its expected presentation.  The value
+                       of this attribute could be one of the following
+                       (not exhaustive) list:
+
+                       o Text
+
+                       o Sound
+
+                       o Image (e.g., a "photograph")
+
+                       o Graphics (e.g., a "drawing")
+
+                       o Animation (i.e., moving graphics)
+
+                       o Movie (i.e., moving image)
+
+    monomedia (adjective)   Said of data which is all of the same media
+                       type.
+
+    multimedia (adjective)  Said of data which contains different media
+                       types.  This definition is stricter than general
+                       usage, where "multimedia" is often  used as a
+                       generic term for non-textual data, and where it
+                       may even be used as a noun.
+
+    physical media     Magnetic or optical storage.  Not to be confused
+                       with media type!
+
+    [simple] node      A monomedia object which may be retrieved and
+                       displayed as a single unit.
+
+    source anchor      An anchor which may be "actioned" by the user,
+                       causing the node(s) containing the target
+                       anchor(s) in the same hyperlink to be retrieved
+                       and displayed.  This process is called
+                       "traversing the link".
+
+    target anchor      an anchor forming part of a hyperlink, whose
+                       containing node is retrieved and displayed when
+                       the hyperlink is traversed.
+
+
+
+
+Adie                                                           [Page 12]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+2. User Requirements
+
+   User requirements in an area such as networking, which is subject to
+   rapid technological change, are sometimes difficult to identify.  To
+   an extent, technology leads applications, and users will exploit what
+   is possible.
+
+2.1. Applications
+
+   Awareness of the range of networked multimedia applications which are
+   currently being envisaged by computer users in the academic and
+   research community leads to a better understanding of the technical
+   requirements.  This section outlines some projects which require
+   remote access to multimedia information across research networks, and
+   which are currently either at a preliminary stage or underway.  The
+   projects are divided into broad categories according to their
+   characteristics.
+
+   Multimedia Databases
+
+   Here are several examples of multimedia projects which have a
+   "database" character.
+
+   The Peirce Telecommunity Project
+
+      This project centres on the construction of a multimedia (text and
+      image) database of the works of the American philosopher Peirce,
+      together with tools to process the data and to make it available
+      over the Internet.  A sub-project at Brown University focuses on
+      adapting existing client/server network tools for this purpose.
+      The requirements for network access include facilities for
+      structured viewing, intelligent retrieval, navigation, linking,
+      and annotation, as well as for domainspecific processing.
+
+   Museum Object Databases
+
+      The RAMA (Remote Access to Museum Archives) project is funded
+      under the EEC RACE II programme.  Its objective is to develop a
+      system which allows museums to make multimedia information about
+      their exhibits and archived material available over an ISDN
+      network.  The requirements capture and technical architecture
+      design phases are now complete, and a prototype system will be
+      delivered in June 1993 to link the Ashmolean Museum (Oxford, GB),
+      the Musee d'Orsay (Paris, FR) and the Museum Archeological
+      National (Madrid, ES).  Image data is the main media type of
+      interest, although video and sound may also play a part.
+
+
+
+
+
+Adie                                                           [Page 13]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   The Bristol Biomedical Videodisk Project
+
+      The Bristol Biomedical Videodisc is a collection of Medical,
+      Veterinary and Dental images.  The collection holds some 24,000
+      still images and is continuously growing.  Textual information
+      regarding the images is included as part of the database and this
+      can be searched on any keyword, number or other data type, or a
+      combination of any of these.  The images are currently delivered
+      in analogue form on a videodisc, but many institutions are unable
+      to afford the cost of videodisc players.  Investigations into
+      making this image and text database available across the network
+      are underway.
+
+   ArchiGopher
+
+      ArchiGopher is a Gopher server at the College of Architecture,
+      University of Michigan, dedicated to the dissemination of
+      architectural knowledge.  Presently in its infancy, ArchiGopher is
+      intended to become a multimedia resource for all architecture
+      faculty and students world-wide.  Some of the available or planned
+      resources are:
+
+            o The College's image bank.
+
+            o The CAD group's collection of computer models (already
+              started).
+
+            o The Doctoral Program's recent dissertation proposals and
+              abstracts.
+
+            o Example archive of Kandinsky paintings.
+
+            o Images of 3D CAD projects.
+
+      The principal media type in ArchiGopher is image.  Files are
+      stored in both TIFF and GIF format.
+
+   Vatican Library Exhibit
+
+      In January 1993, the US Library of Congress mounted an electronic
+      version of the exhibition ROME REBORN:  THE VATICAN LIBRARY AND
+      RENAISSANCE CULTURE.  The exhibition was subsequently processed by
+      the University of Virginia Library. The text files were broken
+      into individual captions associated directly with each image and a
+      WAIS-searchable version of the object index generated.  This has
+      been made available on Gopher by the University of Virginia
+      Library.
+
+
+
+
+Adie                                                           [Page 14]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      This project is particularly interesting, as it demonstrates some
+      limitations of the Gopher system.  The principal media types are
+      image and text, and it is difficult to associate a caption with
+      its image - each must be fetched separately, and using the XMosaic
+      or xgopher client software it is not possible to tell which menu
+      entry is the image and which the caption. (This may be a
+      consequence of how the data has been configured for the Gopher
+      server; if so, a requirement for better publishing tools may be
+      indicated.)  Furthermore, searching the object index will result
+      in a Gopher menu containing references to catalogue entries for
+      relevant exhibits, but not to the online images of the exhibits
+      themselves, which severely limits the usefulness of the index.
+
+      It is interesting to note that during the preparation of this
+      report, the Vatican Exhibition has been mounted on the WorldWide
+      Web (WWW).  The hypermedia presentation on the Web is very much
+      more attractive to use than the Gopher version.
+
+   Jukebox
+
+      Jukebox is a project supported by the EEC libraries program.  The
+      project aims to evaluate a pilot service providing library users
+      with on-line access to a database of digital sound recordings.
+      The database will support multi-user access and use suitable
+      storage media to make available sound recordings in a compressed
+      format.  Users will access the service with a personal computer
+      connected to a telematic network.
+
+   Scientific Publishing
+
+   There are several refereed electronic academic journals presently
+   distributed on the Internet.  These tend to be text-only journals,
+   and have not really addressed the issues of delivering and
+   manipulating non-text data.
+
+   Many scientific publishers have plans for electronic publishing of
+   existing academic journals and conference proceedings, either on
+   physical media or on the network.  The Journal of Biological
+   Chemistry is now published on CD-ROM, for instance.  Some publishers
+   view CD-ROM as an interim step to the ultimate goal of making
+   journals available on-line on the Internet.
+
+   The main types of non-text data which are envisaged are:
+
+      o    Images.  In many cases, image data (a microphotograph, say)
+           is central to an article.  Software which recognises that
+           the text may be of secondary importance to the image is
+           required.
+
+
+
+Adie                                                           [Page 15]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+      o    Application-specific data.  The ChemLab and MoleculeLab
+           applications are widely used, and the integration of
+           corresponding data types with journal articles will enhance
+           readers' ability to visualise molecular structures.
+           Similarly, mathematics appearing in scientific papers could
+           be represented in a form suitable for processing by
+           applications such as Mathematica.  Mathematical content
+           could then become a much more interactive and dynamic aspect
+           of research publications.
+
+      o    Tabular data.  The ability for a reader to extract tabular
+           data from a research paper, to produce a graphical
+           representation, to subset the data, and to further process
+           it in a number of different ways, is viewed as an essential
+           part of scientific electronic publishing.
+
+      o    Movies.  The American Astronomical Society regularly
+           publishes videos to go with its academic journals.
+           Electronic publishing can improve on this "hard copy"
+           publishing by integrating video data much more closely with
+           the source article.
+
+      o    Sound.  There is perhaps slightly less demand for audio
+           information in scientific publishing, but the requirement
+           does exist in particular specialities (such as acoustics and
+           zoology journals).
+
+   Access to academic journals using at least four different paradigms
+   is envisaged.  Hierarchical access, perhaps using a traditional
+   journal/volume/issue/article model, is perhaps the most obvious.
+   Keyword searching (or full-text indexing) will be required.  Browsing
+   is another useful and often underestimated access model - to support
+   browsing it is essential that "eye-catching" data (unlikely to be
+   textual) is prominently accessible. The final method of access is
+   perhaps the most important - the use of interactive viewing tools.
+   Such tools would enable navigation of hypermedia links within and
+   between articles, with gateways to special-purpose applications as
+   described above.  The use of these disparate access methods implies
+   more than one structure being applied to the same underlying data.
+
+   Standards, particularly SGML, are becoming important to publishers,
+   and it is clear that the SGML-based HyTime standard will be a front
+   runner in providing the kind of hypermedia facilities which are being
+   envisaged.  However, progress towards a common SGML Document Type
+   Definition (DTD) for scientific articles, even within individual
+   publishing houses and for text-only documents, is slow.
+
+
+
+
+Adie                                                           [Page 16]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   A specific initiative involving interested parties will be required
+   to formalise detailed requirements and to pilot standards in this
+   area.  A preliminary demonstrator project, funded by publishers and
+   by the British Library Research and Development Department, involves
+   making about 30 sample scientific articles available over the
+   SuperJANET network, using a range of different software products. The
+   demonstrator project is being managed by IOP Publishing and is being
+   carried out at Edinburgh University Computing Service.
+
+   Existing tools, particularly WAIS and WWW, are relevant, but adequate
+   security and charging mechanisms are required if commercial
+   publishers are to use them.  Many research groups are now making the
+   text of preprints and published research papers available on Gopher
+   servers.
+
+   It is interesting to note that the proceedings of the Multimedia 93
+   conference run by the ACM will be published electronically (on CD
+   ROM), using a multimedia document format designed specifically for
+   the event.
+
+   Computer-aided Learning
+
+   The ready availability of user-friendly multimedia authoring tools
+   such as AuthorWare Professional, Asymmetrix Multimedia Toolbook,
+   Macromind Director and many more, has stimulated much interest in
+   multimedia for computer-aided learning applications within the user
+   community.  Sophisticated interactive multimedia courseware
+   applications are being developed in many disparate subjects
+   throughout the European academic community.  Users are now beginning
+   to ask network technologists, "how can I make my multimedia
+   application available to others across the network?".
+
+   There is considerable interest in using the network to enhance
+   delivery of multimedia teaching materials - for instance to allow
+   students to take courses remotely (distance learning) and for their
+   learning process to be supported, monitored and assessed remotely.
+
+   The requirements which flow from this type of network application
+   include the ability to identify and authenticate the students using
+   the material, to monitor their progress, and to supply on-line
+   assessment exercises for the student to complete.  Multimedia
+   authoring tools allow very attractive presentation environments to be
+   created, which encourages learning; this is viewed as essential by
+   course developers.  Easy-to-use authoring tools (preferably existing
+   commercial ones) are also essential.
+
+   Finally, some learning applications involve simulations - examples
+   include meteorological modelling and economic simulations.  Network
+
+
+
+Adie                                                           [Page 17]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   delivery of teaching materials should cope with this requirement
+   (perhaps by acknowledging that executable scripts are just another
+   media type).
+
+   General Information Services
+
+   There are many other possible uses of multimedia data in networked
+   information servers which don't conveniently fall into any of the
+   above categories. Some examples are given below.
+
+      o    On-line documentation.  Manuals and instruction books often
+           rely heavily on pictorial information, and are enhanced by
+           dynamic media types (sound, video).  The ability to access
+           centrally-held manuals across a network makes it much easier
+           to keep the information up-to-date.
+
+      o    Campus-wide information systems (CWIS) are an important
+           growth area.  The opportunities for enhancing such a
+           service with multimedia data (e.g., maps) is obvious.
+
+      o    Multimedia news bulletins (e.g., the Internet Talk Radio,
+           which is sound only).
+
+      o    Product information (the multimedia equivalent of paper
+           advertising matter).
+
+      o    Consumer systems - e.g., tourist information servers.  The
+           utility of such systems in an academic/research environment
+           is perhaps questionable, but it is likely that such systems
+           will address problems which will also be met in this
+           environment.  We should be prepared to learn from such
+           projects.
+
+2.2. Data Characteristics
+
+   Some of the characteristics which make data more appropriate for
+   network publication rather than publication on physical media are
+   listed below.
+
+      o    The data may change frequently.
+
+      o    Implementing corrections and improvements to the data is
+           very much easier.
+
+      o    It is more readily available to the data user - no
+           purchase/delivery cycle need exist.
+
+
+
+
+
+Adie                                                           [Page 18]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      o    Publication on physical media may not be cost-effective for
+           very large volumes of data.  (Of course, there is a cost in
+           networking the data as well, but the research/academic user
+           is normally insulated from this.)
+
+      o    Access for large user communities can be established without
+           requiring each user to purchase a potentially expensive
+           physical media peripheral (such as a laser disk player).
+           This is particularly helpful in classroom situations.
+
+      o    It may require less effort from the data publisher to make
+           data available over a network, rather than set up a manual
+           mechanism for distributing physical media.
+
+      o    If related data from many different sources is to be
+           published, it may be more efficient to leave the data in
+           situ, and simply publish the network addresses of the data.
+
+   There are counter-reasons which may make physical media distribution
+   more appropriate:
+
+      o    Easier to charge for.  (However, charging mechanisms do
+           exist in some network information systems.  It may be that
+           potential information providers need to be made more aware
+           of this.)
+
+      o    Easier to deter or prevent copyright infringement, using
+           traditional copy-protection techniques.
+
+2.3. Requirements Definition
+
+   From studying the applications described in the preceding section,
+   and from discussions with the people involved with the applications,
+   it is possible to draw up a list of general requirements which a
+   distributed multimedia information system for the academic and
+   research community should satisfy.  These requirements are informally
+   described in the following subsections.  The descriptions are
+   necessarily informal and incomplete: every individual application
+   will have its own detailed requirements, which would take a great
+   deal of effort to determine (and indeed some of the requirements may
+   not become apparent until the application is into its development
+   phase).
+
+   Platforms
+
+   It is clear that the European academic community, in common with
+   other such communities, requires support for three main platforms:
+   UNIX, Apple Macintosh, and PC/Windows.  For multimedia client/server
+
+
+
+Adie                                                           [Page 19]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   systems, the latter two are less appropriate as server platforms, but
+   client support for all three is vital.  UNIX will be most often used
+   as the server platform.
+
+   There are other systems, such as VAX/VMS, which are also important in
+   some sectors.
+
+   Media Types
+
+   Unsurprisingly, all applications require text data to be supported as
+   a basic media type.  Image and graphic media types are next in
+   importance, followed by "application-specific" data (such as tabular
+   scientific data, mathematical equations, chemical data types, etc).
+   Sound and video media types are becoming more important as users
+   discover how these can enhance applications.
+
+   Many different encodings are possible for each media type (e.g.,
+   image data can be encoded as TIFF, PCX, GIF, PICT and many more).  An
+   information system should not constrain the type of encoding used,
+   and should ideally offer either a range of alternative encodings, or
+   conversion facilities between the stored encoding and an encoding
+   suitable for display by the client workstation.
+
+   Hyperlinks
+
+   It is clear that many applications require their users to be able to
+   navigate through the information base according to relationships
+   determined by the information provider - in other words, hyperlinks.
+   Academic publishing, CAL, on-line documentation and CWIS systems all
+   require this capability.  The user should be able, by some action
+   such as clicking on a highlighted word in a text node or on a button,
+   to cause another node or nodes to be retrieved and displayed.
+
+   Some "hypermedia" systems are in fact simply hypertext, in that they
+   require the source anchor of a hyperlink to be in a text node.  A
+   true hypermedia system allows hyperlinks to have their source anchors
+   in nodes of any media type.  This allows a user to click the mouse on
+   a component of a diagram or on part of a video sequence to cause one
+   or more related nodes to be retrieved and displayed.
+
+   Some hypermedia systems allow target anchors of a hyperlinks to be
+   finer-grained than a whole node - e.g., the target anchor could be a
+   word or a paragraph within a text document.  Without such a
+   capability, it is necessary for target nodes to be quite small if
+   precision is required in a hyperlink.  This may be difficult to
+   manage, and fine-grained target anchors are therefore better.
+
+
+
+
+
+Adie                                                           [Page 20]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Additional structure above or orthogonal to the underlying
+   hyperlinked data is required in some applications.  This allows the
+   same (generally non-textual) data to be used in several different
+   applications, or the implementation of different access paradigms.
+
+   Presentation
+
+   Related information of different media types must be capable of
+   synchronised display.  Commercial multimedia authoring packages
+   provide many different ways of presenting, synchronising and
+   interacting with media elements.  Some of these are summarised below.
+
+      o    Backdrops.  An application may present all its visual
+           information against a single background bitmap - e.g.,
+           a CAL application might use a background image of an open
+           textbook, with graphics, text and video data all presented
+           on the open pages of the book.
+
+      o    Buttons.  A "button" can be defined as an explicitly-
+           delimited area of the display, within which a mouse click
+           will cause an action to occur.  Typically, the action will
+           be (or can be modelled as) a hyperlink traversal.
+           Applications use different styles of button - some may use
+           "tabs" as in a notebook, or perhaps "bookmarks" in
+           conjunction with the open textbook backdrop mentioned above.
+           Others may use plain buttons in a style conforming to the
+           conventions of the host platform, or may simply highlight a
+           word or phrase in a text display to indicate it is "active".
+
+      o    Synchronisation in space.  When two or more nodes are
+           presented together (e.g., because a link with more than one
+           target anchor has been traversed), the author of the
+           hyperdocument may wish to specify that they be presented in
+           a spatially-related way.  This may involve: x/y
+           synchronisation - e.g., a video node being displayed
+           immediately above its text caption; it may involve
+           contextual synchronisation - e.g., an image being displayed in
+           a specific location within a text node; or it may involve z-
+           axis synchronisation as well - for instance a text node
+           containing a simple title being displayed on top of an
+           image, with the text background being transparent so that
+           the image shows through.
+
+      o    Synchronisation in time.  Isochronous data may require
+           synchronisation - the obvious case being audio and video
+           tracks (where these are held separately).  Other examples
+           are: the synchronisation of an automatically-scrolling text
+           panel to a video clip (for subtitling); or to an audio clip
+
+
+
+Adie                                                           [Page 21]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+           (e.g., a translation); or synchronising an animation to an
+           explanatory audio track.
+
+   Searching
+
+   Database-type applications require varying degrees of sophistication
+   in retrieval techniques.  For applications addressed in this report,
+   non-text nodes form the major data of interest.  Such nodes have
+   associated descriptions, which may be plain text, or may be
+   structured into fields.  Users need to be able to search the
+   descriptions, obtain a list of "hits", and select nodes from that
+   list to display.  Searching requirements vary from simple keyword
+   searching, via full-text indexing (with or without Boolean
+   combinations of search words), to full SQL-style database retrieval
+   languages.
+
+   Interaction
+
+   The user must be able to annotate documents retrieved from the
+   information server.  The annotations may be stored locally.
+   Similarly, the user may wish to add his own (locally-held) hyperlinks
+   to documents.  (Actual modification of documents in the information
+   system itself, or shared annotations to documents - i.e., the
+   information system as a CSCW environment - is viewed as separate
+   issue which this report does not address.)
+
+   If an information provider has included contact details (such as a
+   mail address) in a document, it should be possible for the reader to
+   invoke a program (such as a mailer) which initiates communication
+   with the author.
+
+   In some applications, it may make sense for a user to be able to
+   specify a region of interest in an image or movie clip, and to
+   request a more detailed view of (or other information about) that
+   region.
+
+   Some applications require a sequence of images to be presented under
+   control of the user.  For instance, a three-dimensional microscopic
+   structure could be represented as a sequence of images taken with the
+   microscope focused on a different plane for each image.  For display,
+   the user could control which image was displayed using some kind of
+   slider control, giving the illusion of focusing a microscope.  (This
+   particular example has been taken from the Theseus project at John
+   Moore's University, Liverpool, GB.)
+
+
+
+
+
+
+
+Adie                                                           [Page 22]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Quality of Service
+
+   Research has shown [3] that user toleration of delay in computer
+   systems depends on user perception of the nature of the requested
+   action.  If the user believes that no computation is required,
+   tolerable delays are of the order of 0.2s.  If the user believes the
+   action he or she has requested the computer to perform is "difficult"
+   - for instance a computation of some form - then a tolerable delay is
+   of the order of 2s.  Users tend to give up waiting for a response
+   after about 20s.  Networked multimedia information systems must be
+   able to provide this level of responsiveness.
+
+   Management
+
+   In order to support applications involving real-money information
+   services (e.g., academic publishing) and learning/assessment
+   applications, there must be a reliable and secure access control
+   mechanism.  A simple password is unlikely to suffice - Kerberos
+   authentication procedures are a possibility.
+
+   Users must be able to determine the charge for an item before
+   retrieving it (assuming that pay-per-item will be a common paradigm
+   alternatives such as pay-per-call, pay-per-duration are also
+   possible).  Access records must be kept by the information server for
+   charging purposes.
+
+   Learning applications have similar requirements, except that the
+   purpose here is not to charge for information retrieved, but to
+   monitor and perhaps assess a student's progress.
+
+   Scripting
+
+   Many authoring packages provide scripting languages.  In most cases,
+   these languages are used to manage the presentation environment and
+   control navigation within the hypermedia document.  There are other,
+   declarative rather than procedural, methods for achieving this, so
+   scripting of this type is not necessarily a requirement.  However,
+   some application areas require executable scripts for other purposes
+   (e.g., simulations in CAL applications).  Care in providing such a
+   facility is required, because of the potential for abuse (the
+   possibility of "trojan" scripts).  However, there is work going on to
+   produce "safe" scripting languages - an example is "safe tcl", being
+   developed by Borenstein and Ousterhout (contact
+   ouster@cs.berkeley.edu).
+
+
+
+
+
+
+
+Adie                                                           [Page 23]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Bytestream Format
+
+   For the easy transfer and handling of a hyperdocument, it must be
+   capable of being encoded into a bytestream form, in such a way that
+   the structure of the document is preserved and it can be decoded
+   without loss of information.
+
+   This facility makes it possible for such documents to be supplied to
+   a user over electronic mail, in such a way that he or she can browse
+   them at his or her own site.  This may be appropriate where the user
+   does not have a direct connection to the Internet.  It will also be
+   useful for printing the hyperdocument.
+
+   Authoring
+
+   It is essential that a multimedia information system should have
+   adequate authoring tools which make it easy to prepare and publish
+   hypermedia information.  Such tools need similar power to existing
+   commercial multimedia authoring software for stand-alone multimedia
+   applications.
+
+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,
+   including:
+
+        o UNIX (character terminals)
+
+        o X windows
+
+        o Apple Macintosh
+
+        o MS DOS
+
+
+
+Adie                                                           [Page 24]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+        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.
+
+
+
+
+
+
+Adie                                                           [Page 25]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   Gopher.
+
+   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
+           software.
+
+      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.
+
+
+
+Adie                                                           [Page 26]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+        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
+   clear.
+
+   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:
+
+
+
+
+Adie                                                           [Page 27]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+    INFO               Contains the Gopher reference of the node.
+                       Mandatory.
+
+    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
+                       types.
+
+    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
+                       masquerading.
+
+   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>
+
+
+
+
+Adie                                                           [Page 28]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   complexity.
+
+   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.
+
+
+
+
+Adie                                                           [Page 29]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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 gopher.ed.ac.uk, where the Testing Area
+   contains 20 or 30 short audio files in Sun audio format.  Note - the
+   availability of this archive is not guaranteed.
+
+   Advantages
+
+   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.
+
+   Limitations
+
+   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
+   model.
+
+   There is no access control at the user level - anyone can retrieve
+   anything on a Gopher server.  There is no provision for charging for
+   information.
+
+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
+
+
+
+Adie                                                           [Page 30]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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.
+
+
+
+
+
+
+Adie                                                           [Page 31]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   feedback".
+
+   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
+
+
+
+Adie                                                           [Page 32]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   current WAIS implementations mean that server implementations may be
+   stateless.
+
+   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
+   format.
+
+   Published Non-text Data
+
+   There is relatively little non-text data available in WAIS databases.
+
+      o    URL=wais://quake.think.com:210/CM-images is a database of
+           TIFF images from the Connection Machine.
+
+      o    URL=wais://mpcc3.rpms.ac.uk:210/home/images/pathology/RPMS-
+           pathology is a database of histo-pathological images and
+           documentation on mammalian endocrine tissue.
+
+      o    URL=wais://starhawk.jpl.nasa.gov:210/pio 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.
+
+   Advantages
+
+   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.
+
+
+
+Adie                                                           [Page 33]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Limitations
+
+   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 dcmartin@library.ucsf.edu
+   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
+   areas.
+
+   Browser software is available for a large number of systems
+   including:
+
+        o       Line-mode dumb terminal.
+
+        o       Terminal with Curses support
+
+        o       Macintosh
+
+        o       X/Motif
+
+        o       X11
+
+        o       PC/MS Windows
+
+
+
+Adie                                                           [Page 34]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+        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.
+
+   URL
+
+   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.
+
+
+
+Adie                                                           [Page 35]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   them.
+
+   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
+
+   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.
+
+
+
+
+
+
+
+Adie                                                           [Page 36]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   HTML
+
+   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
+   window.
+
+   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).
+
+
+
+
+
+Adie                                                           [Page 37]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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:
+
+
+
+
+
+Adie                                                           [Page 38]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+    HEAD               Fetch attribute information about a node
+                       (including the media type and encoding)
+
+    CHECKOUT/CHECKIN/PUT/POST
+
+                       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.
+
+   Mosaic
+
+   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:
+
+
+
+
+Adie                                                           [Page 39]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      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
+   distributable.
+
+   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
+   contributions.
+
+   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.
+
+
+
+
+
+
+Adie                                                           [Page 40]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Published non-text data
+
+   See the multimedia demo node on:
+
+   http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/multimedia.html
+
+   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
+   HTML2.
+
+   Advantages
+
+   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.
+
+   Limitations
+
+   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.
+
+
+
+
+
+
+Adie                                                           [Page 41]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+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.
+
+   Platforms
+
+   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
+                                                     available)
+
+    PC with      HGopher (two    WAIS for            Cello (beta
+    Windows      others also     Windows, WAIS       version
+                 available)      Manager             available),
+                                                     Mosaic (beta due
+                                                     3Q93)
+
+    UNIX with X  Xgopher,        XWAIS               XMosaic
+                 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
+           UNIX).
+
+
+
+
+Adie                                                           [Page 42]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      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.
+
+   Hyperlinks
+
+   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.
+
+
+
+
+
+Adie                                                           [Page 43]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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.
+
+   Presentation
+
+   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.
+
+   Searching
+
+   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
+   clients.
+
+
+
+
+Adie                                                           [Page 44]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   Interaction
+
+   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
+   facilities.
+
+   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
+   considerations).
+
+   Management
+
+   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
+    authentication
+
+
+
+
+
+Adie                                                           [Page 45]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+    Charging support    No             No            Yes, in
+                                                     HTTP2
+
+    Monitoring for      No             No            No
+    statistical and
+    assessment
+    purposes
+
+   Note:
+
+   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.
+
+
+
+
+
+
+
+
+
+Adie                                                           [Page 46]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+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
+   include:
+
+      o    "Clusters" are a set of documents which are all
+           presentedtogether.
+
+      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
+
+
+
+Adie                                                           [Page 47]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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.
+
+
+
+Adie                                                           [Page 48]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+      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.
+
+
+
+
+
+Adie                                                           [Page 49]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      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
+
+
+
+Adie                                                           [Page 50]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+           environment
+           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
+           agents.
+
+    R1061  DIMPE - Distributed Integrated Multimedia Publishing
+           Environment. The project designed and implemented interim
+           services for compound document handling, and defined a
+           distributed publishing architecture.
+
+
+
+
+Adie                                                           [Page 51]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+    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
+           applications.
+
+    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.
+
+
+
+Adie                                                           [Page 52]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+    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
+           management.
+
+    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
+
+
+
+Adie                                                           [Page 53]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+           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
+           Database".
+
+      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.
+
+
+
+
+
+
+Adie                                                           [Page 54]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+5. Standards
+
+5.1. Structuring Standards
+
+   This section describes some of the important standards for providing
+   hyperstructure to multimedia data.
+
+   SGML
+
+   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
+           houses.
+
+   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
+   files.
+
+
+
+Adie                                                           [Page 55]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   HyTime
+
+   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
+   purposes.
+
+   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].
+
+
+
+
+
+Adie                                                           [Page 56]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      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
+
+
+
+Adie                                                           [Page 57]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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 lrutledg@cs.ulowell.edu) 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
+   glossaries.
+
+   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
+   efficiency.
+
+   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
+
+   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.
+
+
+
+Adie                                                           [Page 58]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+           objects.
+
+      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).
+
+
+
+Adie                                                           [Page 59]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+      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.
+
+   ODA
+
+   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.
+
+
+
+
+Adie                                                           [Page 60]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+           disbanded);
+
+      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
+
+   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,
+
+
+
+Adie                                                           [Page 61]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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.
+
+   Acrobat
+
+   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
+   document.
+
+   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
+   systems.
+
+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
+   type.
+
+   The expected timescale for this standardisation work is lengthy (part
+   1 - the framework - is targeted for completion in 1996).
+
+
+
+
+Adie                                                           [Page 62]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   There are suggestions that this standard could be used as a query
+   language in conjunction with the HyQ query component of the HyTime
+   standard.
+
+   DFR
+
+   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
+   OSI.
+
+   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
+
+   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
+
+
+
+Adie                                                           [Page 63]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   expressed.
+
+   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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adie                                                           [Page 64]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+    Type            Subtype       Parameters    Meaning
+
+
+    text            plain         charset       Plain text
+
+                    richtext      charset       Text with SGML-like
+                                                markup for
+                                                representing
+                                                formatting.
+
+    image           jpeg                        JPEG File Interchange
+                                                Format
+
+                    gif                         Graphics Interchange
+                                                Format
+
+    audio           basic                       8-bit -law 8kHz PCM
+                                                encoding
+
+    video           mpeg
+
+    application     ODA           profile       Open Document
+    (used                         (Document     Architecture
+    for                           Application   document.
+    application                   Profile)
+    -specific
+    data)
+
+                    octet-        name (e.g.,   General binary data
+                    stream        filename);    such as an arbitrary
+                                  type (for     binary file.
+                                  human
+                                  recipient),
+                                  etc.
+
+                    postscript                  Document in
+                                                postscript.
+
+   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
+
+
+
+Adie                                                           [Page 65]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   from the server.  It is the first MIME application to utilise the
+   8bit Content-Transfer-Encoding, which essentially means no encoding.
+
+   SMSL
+
+   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.
+
+   AVIs
+
+   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
+
+
+
+Adie                                                           [Page 66]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   issues.
+
+   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
+   data.
+
+   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
+
+
+
+Adie                                                           [Page 67]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+
+
+
+Adie                                                           [Page 68]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   systems.
+
+   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
+
+
+
+Adie                                                           [Page 69]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   section:
+
+      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
+           20s.
+
+   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
+           size.
+
+      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-
+           fetching.
+
+      6.   Cache information locally.  The use of Universal Resource
+           Numbers (see the section on WWW) is relevant for managing
+           this.
+
+
+
+Adie                                                           [Page 70]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+      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
+   this.
+
+
+
+
+
+
+
+Adie                                                           [Page 71]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+   follows.
+
+      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
+
+
+
+Adie                                                           [Page 72]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+           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
+           standards).
+
+      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
+   alleviated:
+
+      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.
+
+
+
+
+
+Adie                                                           [Page 73]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+           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
+           limitations.
+
+      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.
+
+
+
+
+
+Adie                                                           [Page 74]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+   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
+           appropriate.
+
+      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).
+
+
+
+
+
+
+
+Adie                                                           [Page 75]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+7. References
+
+      [1]         "A Survey of Distributed Multimedia Research,
+                  Standards and Products", ed. C. Adie, January 1993
+                  (RARE Technical Report 5).
+                  URL=ftp://ftp.ed.ac.uk/pub/mmsurvey/
+
+      [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,
+                  1984.
+
+      [4]         "Gopher+: Proposed Enhancements to the Internet
+                  Gopher Protocol", B. Alberti, F. Anklesaria, P. Linder,
+                  M. McCahill, D. Torrey, Summer 1992.
+                  URL=gopher://boombox.micro.umn.edu:70/11/gopher/gop
+                  her_protocol/Gopher%2b
+
+      [5]         "WAIS Interface Protocol", F. Davies, B. Kahle, H.
+                  Morris, J. Salem, T. Shen, R. Wang, J. Sui and M.
+                  Grinbaum, April 1990.
+                  URL=ftp://quake.think.com/wais/doc/protspec.txt
+
+      [6]         "Uniform Resource Locators", T. Berners-Lee, March
+                  1993.  URL=ftp://info.cern.ch/pub/ietf/url4.ps
+
+      [7]         "The HTTP Protocol as Implemented in W3", T. Berners-
+                  Lee, January 1992.
+                  URL=ftp://info.cern.ch/pub/www/doc/http.txt
+
+      [8]         "Protocol for the Retrieval and Manipulation of
+                  Textual and Hypermedia Information", T. Berners-Lee,
+                  1993.  URL=ftp://info.cern.ch/pub/www/doc/httpspec.ps
+
+      [9]         "Hypertext Markup Language (HTML)", T Berners-Lee,
+                  March 1993. URL=ftp://info.cern.ch/pub/www/doc/html-
+                  spec.ps
+
+      [10]        "Hyper-G: A Universal Hypermedia System", F. Kappe and
+                  N. Sherbakov, March 1992. URL=ftp://iicm.tu-
+                  graz.ac.at/pub/HyperG/doc/report333.txt.Z
+
+
+
+
+
+
+
+Adie                                                           [Page 76]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+      [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.
+                  URL=ftp://ceci.mit.edu/pub/AM2/funcspec.txt.Z
+
+      [13]        "Research and Technology Development in Advanced
+                  Communications Technologies in Europe: RACE '92",
+                  CEC, March 1992.  Available from:
+                  raco@postman.dg13.cec.be
+
+      [14]        "Esprit Programme Synopses", CEC, October 1992.  In
+                  seven volumes.  Available from
+                  esprit_order_mailbox@eurokom.ie
+
+      [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).
+                  URL=ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9305.ps.Z
+
+      [16]        "The Amsterdam Hypermedia Model: extending hypertext
+                  to support real multimedia", L. Hardman, D. C. A.
+                  Bulterman, G. van Rossum, Amsterdam 1993
+                  URL=ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9306.ps.Z
+
+      [17]        "Deja-Vu Distributed Hypermedia Application
+                  Framework", A. Eliens.
+                  URL=ftp://ftp.cs.vu.nl/eliens/Deja-Vu-proposal.ps
+
+      [18]        "Bento Specification", J. Harris and I. Ruben, Apple
+                  Computer Inc, August 1992.
+                  URL=ftp://ftp.apple.com/apple/standards/Bento_1.0d4.1
+
+      [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.
+                  URL=ftp://sgml1.ex.ac.uk/davenport/sofabed.0.9.6.ps.Z
+
+      [20]        Article in comp.text.sgml newsgroup, 24 May 1993, by
+                  Eliot Kimber (drmacro@vnet.ibm.com).
+                  URL=ftp://ftp.ifi.uio.no/SGML/comp.text.sgml/by.msg
+                  id/19930524.152345.29@almaden.ibm.com
+
+
+
+Adie                                                           [Page 77]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+
+      [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
+                  1992.
+
+      [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
+                  1992.
+
+      [28]        "A Status Report on Networked Information Retrieval:
+                  Tools and Groups", ed. J. Foster, G. Brett and P.
+                  Deutsch, March 1993.
+                  URL=ftp://mailbase.ac.uk/pub/nir/nir.status.report
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adie                                                           [Page 78]
+
+RFC 1614        Network Access to Multimedia Information        May 1994
+
+
+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
+   EMail: C.J.Adie@edinburgh.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adie                                                           [Page 79]
+