rfc1436.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 899 行 · 第 1/3 页

   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



Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 6]

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



Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 7]

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
   modest, inexpensive desktop system that typically runs client
   software or basic server software.  Equally important, clients do not
   have to be modified to take advantage of a new resource.

3.5  Building clients

   A client simply sends the retrieval string to a server if it wants to
   retrieve a document or view the contents of a directory.  Of course,
   each host may have pointers to other hosts, resulting in a "graph"
   (not necessarily a rooted tree) of hosts.  The client software may
   save (or rather "stack") the locations that it has visited in search
   of a document.  The user could therefore back out of the current
   location by unwinding the stack.  Alternatively, a client with
   multiple-window capability might just be able to display more than
   one directory or document at the same time.

   A smart client could cache the contents of visited directories
   (rather than just the directory's item descriptor), thus avoiding
   network transactions if the information has been previously
   retrieved.

   If a client does not understand what a say, type 'B' item (not a core
   item) is, then it may simply ignore the item in the directory
   listing; the user never even has to see it.  Alternatively, the item
   could be displayed as an unknown type.

   Top-level or primary servers for a campus are likely to get more
   traffic than secondary servers, and it would be less tolerable for
   such primary servers to be down for any long time.  So it makes sense
   to "clone" such important servers and construct clients that can
   randomly choose between two such equivalent primary servers when they
   first connect (to balance server load), moving to one if the other
   seems to be down.  In fact, smart client implementations do this
   clone server and load balancing.  Alternatively, it may make sense to
   have the domain name system return one of a set of redundant of
   server's IP address to load balance betwen redundant sets of
   important servers.

3.6  Building ordinary internet Gopher servers

   The retrieval string sent to the server might be a path to a file or
   directory.  It might be the name of a script, an application or even
   a query that generates the document or directory returned.  The basic
   server uses the string it gets up to but not including a CR-LF or a
   TAB, whichever comes first.




Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 8]

RFC 1436                         Gopher                       March 1993


   All intelligence is carried by the server implementation rather than
   the protocol.  What you build into more exotic servers is up to you.
   Server implementations may grow as needs dictate and time allows.

3.7  Special purpose servers

   There are two special server types (beyond the normal Gopher server)
   also discussed below:

      1.  A server directory listing can point at a CSO nameserver (the
      server returns a type character of '2') to allow a campus
      student-staff phonebook lookup service.  This may show up on the
      user's list of choices, perhaps preceded by the icon of a phone-
      book.  If this item is selected, the client software must resort
      to a pure CSO nameserver protocol when it connects to the
      appropriate host.

      2.  A server can also point at a "search server" (returns a first
      character of '7').  Such servers may implement campus network (or
      subnet) wide searching capability.  The most common search servers
      maintain full-text indexes on the contents of text documents held
      by some subset of Gopher servers.  Such a "full-text search
      server" responds to client requests with a list of all documents
      that contain one or more words (the search criteria).  The client
      sends the server the selector string, a tab, and the search string
      (words to search for). If the selector string is empty, the client
      merely sends the search string.  The server returns the equivalent
      of a directory listing for documents matching the search criteria.
      Spaces between words are usually implied Boolean ANDs (although in
      different implementations or search types, this may not
      necessarily be true).

   The CSO addition exists for historical reasons: at time of design,
   the campus phone-book servers at the University of Minnesota used the
   CSO protocol and it seemed simplest to just engulf them.  The index-
   server is however very much a Gopher in spirit, albeit with a slight
   twist in the meaning of the selector-string.  Index servers are a
   natural place to incorperate gateways to WAIS and WHOIS services.

3.7.1  Building CSO-servers

   A CSO Nameserver implementation for UNIX and associated documentation
   is available by anonymous ftp from uxa.cso.uiuc.edu.  We do not
   anticipate implementing it on other machines.







Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 9]

RFC 1436                         Gopher                       March 1993


3.7.2  Building full-text search servers

   A full-text search server is a special-purpose server that knows
   about the Gopher scheme for retrieving documents.  These servers
   maintain a full-text index of the contents of plain text documents on
   Gopher servers in some specified domain.  A Gopher full-text search
   server was implemented using several NeXTstations because it was easy
   to take advantage of the full-text index/search engine built into the
   NeXT system software.  A search server for generic UNIX systems based
   on the public domain WAIS search engine, is also available and
   currently an optional part of the UNIX gopher server.  In addition,
   at least one implementation of the gopher server incorperates a
   gateway to WAIS servers by presenting the WAIS servers to gopherspace
   as full-text search servers.  The gopher<->WAIS gateway servers does
   the work of translating from gopher protocol to WAIS so unmodified
   gopher clients can access WAIS servers via the gateway server.

   By using several index servers (rather than a monolithic index
   server) indexes may be searched in parallel (although the client
   software is not aware of this).  While maintaining full-text indexes
   of documents distributed over many machines may seem a daunting task,
   the task can be broken into smaller pieces (update only a portion of
   the indexes, search several partial indexes in parallel) so that it
   is manageable.  By spreading this task over several small, cheap (and
   fast) workstations it is possible to take advantage of fine-grain
   parallelism.  Again, the client software is not aware of this. Client
   software only needs to know that it can send a search string to an
   index server and will receive a list of documents that contain the
   words in the search string.

3.8  Item type characters

   The client software decides what items are available by looking at
   the first character of each line in a directory listing.  Augmenting
   this list can extend the protocol.  A list of defined item-type
   characters follows:

   0   Item is a file
   1   Item is a directory
   2   Item is a CSO phone-book server
   3   Error
   4   Item is a BinHexed Macintosh file.
   5   Item is DOS binary archive of some sort.
       Client must read until the TCP connection closes.  Beware.
   6   Item is a UNIX uuencoded file.
   7   Item is an Index-Search server.
   8   Item points to a text-based telnet session.
   9   Item is a binary file!



Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 10]

RFC 1436                         Gopher                       March 1993


       Client must read until the TCP connection closes.  Beware.
   +   Item is a redundant server
   T   Item points to a text-based tn3270 session.
   g   Item is a GIF format graphics file.
   I   Item is some kind of image file.  Client decides how to display.

   Characters '0' through 'Z' are reserved.  Local experiments should
   use other characters.  Machine-specific extensions are not
   encouraged.  Note that for type 5 or type 9 the client must be
   prepared to read until the connection closes.  There will be no
   period at the end of the file; the contents of these files are binary
   and the client must decide what to do with them based perhaps on the
   .xxx extension.

3.9  User display strings and server selector strings

   User display strings are intended to be displayed on a line on a
   typical screen for a user's viewing pleasure.  While many screens can
   accommodate 80 character lines, some space is needed to display a tag
   of some sort to tell the user what sort of item this is.  Because of
   this, the user display string should be kept under 70 characters in
   length.  Clients may truncate to a length convenient to them.

4.   Simplicity is intentional

   As far as possible we desire any new features to be carried as new
   protocols that will be hidden behind new document-types.  The
   internet Gopher philosophy is:

      (a) Intelligence is held by the server.  Clients have the option
      of being able to access new document types (different, other types
      of servers) by simply recognizing the document-type character.
      Further intelligence to be borne by the protocol should be
      minimized.