as they register a machine name with the campus domain-name server.
   An entry which points to the departmental server will then be made at
   the top level server.  This ensures that users will be able to
   navigate their way down what amounts to a virtual hierarchical file
   system with a well known root to any campus server if they desire.

   Note that there is no requirement that a department register
   secondary servers with the central top-level server; they may just
   place a link to the secondary servers in their own primary servers.
   They may indeed place links to any servers they desire in their own
   server, thus creating a customized view of thethe Gopher information
   universe; links can of course point back at the top-level server.
   The virtual (networked) file system is therefore an arbitrary graph
   structure and not necessarily a rooted tree.  The top-level node is
   merely one convenient, well-known point of entry.  A set of Gopher
   servers linked in this manner may function as a campus-wide
   information system.

   Servers may of course point links at other than secondary servers.
   Indeed servers may point at other servers offering useful services
   anywhere on the internet.  Viewed in this manner, Gopher can be seen
   as an Internet-wide information system.

3.2 Server portability and naming

   It is recommended that all registered servers have alias names
   (domain name system CNAME) that are used by Gopher clients to locate
   them.  Links to these servers should use these alias names rather
   than the primary names.  If information needs to be moved from one
   machine to another, a simple change of domain name system alias
   (CNAME) allows this to occur without any reconfiguration of clients
   in the field.  In short, the domain name system may be used to re-map
   a server to a new address.  There is nothing to prevent secondary
   servers or services from running on otherwise named servers or ports




 
RFC 1436                         Gopher                       March 1993


   other than 70, however these should be reachable via a primary
   server.

3.3 Contacting server administrators

   It is recommended that every server administrator have a document
   called something like: "About Bogus University's Gopher server" as
   the first item in their server's top level directory.  In this
   document should be a short description of what the server holds, as
   well as name, address, phone, and an e-mail address of the person who
   administers the server.  This provides a way for users to get word to
   the administrator of a server that has inaccurate information or is
   not running correctly.  It is also recommended that administrators
   place the date of last update in files for which such information
   matters to the users.

3.4  Modular addition of services

   The first character of each line in a server-supplied directory
   listing indicates whether the item is a file (character '0'), a
   directory (character '1'), or a search (character '7').  This is the
   base set of item types in the Gopher protocol.  It is desirable for
   clients to be able to use different services and speak different
   protocols (simple ones such as finger; others such as CSO phonebook
   service, or Telnet, or X.500 directory service) as needs dictate.
   CSO phonebook service is a client/server phonebook system typically
   used at Universities to publish names, e-mail addresses, and so on.
   The CSO phonebook software was developed at the University of
   Illinois and is also sometimes refered to as ph or qi.  For example,
   if a server-supplied directory listing marks a certain item with type
   character '2', then it means that to use this item, the client must
   speak the CSO protocol.  This removes the need to be able to
   anticipate all future needs and hard-wire them in the basic Internet
   Gopher protocol; it keeps the basic protocol extremely simple.  In
   spite of this simplicity, the scheme has the capability to expand and
   change with the times by adding an agreed upon type-character for a
   new service.  This also allows the client implementations to evolve
   in a modular fashion, simply by dropping in a module (or launching a
   new process) for some new service.  The servers for the new service
   of course have to know nothing about Internet Gopher; they can just
   be off-the shelf CSO, X.500, or other servers.  We do not however,
   encourage arbitrary or machine-specific proliferation of service
   types in the basic Gopher protocol.

   On the other hand, subsets of other document retrieval schemes may be
   mapped onto the Gopher protocol by means of "gateway-servers".
   Examples of such servers include Gopher-to-FTP gateways, Gopher-to-
   archie gateways, Gopher-to-WAIS gateways, etc.  There are a number of




 
RFC 1436                         Gopher                       March 1993


   advantages of such mechanisms. First, a relatively powerful server
   machine inherits both the intelligence and work, rather than the more