rfc1436.txt

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

Network Working Group                                     F. Anklesaria
Request for Comments: 1436                                  M. McCahill
                                                             P. Lindner
                                                             D. Johnson
                                                              D. Torrey
                                                             B. Alberti
                                                University of Minnesota
                                                             March 1993


                      The Internet Gopher Protocol
         (a distributed document search and retrieval protocol)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   The Internet Gopher protocol is designed for distributed document
   search and retrieval.  This document describes the protocol, lists
   some of the implementations currently available, and has an overview
   of how to implement new client and server applications.  This
   document is adapted from the basic Internet Gopher protocol document
   first issued by the Microcomputer Center at the University of
   Minnesota in 1991.

Introduction

   gopher  n.  1. Any of various short tailed, burrowing mammals of the
   family Geomyidae, of North America.  2. (Amer. colloq.) Native or
   inhabitant of Minnesota: the Gopher State.  3. (Amer. colloq.) One
   who runs errands, does odd-jobs, fetches or delivers documents for
   office staff.  4. (computer tech.) software following a simple
   protocol for burrowing through a TCP/IP internet.

   The Internet Gopher protocol and software follow a client-server
   model.  This protocol assumes a reliable data stream; TCP is assumed.
   Gopher servers should listen on port 70 (port 70 is assigned to
   Internet Gopher by IANA).  Documents reside on many autonomous
   servers on the Internet.  Users run client software on their desktop
   systems, connecting to a server and sending the server a selector (a
   line of text, which may be empty) via a TCP connection at a well-
   known port.  The server responds with a block of text terminated by a
   period on a line by itself and closes the connection.  No state is
   retained by the server.



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


   While documents (and services) reside on many servers, Gopher client
   software presents users with a hierarchy of items and directories
   much like a file system.  The Gopher interface is designed to
   resemble a file system since a file system is a good model for
   organizing documents and services; the user sees what amounts to one
   big networked information system containing primarily document items,
   directory items, and search items (the latter allowing searches for
   documents across subsets of the information base).

   Servers return either directory lists or documents.  Each item in a
   directory is identified by a type (the kind of object the item is),
   user-visible name (used to browse and select from listings), an
   opaque selector string (typically containing a pathname used by the
   destination host to locate the desired object), a host name (which
   host to contact to obtain this item), and an IP port number (the port
   at which the server process listens for connections). The user only
   sees the user-visible name.  The client software can locate and
   retrieve any item by the trio of selector, hostname, and port.

   To use a search item, the client submits a query to a special kind of
   Gopher server: a search server.  In this case, the client sends the
   selector string (if any) and the list of words to be matched. The
   response yields "virtual directory listings" that contain items
   matching the search criteria.

   Gopher servers and clients exist for all popular platforms.  Because
   the protocol is so sparse and simple, writing servers or clients is
   quick and straightforward.

1.  Introduction

   The Internet Gopher protocol is designed primarily to act as a
   distributed document delivery system.  While documents (and services)
   reside on many servers, Gopher client software presents users with a
   hierarchy of items and directories much like a file system.  In fact,
   the Gopher interface is designed to resemble a file system since a
   file system is a good model for locating documents and services.  Why
   model a campus-wide information system after a file system?  Several
   reasons:

      (a) A hierarchical arrangement of information is familiar to many
      users.  Hierarchical directories containing items (such as
      documents, servers, and subdirectories) are widely used in
      electronic bulletin boards and other campus-wide information
      systems. People who access a campus-wide information server will
      expect some sort of hierarchical organization to the information
      presented.




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


      (b) A file-system style hierarchy can be expressed in a simple
      syntax.  The syntax used for the internet Gopher protocol is
      easily understandable, and was designed to make debugging servers
      and clients easy.  You can use Telnet to simulate an internet
      Gopher client's requests and observe the responses from a server.
      Special purpose software tools are not required.  By keeping the
      syntax of the pseudo-file system client/server protocol simple, we
      can also achieve better performance for a very common user
      activity: browsing through the directory hierarchy.

      (c) Since Gopher originated in a University setting, one of the
      goals was for departments to have the option of publishing
      information from their inexpensive desktop machines, and since
      much of the information can be presented as simple text files
      arranged in directories, a protocol modeled after a file system
      has immediate utility.  Because there can be a direct mapping from
      the file system on the user's desktop machine to the directory
      structure published via the Gopher protocol, the problem of
      writing server software for slow desktop systems is minimized.

      (d) A file system metaphor is extensible.  By giving a "type"
      attribute to items in the pseudo-file system, it is possible to
      accommodate documents other than simple text documents.  Complex
      database services can be handled as a separate type of item.  A
      file-system metaphor does not rule out search or database-style
      queries for access to documents.  A search-server type is also
      defined in this pseudo-file system.  Such servers return "virtual
      directories" or list of documents matching user specified
      criteria.

2.  The internet Gopher Model

   A detailed BNF rendering of the internet Gopher syntax is available
   in the appendix...but a close reading of the appendix may not be
   necessary to understand the internet Gopher protocol.

   In essence, the Gopher protocol consists of a client connecting to a
   server and sending the server a selector (a line of text, which may
   be empty) via a TCP connection.  The server responds with a block of
   text terminated with a period on a line by itself, and closes the
   connection.  No state is retained by the server between transactions
   with a client. The simple nature of the protocol stems from the need
   to implement servers and clients for the slow, smaller desktop
   computers (1 MB Macs and DOS machines), quickly, and efficiently.

   Below is a simple example of a client/server interaction; more
   complex interactions are dealt with later.  Assume that a "well-
   known" Gopher server (this may be duplicated, details are discussed



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


   later) listens at a well known port for the campus (much like a
   domain-name server).  The only configuration information the client
   software retains is this server's name and port number (in this
   example that machine is rawBits.micro.umn.edu and the port 70). In
   the example below the F character denotes the TAB character.

 Client:          {Opens connection to rawBits.micro.umn.edu at port 70}

 Server:          {Accepts connection but says nothing}

 Client: <CR><LF> {Sends an empty line: Meaning "list what you have"}

 Server:          {Sends a series of lines, each ending with CR LF}
 0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70
 1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70
 1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70
 1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120
 1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70
 1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70
                    {.....etc.....}
 .                  {Period on a line by itself}
                    {Server closes connection}


   The first character on each line tells whether the line describes a
   document, directory, or search service (characters '0', '1', '7';
   there are a handful more of these characters described later).  The
   succeeding characters up to the tab form a user display string to be
   shown to the user for use in selecting this document (or directory)
   for retrieval.  The first character of the line is really defining
   the type of item described on this line. In nearly every case, the
   Gopher client software will give the users some sort of idea about
   what type of item this is (by displaying an icon, a short text tag,
   or the like).

   The characters following the tab, up to the next tab form a selector
   string that the client software must send to the server to retrieve
   the document (or directory listing).  The selector string should mean
   nothing to the client software; it should never be modified by the
   client.  In practice, the selector string is often a pathname or
   other file selector used by the server to locate the item desired.
   The next two tab delimited fields denote the domain-name of the host
   that has this document (or directory), and the port at which to
   connect.  If there are yet other tab delimited fields, the basic
   Gopher client should ignore them.  A CR LF denotes the end of the
   item.





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


   In the example, line 1 describes a document the user will see as
   "About internet Gopher".  To retrieve this document, the client
   software must send the retrieval string: "Stuff:About us" to
   rawBits.micro.umn.edu at port 70.  If the client does this, the
   server will respond with the contents of the document, terminated by
   a period on a line by itself.  A client might present the user with a
   view of the world something like the following list of items:


      About Internet Gopher
      Around the University of Minnesota...
      Microcomputer News & Prices...
      Courses, Schedules, Calendars...
      Student-Staff Directories...
      Departmental Publications...



   In this case, directories are displayed with an ellipsis and files
   are displayed without any.  However, depending on the platform the
   client is written for and the author's taste, item types could be
   denoted by other text tags or by icons.  For example, the UNIX
   curses-based client displays directories with a slash (/) following
   the name; Macintosh clients display directories alongside an icon of
   a folder.

   The user does not know or care that the items up for selection may
   reside on many different machines anywhere on the Internet.

   Suppose the user selects the line "Microcomputer News & Prices...".
   This appears to be a directory, and so the user expects to see
   contents of the directory upon request that it be fetched.  The
   following lines illustrate the ensuing client-server interaction:


    Client:           (Connects to pserver.bookstore.umn.edu at port 70)
    Server:           (Accepts connection but says nothing)
    Client: Prices/   (Sends the magic string terminated by CRLF)
    Server:           (Sends a series of lines, each ending with CR LF)
    0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70
    0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70
    0IBM PricesFPrices/IckFpserver.bookstore.umn.eduF70
    0Printer & Peripheral PricesFPrices/PPPFpserver.bookstore.umn.eduF70
                      (.....etc.....)
    .                 (Period on a line by itself)
                      (Server closes connection)





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


3. More details

3.1  Locating services

   Documents (or other services that may be viewed ultimately as
   documents, such as a student-staff phonebook) are linked to the
   machine they are on by the trio of selector string, machine domain-
   name, and IP port.  It is assumed that there will be one well-known
   top-level or root server for an institution or campus.  The
   information on this server may be duplicated by one or more other
   servers to avoid a single point of failure and to spread the load
   over several servers.  Departments that wish to put up their own
   departmental servers need to register the machine name and port with
   the administrators of the top-level Gopher server, much the same way