RFC 1614
Network Access to Multimedia Information
Network Access to Multimedia Information ๐
Okay bestie, this is RFC 1614 ๐ It's an Informational doc, which means it's here to inform, not to set any Internet standard ๐ฆ It was written by C. Adie at the Edinburgh University Computing Service, and it's listed as a RARE Technical Report: 8 from May 1994 ๐ธ It's filed in the Network Working Group stream, and the header doesn't list anything it obsoletes or updates, so it's standing on its own โจ
Status of this Memo โจ
This memo gives information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited ๐
Abstract ๐ฆ
This report sums up what research and academic network users need when it comes to network access to multimedia information ๐ It looks at a bunch of projects that are planned or already happening in the community. It checks out Gopher, WAIS and the World-Wide Web from a multimedia-support point of view, and it also studies some hypermedia systems coming out of research labs, which are very interesting ๐ญ Relevant standards, both the existing ones and the ones still developing, get discussed too โจ
The report also spots the gaps between what systems people are using right now can actually do and what users need ๐ To close those gaps, it proposes more work centred on the World-Wide Web ๐ฅ
The report gets pretty detailed in places, so there's an extended summary up front that lays out what it found ๐ซถ
Publication History ๐
The first edition came out on 29 June 1993 ๐ This second edition has 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
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 79Acknowledgements ๐ซถ
Huge thanks to everyone who (knowingly or unknowingly) helped put this report together: 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 ๐ Also, NCSA's XMosaic information browser played a big part in gathering the information this report is based on, so big shout-out to its developers ๐
All trademarks are acknowledged as the property of their respective owners ๐ฆ
Disclaimer โ ๏ธ
This report is based on information given to or gathered 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 for any loss or damage arising from or out of the use of this report ๐
The opinions in this report are the author's personal opinions. They do not necessarily represent the policy of either RARE or ECUS ๐
Mentioning a product in this report does not count as endorsing it, whether by EUCS or by RARE โจ
Availability ๐ฅ
This document comes in a few forms (PostScript, text, and Microsoft Word for Windows 2), and you can grab it by anonymous FTP at 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 about the spot where networked information retrieval, database technology and multimedia all overlap ๐ง Its goal is to pin down what research and academic users need for network access to multimedia data, look at existing systems that offer partial solutions, and figure out what has to happen to meet the most urgent needs ๐
User Requirements ๐
There are a bunch of reasons multimedia data might need to be accessed remotely, instead of being physically shipped out (like on CD-ROM) ๐ It all comes down to the cost of physical distribution versus how fast network distribution can be. Network distribution isn't free, of course, but that cost usually stays hidden from the end user ๐
The user requirements came from studying existing and proposed projects that involve networked multimedia data ๐ It was easiest to split the applications into four classes based on what they need: multimedia database applications, academic (especially scientific) publishing applications, cal (computeraided learning), and general multimedia information services ๐
Database applications usually involve big collections of monomedia (non-text) data that come with textual and numeric fields attached. They need a range of search and retrieval techniques ๐
Publishing applications need a range of media types, hyperlinking, and the ability to reach the same data through different access paradigms (search, browse, hierarchical, and links). They also need authentication and charging facilities ๐ณ
Cal applications need sophisticated presentation and synchronisation capabilities, like the ones found in existing multimedia authoring tools ๐ฌ They also need authentication and monitoring facilities ๐
General multimedia information services cover things like on-line documentation, campus-wide information systems, and other systems that don't fit neatly into the categories above. Hyperlinking is probably the most common need in this area ๐
Looking at these application areas, a number of important user requirements stand out ๐
- Support for the Apple Macintosh, UNIX and PC/MS Windows environments.
- Support for a wide range of media types. Text, image, graphics and application-specific media matter most, followed by video and sound.
- Support for hyperlinking, and for multiple access structures built on the same underlying data.
- Support for sophisticated synchronisation and presentation facilities.
- Support for a range of database searching techniques.
- Support for user annotation of information, and for user-controlled display of sequenced media.
- Adequate responsiveness. The maximum time taken to retrieve a node should not exceed 20s โฑ๏ธ
- Support for user authentication, a charging mechanism, and monitoring facilities.
- The ability to execute scripts.
- Support for mail-based access to multimedia documents, and (where appropriate) for printing multimedia documents.
- Powerful, easy-to-use authoring tools. ๐ ๏ธ
Existing Systems ๐ธ๏ธ
The main information retrieval systems used on the Internet are Gopher, Wais, and the World-Wide Web ๐ They all work on a client-server model, and they all offer some level of support for multimedia data ๐
Gopher shows the user a hierarchical arrangement of nodes. Each node is a directory (menu), a leaf node (a document with text or other media types), or a search node (which lets you search a set of documents by keyword, possibly using WAIS) ๐ It supports a range of media types, and Gopher+, which is being developed as an extension, gives better multimedia support ๐ Gopher has a very high penetration, with over 1000 Gopher servers on the Internet, but it doesn't have hyperlinks and it's inflexibly hierarchical ๐ฌ
Wais (Wide Area Information Server) lets users search for documents in remote databases ๐ Full-text indexing lets you find and retrieve every document containing particular words or combinations of words โจ Non-text data, mainly image data, can be handled, but those documents only get indexed by their file name, which seriously limits how useful that is ๐ Still, WAIS is ideally suited to text search applications ๐
World-Wide Web (WWW) is a large-scale distributed hypermedia system ๐ฆ The Web is made of nodes (also called documents) and links. Links connect documents: to follow one, the user clicks a highlighted word in the source document, which retrieves and displays the linked document ๐ฑ๏ธ A document can be one of many media types, or it can be a search node, similar to Gopher ๐ง The WWW addressing method means WAIS and Gopher servers can also be accessed from the Web, and they actually form part of it ๐ซ WWW has a smaller penetration than Gopher, but it's growing faster ๐ The Web technology is currently being revised to better account for the needs of multimedia information ๐
All three systems go some way toward meeting the user requirements ๐
- Support for multiple platforms and for a wide range of media types (through "viewer" software external to the client program) is good.
- Only WWW has hyperlinks.
- There is little or no support for sophisticated presentation and synchronisation requirements.
- Support for database querying tends to be limited to "keyword" searches, but current developments in Gopher and WWW should make more sophisticated queries possible.
- Some clients support user annotation of documents.
- 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 ๐ข
- There is little in the way of authentication, charging and monitoring facilities, although these are planned for WWW. ๐
- Scripting is not supported because of security issues ๐
- WWW supports a mail responder ๐
- The only system sufficiently complex to warrant an authoring tool is WWW, which has editors to support its hypertext markup language ๐
Research
okay so there are a bunch of research projects that are lowkey fascinating ๐ฌโจ
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. It's giving well-rounded energy ๐
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" ๐ผ
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. Main character energy, but make it research ๐
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 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:
- 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 ๐
- 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 ๐
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:
- content is distinct from hyperstructure
- media type is distinct from media encoding
- 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:
- Develop conversion tools from commercial multimedia authoring packages to WWW, and accompanying authoring guidelines.
- Implement and evaluate the most promising ways of overcoming the QOS problem.
- Implement a specific user project using these tools, to validate that the facilities being developed are truly relevant to real applications.
- Use the experience gained to inform and influence the development of the WWW technology.
- 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:
- 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 ๐ง
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 โจ
okay so before we get into the juicy stuff, we need a shared vocab, bestie ๐ the definitions below borrow some ideas from the Dexter hypertext reference model [2]. It's general enough to describe most of the facilities and requirements of the multimedia information systems in this report ๐ง (but the Dexter model does not describe searchable index objects - it is not a database reference model, so don't go looking for databases in there ๐)
- 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". ๐
- 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:
- Text
- Sound
- Image (e.g., a "photograph")
- Graphics (e.g., a "drawing")
- Animation (i.e., moving graphics)
- 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. ๐ฏ
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. ๐ it's giving "chicken or egg" vibes, honestly ๐ฅ
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. ๐๏ธ
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:
- The College's image bank.
- The CAD group's collection of computer models (already started).
- The Doctoral Program's recent dissertation proposals and abstracts.
- Example archive of Kandinsky paintings.
- 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. ๐บ
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:
- 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. ๐ฌ
- 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. ๐งช
- 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. ๐
- 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 โจ.
- 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 ๐ข.
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, it allows 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, and 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 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 ๐ธ.
- 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 ๐.
- Campus-wide information systems (CWIS). These are an important growth area. The opportunities for enhancing such a service with multimedia data (e.g., maps) is obvious ๐บ๏ธ.
- Multimedia news bulletins. For example, the Internet Talk Radio, which is sound only ๐ป.
- Product information. This is the multimedia equivalent of paper advertising matter ๐๏ธ.
- Consumer systems. For example, 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 ๐ก.
- The data may change frequently ๐.
- Implementing corrections and improvements to the data is very much easier โ๏ธ.
- It is more readily available to the data user. No purchase/delivery cycle need exist ๐.
- 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.) ๐ธ
- 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 ๐ซ๐.
- 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 ๐.
- 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 ๐ค:
- 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.) ๐ฐ
- Easier to deter or prevent copyright infringement, using traditional copy-protection techniques ๐.
2.3. Requirements Definition โจ
okay bestie, so after studying the apps in the last bit and chatting with the people building them, the authors put together a list of general requirements. A distributed multimedia information system for the academic and research community should satisfy all of these ๐ They're described informally below. They're necessarily informal and incomplete, because every individual app will have its own detailed requirements, which would take forever to pin down (and some requirements might not show up until the app is in development) ๐ซถ
Platforms ๐ฅ๏ธ
It's clear that the European academic community, like other communities, needs support for three main platforms: UNIX, Apple Macintosh, and PC/Windows. For multimedia client/server systems, the latter two are less appropriate as server platforms, but client support for all three is vital. UNIX will be the one 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 come 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. Ideally, it should 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's 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 to click something, such as a highlighted word in a text node or a button, to cause another node or nodes to be retrieved and displayed.
Some "hypermedia" systems are really just hypertext, in that they require the source anchor of a hyperlink to be in a text node. A true hypermedia system lets hyperlinks have their source anchors in nodes of any media type. That means a user can 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 hyperlinks to be finer-grained than a whole node. For example, the target anchor could be a word or a paragraph within a text document. Without such a capability, target nodes have to be quite small if precision is required in a hyperlink. That can be hard to manage, so fine-grained target anchors are therefore better ๐ฏ
Additional structure above or orthogonal to the underlying hyperlinked data is required in some applications. This lets the same (generally non-textual) data be used in several different applications, or lets different access paradigms be implemented ๐งฉ
Presentation ๐ญ
Related information of different media types must be capable of synchronised display. Commercial multimedia authoring packages offer lots of different ways of presenting, synchronising and interacting with media elements. Some of these are summarised below ๐
- Backdrops. An application may present all its visual information against a single background bitmap. For example, 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 ๐
- 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" ๐
- 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 ๐
- Synchronisation in time. Isochronous data may require synchronisation. The obvious case is audio and video tracks (where these are held separately). Other examples are: synchronising an automatically-scrolling text panel to a video clip (for subtitling); or to an audio clip (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 their 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 a 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.) ๐ฌ
Quality of Service โก
Research has shown [3] that user toleration of delay in computer systems depends on the user's 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 they've asked 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 and 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) โ ๏ธ
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 they can browse them at their 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 ๐ฟ๏ธ
Okay bestie, so Gopher is a distributed document delivery service ๐ It lets a total neophyte grab all kinds of data sitting on loads of different hosts, and it feels super seamless โจ The trick? It shows you a hierarchy of nodes and runs on a client-server model. The Gopher server takes simple queries and sends the client back a node (usually called a document in this context) ๐ฆ
Client software is available for a large number of systems, including:
- UNIX (character terminals)
- X windows
- Apple Macintosh
- MS DOS
- NeXT
- VM/CMS
- VMS
- OS/2
- MVS/XA
Servers are available for systems such as:
- UNIX
- VMS
- Apple Macintosh
- VM/CMS
- MVS
- MS DOS
Gopher was developed at the University of Minnesota ๐
Gopher User Image
A Gopher client gives you an interface into "gopherspace" ๐ To you it looks like a hierarchy of menus and document nodes, kinda like a file system with directories and files. Pick an entry from a menu node and either another menu pops up, or a document gets retrieved and displayed. Iconic ๐
Gopher also has "search nodes" ๐ When you select one from a menu, you get prompted for one or more words to search on. The result is a "virtual" menu with entries for document nodes (within some subset of gopherspace) that match your search. There's also a special type of Gopher search server called "veronica" ๐ธ It gives you access to a database of all directory nodes in gopherspace, so you can build a virtual menu of every Gopher menu item containing a particular word. And WAIS databases can live at Gopher search nodes too, since some Gopher servers understand the format of WAIS index files ๐ง
Gopher Protocol
Gopher is client-server all the way ๐ซถ It runs over a reliable data stream service, typically TCP, and it's fully defined in RFC 1436. The overview below is just enough to get how multimedia data gets handled in Gopher.
A Gopher client opens a TCP connection to a Gopher server (defined by machine name and TCP port number), then sends a line of text called the "selector" to request info from the server. The server responds with a block of data and closes the connection. No state is retained by the server ๐ A null (empty) selector tells the Gopher server to return its "root" menu node, which has pointers to other information in gopherspace ๐บ๏ธ
A menu comes back from a Gopher server as a sequence of lines of text, one per menu entry. Each line (sometimes called a "Gopher reference") holds the following data, which the client software can use to retrieve and display the matching node in gopherspace:
- A single character which identifies the type of the node. Possible values of this type ID are given below.
- A human-readable string which the client software uses when it displays the menu entry to the user.
- The selector which should be used by client software to retrieve the node. It is treated as opaque by the client software.
- The domain name of the host on which the node is held.
- The port number to use for the TCP connection.
A document node is sent by a Gopher server simply as lines of text ending in a dot on a line by itself, or as raw binary data. For raw binary, the end of the data is marked by the server closing the TCP connection. Which one you get depends on the type of node ๐
The currently-defined type IDs are:
0 Node is a file.
1 Node is a directory.
2 Node is a CSO phone book server.
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
Gopher+ is an extension of the Gopher protocol ๐ It's defined informally in [4]. It's designed to be downwards compatible with the original protocol, so old Gopher clients can access Gopher+ servers (without getting the new facilities), and Gopher+ clients can access old Gopher servers. Gopher+ is still experimental, and it's liable to change โ ๏ธ
The most important new feature is "attributes" attached to individual nodes โจ The client can retrieve a node's attributes instead of the node contents. Attributes defined so far include:
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.ASK warning ๐ Using the interactive query facility to supply a password for access control purposes is not a good idea, because 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. 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>Here xxx is a general type-of-information advisory, yyy is what information format you need to 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.
(Okay, plot twist: the University of Minnesota Gopher Team now accepts the need to be consistent with the MIME specification when it comes to type/encoding attributes ๐ So the Gopher+ Type Registry may eventually disappear, along with the set of xxx/yyy values it currently contains.)
No view descriptors for directory nodes are currently registered ๐๏ธ
To use the info in attributes, you have to fetch the attributes before fetching the contents of a node. Gopher+ lets you fetch the attributes for each entry in a menu at the same time the menu is retrieved ๐ That saves you from establishing two successive TCP connections to fetch a single document, at the cost of some extra client software complexity.
Gopher Publishing
Publishing on the Unix Gopher server "gopherd" is super straightforward ๐
The hierarchical nature of the Unix file system closely matches the Gopher concept of menus and documents. gopherd leans into this: Unix directories become Gopher menu nodes, and Unix files become Gopher document nodes. The names of directories and files are the entries in Gopher menus. That can lead to awkward file names with spaces, so gopherd provides an aliasing mechanism (the \.cap directory) to get around 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 is 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 specifies administration attributes, and the mapping between filename extensions and view descriptors. The Gopher+ version of gopherd also provides some limited access control, based on the client's IP address/domain name ๐
Published Non-text Data
There's already some useful non-text data published on Gopher, almost exclusively image data ๐ธ Check out the Vatican Library Exhibition at the University of Virginia Library, the ArchiGopher at the University of Michigan, and 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 if you're curious, you can access the Edinburgh University Computing Service Gopher server at 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. Part of why it's so popular is how easy it is to set up a Gopher server and make information available on it, especially on a Unix platform โจ
Limitations
It's unfortunate that the nicely defined MIME types didn't make it into Gopher+ ๐ญ. As mentioned above, this might still happen ๐ค. There seem to be reasons to keep the MIME set small, but Gopher needs a huge range of types to offer clients. The latest news is that the MIME registry will be expanded to include the types the Gopher+ developers want ๐.
Gopher is inflexibly hierarchical ๐. It's not hypertext or hypermedia, and links to other nodes from inside document nodes aren't possible ๐ โโ๏ธ. The Gopher+ spec suggests that alternate views of directory nodes could give you some kind of hypermedia capability, but that doesn't exist yet, and it's unlikely it could ever work as easily as the WWW hypertext model ๐ .
There's no access control at the user level. Anyone can retrieve anything on a Gopher server ๐. There's also no provision for charging for information ๐ธ.
3.2. Wide Area Information Server โจ
The Wide Area Information Server (WAIS) system lets users search for and retrieve information from databases anywhere on the Internet ๐. WAIS uses a client-server paradigm, and client and server software is available for a wide range of platforms ๐ง. Clients can 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 can then ask 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 announced that they would stop supporting their publicly-distributed WAIS as of version 8b5.1 ๐ฌ. Future support and development of the publicly-distributed WAIS was 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, was formed by Thinking Machines to take over commercial exploitation of the Thinking Machines WAIS software ๐ผ.
WAIS server software is available for the following platforms:
- UNIX
- VAX/VMS
Client software is available for the following platforms:
- UNIX (versions for X, Motif, Open Look, Sun View)
- NeXT
- Macintosh
- MS DOS
- MS Windows
- 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 ๐ข.
WAIS User Image
To ask a question, the user first has to select one or more databases to look for the answer in ๐. (A list of all available databases is available from a number of well-known sites.) Next, they enter one or more keywords as the basis of the search ๐. The search returns a list of documents (the "result set") which contain any of the keywords. Each document gets a ranking (a number between 1 and 1000) showing how relevant the server thinks it is to the user's question ๐. The size of each document is also shown in the list. The user can limit the size of the result set, and the default limit is typically 40 documents ๐.
The user can then choose to retrieve and display one or more documents from the list. Or they can mark one or more documents in the list as "relevant" and run another search to find "more documents like this". This is called "relevance feedback" ๐.
The user can get general information about the database and look through the catalogue of all documents in it ๐๏ธ. There's also a "database of databases", which can be searched to find WAIS databases that 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 current WAIS protocol doesn't use a full OSI stack. APDUs are transferred directly over a TCP/IP connection ๐ค๏ธ. The WAIS protocol is described in [5].
WAIS doesn't, 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'") ๐ง. Boolean search capability is being added to the FreeWAIS implementation, though ๐. Z39.50 has facilities for access control and charging, but these aren't currently implemented in WAIS ๐ซ.
The WAIS extensions to Z39.50 are mainly there to provide the relevance feedback capability ๐.
Note that Z39.50 isn't stateless. The result set may in some circumstances be retained by the server so the user can refine or refer to it further. However, the subset of Z39.50 used by current WAIS implementations means 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 ๐ ๏ธ. It 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. The WAIS server software uses this index file 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 text formats treat a file as a collection of documents for the purposes of WAIS access. There's no formal "registry of types", just whatever the waisindex program supports ๐คทโโ๏ธ. There is also no distinction between media type and encoding format.
Published Non-text Data
There's relatively little non-text data in WAIS databases ๐ฅฒ.
URL=wais://quake.think.com:210/CM-imagesis a database of TIFF images from the Connection Machine ๐ฅ๏ธ.URL=wais://mpcc3.rpms.ac.uk:210/home/images/pathology/RPMS-pathologyis a database of histo-pathological images and documentation on mammalian endocrine tissue ๐ฌ.URL=wais://starhawk.jpl.nasa.gov:210/piocontains GIF images from NASA planetary probe missions, together with their captions ๐ช. The caption index information makes it difficult to build a search that returns images in the result set. Increasing the maximum result set size may help ๐.
Advantages
WAIS is ideally suited to its intended purpose of searching databases of textual information by keyword ๐ฅฐ. It seems to have the potential to meet the requirements of some of the "database" category of applications mentioned in Chapter 1 โ .
Limitations
WAIS isn't (and doesn't pretend to be) a general-purpose information system like Gopher and WWW are ๐. WAIS has no hyperlinking and offers a purely flat structure ๐.
A limitation that really stands out is how the current version of FreeWAIS indexes non-text files: using only the filename! ๐ญ However, it seems like simply changing the indexing program to attach a list of keywords to non-text files would be enough for sensible indexing of non-text data ๐ก. The commercial (WAIS Inc) version of WAIS lets several files be associated together for indexing and retrieval ๐ค. Furthermode, the UCSF Centre for Knowlege Management is modifying the FreeWAIS code to support indexing of multiple content types. The document returned by WAIS will be an HTML document containing pointers to the multimedia data ๐๏ธ. For more information, contact dcmartin@library.ucsf.edu ๐ง.
WAIS isn't a fully-featured query/response protocol like 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) was started and driven by CERN. It's a large-scale distributed hypertext system ๐. It uses the standard client-server paradigm, with client "browser" software responsible for fetching and displaying data. It was originally aimed at the High Energy Physics community, but it has spread to other areas ๐ธ.
Browser software is available for a large number of systems, including:
- Line-mode dumb terminal
- Terminal with Curses support
- Macintosh
- X/Motif
- X11
- PC/MS Windows
- NeXT
There is server software available for:
- VM mainframes
- UNIX
- Macintosh
- VMS
WWW User Image
The WWW world is made of nodes (usually called documents) and links ๐งฉ. Links connect documents. To follow a link, a reader clicks with a mouse on a word in the source document, which makes the linked-to document get retrieved and displayed ๐ฑ๏ธ. (On systems without a mouse, the user types a number instead ๐ข.)
Indexes are special documents that you search rather than read ๐. To search an index, a reader supplies keywords or other search criteria. The result 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 an interface to Gopher and anonymous FTP information sources can be set up in a way that's transparent to the user. So 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, and Gopher ๐. The <path> component locates the document in a way that matters for the access method ๐.
Okay so the path part ๐ฆ for anonymous FTP includes the fully qualified domain name of the host where the document lives, plus the directory and file name where you'll find it. โจ For some schemes, the <path> can also include a search string (or a combo of strings) that addresses a "virtual" object, made by searching some kind of index ๐. The HTTP, WAIS and Gopher schemes can use search strings, which usually come after the rest of the path, separated by a ?. ๐
The optional <anchorid> is for addressing something inside an object ๐ฏ. How it gets interpreted isn't defined in the URL specification, so that part is up to whoever's using it ๐คทโโ๏ธ
"Partial" URLs are also a thing ๐ธ. These are used inside a document on the Web to point at another "nearby" document, like one in another file on the same machine. Certain parts of the URL (like the scheme and machine name) can be left out, following well-defined rules. This makes it so much easier to move groups of documents around while keeping the links within and between them ๐ซถ
A URL locates one and only one object on the Internet ๐ . However, more than one URL can point to the same object, and given two URLs, it's not generally possible to tell whether they refer to the same object ๐. Also, there's no guarantee that a single URL will point to the same object at different times. The object might change bit by bit, get completely replaced with something different, or just get removed ๐
HTTP
HTTP (HyperText Transfer Protocol) is the protocol used between server and client โจ. It's defined in [7]. It's currently being revised (see the Future Developments section below), and it'll eventually be proposed as an Internet standard ๐
The original protocol is extremely simple ๐ง. It only needs a reliable, connection-oriented transport service, typically TCP/IP.
The client sets up 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, ending with CR LF. The server responds with the node contents, which is a text document in the Hypertext Markup Language (HTML). The end of the contents is signalled by the server closing the connection ๐ฅ
HTML
HTML (HyperText Markup Language) is how text documents have to be structured if they're going to contain links to other documents ๐. Non-HTML text documents can totally be made available on the Web, but they can't contain links to other documents (so they're leaf nodes ๐), and browsers will display them without formatting, probably using a fixed-width font ๐ญ
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 marking up a node title, paragraph boundaries, headings of several different levels, highlighting, lists, and more. Anchors are represented using an <A> tag ๐ฆ
Here's an example of HTML containing an anchor, bestie ๐
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's a source anchor, with a target given by the URL in the HREF attribute, so the text would appear highlighted somehow in a client's window to show that clicking it would traverse a hyperlink โจ. It's also a target anchor, with an anchor ID given by the NAME attribute. A source anchor pointing at this target would specify #13 at the end of the node's URL ๐ฏ
Traversing a hyperlink to this node would retrieve the entire node, but the target anchor text would be displayed in some emphasised way. For instance, if the retrieved text is shown in a scrolling window, it might be positioned so the target anchor sits at the top of the window ๐ช
Another attribute of the <A> element, TYPE, is also available. It's meant to describe the nature of the relationship the link models ๐ค. However, it isn't in extensive use, and there doesn't appear to be a registry of the possible values for these types ๐
Future Developments
HTTP and HTML are currently being extended in a backward-compatible way to add multimedia facilities ๐ฌ. [8] describes the HTTP2 protocol, and the revised HTML is defined in [9]. Both documents are subject to change (and the HTML2 specification has actually changed substantially while this report was being prepared) ๐ญ
The revised HTML has loads of enhancements that are useful for multimedia support. Some of the most relevant ones are below ๐
- "Universal Resource Numbers" are a proposed system for unique, timeless identifiers of network-accessible files, currently being designed by IETF Working Groups ๐ข. URNs have to 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, which allows sensible caching of large video clips, for instance ๐๏ธ. The downside is that when something changes and gets a new URN, the source anchors of every link pointing to it must be changed too (and the URNs of those documents must therefore be changed, and so on) ๐ตโ๐ซ. So it makes sense to allocate URNs only to very large documents that change rarely, and not to the documents that reference them ๐
- The title of a destination document may be included as an attribute of a source anchor ๐ท๏ธ. This lets a client show the title to the user before or during retrieval, and it also lets data that doesn't contain its own title (like image data) be given one ๐ผ๏ธ
- There's provision for in-line non-text data (like images, video, graphics, and mathematical equations), which appears in the same window as the main textual material in the node ๐
- The concept of the relationship a hyperlink expresses is expanded ๐ซ. Both source and target anchors may contain relation attributes that point forwards and backwards respectively. Possible relationships include "is an index for", "is a glossary for", "annotates", "is a reply to", "is embedded in", and "is presented with" ๐งฉ. The last two are super useful for multimedia. For example, 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 keeps the same stateless connect/request/response/close procedure as current HTTP ๐. Data is transferred in MIME-shaped messages, so all MIME data formats (including HTML) can be used ๐. As well as the GET operation, HTTP2 has operations such as:
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 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 (like date, cost, and 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 an authorisation failure or the absence of a charge account in the request ๐ซ
The protocol also contains a mechanism designed to let the server make an intelligent decision about the most appropriate format to return data in, based on information the client supplied in the request ๐ง . This might let a powerful server store the uncompressed bitmap of an image but compress it on request using an appropriate encoding, according to the decoding capabilities the client announced ๐ผ๏ธโจ
An HTTP2 server and client are currently under test ๐งช. Some HTML2 features are already built into 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 for wide-area distributed asynchronous collaboration and hypermedia-based information discovery and retrieval ๐. Mosaic is specifically aimed at scientific research workers ๐ฌ. It 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 with similar functionality are under development for the Apple Macintosh and the PC with Windows ๐
The capabilities of the XMosaic browser include:
- Support for NCSA's Data Management Facility (DMF) for scientific data ๐งช
- Support for transferring data with other NCSA tools, such as Collage, using NCSA's Data Transfer Mechanism (DTM) ๐ฆ
- The ability to "check out" documents for revision, and to check them back in again โ๏ธ
- Local and remote annotation of Web documents ๐
Future planned functionality includes:
- In-line non-text data (in addition to images) ๐จ
- Information space graphical representation and control ๐
- Hypermedia document editing โ๏ธ
- Information filtering ๐
NCSA intends to make the entire Mosaic system publicly available and distributable ๐ฅณ
The XMosaic browser was used extensively for finding and retrieving the information used to prepare this report ๐
Web Publishing
Making a web is as simple as writing a few SGML files that 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 one ๐ฃ. 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 that understand HTML, for instance on UNIX and on the NeXT platform โ๏ธ๐
Published non-text data
See the multimedia demo node on:
http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/multimedia.htmlThis is where the media types get the spotlight ๐ Links to images, sound, movies and postscript files are all there. The media type comes from the filename extension in the target node's URL. The XMosaic client uses that to launch a separate program that matches the type, or, in some cases, it shows the media right inside the source document. That embedded version uses an <IMG> tag, which is part of HTML2 ๐ผ๏ธโจ
Advantages
Okay, the WWW is a hypertext system, so its underlying tech is way richer than Gopher ๐ SGML is becoming really important in hypermedia systems, and it gives you so much expressiveness and structure. Text can look super attractive too ๐ธ The multimedia support in the extended versions of HTTP and HTML is honestly excellent ๐ญ And it seems like the QOS and management issues from Chapter 2 are being handled to some degree in these extensions ๐
Limitations
Here's the tea ๐ต The source anchor doesn't tell you the media type of the destination node, or its size. That was ruled out on the argument that the information is likely to degrade over time ๐ So you have to send a HEAD request (in HTTP2) to figure it out ๐
Link source anchors have to live in text documents, so non-text nodes must be leaf nodes ๐ฆ BUT, with HTML2 and the <IMG> tag, an embedded bitmap can be a source anchor! The position of the mouse click inside the image gets passed to the server, and then the server can choose to return a different document depending on where in the image you clicked. Iconic, honestly ๐ฅ
WWW is way 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. Still, the growth in WWW use is much faster than the growth in Gopher use ๐ Sophisticated WWW clients like XMosaic are fuelling this growth, and I'm obsessed ๐
3.4. Evaluating Existing Tools โจ
okay so this section lines up Gopher, WAIS, and WorldWideWeb (aka GWW ๐ ) against the requirements we set up in section 2.3. spoiler: some of them slay and some are... a lot ๐
Platforms
the table below lists the big client names for each GWW system on the three platforms that matter most ๐. ngl WWW is giving "still getting ready" energy, since the Macintosh and PC clients are still under development ๐. also, the main PC Gopher client is "PC Gopher III", and it's a DOS program, NOT a Windows one. bestie, be careful with that one ๐ญ
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
XMosaicAt the moment, multimedia support in most of these clients (where it exists) is basically limited to calling out to external "viewer" programs for particular media types ๐ฆ. the exception is XMosaic, which can show in-line images in WWW documents ๐.
Media Types
the GWW tools can all handle multiple media types well ๐ซถ
- Text is very well supported by all three tools ๐. WWW also has ways to display "richer" text, with headings, lists, emphasised text etc., all in a standardised way ๐ .
- Image data is also well supported ๐ผ๏ธ. it can go through external viewers (for example, the TurboGopher client on a Macintosh might invoke
JPEGViewto display an image), or it can show up in-line within a text document (WWW with XMosaic on UNIX) โจ. - Application-specific data gets little direct support, but most systems let data of a nominated type get passed to an external viewer or editor program ๐ง. this is more of a client software thing than something built into the protocol or server. the WWW community has talked about using TeX for math equations, and about "panels" inside a text document where a separate application could render its own application-specific data (or pretty much any data that can be shown spatially) ๐ธ. that last idea fits really well with OLE (Object Linking and Embedding), the approach used in Microsoft Windows ๐.
- Sound can be supported through the external "viewer" concept ๐ง. some platforms don't have easy-to-get "viewers" with "tape recorder"-style controls for playback ๐ญ. and there's no single commonly-accepted sound encoding format, so it's a bit of a free-for-all ๐.
- 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 letting the client figure out the type of a node (plus a list of available encodings) before downloading it ๐. WAIS and Gopher send this info in the result set and menu respectively ๐. WWW clients currently work it out either by analysing the URL of a target node, or by spotting the <IMG> tag ๐ค. the new WWW HTTP2 protocol lets the media type and encoding of a node get determined through a separate interaction with the server ๐ฆ.
the GWW systems all use different methods for expressing type and encoding ๐. WAIS doesn't distinguish the encoding from the media type. WWW is moving to the MIME type/encoding system. Gopher doesn't distinguish type and encoding either, but Gopher+ does, and it's also moving to the MIME type/encoding system โจ.
Hyperlinks
only the WWW system has hyperlinks ๐. source anchors can be text, images, or points within an image. target anchors can be entire nodes of any media type, or points within text nodes (with HTTP2, portions of text nodes) ๐.
Gopher+ could potentially be enhanced to include hyperlinks, but there doesn't seem to be any development effort going towards that. those who need hyperlinking are using WWW instead ๐.
Gopher menus can be built to offer alternative views of gopherspace ๐บ๏ธ. for example, there's a geographically-organised menu tree of gopherspace already in place, but a parallel subject-based menu tree could be added as another way to get at the same data (and there are in fact moves to set this up ๐). since WWW offers a superset of Gopher functionality, all of this applies to the Web too. actually, the Web already has a rudimentary subject tree ๐ณ.
in both Gopher and WWW, non-textual data can be used in different information structures without having to keep more than one copy ๐งโโ๏ธ.
Presentation
there's little support in GWW for controlling how non-text data is presented ๐จ.
- Backdrops are not supported by GWW ๐ซ.
- Buttons are supported in a limited way. usually, a node gets retrieved by clicking a highlighted text phrase, or an entry in a list ๐ฑ๏ธ. in XMosaic, bitmap images can be used as buttons, but there's no support for different styles of button ๐ . client software may have generic navigation buttons (e.g., "Back", "Next", "Home") that are always available and don't form part of a node ๐ .
- Synchronisation in space is not supported by GWW, except that WWW supports contextual synchronisation of images using the
<IMG>tag ๐ผ๏ธ. - Synchronisation in time is not supported by GWW โฐ.
Searching
WAIS supports keyword searching and is extremely well suited for that task ๐. the Gopher+ protocol could potentially support multimedia database querying apps through the ASK attribute, but there isn't any server implementation that supports such database applications yet ๐ญ. in the WWW project, there are ongoing discussions about how best to extend HTML to handle database query applications. an <INPUT> tag has been suggested, but no consensus has emerged yet ๐คทโโ๏ธ.
both Gopher and WWW can make use of WAIS-type keyword searching ๐ซ. they can do it by including WAIS code in the server (so WAIS index files can be searched), or through WAIS gateways, which run searches on remote WAIS servers in response to queries from non-WAIS clients ๐ธ.
Interaction
XMosaic lets users make text (or, on some platforms, audio) annotations to any text node ๐. the annotations show up at the end of the text display.. they're held locally, so other users of the node don't see them. (a recently added facility does allow globally-visible annotations held on an "annotation server", though ๐.) text annotations can include hyperlinks to other nodes, provided the user knows how to use HTML ๐ค. other clients don't offer facilities like this ๐.
there's a move to add an "email" address notation to URL. this would let WWW client software invoke a mail program when a user selects an anchor with such a URL ๐ง.
there are plans to let WWW users outline a rectangular area of interest within an image, for use in an HTTP request ๐ฏ.
there's 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 really hard to meet with the wide-area network (or even LAN) tech that's deployed right now ๐ข. it's especially rough for voluminous multimedia data ๐ญ.
none of the GWW systems currently take advantage of the emerging isochronous data transfer capabilities of protocols like RTP, or technologies like ATM โก. none of them make serious attempts to fix the problem in other ways either, except for WWW, which defines some mechanisms in HTTP2 for format negotiation based on size and available bandwidth considerations ๐ .
Management
the table below shows support for three key management facilities across the GWW systems ๐. the first two facilities need support in the client/server protocol. the third needs support in the server, but it depends on authentication being available ๐.
Gopher WAIS WWW
Access control No No1 Yes, in
and HTTP2
authentication
Charging support No No Yes, in
HTTP2
Monitoring for No No No
statistical and
assessment
purposesNote:
- "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 client to execute scripts, because of security issues (it would be way too easy for a malicious "trojan" script to get executed) ๐จ. Gopher and WWW servers can run a UNIX script on the server, with the script output returned to the client ๐. scripting as understood in the context of stand-alone multimedia applications doesn't exist in GWW ๐ โโ๏ธ.
Bytestream Format
none of the three GWW systems use a bytestream format for swapping collections of material ๐ฆ. there's been some talk about setting up something like the "Trickle" mail server, for retrieving single document nodes from GWW using mail ๐ฌ. a system like that has been implemented for WWW โ .
Authoring tools
Gopher is simple enough to set up that no special authoring tools are needed ๐ฑ. WAIS only requires an indexing program (as discussed in section 3.2) to prepare material for publication ๐.
WWW uses a sophisticated authoring language (HTML), so it benefits from the availability of authoring tools ๐ ๏ธ. there are HTML editors for UNIX (using the tk toolkit) and the NeXT system ๐ป. there aren't any authoring tools designed specifically for exploiting the multimedia capabilities of WWW, mainly because those capabilities are still evolving ๐.
4. Research โจ
this section covers some current research projects in the area of distributed hypermedia information systems ๐ฌ. ooh, this is where it gets spicy ๐ถ๏ธ.
4.1. Hyper-G โจ
Okay bestie, Hyper-G ๐ฆ is an ambitious distributed hypermedia research project. It's spread across several 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. The Austrian Ministry of Science funds it. It mixes hypermedia, information retrieval, and documentation systems with communication, collaboration, and computer-supported teaching and learning. Major brain energy ๐ง ๐
Hyper-G is different from WWW in a few iconic ways. First, it supports bi-directional links, so you can see which other documents reference the one you're reading. That also means the system can avoid dangling pointers when a linked-to document gets deleted. ๐ Second, links are stored separately from their source and target nodes. This makes it easy to link to read-only documents and keeps link maintenance simple. Third, on top of manually defined links, Hyper-G can automatically generate and maintain links, both statically and dynamically (that is, at view time). ๐ฅ
Hyper-G also has a concept of generic "structures," which is an extra layer of relationships sitting on top of the web of documents and links (and it doesn't interfere with them). A document can belong to more than one structure, and structures can be arranged hierarchically. The types of structure are:
- "Clusters" are a set of documents that are all presented together.
- "Collections" are unordered sets of documents or other structures. They can be used as query domains or to build gopher-like menus.
- "Paths" are ordered sets of documents or structures that must be visited in sequence. ๐
One application of structures is "guided tours" through the information space, which is so giving main character energy ๐
Beyond hypernavigation, the collection hierarchy, and guided tours, you can also interact with the system through database queries. There are two kinds: keyword searching across a user-defined list of databases, and collection-specific form-filling queries. With the form-filling kind, the answer to the query can show up dynamically while you're still filling out the form. Iconic. ๐
Hyper-G recognises four modes of user identification:
- "identified", where a userid is publicly tied to a particular individual through name and address information.
- "semi-identified", where the system ties a userid to an individual, but other users only know that person by a pseudonym.
- "anonymously identified", where the system doesn't tie the userid to any individual.
- "anonymous", where there's no userid at all, or only a generic one such as "guest."
What you can do in the system depends on your mode of identification. You can get into the system in whichever mode you want, and only switch to other modes when you actually need to. Privacy queen behaviour ๐๐ธ
Hyper-G has specific support for multilingual documents and document clusters. For example, you can specify an ordered list of preferred languages. There are also plans to experiment with automatic translation programs, which is lowkey exciting ๐
Integrating other, external systems such as WWW into Hyper-G in a seamless way is possible. ๐ซถ
Hyper-G is already in use as a CWIS at Graz Technical University. Client software is available for UNIX workstations from DEC, HP, SGI, and SUN. The system is still experimental, but about 200 students have used it as part of a course on the social impact of information technology. Not bad for a research project โจ
4.2. Microcosm
Microcosm [11] is an open hypermedia system developed at the University of Southampton. It runs on the PC under MS Windows, and versions for the Apple Macintosh and for UNIX with X are in development. ๐
Microcosm is made up of a number of autonomous processes that talk to each other through a message-passing system. Information about links between documents lives in a link database, called a "linkbase," rather than inside the documents themselves. That gives you a few perks:
- Links to and from read-only documents (perhaps stored on CD-ROM) are possible.
- Documents don't need any conversion process to be imported into the system. You can still view and edit them in the original application that created them, and the link information doesn't get in the way.
- Establishing links to and from non-text documents is just as easy as doing it for text documents. ๐ฆ
In Microcosm, the user works through a "viewer" program for a particular media type. Viewers can be written specifically for Microcosm (about 10 have been written for a number of common media types and encodings). They can also be programs that were adapted for use with Microcosm (the programmability of Microsoft Word for Windows made it possible to adapt it this way). Or they can be programs that know nothing about Microcosm at all. ๐ง
The user selects an object (for example, a piece of text) in the viewer and asks Microcosm to do something with it. The usual move is to follow a link to another document. That might mean launching another viewer to display the target document. ๐
Microcosm link source anchors can be specific (pointing to a unique spot in a particular document), local (pointing to any occurrence of a particular object in a particular document), or generic (pointing to any occurrence of an object in any document). Target anchors can point to specific objects within a document. Other link styles include text-retrieval links (which look up a full-text index, the way WAIS does) and relevance links (which point to a set of documents using similar vocabulary to the source document, similar to WAIS's relevance feedback). ๐ธ
Readers can create links as well as authors. Dynamically computed links can be added to the permanent linkbase for later use. Microcosm keeps a history of link traversal, and "guided tours" can be set up so the reader can wander off the tour and come back to it. ๐บ๏ธ
Microcosm viewers work by sending messages to the Microcosm system. On MS Windows, those messages go through DDE (Dynamic Data Exchange). In the Apple Macintosh version, Apple Events are used. On UNIX, sockets are used. For viewers that aren't Microcosm aware, the user has to copy the selected object to the system clipboard before following a link from it. ๐
Networking support in Microcosm is still under development. Its components can be distributed across multiple machines, so there isn't necessarily a concept of "client" and "server." ๐
There are problems with the Microcosm approach. They're common to systems that keep link information separate from documents and that use external viewers:
- Documents move and change, which invalidates links. Microcosm datestamps links to help detect such problems, but it doesn't correct them. ๐ญ
- It isn't always clear what links can be followed from a document, because the viewer program doesn't know what's in the linkbase.
- It isn't always possible to indicate which object in a document is the target anchor of a link. Many viewers automatically show the start of a document (a word processor, for example) or the entire document (a picture viewer, for example). The user has no way of knowing which part of the target document the followed link points to. ๐
Microcosm can be seen as an integrating hypermedia framework: a layer on top of a range of existing applications that lets you set up relationships between different documents. ๐ซถ
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 builds on AM1, an earlier system developed as part of MIT's Project Athena. ๐
The first version of AM2 is scheduled for January 1994. It will be "pre-commercial software," and a fully commercialised version is due about 6 months later. Both the educational and commercial sectors are the intended market. The system will start out based on X and UNIX workstations, and PC/Windows support will come 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:
- AM2 will support importing and exporting applications from and to standard forms. The project is keeping an eye on standards such as HyTime, MHEG and ODA. ๐ฅ
- Several "application themes," which are frequently occurring collections of functionality, are seen as useful. They are as follows:
Application Theme Interactive?
Presentation of multimedia data No
Exploration of a rich multimedia Yes
environment
Simulation of a real-world scenario Partially
Communication of real-time No
information to the user
Authoring Yes
Annotation of material Yes- "Interface templates" let a multimedia application use a common format for presenting a range of content. This is similar to the "backdrop" concept mentioned in section 2.3.4. ๐
- A range of link types will be supported. ๐ฆ
- Media content editors and interface/application editors for structuring will be provided. A third class of editor, the "hypermedia notebook," will let readers 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 โจ
Okay bestie, some of the research programmes sponsored by the Commission for the European Community (CEC) have projects that are apparently relevant ๐ [1] has the deets on some of them ๐
RACE programme
The RACE programme is outlined in [13], so check that one for more info on the projects below ๐ RACE targets the industrial, commercial and domestic sectors, so the results aren't necessarily directly applicable to the research and academic community. The RACE project numbers are listed here:
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.
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], so that's the one to read for more on the projects below โจ ESPRIT project numbers are listed here:
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.
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
Here are some other research projects that are less immediately relevant ๐ง Some of them get a longer write-up in [1].
- Xanadu is a project to develop an "open, social hypermedia" distributed database server with CSCW features ๐ฆ It's been around for many years and a bunch of companies have funded it. The current status isn't known, and even though an imminent availability of alpha-test versions was announced more than once, no software has actually been delivered ๐
- CMIFed [15] is an editing and presentation environment for portable hypermedia documents, being developed at CWI in Amsterdam, NL ๐ธ It's based on the "Amsterdam Model" of hypermedia [16], which extends the Dexter hypertext reference model with "channels" for media delivery and synchronisation constraints.
- Deja Vu [17] is a proposed "intelligent" distributed hypermedia application framework ๐ฎ It's meant as a research vehicle for hypermedia systems, object-oriented programming, distributed logic programming, and intelligent information systems. Techniques proposed for it include "inferential links", which are defined automatically according to predefined rules, and a scripting language for information providers and users is planned. It's at a very early proposal stage, with relatively little software developed so far, and it's intended principally as a research framework rather than a service tool.
- Demon is a project at Bellcore, US, looking into the network requirements of near-term residential multimedia services ๐ It's designing and implementing an experimental application for casual multimedia users.
- InfoNote is a distributed, multiuser hypermedia system from Japan, running on a NEC EWS4800 with UNIX and X ๐ It has an editor that can create Japanese texts, figures and raster images. The same windows are used for both editors and browsers, and a window's functionality can change at any time as long as the data isn't write-protected.
- MADE (Multimedia Application Demonstration Environment) is a project at British Telecom's research laboratory ๐ฌ It centres on using the developing MHEG standard to access a multimedia object server. The server platform is a Sun SPARCstation with an object-oriented database package (ONTOS), and it covers audio, video, text and graphical media types. The University of Kent is working on a sub-project called "Multi-user Indexing in a Distributed Multimedia Database".
- Zenith aimed to set out principles to help designers and developers of object management systems for distributed multimedia design environments ๐ The project implemented a prototype generalised multimedia object management system.
5. Standards
5.1. Structuring Standards
This section is all about the important standards for giving multimedia data its hyperstructure ๐งฉ Let's get into it bestie!
SGML
SGML (Standard Generalized Markup Language - ISO 8879) is a metalanguage for defining markup notations for text ๐ It's used to write Document Type Definitions (DTDs), which individual document instances have to conform to. It shows up in a wide and growing range of text processing applications.
SGML is surprisingly relevant to distributed hypermedia systems ๐ญ mainly because it's so expressive, and because it can handle non-textual data using "external entities" and "notations". Here's where it pops up:
- The World-Wide Web is an SGML application with its own DTD ๐
- The important HyTime hypermedia structuring standard (see below) is based on SGML.
- The forthcoming MHEG hypermedia structuring standard (see below) has an SGML encoding.
- SGML has been used in research hypermedia systems, for example Microcosm.
- SGML is used in some commercial hypermedia systems, for example DynaText.
- SGML is becoming more and more important 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 knew their stuff about SGML and were supportive of using it for these systems ๐
A related standard that may become important for SGML on networks is SDIF (SGML Data Interchange Format - ISO 9069) ๐ซถ It specifies how an SGML document, which may live in a number of separate files of different media types, can be encoded using ASN.1 into a single bytestream. The entity structure is preserved, so the recipient can decode the bytestream back into the same set of files.
HyTime
HyTime (Hypermedia/Time-Based Structuring Language) is a standardised infrastructure for representing integrated, open hypermedia documents โจ It was developed mainly by ANSI committee X3V1.8M, then adopted by ISO and published as ISO 10744.
HyTime is based on SGML, but it isn't an SGML DTD itself ๐ Instead it provides constructs and guidelines ("architectural forms") for making DTDs that describe hypermedia documents. For example, the Standard Music Description Language (SMDL: ISO/IEC Committee Draft 10743) defines a (meta-)DTD that's an application of HyTime. Honestly, HyTime started out as an attempt to make a markup scheme for music publishing, which is kind of iconic ๐ถ
HyTime specifies how certain concepts common to all hypermedia documents can be represented using SGML. Those concepts are:
- association of objects within documents with hyperlinks
- placement and interrelation of objects in space and time
- logical structure of the document
- inclusion of non-textual data in the document
An "object" in HyTime is part of a document and is unrestricted in form, so it can be video, audio, text, a program, graphics, and so on ๐ฆ The terminology in HyTime (and in this section) differs slightly from the rest of this report, so a HyTime object corresponds roughly to a node as defined in section 1.2, and a HyTime document is a hyperdocument in this report's terms ๐ค
HyTime consists of six modules, which are very briefly and selectively described below:
Okay so the Base module is the foundation everything else leans on ๐ It gives you a lexical model for describing element contents, facilities for picking policies for coping with changes to a document or following a link ("activity tracking"), and the ability to define "container entities" that can hold multiple data objects. That last one got added to HyTime super late, at the instigation of Apple Computers Inc, as a "hook" for their Bento specification [18] ๐
- Measurement module ๐ This lets an object be located in time and/or space (which HyTime treats as the same thing ๐ง), or in any other domain that can be represented by a finite coordinate space. It sits inside a bounding box called an "event", which is defined by a set of coordinate points. Coordinates can be expressed in any units (the predefined ones include femtoseconds, fortnights, millenia, angstroms, Northern feet and lightyears!) ๐ญ
- Location Address module ๐ On top of SGML's basic ability to identify and refer to elements, this module adds a special "named location address" architectural form. It can point indirectly at data that spans elements, or that lives in external entities. You can also address data indirectly with "queries", which return the addresses of objects in some domain whose properties match the query. There's a "HyQ" notation for defining the query ๐
- Hyperlinks module ๐ฆ Two basic types of hyperlink are defined. The contextual link (clink) has two anchors, and one of them is embedded in a document to explicitly denote where the anchor is. The independent link (ilink) can have more than two anchors, and it doesn't require them to be embedded in the document. So ilinks let hyperlink info live separately from the document content ๐ซถ
- Scheduling module ๐๏ธ This specifies how events in a source finite coordinate space (FCS) get mapped onto a target FCS. For example, events on a time axis could be projected onto a spatial axis for graphical display, or a "virtual" time axis as used in music could be projected onto a physical time axis ๐ถ
- Rendition module ๐ This lets individual objects get modified before rendition, in an object-specific way. One example is tweaking the colours in an image so 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, bestie. An application designer can choose appropriate HyTime architectural forms and add application-specific constraints to them. The designer may also use non-HyTime SGML elements and attributes, but those parts of the application can't be understood by a "HyTime engine" ๐ญ Even without a HyTime engine, though, the HyTime architectural forms give you a useful base of ideas to work from โจ
The role of a HyTime engine isn't specified in the standard, but basically it's a (sub)program that 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 that 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 a format for directly-executable hypermedia applications. So it's very expressive, but it 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 going to be published in two parts. Part 1 is the base notation, representing objects using ASN.1, and part 2 is 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 ๐ง
MHEG is suited to interactive hypermedia applications such as on-line textbooks and encyclopaedia. It's also suited to lots 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 those markets, MHEG represents objects in a non-revisable form, so it's 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 that let the objects be represented in a convenient "final" form with the aim of direct presentation ๐ฌ
The MHEG draft standard is expressed in object-oriented terms, and the main object classes are outlined below ๐งฉ
- Content class. A content object contains the encoded (monomedia) information to be presented, along with attributes that identify the type of information and the encoding method, and media-specific attributes such as fonts used, sampling rate, image size, etc.
- Selection class and Modification class. The user may interact with MHEG objects that inherit interactive behaviour from these classes. (The MHEG object model supports multiple inheritance.)
- 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.
- 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 that are carried out when those conditions are satisfied. Links also define the spatio-temporal relationships between objects ๐
- 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 that may be executed by an external program (see SMSL below).
- 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 that are also members of the composite object ๐ช
- Descriptor class. Descriptor objects contain general information about sets of interchanged objects, so that a target system can make sure it has adequate resources to run the hypermedia application represented by the object set ๐
The relationship between HyTime and MHEG hasn't been fully established yet. One possible relationship [21] is that an MHEG application could be the output of a compilation process that used an equivalent HyTime document as input. This approach would benefit from both 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 don't 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. Given the draft nature of the MHEG standard, this report recommends that RARE should not invest substantial effort in MHEG at this time. However, particularly given 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 can represent documents in both a formatted form and a processable (i.e., revisable) form, so both the content and the printed appearance of the document can 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 ๐
Hypermedia extensions to ODA (HyperODA) are underway. The extensions will support:
- References to data held externally to the document (similar to SGML's external entities?).
- Non-linear structures, using contextual and independent hyperlinks based on the HyTime model.
- 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:
- the HyperODA extensions are still under development;
The ODA case is looking pretty shaky, bestie ๐
- in some senses ODA can be seen as a competitor to SGML, which has greater presence in the hypermedia world ๐
- there seems to be a lack of enthusiasm for ODA in the Internet community (the IETF WG on piloting ODA has disbanded) ๐ฌ
- Adobe's newly-released Acrobat technology (described below) will have a significant effect on the marketplace ๐ฅ
So okay, this report recommends that ODA should not form a basis for investment in networked hypermedia technology by RARE. Not me saying no to ODA ๐
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 is about building, presenting, and interacting 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 it 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, they appear not to be mentioned in the text. Honestly, 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 PDF thus appears to offer very similar functionality to ODA ๐. Adobe's successful PostScript de facto standard profoundly influenced information technology, so 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) ๐ข.
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 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:
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 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 ๐ค
okay so this section is about some trade associations that are helping make the standards in the multimedia world ๐ bestie, the drama is real
Interactive Multimedia Association
The Interactive Multimedia Association (IMA) is an international trade association with over 250 members ๐ญ It's giving "everyone who's anyone in multimedia." The members include Apple, Microsoft, MIT CECI (the developers of AthenaMuse 2), 3DO, and lots of other important market players ๐
In 1989, the IMA started a "Compatibility Project" ๐ฅ Its whole job was building technical solutions for the cross-platform compatibility problem. The Project has already published two big documents:
- "Recommended Practices for Multimedia Portability" [23] lays out a spec for a common interface that interactive video delivery systems can use. The US Military adopted it as part of Military Standard 1379. Iconic ๐
- "Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems" [24] defines four standard digital audio data types and four sampling rates. They go all the way from low-end ฮผ-law 8kHz mono encoding, up through ADPCM modes, to CD-quality 44kHz 16-bit stereo ๐ง
More recommendations on other issues are still in the works ๐ธ
Now the Compatibility Project has started a procurement process by publishing three Request for Technology (RFT) documents ๐ These define the requirements for a platform-independent interactive multimedia system, networking requirements included. 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 is the framework behind these RFTs. They're very practical documents that spell out the technical requirements for time-based media handling in detail โจ Just note that they say relatively little about non-time-based data.
Okay, first reading of the Multimedia Data Exchange RFT: the Apple Bento standard [18] and the Microsoft/IBM RIFF format [25] both clearly influenced it ๐ฆ The selected system may well be based on one or both of them, so keep an eye out.
A joint response to the Multimedia System Services RFT came in from HP, IBM and Sun. Two responses to the Scripting Languages RFT arrived, from Kaleida (Script-X) and Gain Technology (GEL). Two partial responses to the Multimedia Data Exchange RFT came from Apple (Bento) and Avid (Open Media Framework) ๐
The IMA is still analysing the responses to the RFTs, and the result will be announced in November 1993. The specs that come out of this will matter a lot for future commercial multimedia products, so it's important that the community keeps a watching brief on the IMA Compatibility Project ๐ Its possible implications for distributed multimedia applications on the Internet are a big deal, iykyk ๐
Multimedia Communications Forum
The Multi-Media [sic] Communications Forum (MMCF) is a brand new trade consortium, formed in June 1993 ๐ Its initial members include IBM, National Semiconductor, Apple, Siemens and AT&T. It's meant to complement the IMA's work. 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 give input to standards bodies ๐ง
Honestly, it's still too early to say whether this forum will succeed ๐ If the IMA Compatibility Project specifications leave networking issues open when they're published, then MMCF could have an important role to play. It is recommended that RARE consider becoming an Observing Member ($350 US pa). That gets them into general and annual MMCF meetings (but not committee meetings), and they'd receive minutes and other general papers (but not working documents). Later on, there's the prospect of becoming an Auditing Member ($1200 US pa) if it turns out to be 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 applications that let people in different locations view documents, images, graphics and full-motion video on a PC screen. Its remit includes CSCW aspects. Members include IBM, Intel, Northern Telecom, Telstra (Australia), BT, France Telecom and DB Telekom. The companies plan to run 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 coming out of the research phase and into experimental deployment ๐ Basically every project team (and standards committee), almost without exception, is hoping their system becomes the de facto standard for hypermedia. Main character energy, all of them ๐
As we've seen, Gopher and WWW already offer multimedia capability, but they're still mostly oriented to using external viewers for non-text nodes ๐ This "unintegrated" approach is pretty different from typical stand-alone multimedia applications, where the presentation of related information in different media is tightly integrated. The in-line image feature of XMosaic and the new version of HTML currently under development might be the start of a move toward greater integration of different media in these distributed hypermedia systems ๐ฆ
Three important factors in designing distributed hypermedia systems come out of the earlier chapters of this report ๐ Each one can be explained as a distinction between two aspects of the system.
- A common and pretty fruitful approach to hypermedia systems is to distinguish the content from the hyperstructure. Standards work clearly separates these concepts: MPEG, JPEG, G.72x, etc, are for content, and HyTime or MHEG are for structure ๐งฉ Systems that are already deployed also make this split, most obviously Gopher, where the structure/content split maps onto the server filesystem's directory/file split ๐ In a similar way, keeping hyperlink information separate from data is seen in hypermedia research circles as a "good thing" โจ Research systems like Microcosm and Hyper-G do this, and HyTime with its ilink element supports it too. WWW doesn't support this, though. It requires link anchors to be edited into source data. There are problems with this approach, however, so see the section on Microcosm for details ๐
- A useful approach to content is to distinguish the media type from the media encoding. The MIME standard (used by HTTP2) shows how this can be done, and Gopher+ uses a similar system ๐
- The distinction between data and protocol is also important for some systems. WWW, for instance, has clearly separate protocol (HTTP) and data (HTML) specifications. Gopher+, however, is specified without making this distinction. (The original Gopher system is very simple and arguably has no need for that separation ๐)
The biggest mismatches between what currently-deployed systems can do and what users need are in 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). Those capabilities could come out of the progress toward greater media integration I just mentioned ๐ Improving QOS, though, is significantly harder, because it may require changes at a more fundamental level ๐ The following section outlines some possible solutions to this problem, so stay tuned ๐ ๐ซถ
6.2. Quality of Service ๐
Okay bestie, responsiveness is literally the make-or-break thing โจ If users are stuck waiting forever, networked multimedia info systems are not going to get accepted, no cap ๐ญ Here's the number-crunch we already talked about:
- For simple actions such as "next page", tolerable delays are of the order of 0.2s.
- For more complex actions such as "search for documents containing this word", then a tolerable delay is of the order of 2s.
- 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. Honestly, the second option is iconic ๐ sometimes the move is just lowering everyone's expectations lol ๐ธ
- 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. ๐๐
- Display a "progress" indicator while fetching data. ๐โจ
- 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.
- 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. ๐งต
- 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. ๐ฎ
- Cache information locally. The use of Universal Resource Numbers (see the section on WWW) is relevant for managing this. ๐พ
- 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. ๐
- 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. ๐๐
- 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. ๐ผ๏ธ
- 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 โจ
okay so bestie, to make apps like the ones in section 2.1 actually work, the community has to adapt and upgrade the tools we already have instead of building brand new ones ๐ ๏ธ๐ RARE has a real chance to kickstart this, and the subsections below lay out a plan for how ๐ซถ
Selecting a System ๐ฏ
RARE should focus its energy on just one of the existing tools to get the biggest impact ๐ The candidates are the ones we already covered: Gopher, WWW, WAIS, Hyper-G, Microcosm and AthenaMuse 2.
RARE should pick the World-Wide Web ๐ธ๏ธโจ Here's why, no cap:
- Flexibility. WWW is rich but still straightforward, and its parts (HTML, URL and HTTP) are clearly separable, so it's a super flexible base for building distributed multimedia apps ๐ฆ
- Existing efforts. The WWW implementor community is already talking about and designing extensions to HTML (HTML2), which is meant (among other things) to support multimedia. There's clearly a lot of interest here, and RARE's work could complement what's already happening ๐
- Hyperlinks. Lots of apps need hyperlinking, and WWW handles it really well ๐
- Integrated solution. WAIS, Gopher and Hyper-G (plus anonymous FTP servers) can all be reached from Web clients, so WWW acts as a big integrating tool for information services ๐ง Multimedia apps need heavy client-side support, so they should be built on something "close to" these integrated clients ๐
- Penetration and growth. Gopher has way more servers than WWW, but WWW usage is growing faster. The community is increasingly realising that Gopher is over-simplistic for many purposes, and interest in WWW is rising to match ๐
- Attention to QOS issues. The WWW community already knows it needs an appropriate QOS, and a mechanism has already been proposed in HTTP2 to help with the problem ๐
- Standardisation. The WWW team is seriously working on standardising the existing WWW components ๐ The URL format has already been published as an Internet draft (and it's been adopted as an important part of the proposed Internet integrated information infrastructure), and the current version of HTML is about to follow. Using SGML as the basis of HTML matches how important SGML is considered for hypermedia in general, and it also fits RARE's approach of adopting appropriate open standards ๐
- Software status. CERN recently put the WWW code it developed into the public domain ๐ Every other candidate has restrictions on what people can do with its code, and in Gopher's case those restrictions are already pushing some commercial users to look at other options ๐
WWW has two significant disadvantages, and both are being fixed ๐ง
- Restricted choice of client software. Right now, Apple Macintosh and PC/MS Windows clients are only available in beta ๐ฅฒ By comparison, there's more than one well-tested Gopher client for these platforms.
However, other WWW clients for the Mac and MS Windows are in the pipeline ๐
- There's a perception that making information available over HTTP is difficult, and that it has to be put into HTML.
However, you can put plain-text, non-HTML documents onto the Web ๐ Those documents obviously can't contain links, though.
Also, WYSIWYG HTML text editors exist to take the pain out of writing HTML ๐
The main disadvantages of the other systems are:
- Gopher is designed for simplicity, so it lacks WWW's flexibility. Its structure is too rigidly hierarchical and it has no hyperlinks ๐ฒ Its main advantage is its very heavy penetration. But because WWW accesses data using other protocols, all of gopherspace is part of the Web, and any Web client should be able to act as a Gopher client too ๐ซง
Gopher isn't expected to go away, and it isn't expected to be ruled out for multimedia data either. Still, it's unlikely to be used for more sophisticated multimedia apps like academic publishing, interactive multimedia databases and CAL, because of the limitations above ๐
- WAIS is a specialised tool ๐๏ธ It will definitely be part of the overall solution, especially for database-type applications, but it isn't a general solution for distributed hypermedia apps.
- AthenaMuse 2 is commercially oriented: academic and research users clearly will have to pay to use the software ๐ธ So its level of use is very unlikely to match publicly available systems like WWW. On top of that, it doesn't support all the required platforms.
- Microcosm network support is still in its early stages and currently limited to the PC/Windows platform ๐ฅ๏ธ If it's shown to perform adequately over a network, can scale to global levels, and the advantages of keeping link information separate from documents are found to clearly outweigh the resulting difficulties, it may become important in the future. Microcosm's authors need to make sure that commercialising Microcosm doesn't hinder its adoption by the academic community ๐
- Hyper-G is harder to dismiss ๐ค It's still at a relatively early stage of development, but it appears to have many of the necessary features. Its main disadvantages are: (a) its lack of penetration outside the University of Graz, since the author is aware of only one other site using it; and (b) it's currently limited to UNIX only. The author believes that, given WWW's head start in deployment and the current progress in adding multimedia facilities to it, WWW has 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, we said the most important areas needing effort were (a) providing facilities for the integrated presentation of multimedia data (including synchronisation issues), and (b) making sure responsiveness is adequate ๐ซถ
With that in mind, RARE should invite proposals and (if funding is available) then commission work to:
- Develop conversion tools from commercial authoring packages to WWW, and set up authoring guidelines for authors who want to use the conversion tools. This is a significant, high-profile development aimed at letting sophisticated multimedia apps run over the network ๐คฉ (Authoring guidelines are needed so authors can fit in with the Web's way of doing things, and to document features of the authoring package that should be avoided because of conversion difficulties.)
- Implement and evaluate the most promising ways of overcoming the QOS problem. This is essential, because interactive distributed multimedia apps can't become a reality without it โก Some possibilities were already outlined in the preceding chapter.
- Implement a specific user project using these tools, to validate that the facilities being developed are truly relevant to actual user requirements ๐โโ๏ธ Partner funding from the selected user project might be appropriate.
- Use the experience gained from 1, 2 and 3 to inform and influence the further development of HTML2 and HTTP2, so they provide the required facilities ๐ง
- Contribute to the development of WWW clients (particularly the Apple Macintosh and PC/MS Windows clients) in terms of their multimedia data handling facilities ๐จ
Okay, this part is technically outside the remit of this report, since it isn't specifically about multimedia data, but I have to flag it ๐ The rapid growth of WWW may eventually cause problems through multiple, uncoordinated and mutually incompatible add-on features. To guard against this, it may be appropriate for RARE, in coordination with CERN and other interested parties such as NCSA, to:
- Encourage the formation of a consortium to coordinate WWW technical development (protocol enhancements, etc.) ๐ธ
7. References ๐
Okay bestie, here's the reading list. Every single one of these is cited in the doc, so it's all the receipts ๐งพโจ
- [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/gopher_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 - [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.msgid/19930524.152345.29@almaden.ibm.com - [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
8. Security Considerations ๐
Okay, plot twist, and I need you to sit down for this ๐ญ Security issues are not discussed in this memo. Not a single word! So if you were hoping to find security guidance in here, sorry bestie, it's not giving ๐
Security is serious stuff, so don't skip past this one. This memo simply doesn't cover it.
9. Author's Address ๐
The author, Chris Adie, is reachable here ๐
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.ukThat's the whole doc, bestie! ๐ฆโจ
๐ฆ where this page comes from
- ietf: rfc1614 1994-05
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms