doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc1436.txt b/doc/rfc/rfc1436.txt
new file mode 100644
index 0000000..a4cd7e0
--- /dev/null
+++ b/doc/rfc/rfc1436.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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
+   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.
+
+      (b) The well-tempered server ought to send "text" (unless a file
+      must be transferred as raw binary).  Should this text include
+      tabs, formfeeds, frufru?  Probably not, but rude servers will
+      probably send them anyway.  Publishers of documents should be
+      given simple tools (filters) that will alert them if there are any
+      funny characters in the documents they wish to publish, and give
+      them the opportunity to strip the questionable characters out; the
+      publisher may well refuse.
+
+      (c) The well-tempered client should do something reasonable with
+      funny characters received in text; filter them out, leave them in,
+      whatever.
+
+
+
+
+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 11]
+
+RFC 1436                         Gopher                       March 1993
+
+
+Appendix
+
+   Paul's NQBNF (Not Quite BNF) for the Gopher Protocol.
+
+   Note:  This is modified BNF (as used by the Pascal people) with a few
+          English modifiers thrown in.  Stuff enclosed in '{}' can be
+          repeated zero or more times.  Stuff in '[]' denotes a set of
+          items.  The '-' operator denotes set subtraction.
+
+
+Directory Entity
+
+CR-LF     ::= ASCII Carriage Return Character followed by Line Feed
+              character.
+
+Tab       ::= ASCII Tab character.
+
+NUL       ::= ASCII NUL character.
+
+UNASCII   ::= ASCII - [Tab CR-LF NUL].
+
+Lastline  ::= '.'CR-LF.
+
+TextBlock ::= Block of ASCII text not containing Lastline pattern.
+
+Type      ::= UNASCII.
+
+RedType   ::= '+'.
+
+User_Name ::= {UNASCII}.
+
+Selector  ::= {UNASCII}.
+
+Host      ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}.
+
+Note: This is a Fully Qualified Domain Name as defined in RFC 1034.
+      (e.g., gopher.micro.umn.edu)  Hosts that have a CR-LF
+      TAB or NUL in their name get what they deserve.
+
+Digit     ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' .
+
+DigitSeq  ::= digit {digit}.
+
+Port      ::= DigitSeq.
+
+Note: Port corresponds the the TCP Port Number, its value should
+      be in the range [0..65535]; port 70 is officially assigned
+      to gopher.
+
+
+
+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 12]
+
+RFC 1436                         Gopher                       March 1993
+
+
+DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF
+          {RedType User_Name Tab Selector Tab Host Tab Port CR-LF}
+
+
+
+Notes:
+
+   It is *highly* recommended that the User_Name field contain only
+   printable characters, since many different clients will be using
+   it.  However if eight bit characters are used, the characters
+   should conform with the ISO Latin1 Character Set.  The length of
+   the User displayable line should be less than 70 Characters; longer
+   lines may not fit across some screens.
+
+   The Selector string should be no longer than 255 characters.
+
+
+Menu Entity
+
+Menu      ::= {DirEntity} Lastline.
+
+
+Menu Transaction  (Type 1 item)
+
+C: Opens Connection
+S: Accepts Connection
+C: Sends Selector String
+S: Sends Menu Entity
+
+   Connection is closed by either client or server (typically server).
+
+
+Textfile Entity
+
+TextFile  ::= {TextBlock} Lastline
+
+Note:  Lines beginning with periods must be prepended with an extra
+     period to ensure that the transmission is not terminated early.
+     The client should strip extra periods at the beginning of the line.
+
+
+TextFile Transaction (Type 0 item)
+
+C: Opens Connection.
+S: Accepts connection
+C: Sends Selector String.
+S: Sends TextFile Entity.
+
+
+
+
+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 13]
+
+RFC 1436                         Gopher                       March 1993
+
+
+   Connection is closed by either client or server (typically server).
+
+Note:  The client should be prepared for the server closing the
+       connection without sending the Lastline.  This allows the
+       client to use fingerd servers.
+
+
+Full-Text Search Transaction (Type 7 item)
+
+Word      ::= {UNASCII - ' '}
+BoolOp ::= 'and' | 'or' | 'not' | SPACE
+SearchStr ::= Word {{SPACE BoolOp} SPACE Word}
+
+C: Opens Connection.
+C: Sends Selector String, Tab, Search String.
+S: Sends Menu Entity.
+
+Note:  In absence of 'and', 'or', or 'not' operators, a SPACE is
+       regarded as an implied 'and' operator.  Expression is evaluated
+       left to right.  Further, not all search engines or search
+       gateways currently implemented have the boolean operators
+       implemented.
+
+Binary file Transaction (Type 9 or 5 item)
+
+C: Opens Connection.
+S: Accepts connection
+C: Sends Selector String.
+S: Sends a binary file and closes connection when done.
+
+
+Syntactic Meaning for Directory Entities
+
+
+The client should interpret the type field as follows:
+
+0   The item is a TextFile Entity.
+    Client should use a TextFile Transaction.
+
+1   The item is a Menu Entity.
+    Client should use a Menu Transaction.
+
+2   The information applies to a CSO phone book entity.
+    Client should talk CSO protocol.
+
+3   Signals an error condition.
+
+4   Item is a Macintosh file encoded in BINHEX format
+
+
+
+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 14]
+
+RFC 1436                         Gopher                       March 1993
+
+
+5   Item is PC-DOS binary file of some sort.  Client gets to decide.
+
+6   Item is a uuencoded file.
+
+7   The information applies to a Index Server.
+    Client should use a FullText Search transaction.
+
+8   The information applies to a Telnet session.
+    Connect to given host at given port. The name to login as at this
+    host is in the selector string.
+
+9   Item is a binary file.  Client must decide what to do with it.
+
++   The information applies to a duplicated server.  The information
+    contained within is a duplicate of the primary server.  The primary
+    server is defined as the last DirEntity that is has a non-plus
+    "Type" field.  The client should use the transaction as defined by
+    the primary server Type field.
+
+g   Item is a GIF graphic file.
+
+I   Item is some kind of image file.  Client gets to decide.
+
+T   The information applies to a tn3270 based telnet session.
+    Connect to given host at given port. The name to login as at this
+    host is in the selector string.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Authors' Addresses
+
+   Farhad Anklesaria
+   Computer and Information Services, University of Minnesota
+   Room 152 Shepherd Labs
+   100 Union Street SE
+   Minneapolis, MN 55455
+
+   Phone: (612) 625 1300
+   EMail: fxa@boombox.micro.umn.edu
+
+
+
+
+
+
+
+
+
+
+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 15]
+
+RFC 1436                         Gopher                       March 1993
+
+
+   Mark McCahill
+   Computer and Information Services, University of Minnesota
+   Room 152 Shepherd Labs
+   100 Union Street SE
+   Minneapolis, MN 55455
+
+   Phone: (612) 625 1300
+   EMail: mpm@boombox.micro.umn.edu
+
+
+   Paul Lindner
+   Computer and Information Services, University of Minnesota
+   Room 152 Shepherd Labs
+   100 Union Street SE
+   Minneapolis, MN 55455
+
+   Phone: (612) 625 1300
+   EMail: lindner@boombox.micro.umn.edu
+
+
+   David Johnson
+   Computer and Information Services, University of Minnesota
+   Room 152 Shepherd Labs
+   100 Union Street SE
+   Minneapolis, MN 55455
+
+   Phone: (612) 625 1300
+   EMail: dmj@boombox.micro.umn.edu
+
+
+   Daniel Torrey
+   Computer and Information Services, University of Minnesota
+   Room 152 Shepherd Labs
+   100 Union Street SE
+   Minneapolis, MN 55455
+
+   Phone: (612) 625 1300
+   EMail: daniel@boombox.micro.umn.edu
+
+
+   Bob Alberti
+   Computer and Information Services, University of Minnesota
+   Room 152 Shepherd Labs
+   100 Union Street SE
+   Minneapolis, MN 55455
+
+   Phone: (612) 625 1300
+   EMail: alberti@boombox.micro.umn.edu
+
+
+
+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 16]
+
\ No newline at end of file