rfc1614.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Quality of Service

   Research has shown [3] that user toleration of delay in computer
   systems depends on user perception of the nature of the requested
   action.  If the user believes that no computation is required,
   tolerable delays are of the order of 0.2s.  If the user believes the
   action he or she has requested the computer to perform is "difficult"
   - for instance a computation of some form - then a tolerable delay is
   of the order of 2s.  Users tend to give up waiting for a response
   after about 20s.  Networked multimedia information systems must be
   able to provide this level of responsiveness.

   Management

   In order to support applications involving real-money information
   services (e.g., academic publishing) and learning/assessment
   applications, there must be a reliable and secure access control
   mechanism.  A simple password is unlikely to suffice - Kerberos
   authentication procedures are a possibility.

   Users must be able to determine the charge for an item before
   retrieving it (assuming that pay-per-item will be a common paradigm
   alternatives such as pay-per-call, pay-per-duration are also
   possible).  Access records must be kept by the information server for
   charging purposes.

   Learning applications have similar requirements, except that the
   purpose here is not to charge for information retrieved, but to
   monitor and perhaps assess a student's progress.

   Scripting

   Many authoring packages provide scripting languages.  In most cases,
   these languages are used to manage the presentation environment and
   control navigation within the hypermedia document.  There are other,
   declarative rather than procedural, methods for achieving this, so
   scripting of this type is not necessarily a requirement.  However,
   some application areas require executable scripts for other purposes
   (e.g., simulations in CAL applications).  Care in providing such a
   facility is required, because of the potential for abuse (the
   possibility of "trojan" scripts).  However, there is work going on to
   produce "safe" scripting languages - an example is "safe tcl", being
   developed by Borenstein and Ousterhout (contact
   [e-mail]).







Adie                                                           [Page 23]

RFC 1614        Network Access to Multimedia Information        May 1994


   Bytestream Format

   For the easy transfer and handling of a hyperdocument, it must be
   capable of being encoded into a bytestream form, in such a way that
   the structure of the document is preserved and it can be decoded
   without loss of information.

   This facility makes it possible for such documents to be supplied to
   a user over electronic mail, in such a way that he or she can browse
   them at his or her own site.  This may be appropriate where the user
   does not have a direct connection to the Internet.  It will also be
   useful for printing the hyperdocument.

   Authoring

   It is essential that a multimedia information system should have
   adequate authoring tools which make it easy to prepare and publish
   hypermedia information.  Such tools need similar power to existing
   commercial multimedia authoring software for stand-alone multimedia
   applications.

3. Existing Systems

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

3.1. Gopher

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

   Client software is available for a large number of systems,
   including:

        o UNIX (character terminals)

        o X windows

        o Apple Macintosh

        o MS DOS



Adie                                                           [Page 24]

RFC 1614        Network Access to Multimedia Information        May 1994



        o NeXT

        o VM/CMS

        o VMS

        o OS/2

        o MVS/XA

   Servers are available for systems such as:

        o UNIX

        o VMS

        o Apple Macintosh

        o VM/CMS

        o MVS

        o MS DOS

   Gopher was developed at the University of Minnesota.

   Gopher User Image

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

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






Adie                                                           [Page 25]

RFC 1614        Network Access to Multimedia Information        May 1994


   Gopher Protocol

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

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

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

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

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

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

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

      o    The port number to use for the TCP connection.

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

   The currently-defined type IDs are as follows:

        0       Node is a file.

        1       Node is a directory.

        2       Node is a CSO phone book server.



Adie                                                           [Page 26]

RFC 1614        Network Access to Multimedia Information        May 1994



        3       Error.

        4       Node is a BinHexed Macintosh file.

        5       Node is DOS binary archive of some sort.

        6       Node is a UNIX uuencoded file.

        7       Node is a search server.

        8       Node points to a text-based telnet session.

        9       Node is a binary file.

        T       Node points to a TN3270 connection.

   Some experimental IDs are also in use:

        s       Node contains -law sound data.

        g       Node contains GIF data.

        M       Node contains MIME data.

        h       Node contains HTML data.

        I       Node contains image data of some kind.

        i       In-line text type.

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

   Gopher+ Protocol

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

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




Adie                                                           [Page 27]

RFC 1614        Network Access to Multimedia Information        May 1994


    INFO               Contains the Gopher reference of the node.
                       Mandatory.

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

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

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

    ASK                This attribute is used for the interactive query