RFC 1436

The Internet Gopher Protocol 🐿️

RFC 1436 🎀 is from the Network Working Group, dated March 1993 📅. The subtitle is a distributed document search and retrieval protocol. The authors are F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, and B. Alberti, all from the University of Minnesota 🎓. It's basically an informational doc, meaning it provides info for the Internet community and does not specify an Internet standard. The title block doesn't list anything it obsoletes or updates 💅.

Status of this Memo 📜

okay so this memo provides information for the Internet community 🫶. It does not specify an Internet standard, so it's not a rulebook. Distribution of this memo is unlimited 🌈.

Abstract 🦋

the Internet Gopher protocol is built for distributed document search and retrieval 🔍. This doc describes the protocol, lists some of the implementations that are available, and gives an overview of how to build new client and server applications 💅. It's adapted from the basic Internet Gopher protocol doc that the Microcomputer Center at the University of Minnesota first put out in 1991 🌸.

Introduction 🐿️

okay the dictionary entry for gopher is iconic, so here it is 😭:

1. any of various short-tailed, burrowing mammals of the family Geomyidae, from North America 🐹
2. (American colloquial) a native or inhabitant of Minnesota, the Gopher State
3. (American colloquial) someone who runs errands, does odd jobs, or fetches and 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, and TCP is assumed. Gopher servers should listen on port 70, since IANA assigned port 70 to Internet Gopher 🔌. Documents live on lots of autonomous servers across the Internet. Users run client software on their desktops, connect to a server, and send it a selector (a line of text, which may be empty) over a TCP connection at a well-known port. The server replies with a block of text terminated by a period (.) on a line by itself, and then closes the connection. The server keeps no state 🙈.

While documents (and services) live on many servers, Gopher client software shows users a hierarchy of items and directories, kind of like a file system 📁. The Gopher interface is designed to look like a file system because a file system is a really good model for organizing documents and services. The user sees what's basically one big networked information system, made mostly of document items, directory items, and search items. The search items let you search 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), a user-visible name (used to browse and select from listings), an opaque selector string (typically a pathname the destination host uses to locate the desired object), a host name (which host to contact to get this item), and an IP port number (the port the server process listens on for connections). The user only sees the user-visible name 👀. The client software can locate and retrieve any item using the trio of selector, hostname, and port 🎯.

To use a search item, the client submits a query to a special kind of Gopher server called a search server 🔍. The client sends the selector string (if there is one) 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 the 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) live 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 look like a file system because a file system is a good model for locating documents and services. So why model a campus-wide information system after a file system? Several reasons 💅:

• (a) A hierarchical arrangement of information is familiar to lots of users 🌸. Hierarchical directories holding items (like 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 expect some sort of hierarchical organization to the info presented.
• (b) A file-system style hierarchy can be expressed in a simple syntax 🧠. The syntax used for the Internet Gopher protocol is easy to understand, and it 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, so you don't need special purpose software tools. Keeping the syntax of the pseudo-file-system client/server protocol simple also gets us better performance for a super common user activity: browsing through the directory hierarchy 🏃.
• (c) Gopher originated in a university setting, so one of the goals was for departments to have the option of publishing info from their inexpensive desktop machines 🖥️. Since much of the info can be presented as simple text files arranged in directories, a protocol modeled after a file system has immediate utility. 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, so 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's 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 doesn't rule out search or database-style queries for access to documents either. A search-server type is also defined in this pseudo-file system, and such servers return "virtual directories," or lists of documents matching user-specified criteria 💖.

part 2 is where the protocol details get juicy, so stay tuned 🫶

2. The internet Gopher Model ✨

okay so the appendix has a full BNF rendering of the internet Gopher syntax 🤓 but bestie, you don't need to read it closely to get the protocol. ngl it's giving "vibes first, grammar later" 💅

In essence, the Gopher protocol is a client connecting to a server 🔌 and sending it a selector (a line of text that can be totally empty 🫠) over a TCP connection. The server replies with a block of text ending in a period on a line by itself, then closes the connection. No state is retained by the server between transactions with a client 🧼, so every visit is a fresh start. The whole thing is so simple because it had to run on the slow, smaller desktop computers (1 MB Macs and DOS machines) and it had to be built quickly and efficiently 🖥️✨.

Below is a simple example of a client/server interaction, and more complex ones come later 🦋. Assume there's a "well-known" Gopher server (this may be duplicated, details are discussed later) listening on a well known port for the campus, kind of like a domain-name server 🌸. The only configuration the client software keeps is this server's name and port number. In this example that machine is rawBits.micro.umn.edu and the port is 70 🎀. In the example below, the F character stands for the TAB character, so keep that in mind 🫶.

 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 you what kind of thing the line describes: a document, a directory, or a search service. The characters '0', '1', and '7' are the main ones, and there are a handful more that get explained later 🧩. The characters after that, up to the tab, form a user display string that the client shows so people can pick this document or directory 👀. That first character is really the thing defining the item's type. Pretty much every Gopher client tells the user what type it is with an icon, a short text tag, or something similar 💜.

The characters after the tab, up to the next tab, form a selector string. The client has to send that string to the server to fetch the document or directory listing 📨. The selector should mean absolutely nothing to the client software, so the client should never change it 🙅‍♀️. In practice, the selector is often a pathname or some other file selector the server uses to find the item. The next two tab-delimited fields are the domain name of the host that has the item, and the port to connect to 🌐. If there are any more tab-delimited fields after that, a basic Gopher client should just ignore them 🫧. A CR LF marks the end of the item 🏁.

In our example, line 1 describes a document the user sees as "About internet Gopher". To retrieve it, the client has to send the retrieval string Stuff:About us to rawBits.micro.umn.edu on port 70 🎯. If the client does that, the server responds with the contents of the document, ending with a period on a line by itself 📄✨. A client might show the user a list of items that looks something like this:

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

Here, directories get an ellipsis and files don't 🗂️. But depending on the platform the client is written for and the author's taste, item types can be shown with other text tags or with icons 🎨. For example, the UNIX curses-based client puts a slash (/) after directory names, and Macintosh clients show directories next to a folder icon 📁💅.

The user doesn't know or care that the items on the list might live on tons of different machines all over the Internet 🌍. That's the magic, honestly 🪄.

Now say the user picks "Microcomputer News & Prices...". That looks like a directory, so the user expects to see its contents once it's fetched 👀. Here's the back-and-forth:

    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)

---

3. More details 🎀

3.1 Locating services 🗺️

Documents (or other services that can be viewed as documents, like a student-staff phonebook) are tied to the machine they live on by a trio of things: the selector string, the machine's domain name, and the IP port 🧵. The assumption is that an institution or campus has one well-known top-level root server 👑. Its information can be duplicated across one or more other servers, which avoids a single point of failure and spreads the load across several machines 🫶.

Departments that want their own servers have to register the machine name and port with the top-level Gopher server's administrators. It's kind of like how they'd register a machine name with the campus domain-name server 📝. Then an entry pointing to the departmental server gets added at the top level 🔗. That way, users can navigate down what's basically a virtual hierarchical file system, starting from a well known root, all the way to any campus server they want 🧚.

Here's the tea 🍵: departments don't have to register secondary servers with the central top-level server. They can just put a link to those secondary servers in their own primary servers 💅. They can link to any servers they like from their own server, which creates a customized view of the Gopher information universe. Links can totally point back at the top-level server too 🔁. So the virtual (networked) file system is an arbitrary graph structure, not necessarily a rooted tree 🌳. The top-level node is just one convenient, well-known point of entry 🚪. A bunch of Gopher servers linked together this way can work as a campus-wide information system 🏫.

Servers can also point links at things other than secondary servers. In fact, servers can point at other servers that offer useful services anywhere on the Internet 🌐. Seen that way, Gopher can be thought of as an Internet-wide information system 💜✨.

3.2 Server portability and naming 🏷️

It's recommended that all registered servers have alias names (domain name system CNAME) that Gopher clients use to find them 🫧. Links to these servers should use those alias names instead of the primary names 🔗. If information needs to move from one machine to another, a simple change to the domain name system alias (CNAME) lets that happen without reconfiguring any clients out in the field 🚚. Basically, the domain name system can be used to re-map a server to a new address, and that's iconic 😭🔥. Nothing stops secondary servers or services from running on other named servers or ports besides 70 🌈. However, these should be reachable through a primary server 🫶.

3.3 Contacting server administrators 📬

It's recommended that every server administrator have a document called something like "About Bogus University's Gopher server", and it should be the first item in the server's top level directory 🥹. This document should contain a short description of what the server holds, plus the name, address, phone number, and email address of the person who runs the server 📞. That gives users a way to get word to the administrator when a server has inaccurate information or isn't running correctly 🙈. It's also recommended that administrators put the date of the last update in files where that info matters to users 📅💖.

3.4 Modular addition of services 🧩

The first character of each line in a server-supplied directory listing says whether the item is a file (character '0'), a directory (character '1'), or a search (character '7') 🔍. That's the base set of item types in the Gopher protocol 🌸. It's desirable for clients to be able to use different services and speak different protocols as their needs change 🦋. Some examples are simple ones like finger, and others like the CSO phonebook service, Telnet, or X.500 directory service 📇. The CSO phonebook is a client/server phonebook system that Universities typically use to publish names, email addresses, and so on 🎓. It was developed at the University of Illinois, and it's sometimes referred to as ph or qi 🤍.

Here's the cool part: if a server-supplied directory listing marks an item with type character '2', then the client has to speak the CSO protocol to use that item 🙌. This means the basic protocol doesn't have to predict every future need and hard-wire it in, so it stays super simple 🧁. Even so, the scheme can grow and change with the times, just by agreeing on a new type character for a new service ⭐. Client implementations can evolve in a modular way too, simply by dropping in a module (or launching a new process) for some new service 🧚‍♀️. The servers for the new service don't have to know anything about Internet Gopher. They can just be off-the-shelf CSO, X.500, or other servers 💅. That said, we do not encourage arbitrary or machine-specific proliferation of service types in the basic Gopher protocol 🙅‍♀️💀.

On the other hand, subsets of other document retrieval schemes can be mapped onto the Gopher protocol through "gateway-servers" 🚪✨. Examples include Gopher-to-FTP gateways, Gopher-to-archie gateways, Gopher-to-WAIS gateways, and so on 🌐. There are a bunch of advantages to this. First, a relatively powerful server machine takes on the intelligence and the work, instead of the more modest, inexpensive desktop system that usually runs client software or basic server software 💻💖. Equally important, clients don't have to be modified to take advantage of a new resource 🎉👑.

3.5. Building clients 📱

okay so bestie, a client just sends the retrieval string to a server when it wants a document or wants to peek at a directory 👀. Each host can have pointers to other hosts, so you end up with a "graph" (not necessarily a rooted tree) of hosts 🕸️. The client can save (or, like, "stack") the places it's already visited while hunting for a document 📚. That means the user can back out of where they are by unwinding the stack 🔙. If the client has multiple-window capability, it might even show more than one directory or document at the same time 🪟✨.

A smart client could cache the contents of visited directories (not just the directory's item descriptor) 🧠💾. That way it skips network transactions when the info was already fetched. Iconic efficiency 😤.

If a client doesn't understand what a say, type 'B' item (not a core item) is 🤷‍♀️, it can simply ignore that item in the directory listing, and the user never even has to see it 🙈. Or it can display the item as an unknown type. Your call, queen 👑.

Top-level or primary servers for a campus get way more traffic than secondary ones, and it's less tolerable for them to be down for any long time 😬. So it makes sense to "clone" these important servers and build clients that randomly pick between two equivalent primary servers when they first connect (to balance server load) 🎲. If one seems down, they move to the other 🔁. Smart client implementations literally do this clone server and load balancing 💅. Alternatively, it may make sense for the domain name system to return one of a set of redundant servers' IP addresses, to load balance between 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 also be the name of a script, an application, or even a query that generates the document or directory that gets returned 🪄. The basic server uses the string it gets, up to but not including a CR-LF or a TAB, whichever comes first ✂️.

All the intelligence lives in the server implementation, not 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) that we'll also talk about below 🫶:

1. A server directory listing can point at a CSO nameserver (the server returns a type character of '2'), which lets a campus student-staff phonebook lookup service show up 📒. This may appear on the user's list of choices, maybe with a little phonebook icon 📖. If the user picks this item, 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 keep 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 (the 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 the 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 incorporate gateways to WAIS and WHOIS services 🚪.

3.7.1. Building CSO-servers 📇

A CSO Nameserver implementation for UNIX, along with its documentation, is available by anonymous ftp from uxa.cso.uiuc.edu 💾. We do not anticipate implementing it on other machines 🙅‍♀️.

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 is currently an optional part of the UNIX gopher server 🐧. In addition, at least one implementation of the gopher server incorporates a gateway to WAIS servers by presenting the WAIS servers to gopherspace as full-text search servers 🌌. The gopher<->WAIS gateway server does the work of translating from the gopher protocol to WAIS, so unmodified gopher clients can access WAIS servers via the gateway server 🫶.

By using several index servers (rather than one monolithic index server), indexes can be searched in parallel (although the client software isn't aware of this) 🏃‍♀️💨. Maintaining full-text indexes of documents distributed over many machines may seem a daunting task 😵‍💫. But 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's possible to take advantage of fine-grain parallelism ⚡. Again, the client software isn't 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 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 🧩. Here's the list of defined item-type characters:

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!

    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 meant to be shown on a line on a typical screen for the user's viewing pleasure 🥰. While many screens can fit 80 character lines, some space is needed to display a tag that tells 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 that's convenient for them ✂️.

---

4. Simplicity is intentional ✨

As far as possible, we want any new features to be carried as new protocols that will be hidden behind new document-types 🫧. The internet Gopher philosophy goes like this 💭:

• (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 🫶.

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 to the TCP Port Number. Its value should be in the range [0..65535]. Port 70 is officially assigned to gopher 🔌.

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.

Okay so the server can close the connection whenever it wants, typically the server 💅

S: Sends TextFile Entity.

Connection is closed by either client or server (typically server). Bestie, that means the connection can end from either side, but the server is usually the one who hangs up 🫶

Note: The client needs to be ready for the server closing the connection without sending the Lastline. This is what lets the client work with fingerd servers 🧚

---

Full-Text Search Transaction (Type 7 item) 🔍

Okay, the search one is giving grammar 🤓 Here's how a search string gets built:

Word      ::= {UNASCII - ' '}
BoolOp ::= 'and' | 'or' | 'not' | SPACE
SearchStr ::= Word {{SPACE BoolOp} SPACE Word}

And here's the flow, step by step:

C: Opens Connection.
C: Sends Selector String, Tab, Search String.
S: Sends Menu Entity.

Note: If there's no 'and', 'or', or 'not' operator in the mix, a SPACE counts as an implied 'and' 🎀 The expression gets evaluated left to right, no skipping ahead. Also, not every search engine or search gateway out there has the boolean operators implemented yet, so don't be surprised if they're missing 💀

---

Binary file Transaction (Type 9 or 5 item) 🦋

This one is super simple, no drama:

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 ✨

Here's how the client reads the type field. Lowercase it's giving "decode this" energy 🔥

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
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 💀

Okay bestie, I have to be real with you: this memo does not discuss security issues at all. Zero. None. Plan accordingly 🙈🔒

---

Authors' Addresses 🌸

Here are the brains behind it, all from the University of Minnesota's Computer and Information Services team 👑

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

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

That's the whole thing, bestie! Gopher forever 🌈💖