<!doctype html>
<html>
<head>
<meta charset="utf-8">
<style>
h1,
h2,
h3,
h4,
h5,
h6,
p,
blockquote {
    margin: 0;
    padding: 0;
}
body {
    font-family: "Helvetica Neue", Helvetica, "Hiragino Sans GB", Arial, sans-serif;
    font-size: 13px;
    line-height: 18px;
    color: #fff;
    background-color: #282a36;
    margin: 10px 13px 10px 13px;
}
a {
    color: #59acf3;
}
a:hover {
    color: #a7d8ff;
    text-decoration: none;
}
a img {
    border: none;
}
p {
    margin-bottom: 9px;
}
h1,
h2,
h3,
h4,
h5,
h6 {
    color: #fff;
    line-height: 36px;
}
h1 {
    margin-bottom: 18px;
    font-size: 30px;
}
h2 {
    font-size: 24px;
}
h3 {
    font-size: 18px;
}
h4 {
    font-size: 16px;
}
h5 {
    font-size: 14px;
}
h6 {
    font-size: 13px;
}
hr {
    margin: 0 0 19px;
    border: 0;
    border-bottom: 1px solid #ccc;
}
blockquote {
    padding: 13px 13px 21px 15px;
    margin-bottom: 18px;
    font-family:georgia,serif;
    font-style: italic;
}
blockquote:before {
    content:"\201C";
    font-size:40px;
    margin-left:-10px;
    font-family:georgia,serif;
    color:#eee;
}
blockquote p {
    font-size: 14px;
    font-weight: 300;
    line-height: 18px;
    margin-bottom: 0;
    font-style: italic;
}
code, pre {
    font-family: Monaco, Andale Mono, Courier New, monospace;
}
code {
        color: #ff4a14;
    padding: 1px 3px;
    font-size: 12px;
    -webkit-border-radius: 3px;
    -moz-border-radius: 3px;
    border-radius: 3px;
}
pre {
    display: block;
    padding: 14px;
    margin: 0 0 18px;
    line-height: 16px;
    font-size: 11px;
    border: 1px solid #bf370f;
    white-space: pre;
    white-space: pre-wrap;
    word-wrap: break-word;
}
pre code {
    background-color: #282a36;
    color: #ff4a14;
    font-size: 11px;
    padding: 0;
}
@media screen and (min-width: 768px) {
    body {
        width: 748px;
        margin:10px auto;
    }
}
</style>
<title>Goals</title>
</head>
<body>
<h1>Goals</h1>

<ol>
<li>Author a contemporary specification of the Gopher communications protocol.  Do not attempt to reinvent the wheel.</li>
<li>Combine Gopher standards into one reference document, reflecting actual practice.</li>
<li>RFC 1346 compliance a must</li>
<li>Describe and/or update handling of errors</li>
<li>Describe and/or update handling of “URL:”</li>
<li>Describe and implement item type “M” (MIME) handling</li>
</ol>


<h1>What is Gopher? </h1>

<p>Gopher is a lightweight, client-server oriented query-answer protocol, functioning as a world-wide information system (WWIS).  It accomplishes its purpose by facilitating access to other servers around the world, whether they be running Gopher or not.  The protocol and software permits users on a heterogeneous mix of desktop systems to browse, search, and retrieve documents residing on multiple distributed server machines.  Faster and more hierarchical than HTTP, Gopher provides the ideal method for transmitting information from and to mobile devices.</p>

<h1>Basic Gopher Transactions</h1>

<p>There are four broad forms of basic transactions in Gopher:</p>

<ul>
<li>Menu Transaction;</li>
<li>Index Transaction;</li>
<li>Simple Text Transaction; and</li>
<li>Binary Transaction.</li>
</ul>


<p>The precise make-up of these transactions is elucidated below.</p>

<pre><code>Menu Transaction
----------------
Client : [Open Connexion]
Client : Send [selector<CR><LF>]
Server : Send <Menu>
Server : [Close Connexion]

Index Transaction
-----------------
Client : [Open Connexion]
Client : Send  [selector<TAB>query parameters<CR><LF>]
Server : Send [<Menu>]
Server : [Close Connexion]

Simple Text Transaction
-----------------------
Client : [Open Connexion]
Client : Send  [selector<CR><LF>]
Server : Send [<Simple Text>]
Server : [Close Connexion]

Binary Transaction
------------------
Client : [Open Connexion]
Client : Send  [selector<CR><LF>]
Server : Send [<Raw Binary Data>]
Server : [Close Connexion]
</code></pre>

<p>Gopher servers are normally found on TCP/IP port 70. Clients should assume this port if no other port is specified.  When a client opens a connection to a server, the server should accept the connection but say nothing, waiting for a CRLF-terminated selector string from the client. The client should then send the selector string followed by CRLF (or nothing to retrieve the root menu from the server, which MUST always be type 1). The server should then send the requested content and close the connection.</p>

<h1>Line Terminators</h1>

<p>ASCII, the international standard that governs the interchange of plain-text information between computer systems, is nothing more or less than a table mapping each character (letter, number, space, or symbol) to a numerical code, which is then converted to binary and written to disc.  Its necessity was seen long before the advent of the electronic monitor, so some of its more unique quirks must be understood in view of the time period of which it was a product.  Historically, input and output was through a specially-adapted typewriter, and the ASCII convention reflects this in the codes it uses to terminate lines of text.</p>

<p>In ASCII, there are two codes, both having physical equivalents in the real world, that signal the end of the line: the Carriage Return (abbreviated C/R, CR, or c/r) and the Line Feed (abbreviated L/F, LF, or l/f).  Originally, the term <em>carriage return</em> was used for a command that caused the assembly holding the paper (the carriage) to return to the right so the machine was ready to type again on the left side of the paper (assuming a left-to-right language).  On the other hand, the <em>line feed</em> moved the paper upwards, allowing the carriage to type on the following line.</p>

<p>Different operating systems <em>traditionally</em> signal the end of a line in different ways.  UNIX and its descendants (including all modern versions of Mac OS), the operating systems most likely to run on a server, use the line feed alone.  CP/M, DOS, and Microsoft Windows use the sequence of carriage return and line feed (CR/LF).  Obsolete versions of Mac OS (up to, and including, System 9) use the carriage return alone.</p>

<p>Throughout the Gopher system, however, this does not apply.  Internal Gopher commands must <em>always</em> use CR/LF, regardless of the type of system sending them.  The situation becomes more unclear in regards to sending text files, however.  Although the client is required to be capable of converting between line terminators, it is <em>strongly recommended</em> that files on the server be maintained in standard Gopher format (that is, CR/LF).</p>

<h1>Capability Files</h1>

<p>It is recommended, when hosting a public-access Gopher server, to include a capability file.  Although it is, ultimately, the choice of the owner or operator of the server, a capability (or caps) file can be useful for clients querying the server for certain information without using extensions such as Gopher+.</p>

<p>The purpose of a caps file is so that a server can instruct a client on how to properly parse selectors in its filesystem; it ensures that the client can understand how files on the server are organised. The scheme used in the current implementation of caps can handle POSIX (UNIX and related operating systems), FAT/NTFS (used by Microsoft Windows), and HFS (used by Apple Mac OS).  Due to technical issues, caps files <em>can not handle VMS or Files-11 paths</em>.   Caps files, however, use an open interface; they can be arbitrarily extended.</p>

<p>A caps file is quite simple in its composition: it is a plain text file with no more than seventy characters per line in the root directory of a Gopher server with the name</p>

<pre><code>caps.txt
</code></pre>

<p>and beginning with the six characters</p>

<pre><code>CAPS[CR][LF]
</code></pre>

<p>Because of the constrained name and location of the caps file, it is a trivial matter to verify if one exists or not; the address is always of the form <gopher://gopher.example.com/1/caps.txt>, with the real name of the server substituting for <em>example</em>.</p>

<p>A caps file contains <em>keys</em>, <em>values</em>, and <em>comments</em>.</p>

<p>Keys can be compared to labelled containers for data; for instance, the key <em>ServerSoftware</em> is a container for the name of the Gopher software running on the server.  Keys in caps files are always alphanumeric (i.e., composed of letters and numbers only) and generally are in CamelCase (each individual word within the key capitalised).  The data in these containers is called a value; values can use letters, numbers, and symbols.  Keys and values are connected by the equals (=) sign.  Any amount of whitespace (spaces and tabs) around the equals sign is acceptable.</p>

<p>Anything not conforming to the syntax</p>

<pre><code>SomeKey = Value
</code></pre>

<p>is ignored (treated as a comment).  To be standards-compliant, comments must begin with a hash (#) sign; more importantly, they must be on a line to their own.</p>

<p>Below is an example caps file.</p>

<pre><code>CAPS
# These four characters must be at the beginning to identify the file
# as successfully fetched.

# This is a caps file. This contains a list of key=value pairs that are
# useful to clients wishing to query the server for special information
# without using extensions such as Gopher+. Not all clients support caps
# queries, so your site should be navigable without it. This is an
# optional feature and is not currently a Gopher protocol standard.
# Blank lines and lines starting with # are ignored.
# Clients should cache the information where possible.
# Some servers may automatically generate caps files for you as a pseudo
# selector. In that case, this file may serve only to supersede the
# machine-generated keys. You should read your server documentation.
#
# To use this file, customize it and place it in your server's root mountpoint
# such that a fetch for selector "caps.txt" will retrieve it.
#
# All keys are optional. Not all keys listed here need be specified, and
# in fact many sites won't specify all of them. The client should be
# prepared to deal with that too.

### CAPS META PROPERTIES ###
#
# Spec version of this caps file. This should be the first key specified
# so that an incompatible later format might be detected by the client.
CapsVersion=1

# This tells the client the recommended caps cache expiry time, in seconds.
# This particular property tells the client to refetch the caps file after
# an hour has passed, preferentially. This is optional for the client to
# implement.
ExpireCapsAfter=3600

### PATH SECTION. USE THESE DEFAULT VALUES IF YOU ARE ON A POSIX FILESYSTEM ###

# This tells the client how to cut up a selector into a breadcrumb menu.
# This is a simple ASCII string. If it is not specified, the selector is
# treated as if it were opaque. The client may collapse consecutive
# delimiters (e.g., x//y is treated as x/y) except if PathParentDouble is
# true (for Mac).
PathDelimeter=/

# This tells the client what the "identity" path is, i.e., it can treat
# this as a no-op, turning x/./y into x/y. If this is not specified, the
# literal path . is used.
PathIdentity=.

# This tells the client what the parent path is, i.e., it can treat this
# as a path instruction to delete previous path, turning x/y/../z into x/z
# If this is not specified, the literal path .. is used.
PathParent=..

# This tells the client that consecutive path delimeters are treated as
# parent (mostly for Mac HFS prior to Mac OS X), e.g., turning
# MacHD:x:y:::z into MacHD:z. If this is not specified, it is default FALSE.
PathParentDouble=FALSE

# This tells the client the escape character for quoting the above
# metacharacters. Most of the time this is \. If this is not specified,
# no escape characters are used.
PathEscapeCharacter=\

# This tells the client not to cut everything up to the first path delimeter.
# Normally caps makes gopher://x/11/xyz and gopher://x/1/xyz both into /xyz
# assuming your server is happy with the latter URL (almost all will be).
# If this is not specified, it is by default FALSE. This should be TRUE
# *only* if your server requires URLs like gopher://x/0xyz (i.e., the
# selector should NOT start with the path delimiter).
PathKeepPreDelimeter=FALSE

### OTHER PROPERTIES ###
#
# Some clients will or may make use of these; some won't.

# Freetext description of the server software and server hardware.
ServerSoftware=Bucktooth
ServerSoftwareVersion=0.2.9
ServerArchitecture=AIX
ServerDescription=IBM Power 520 Express, dual 4.2GHz POWER6 CPU, 8GB RAM
ServerGeolocationString=Southern California, USA

# Special server features.
ServerSupportsStdinScripts=TRUE

# An E-mail contact for the server.
ServerAdmin=gopher@floodgap.com
</code></pre>

<h2>Robots Files</h2>

<p>(This sxn needs work!)</p>

<h1>Selector Formats</h1>

<h2>Type Codes</h2>

<p>The following selectors are defined by RFC 1436:</p>

<pre><code>Type    Treat As    Meaning
0       TEXT        Plain text file
1       MENU        Menu
2       EXTERNAL    CCSO flat database (formerly used as telephone 
                    directories); other databases
3       ERROR       Error message
4       TEXT        Macintosh BinHex file
5       BINARY      Binary archive (zip; rar; 7-Zip; gzip; tar)
6       TEXT        UUEncoded archive
7       INDEX       Query a search engine or CGI script
8       EXTERNAL    Telnet to: VT100 series server
9       BINARY      Binary file (see also 5)
+       -           Redundant server (TODO: How is this used?)
T       EXTERNAL    Telnet to: tn3270 series server
g       BINARY      GIF format graphics file (TODO: Why not use I?)
I       BINARY      Any image file.
</code></pre>

<p>Additionally, the following selectors have been in common use and are standardised here.  If a client does not have the capability to display a particular item type, it should treat it as a more generic item type, passing it off to the operating system (itemtype p “implies” itemtype 0, etc.).</p>

<pre><code>Type    Treat As    Meaning
c       BINARY      Calendar file (Kim Holviala)
d       BINARY      Word-processing document (MS Word; OpenOffice.org; 
                    WordPerfect); PDF document
h       TEXT        HTML document
i       -           Informational text (not selectable)
p       TEXT        Page layout or markup document (TeX; LaTeX; 
                    PostScript; Rich Text Format)—these documents are all                         plain text, but contain ASCII "tags" that make the 
                    document prettier when sent through a special 
                    programme.
m       BINARY      Electronic mail repository (also known as MBOX) (Kim 
                    Holviala)
s       BINARY      Audio recordings (files that consist of audible, but no
                    visible, data) (Wesley Teal)
x       TEXT        eXtensible Markup Language document (Wesley Teal)
;       BINARY      Video files (files that consist of both audible and
                    visible data) (Wesley Teal)
</code></pre>

<p>For standards compliance, 4, 6, h, p, and x filetypes send as text (itemtype 0)—this way, the text appears directly on the user’s terminal without being downloaded (unless the appropriate command is sent to the server, i.e. “Save As…”).  It is vital to note that text information can be sent via binary (with the minor inconvenience noted above), as binary files contain a greater range of information than ASCII.  However, binary files, if sent via text, will be irreparably ruined, as this effectively passes raw eight-bit data through an ASCII filter.  In the case of confusion, the owner/operator of the server should simply mark the file as binary to ensure that it transfers safely.</p>

<h2>Gopher Menus</h2>

<p>Menu (type 1) content has the following format:</p>

<pre><code>T<itemtext>^I<selector>^I<host>^I<port>
</code></pre>

<p>Where:</p>

<ul>
<li>^I is a tab character (TODO: note the F character used in many documents)</li>
<li>T is the type code (Note: T is run together with the Item text)</li>
<li><selector> is the selector string to send to the specified server</li>
<li><host> is the server to send the selector to</li>
<li><port> is the port on the server to connect to</li>
</ul>


<p>Note on ‘i’ item type: For the ‘i’ item type, Selector, Server, and Port are mostly ignored, but must be there anyway. These should be dummy values. (Floodgap.org uses a blank selector on error.host port 1.) One exception to their being ignored is TITLE entries. These have TITLE as the selector value.</p>

<h3>Note on the terminating full stop</h3>

<p>The original RFC specified that a terminating full stop (.) character, followed by a newline, should be sent on a line by itself after the end of the content. However, it also made exceptions for binary data. This terminating full stop has caused no end of trouble ever since. Many, if not most, modern Gopher servers omit this terminating full stop. The following practice is therefore suggested.</p>

<ul>
<li>Servers <em>may</em> send the full stop; clients <em>must</em> accept it</li>
<li>Servers <em>should</em> send the full stop after menus, but may choose whether they want to send it after other files</li>
<li>Clients should display the full stop at the end of menus, if sent, to notify the user that this is the end of the menu</li>
<li>Clients should not include the full stop in other output, in case that output has some significance which the full stop may disrupt.</li>
<li>Clients should only consider a full stop as significant if it occurs immediately before the connection is terminated.</li>
</ul>


<h2>Titles in Gopher</h2>

<p>The previous governing document for Gopher (RFC 1436) did not allow for menus with titles.  When one simply browses about Gopherspace, this does not matter; for bookmarking and Gopher crawlers, such as Veronica-2, however, this presents a large problem.</p>

<p>A Gopher TITLE resource has the following format:</p>

<pre><code>i<titletext>^ITITLE^Iexample.com^I0
</code></pre>

<p>It is identical to a standard informational resource (itemtype <em>i</em>); the selector string, however, is set to the specific value, “TITLE”.</p>

<p>The composition of the above format is as follows:</p>

<ul>
<li>^I is a tab character</li>
<li>The type code is <em>always</em> i (information)</li>
<li>The selector string is <em>always</em> TITLE</li>
<li>There is no server to connect to; the dummy text used in place of the server is <em>always</em> example.com</li>
<li>There is no port to connect to; instead of a port, <em>always</em> enter the number 0 (zero).</li>
</ul>


<p>A Gopher client that conforms to the above TITLE standard shall render it in one of two ways, depending on the placement of the resource.  If the TITLE is the <em>first</em> resource in the document, it shall be considered its principal TITLE and is to be used <em>wherever a principal title is needed</em> (window headings, bookmarks, etc.); furthermore, it is to be rendered in a different size, font, and/or colour to the remainder of the document.  In <em>all other</em> cases, it shall be considered a subordinate TITLE and is to be rendered in a different size, font, and/or colour to the remainder of the document, but smaller and/or with less emphasis than the main title.</p>

<p>If a non-standards compliant Gopher client receives a TITLE resource as per above, it will render it as plain informational text  As the main TITLE must be on the first line of a menu, it will appear visually similar to a title in any case, although not rendered as such.</p>

<h2>Linking to Web Addresses</h2>

<p>It is now possible, and standard, to link to documents, preferably in HTML, on the World Wide Web, Gopher’s younger, more widespread cousin, from Gopher itself, using a two-part system: a <em>URL:</em> selector on the Gopher (local) end, and a <em>redirect page</em> (following rules as set out below) on the HTTP (remote) end.  Servers need not follow any compliance requirements except for the bulleted list following the example redirect page; if the list is not followed, the server shall be deemed non-compliant.</p>

<p>A client adhering to this specification will, when it sees a Gopher selector with a path starting with URL:, interpret the path as a URL.  It will <em>ignore</em> the host and port components of the Gopher selector, using those components from the URL instead, if applicable.</p>

<p>The use of URL: selectors should, wherever possible, be avoided; this is especially true when it is possible to otherwise link to the content and protocol needed.  The following URL types are specifically excluded from being linked to by this method:</p>

<ul>
<li>gopher</li>
<li>telnet (VT100-compatible)</li>
<li>tn3270</li>
</ul>


<p>Authors should avoid links to any document not of HTML type whenever possible.  Linking to non-HTML documents will break compatibility with non-compliant Gopher browsers.</p>

<p>A Gopher URL: selector takes the following format:</p>

<pre><code>h<itemtext>^IURL:<address>^I<localhost><localport>
</code></pre>

<p>URL: selectors are, <em>generally</em>, identical to standard HTML selectors, but composed of particular data:</p>

<ul>
<li>The item type corresponds to the type of document on the remote end.  Most typically, this is a Web page authored in HTML; therefore, the item type is most commonly h.</li>
<li><itemtext> is the text of the link; this can be almost anything.</li>
<li><address> is the full URL, preceded by the string “URL:”.  For example, this could be URL:http://www.example.com</li>
<li><localhost> is the server that the link <em>originated</em> from; this is ignored by compliant browsers</li>
<li><localport> is the port that the link <em>originated</em> from; this is also ignored by compliant browsers</li>
</ul>


<p>It is possible for a non-compliant Gopher client to follow a link to an HTML page, as long as the server is compliant, by the following means: when the client receives a command to follow a URL: selector, it will contact the server that provided the menu, as the originating host and port are <em>mandatory</em> as per this standard.</p>

<p>When a Gopher server receives a request from a client beginning with the string <em>URL:</em>, it will write out an HTML document that redirects the browser to the appropriate place.  A conforming example of such a document is as follows:</p>

<pre><code><HTML>
<HEAD>
<META HTTP-EQUIV="refresh" ">content="2;URL=http://www.example.com/">
</HEAD>
<BODY>
You are following an external link to a Web site.  You will be
automatically taken to the site shortly.  If you do not get sent
there, please click
<A here">HREF="http://www.example.com/">here to go to the web site.
<P>
The URL linked is:
<P>
<A http://www.example.com/">HREF="hhttp://www.example.com/">http://www.example.com/
<P>
Thanks for using Gopher!
</BODY>
</HTML>
</code></pre>

<p>This document may be any desired by the server authors, but must adhere to the following requirements.  If not, the server shall be deemed non-compliant.</p>

<ul>
<li>It must provide a refresh of a duration of 10 seconds or less</li>
<li>It must not use IMG tags, frames, or have any reference whatsoever to content outside that particular file, with the sole exception of the link to the real destination.</li>
<li>It must not use JavaScript.</li>
<li>It must adhere to the W3C HTML 3.2 standard.</li>
</ul>


<p>When a non-compliant Gopher client finds a reference to a HTML file (type h), it will open up the file via Gopher, receiving the redirect document using a Web browser.  The Web browser will then be redirected to the actual link destination.</p>

<p>Compliant Gopher clients will simply render the target directly.</p>

<h2>Algorithm to use with selectors</h2>

<p>Here is a description for a hypothetical algorithm for parsing item types, splitting them into levels of interaction.</p>

<pre><code>PROTOCOL
--------
Type    Description     What to do
0       Brief text      Render directly line by line.
1       Menu            Request and analyse menu.  If it contains '3' error
                        node, print error.  Else, render menu in new
                        window.
7       Index/Search 
        Server  

DATA NODES
----------
Type            Description     What to do
4, 9, g, I, c,  Binary file     Request and analyse file.  If it contains 
d, m, s, ;                      '3' error node, print error.  Else, does
                                plug-in exist? If yes, display.  If no, 
                                save to disc.  
6, p, x         Text file       Request and analyse file.  If it contains
                                '3' error node, print error.  Else, print
                                on screen.
h, 2, 8, T      Link            Treat as URL.
5               Archive File    Request and analyse file.  If it contains 
                                '3' error node, print error.  Else, does
                                plug-in exist? If yes, display.  If no, 
                                save to disc.  
</code></pre>

<p>For instance, if the client is incapable of handling images as it is text-only, the algorithm above would have it save to disc.</p>

<h1>Representation of Gopher Addresses</h1>

<p>This section is greatly indebted to RFC 4266.</p>

<p>A Gopher address, or uniform resource locator, takes the form:</p>

<pre><code>gopher://<host>:<port>/<gopher-path>
</code></pre>

<p>where <gopher-path> is one of:</p>

<pre><code>* <gophertype><selector>
* <gophertype><selector>%09<search>
* <gophertype><selector>%09<search>%09<gopher+_string>
</code></pre>

<p>If :<port> is omitted, the port defaults to 70. <gophertype> is a single-character field to denote the Gopher type of the resource to which the URL refers.  The entire <gopher-path> may also be empty, in which case the delimiting “/” is also optional and the <gophertype> defaults to “1”.</p>

<p><selector> is the Gopher selector string.  Selector strings are arbitrary sequences of characters; they may not, however, contain the characters corresponding to horizontal tab, line feed, or carriage return.  Gopher clients specify which item to retrieve by sending the Gopher selector string to a Gopher server. It is important to know that within the <gopher-path> itself, there are no reserved characters, so one may be arbitrarily creative when creating selector names.</p>

<p>Note that some Gopher <selector> strings begin with a copy of the <gophertype> character, in which case that character will occur twice consecutively.  The Gopher selector string may be an empty string; this is how Gopher clients refer to the top-level directory on a Gopher server.</p>

<p>If the URL refers to a search to be submitted to a Gopher search engine, the selector is followed by an encoded tab (%09) and the search string.  To submit a search to a Gopher search engine, the Gopher client sends the <selector> string (after decoding), a tab, and the search string to the Gopher server.</p>

<h1>References</h1>

<ul>
<li>Anklesaria, Farhad; Lindner, Paul; McCahill, Mark P.; Torrey, Daniel; Johnson, David; Alberti, Bob (1993). <em>Gopher+: upward compatible enhancements to the Internet Gopher protocol</em> Retrieved 23 May, 2012, from <gopher://gophernicus.org/0/doc/gopher/gopher+.txt></li>
<li>Anklesaria, Farhad; McCahill, Mark P.; Lindner, Paul; Johnson, David; Torrey, Daniel; Alberti, Bob (1993). <em>The Internet Gopher Protocol (a distributed document search and retrieval protocol).</em>  Retrieved 23 May, 2012, from <gopher://gopher.rbfh.de/0/RFC/rfc1436.txt></li>
<li>Goerzen, John (2002). <em>Links to URL.</em>  Retriever 23 May, 2012, from <gopher://gophernicus.org/0/doc/gopher/hURL.txt></li>
<li>Hoffman, P. (2005). <em>The gopher URI Scheme.</em>  Retrieved 23 May, 2012, from <gopher://gopher.rbfh.de/0/RFC/rfc4266.txt></li>
<li>Kaiser, Cameron (2010). <em>Welcome to caps!</em> Retrieved 23 May, 2012, from <gopher://gophernicus.org/0/doc/gopher/gopher-caps.txt></li>
<li>The “Updated Gopher RFC” thread (started May 8 2012) on the gopher-project mailing list</li>
<li><gopher://gophernicus.org/1/doc/gopher/> - A number of documents relating to gopher, including the RFCs</li>
<li><gopher://jgw.mdns.org/9/REFS/56817068-PIL3254-Internet-Gopher-PPL-Alberti.pdf> – A paper on the history of Gopher</li>
<li><gopher://gopher.floodgap.com/0/caps.txt> - Floodgap’s caps file</li>
</ul>


<h2>Brain dump</h2>

<p>This is a brain dump of some other things to include at some point.</p>

<p>/robots.txt
Server SHOULD add it !  xDIAMORPHINEx: NO.  IT SHOULD BE THE PREFERENCE OF THE OP TO USE THEM; FURTHERMORE, <em>RESTRICTIVE</em> ROBOTS FILES SHOULD BE RECOMMENDED AGAINST.</p>

<p>Errors:
Errors should be indicated by returning a gopher menu whose first item is of
type 3. However, many servers use various heuristics and may return images, HTML
pages, or other non-error-menu content.</p>

<p>Mime-multipart encoded files should use type ’M' and base64 encoding</p>

<p>What about the ‘+’ item-type? No info in RFC 1436</p>
</body>
</html>