GopherProxy

	Get repository to current brcon2022 state. - gopher-protocol - Gopher Protocol …
	git clone git://bitreich.org/gopher-protocol git://enlrupgkhuxnvlhsf6lc3fziv5h2…
	Log
	Files
	Refs
	Tags
	README
	LICENSE
	---
	commit f7bb7959972ce0d459cb2a7b478250f908b3728d
	Author: Christoph Lohmann <[email protected]>
	Date: Sat, 6 Aug 2022 14:06:48 +0200

	Get repository to current brcon2022 state.

	Diffstat:
	A LICENSE \| 12 ++++++++++++
	A README.md \| 29 +++++++++++++++++++++++++++++
	A TODO.md \| 7 +++++++
	A references/gopherplus.txt \| 1267 ++++++++++++++++++++++++++++++
	A references/rfc1436.txt \| 906 +++++++++++++++++++++++++++++…
	A references/rfc4266.txt \| 339 +++++++++++++++++++++++++++++…

	6 files changed, 2560 insertions(+), 0 deletions(-)
	---
	diff --git a/LICENSE b/LICENSE
	@@ -0,0 +1,12 @@
	+/*
	+ * ----------------------------------------------------------------------------
	+ * "THE FRIKANDEL-WARE LICENSE":
	+ * The authors of this repository wrote this file. As long as you retain this
	+ * notice you can do whatever you want with this stuff. If we meet some day,
	+ * and you think this stuff is worth it, you can buy me a frikandel in return.
	+ * ----------------------------------------------------------------------------
	+ *
	+ * Authors:
	+ * Hiltjo Posthuma <[email protected]>
	+ * Christoph Lohmann <[email protected]>
	+ */
	diff --git a/README.md b/README.md
	@@ -0,0 +1,29 @@
	+# Gopher Protocol
	+
	+## Introduction
	+
	+Gopher is a really old protocol. It has much history to preserve. Over
	+time and development the usage changed from the original RFC 1436 (see
	+rfc1436.txt) to usage now (2018). We now use UTF-8, we have other media
	+format, file type detection is more advanced, the web has grown and
	+brought use URIs and gopher+ has failed.
	+
	+The goal of this repository is to gather and document recommendations
	+for how to use gopher today so errors of the past are not redone.
	+
	+We do not plan to write a new RFC, since the recommendations are rather
	+small and do not require a big redefinition of the basic gopher
	+protocol.
	+
	+## Recommendations
	+
	+See the gopher-extension.md for the current state.
	+
	+## License
	+
	+See LICENSE file.
	+
	+## Have Fun
	+
	+We all should have fun!
	+
	diff --git a/TODO.md b/TODO.md
	@@ -0,0 +1,7 @@
	+## TODO
	+
	+* define more types such as 'd', 's', 'a'?
	+ * TODO: add all historical item types found
	+* define robots.txt? (probably out of scope for this document)?
	+ * search for mailing list post about robots.txt of 20h
	+
	diff --git a/references/gopherplus.txt b/references/gopherplus.txt
	@@ -0,0 +1,1267 @@
	+
	+Gopher+
	+
	+
	+upward compatible enhancements to
	+the Internet Gopher protocol
	+
	+
	+
	+Farhad Anklesaria, Paul Lindner, Mark P. McCahill,
	+Daniel Torrey, David Johnson, Bob Alberti
	+
	+Microcomputer and Workstation Networks Center /
	+Computer and Information Systems
	+University of Minnesota
	+
	+July 30, 1993
	+
	+
	+
	+gopher+ n. 1. Hardier strains of mammals of the
	+family Geomyidae. 2. (Amer. colloq.) Native or
	+inhabitant of Minnesota, the Gopher state, in full
	+winter regalia (see PARKA). 3. (Amer. colloq.)
	+Executive secretary. 4. (computer tech.) Software
	+following a simple protocol for burrowing through a
	+TCP/IP internet, made more powerful by simple
	+enhancements (see CREEPING FEATURISM).
	+
	+
	+Abstract
	+
	+The internet Gopher protocol was designed for
	+distributed document search and retrieval. The
	+documents "The internet Gopher protocol: a
	+distributed document search and retrieval protocol"
	+and internet RFC 1436 describe the basic protocol and
	+has an overview of how to implement new client and
	+server applications. This document describes a set of
	+enhancements to the syntax, semantics and
	+functionality of the original Gopher protocol.
	+
	+
	+Distribution of this document is unlimited. Please
	+send comments to the Gopher development team:
	+<[email protected]>. Implementation of
	+the mechanisms described here is encouraged.
	+
	+
	+
	+1. Introduction
	+
	+The Internet Gopher protocol was designed primarily to
	+act as a distributed document delivery system. It
	+has enjoyed increasing popularity, and is being used
	+for purposes that were not visualized when the
	+protocol was first outlined. The rest of this
	+document describes the Gopher+ enhancements in a non-
	+rigorous but easily read and understood way. There
	+is a short BNF-like section at the end for exact
	+syntax descriptions. Throughout the document, "F"
	+stands for the ASCII TAB character. There is an
	+implicit carriage return and linefeed at the ends of
	+lines; these will only be explicitly mentioned where
	+necessary to avoid confusion. To understand this
	+document, you really must be familiar with the basic
	+Gopher protocol.
	+
	+
	+Servers and clients understanding the Gopher+
	+extensions will transmit extra information at the ends
	+of list and request lines. Old, basic gopher clients
	+ignore such information. New Gopher+ aware servers
	+continue to work at their old level with unenhanced
	+clients. The extra information that can be
	+communicated by Gopher+ clients may be used to summon
	+new capabilities to bridge the most keenly felt
	+shortcomings of the venerable old Gopher.
	+
	+
	+
	+
	+2. How does Gopher+ work?
	+
	+Gopher+ enhancements rely on transmitting an "extra"
	+tab delimited fields beyond what regular (old) Gopher
	+servers and clients now use. If most existing (old)
	+clients were to encounter extra stuff beyond the
	+"port" field in a list (directory), most would ignore
	+it. Gopher+ servers will return item descriptions in
	+this form:
	+
	+
	+1Display stringFselector stringFhostFportFextra
	+stuff<CRLF>
	+
	+
	+If an existing (old) client has problems with
	+additional information beyond the port, it should not
	+take much more than a simple tweak to have it discard
	+unneeded stuff.
	+
	+
	+
	+
	+2.1 Advisory issued to client maintainers.
	+
	+If it does not do this already, your existing client
	+should be modified as soon as possible to ignore
	+extra fields beyond what it expects to find. This
	+will ensure thatyour clients does not break when it
	+encounters Gopher+ servers in gopherspace.
	+
	+
	+All the regular Gopher protocol info remains intact
	+except for:
	+
	+
	+(1) Instead of just a CRLF after the port field in
	+any item of a list (directory) there may be an
	+optional TAB followed by extra stuff as noted above
	+(explanation to follow).
	+
	+
	+
	+(2) In the original Gopher protocol, there was
	+provision for a date-time descriptor (sec 3.6) to be
	+sent after the selector (for use by autoindexer
	+beasts). As far as we know, while the descriptor is
	+implemented in the Mac server, it is not in any other
	+server and no clients or daemons use it. This is a
	+good time to withdraw this feature. The basic gopher
	+protocol has been revised for the final time and will
	+be frozen.
	+
	+
	+
	+
	+
	+
	+2.2 Gopher+ item lists.
	+
	+Gopher servers that can utilize the Gopher+
	+enhancements will send some additional stuff
	+(frequently the character "+") after the port field
	+describing any list item. eg:
	+
	+
	+1Some old directoryFfoo selectorFhost1Fport1
	+
	+1Some new directoryFbar selectorFhost1Fport1F+
	+
	+0Some file or otherFmoo selectorFhost2Fport2F+
	+
	+
	+The first line is the regular old gopher item
	+description. The second line is new Gopher+ item
	+description. The third line is a Gopher+ description
	+of a document. Old gopher clients can request the
	+latter two items using old format gopher selector
	+strings and retrieve the items. New, Gopher+ savvy
	+clients will notice the trailing + and know that they
	+can do extra things with these kinds of items.
	+
	+
	+
	+
	+
	+2.3 Gopher+ data transfer.
	+
	+If a client sends out a Gopher+ type request to a
	+server (by tagging on a tab and a "+" to the
	+request):
	+
	+
	+ bar selectorF+
	+
	+
	+The server may return the response in one of three
	+ways; examples below:
	+
	+
	+ +5340<CRLF><data>
	+
	+
	+
	+ +-1<CRLF><data><CRLF>.<CRLF>
	+
	+
	+
	+ +-2<CRLF><data>
	+
	+
	+The first response means: I am going to send exactly
	+5340 bytes at you and they will begin right after this
	+line. The second response means: I have no idea how
	+many bytes I have to send (or I am lazy), but I will
	+send a period on a line by itself when I am done.
	+The third means: I really have no idea how many
	+bytes I have to send, and what's more, they COULD
	+contain the <CRLF>.<CRLF> pattern, so just read until
	+I close the connection.
	+
	+
	+The first character of a response to a Gopher+ query
	+denotes success (+) or failure (-). Following that is
	+a token to be interpreted as a decimal number. If the
	+number is >= 0, it describes the length of the
	+dataBlock. If = -1, it means the data is period
	+terminated. If = -2, it means the data ends when the
	+connection closes.
	+
	+
	+The server may return an error also, as in:
	+
	+
	+--1<CRLF><data><CRLF>.<CRLF>
	+
	+
	+The (short!) error message will be in ASCII text in
	+the data part. The first token on the first line of
	+the error text (data) contains an error-code (an
	+integer). It is recommended that the first line also
	+contain the e-mail address of the administrator of
	+the server (in angle brackets). Both the error-code
	+and the email address may easily be extracted by the
	+client. Subsequent lines contain a short error
	+message that may be displayed to the user. Basic error
	+codes are:
	+
	+
	+ 1 Item is not available.
	+
	+ 2 Try again later ("eg. My load is too high
	+right now.")
	+
	+ 3 Item has moved. Following the error-code is
	+the gopher descriptor
	+
	+ of where it now lives.
	+
	+
	+More error codes may be defined as the need arises.
	+
	+
	+
	+This should be obvious: if the client sends out an
	+"old" Gopher kind of request:
	+
	+
	+
	+ bar selector
	+
	+
	+
	+the server will know that it is talking to an old
	+client and will respond in the old way. This means
	+that old gopher clients can still access information
	+on Gopher+ servers.
	+
	+
	+
	+
	+2.4 Gopher+ client requests.
	+
	+
	+Clients can send requests to retrieve the contents of
	+an item in this form:
	+
	+
	+
	+selectorstringF+[representation][FdataFlag]<CRLF>[dat
	+ablock]
	+
	+
	+If dataFlag is '0', or nonexistent, then the client
	+will not send any data besides the selector string.
	+If the dataFlag is '1' then a block of data will
	+follow in the same format as Section 2.3. The client
	+can send a large amount of data to the server in the
	+dataBlock. Representations or alternative views of an
	+item's contents may be discovered by interrogating the
	+server about the item's attribute information; this is
	+explained below.
	+
	+
	+Note that in the original Gopher protocol, a query
	+submitted to an index server might have a selector
	+string followed by a TAB and the words for which the
	+index server was being asked to search. In Gopher+,
	+the extra TAB and Gopher+ information follow the words
	+for which the server is being asked to search. Gopher+
	+client have to be smart enough to know that in the
	+case of a type 7 item (an index server) they append
	+the Gopher+ information after the words being searched
	+for.
	+
	+
	+
	+2.5 Gopher+ Item Attribute Information.
	+
	+
	+The most basic enhancement of Gopher+ items is the
	+ability to associate information about an item such
	+as size, alternative views, the administrator, an
	+abstract, etc. with the item. To get Attribute
	+Information, a client can send out a request to the
	+gopher server that looks like this:
	+
	+
	+ selector stringF!<CRLF>
	+
	+
	+(think of "!" as an upside-down i for "information").
	+To the server this means "Instead of returning the
	+contents of the item, return the item's Attribute
	+Information". The Attribute Information is returned as
	+an ASCII text stream containing blocks of
	+information.For example, a server might return:
	+
	+
	+ +INFO: 0Some file or otherFmoo
	+selectorFhost2Fport2F+
	+
	+ +ADMIN:
	+
	+ Admin: Frodo Gophermeister <[email protected]>
	+
	+ Mod-Date: Wed Jul 28 17:02:01 1993
	+<19930728170201>
	+
	+ +VIEWS:
	+
	+ Text/plain: <10k>
	+
	+ application/postscript: <100k>
	+
	+ Text/plain De_DE: <15k>
	+
	+ application/MacWriteII: <45K>
	+
	+ +ABSTRACT:
	+
	+ This is a short (but multi-line) abstract about
	+the
	+
	+ item. Two or three lines ought to be enough
	+
	+
	+The beginning of a block of information is denoted by
	+a "+" in column 1 of a line. Another way to think of
	+it is: the name of each block begins with a + and the
	+rest of the name cannot contain a +. Each line of
	+information within a block begins with a space so
	+that it is easy to locate the beginning of a block.
	+
	+
	+There can be multiple blocks of information about an
	+item, but the first block must be the one-line +INFO
	+block containing the keyword +INFO followed by the
	+gopher item description. This is done to make it easy
	+to associate informational attributes with the gopher
	+items to which they refer (see section 2.7 for some
	+good reasons for doing this). The very first line of
	+Attribute Information for an item contains a one-line
	++INFO block containing the gopher descriptor for the
	+item. All Gopher+ servers must return an "+INFO"
	+block for all items listed by the server. Also
	+present may be an +ADMIN block that can be many lines
	+long. The server must also send an +ADMIN block when
	+asked to send all the item's attributes (as in the
	+example above). The +ADMIN block must contain at
	+least an Admin attribute and Mod-Date attributes,
	+though there may be many other administrative items
	+also present in the +ADMIN block. The Admin (the
	+administrator of the item) and Date (the date of the
	+item's last modification) attributes are required to
	+be returned by the server, and other optional
	+attributes may be returned as well. In this example,
	+there are two pieces of information within the +ADMIN
	+block (Admin and Mod-Date). The Admin attribute must
	+contain the e-mail address of an administrator inside
	+angle brackets. The Admin line might also contain the
	+administrator's name and phone number. The Date line
	+must contain the modification date in angle brackets.
	+The format of the date is <YYYYMMDDhhmmss> where YYYY
	+is year, MM is month, DD is day, hh is hours, mm is
	+minutes, and ss is seconds.
	+
	+
	+The third block in the example is the +VIEWS block.
	+This block lists different formats in which the
	+document can be retrieved. The first format listed is
	+what the server believes to be the preferred format.
	+A gopher client might display the list of possible
	+view labels of the item to the user and let the user
	+select the view they prefer. Alternatively, a smart
	+client might look at the content of the labels and
	+preferentially retrieve Postscript views of items.
	+Note that the view labels are structured. View labels
	+specify a Content-Type (application/Postscript,
	+Text/plain, etc.), an optional language (En_US, De_DE,
	+etc.) and an optional size. Note that the View labels
	+for content type use the MIME content types to specify
	+names of the variious views. The optional language
	+descriptors use the ISO-639 codes for representing
	+languages to name the language. Smart clients might
	+want to translate these rather cryptic codes into
	+something mere mortals can read and understand.
	+
	+
	+The client software can pick off the size of each
	+view IF there are any angle brackets on the line.
	+There might not be a size that the server cares to
	+tell you about. Also this might NOT be the exact size
	+that the server will wind up delivering to you if you
	+ask for it... but it should be reasonably close. This
	+information makes it possible for clever clients to
	+select views based on size, data representation, or
	+language. See section 2.6 for how alternate
	+representations (views) are retrieved.
	+
	+
	+The next block in the example is an (optional)
	++ABSTRACT. Here the block consists of lines of text
	+that might be displayed to the user.
	+
	+
	+Other blocks of information can defined and added as
	+the need arises. For instance, a Neuromancer-esque 3-D
	+cyberspace attribute might be accommodated by
	+including a 3D-ICON block (with an image to display
	+in 3-space) and a 3D-COORDINATE block (with y,x, and
	+z coordinates). More immediate needs can also
	+addressed by defining other information blocks. For
	+instance, a SCRIPT block would be a natural place to
	+put information for scripting telnet sessions.
	+Information blocks give us an extensible way of
	+adding attributes (or what Macintosh programmers call
	+resources) to gopher items.
	+
	+
	+Some of the really cool ideas we have for information
	+attributes may require sending large amounts of data,
	+some of which may not be easily represented as ASCII
	+text, but the idea of the attributes information is
	+that it is a relatively compact list of attributes.
	+These somewhat conflicting desires can be reconciled
	+by allowing references to gopher items in an
	+attribute. For example, an +ABSTRACT block might be
	+returned this way:
	+
	+
	+ +ABSTRACT: 0long abstractFselectorFhost2Fport2F+
	+
	+
	+In this example, the abstract is a document that
	+resides on a gopher server. By allowing references to
	+to gopher items, we can also accommodate data that
	+must be sent in an 8-bit clear stream by using the
	+Gopher+ methods for retrieving binary data.
	+
	+
	+If both a reference to an attribute and an explicit
	+value for the attribute are present in an attribute
	+list, the preferred version is the explicit value. In
	+the example below, the preferred version is "the
	+short abstract goes here".
	+
	+
	+ +ABSTRACT: 0long abstractFselectorFhost2Fport2F+
	+
	+ the short abstract goes here
	+
	+
	+Note that if you want to have several views of (for
	+example) an +ABSTRACT this is possible by using a
	+reference to a item residing on a gopher server
	+because the item can have its own attributes.
	+
	+
	+Attributes names are case sensitive (easier to match
	+and more of them). There is no need to "preregister"
	+all possible attributes since we cannot anticipate
	+all possible future needs. However it would be
	+reasonable to maintain a registry for implementors
	+and administrators so duplication can be avoided.
	+Server implementors or administrators can request that
	+new attributes be included in the attribute registry.
	+
	+
	+Dream on: What gets us excited are alternate
	+representations for directory lists. Sure, the
	+standard representation for a gopher directory list
	+is known to us all. But isn't hypertext (in a WWW
	+sense) an alternate kind of directory list? We also
	+envisioned a "geographical view" (GView?) mapping
	+servers onto a map of the world (throw up a gif
	+picture and then overlay dots based on latitude and
	+longitude or xy coordinates). OK. Dream off.
	+
	+
	+ Note that interested parties outside gopherspace have
	+long and complex wish-lists for "attributes" that all
	+well-dressed Internet citizens should have. We don't
	+want to comment on the use or value of these laundry-
	+lists. Suffice it to say that nothing precludes
	+server administrators from including whatever
	+attributes they see fit to include. Certainly IAFA
	+blocks are desirable, bearing UDIs, URL's or whatever
	+else is desired. The gopher community will probably
	+arrive at a list of "recommended" attributes that
	+server administrators should try to support. Because
	+not every server administrator sees advantage to
	+cluttering Attribute Info files with information
	+their primary users will never need, it does not seem
	+fair to "force" folks to include them; most will
	+just ignore the harsh protocol guideline and the
	+value of the protocol will be diminished. We want to
	+mandate as little as we possibly can.
	+
	+
	+
	+
	+
	+2.6 Using Attribute Info: Alternate
	+representations (+VIEWS).
	+
	+
	+The user may locate a document and wonder if there are
	+representations of it besides, say, the standard Text.
	+Using the appropriate client incantation (Option
	+Double-Click? or whatever) the user indicates a wish
	+to see what's available. The client retrieves the
	+Attribute Information, displays the list of views to
	+the user in some kind of scrolling list dialog. User
	+selects a line and client now requests the document
	+in say, Postscript representation:
	+
	+
	+ the selectorF+application/Postscript
	+
	+
	+
	+Smart clients are not precluded from doing things like
	+"Always get Postscript if you can" or "Always get
	+Postscript if that is less than 700K in size." etc.
	+And the "smarter" you make it, the hairier your
	+client will become - unless you are a user interface
	+wizard of awesome proportions. While the example
	+above is of fetching a document's postscript view,
	+there is nothing precluding having different views
	+for directories. In the dream sequence earlier, we
	+imagined a geographic view of a directory. For a
	+client to fetch that view, it would say this:
	+
	+
	+ the selectorF+GView
	+
	+
	+
	+2.7 Getting attributes for all items in a
	+directory in one transaction.
	+
	+
	+Heavyweight/clever/special-purpose clients may want to
	+know all the attributes of items in a given directory
	+in one transaction. The "$" command is used to
	+request all the attributes of a directory at once.
	+For instance, a client might sent the request:
	+
	+
	+ selector stringF$
	+
	+
	+ and the server might return this:
	+
	+
	+ +INFO: 0Salmon dogsFsome selectorFhost2Fport2F+
	+
	+ +ADMIN:
	+
	+ Admin: Frodo Gophermeister <[email protected]>
	+
	+ Mod-Date: August 15, 1992 <19920815185503>
	+
	+ +VIEWS:
	+
	+ Text/plain: <10k>
	+
	+ application/Postscript De_DE: <100k>
	+
	+ +ABSTRACT:
	+
	+ A great recipe for making salmon
	+
	+ +INFO: 0Hot pupsFother selectorFhost3Fport3F+
	+
	+ +ADMIN:
	+
	+ Admin: Bilbo Gophernovice <[email protected]>
	+
	+ Date: <19910101080003>
	+
	+
	+In this example, the server returned the attribute
	+lists for two items because there were only two items
	+in the directory.. The client software can easily
	+separate the attributes for the items since each
	+attribute list starts with "+INFO". It is also easy
	+for the client to use the "$" command to get
	+directory listings since the gopher item descriptor is
	+on the +INFO line for each item.
	+
	+
	+Note that the $ command is the only way to find the
	+administrator of a remote link. To get the full
	+attribute information for a link on another machine
	+may require asking the master machine for the item
	+information. It is possible to append which
	+attributes you are interested in retrieving after the
	+$, eg:
	+
	+
	+ some directory selectorF$+VIEWS
	+
	+or
	+
	+ other directory selectorF$+VIEWS+ABSTRACT
	+
	+
	+
	+The $ command makes it possible for a client that does
	+not mind burning bandwidth to get attribute
	+information for all items as the user navigates
	+gopherspace. Clients using 2400 bps SLIP links will
	+probably not use this method... but clients on
	+Ethernet may not mind. This command may also be useful
	+for building smart indexes of items in gopherspace.
	+Note that the specific requested attributes are only
	+suggestions to the server that the client would like
	+less than a full set of attributes. The server may
	+choose to ignore the request (if it is not capable of
	+extracting the required attributes) and return the
	+client the full set anyway. Other caveats: even if
	+the attributes requested are not available, the
	+server WILL NOT return an error, but will send
	+whatever IS available. It is the client's
	+responsibility inspect the returned attributes.
	+
	+
	+Analogous to use of the $ command, the ! command can
	+also be used to request certain attribute blocks.
	+
	+
	+
	+
	+2.8 Gopher+ Interactive Query items.
	+
	+
	+The principle here is based on Roland Schemer's "Q/q"
	+type ideas. We're calling it the Interactive Query
	+enhancements...
	+
	+
	+The server may list items that have a "?" following
	+the port field:
	+
	+
	+ 0A fileFfile selectorFhostFportF?
	+
	+ 1A directoryFdir selectorFhostFportF?
	+
	+
	+Now the fact that there's something after the port
	+field means that these are Gopher+ items. Old clients
	+will still be able to show such items in lists, but
	+if they simply send the old style plain selector
	+string to retrieve them, the server will respond with
	+an old style error telling them to get an updated
	+client. New clients will know that before getting one
	+of these items, it will be necessary to retrieve
	+questions from the server, have the user answer them,
	+and then feed the answers back to the server along
	+with the selector. The questions to be asked of the
	+user are retrieved from the server by looking at the
	++ASK attribute in the item's attribute information.
	+
	+
	+
	+
	+When the user selects a query item, the client quickly
	+connects to the server and requests the Attribute
	+Information for the item. Then the client extracts
	+the information in the +ASK attribute block. Here's
	+an example:
	+
	+
	+ +INFO: 0inquisitiveFmoo moo
	+selectorFhost2Fport2F+
	+
	+ +ADMIN
	+
	+ Admin: Frank Gophermeister <[email protected]>
	+
	+ Mod-Date: August 15, 1992 <19920815185503>
	+
	+ +ASK:
	+
	+ Ask: How many volts?
	+
	+ Choose: Deliver electric shock to administrator
	+now?FYesFNot!
	+
	+
	+
	+
	+
	+The client will use all lines in the order they appear
	+in the +ASK attribute block. The content will be
	+presented to the user as questions or prompts or
	+dialogs or something like that.
	+
	+
	+The "Ask" presents the user with a question, supplies
	+a default text answer if it exists and allows the
	+user to enter a one-line responce.
	+
	+
	+The "AskP" presents the user with a question, and
	+bullets out the responce typed in by the user so that
	+someone watching over the user's sholder cannot read
	+the responce.
	+
	+
	+The "AskL" presents the user with a question, and
	+ideally should allo the user to enter several lines of
	+responce.
	+
	+
	+The "AskF" requests the user for a new local filename,
	+presumably for stashing the response returned by the
	+server. It may supply a default filename.
	+
	+
	+The "Select" presents the user with a set of options
	+from which the use can select one or many. This is
	+equivalent to Macintosh check boxes.
	+
	+
	+The "Choose" presents the user with a few short
	+choices only one of which may be selected at a time.
	+This is equivalent to Macintosh radio buttons.
	+
	+
	+The "ChooseF" requests that the user select an
	+existing local file, presumably for sending to the
	+server. On some systems, the client writer or
	+administrator might want to restrict the selection of
	+such files to the current directory (ie. not allow
	+paths in the filename to prevent sending things like
	+password files).
	+
	+
	+The n responses harvested from the user are sent on to
	+the server as the first n lines in the dataBlock.
	+There can only be one file sent, and it will be the
	+remainder of the dataBlock if any. If there is an
	+AskL the responce is returned with a count of the
	+number of lines entered by the user on a line by
	+itself, followed by the lines entered by the user.
	+
	+
	+Gopher was originally designed as an essentially
	+anonymous document retrieval protocol to facilitate
	+easy access to information rather than limited
	+access. Various kinds of restrictive mechanisms have
	+been implemented at the server end (for example,
	+access restriction by source IP address); however if
	+you have sensitive information, we emphasize that
	+putting it under a Gopher's nose is not a good idea.
	+
	+
	+
	+
	+The folks with a hirsute tendency will have noticed
	+that all these interactions are static rather than
	+truly dynamic and interactive. In other words, the
	+server cannot ask different questions in response to
	+different answers. +ASK does not constitute a
	+scripting language by any means.
	+
	+
	+To do "true" scripting, we have to do one of two
	+things
	+
	+
	+1. Write a full language parser/interpreter into
	+clients. The server loads a whole script into the
	+client's brain, and the client "runs" it. This
	+rather grossly violates the spirit of simplicity in
	+cross-platform gopher implementation. However, when
	+and if a standard scripting language is adopted,
	+there will be room for it in a SCRIPT attribute block.
	+
	+
	+2. Client enters a complex back-and-forth transaction
	+with the server. This requires the server, client, or
	+both to save rather a lot of state. NOPE! Server
	+saving state means holding open a connection or
	+(worse) the server retaining tokens between
	+connections. Client saving state means the server
	+has an even worse job to do.
	+
	+
	+As Opus the Penguin would say: a Hairball.
	+
	+
	+
	+2.9 Gopher+ Pictures, Sounds, Movies.
	+
	+
	+A lot of folks need ability to retrieve and display
	+pictures, but there is no real consensus on ONE format
	+for these pictures. We don't want to define a type
	+character for every oddball picture type. Gopher+
	+handles Pictures, Movies, and Sounds by defining
	+three item types: ":" for bitmap images, ";" for
	+movies, and "<" for sounds (originally I, M, and S
	+were suggested, but they were informally in use in
	+other ways; the only thing magic about ":", ";", and
	+"<", is that they are the first characters after '9')
	+
	+
	+Note that there is NO default format for Pictures,
	+Movies and Sounds; the specific format of the image,
	+movie, or sound must be gleaned from the +VIEWS
	+information for the item (eg. Gif, PICT, TIFF, etc.).
	+
	+
	+
	+
	+Appendix I
	+
	+
	+Required attributes and suggested attributes.
	+
	+
	+
	+A1.0 The +INFO attribute block
	+
	+
	+The +INFO atttribute block is sent whenever an item's
	+attributes are requested. It is required that the
	+Attribute Information list for an item must contain a
	+one-line +INFO attribute, and the +INFO attribute
	+must contain the gopher+ descriptor for the item.
	+
	+
	+ +INFO: 1Nice stuffF/selectorFhostFportF+
	+
	+
	+
	+A2.0 The +ADMIN attribute
	+
	+
	+ A Gopher+ server is required to have an +ADMIN block
	+for every item and the +ADMIN block must contain
	+Admin and a Mod-Date lines:
	+
	+
	+ +ADMIN:
	+
	+ Admin: [comments] <administrator e-mail address>
	+
	+ Mod-Date: [comments] <YYYYMMDDhhmmss>
	+
	+
	+In addition to the required lines, we recommend that
	+the +ADMIN attribute of items returned by a full-text
	+search engine contain a SCORE attribute. The SCORE
	+attribute should contain the relevance ranking (an
	+integer) of the item.
	+
	+
	+ Score: relevance-ranking
	+
	+
	+We recommend that the +ADMIN attribute of a full-text
	+search engine contain a Score-Range attribute. This
	+attribute is used to specify the range of values
	+taken on by the relevance ranking scores of items
	+returned by the search engine. The Score-Range makes
	+it possible to normalize scores from different search
	+engine technologies. The first number is the lower
	+bound, the second number is the upper bound.
	+
	+
	+ Score-range: lower-bound upper-bound
	+
	+
	+We also recommend that the +ADMIN attribute for the
	+root of the server (i.e. what you get back when you
	+ask for the attributes of the item with the empty
	+selector string) also contain these fields:
	+
	+
	+ Site: the name of the site
	+
	+ Org: organization or group owning the site
	+
	+ Loc: city, state, country
	+
	+ Geog: latitude longitude
	+
	+ TZ: timezone as gmt-offset
	+
	+
	+Other useful attributes might include:
	+
	+
	+ Provider: who provided this item
	+
	+ Author: who wrote this item
	+
	+ Creation-Date: when it was born <YYYYMMDDhhmmss>
	+
	+ Expiration-Date: when it expires <YYYYMMDDhhmmss>
	+
	+
	+
	+A3.0 The +VIEWS attribute
	+
	+
	+The +VIEWS attribute is used to specify alternative
	+representations of an item. The form of the +VIEWS
	+attribute is:
	+
	+
	+ +VIEWS: [gopher descriptor]
	+
	+ Content-Type[ viewLanguage]: [<56K>]
	+
	+ Content-Type[ viewLanguage]: [<93K>]
	+
	+ Content-Type[ viewLanguage]: [<77K>]
	+
	+
	+Some values for Content-Type are
	+
	+
	+ Text/plain, application/Postscript, image/Gif,
	+image/jpeg,
	+
	+
	+Content Types are defined by the Internet Assigned
	+Numbers Authority (IANA). To register a new content
	+type send e-mail to [email protected]. For a
	+comprehensive list, consult the most up-to-date MIME
	+Request for Comments (RFC). A list of currently
	+defined views may be retrieved by anonymous ftp from
	+isi.edu in the directory
	+
	+
	+/pub/in-notes/MIME/mime-types
	+
	+
	+All gopher servers must support the Text/plain view
	+for readable documents and the application/gopher-
	+menu view (the basic Gopher+ directory list) for
	+directories. These are the views that must be
	+returned by default. If all a server supports is the
	+default views, then it may omit the +VIEWS attribute
	+block (although we suggest that it not do so).
	+
	+
	+The viewLanguage is defined as a concatanation of two
	+ISO standard values, the ISO 639 language code and
	+the ISO-3166 country code.
	+
	+
	+Some values for viewLanguage are:
	+
	+
	+ En_US, De_DE, Es_ES, Se_SE
	+
	+
	+
	+A4.0 The +ABSTRACT attribute
	+
	+
	+The +ABSTRACT attribute is used to specify a short
	+abstract for the item. The form of the +ABSTRACT
	+attribute is:
	+
	+
	+ +ABSTRACT: [gopher reference]
	+
	+ A line of text<CRLF>
	+
	+ another line of text<CRLF>
	+
	+ still another line of text.<CRLF>
	+
	+
	+We recommend that a description of the sorts of
	+information at the site, a postal address, a phone
	+number, and the administrator name for the site be
	+included in the +ABSTRACT attribute for the server
	+root (i.e. what you get when you ask for the
	+attribute list of the server with no selector
	+string).
	+
	+
	+
	+
	+
	+Appendix II
	+
	+
	+Paul's NQBNF (Not Quite BNF) for the Gopher+
	+Enhancements.
	+
	+
	+
	+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.
	+
	+
	+This section is not quite solid yet. Please send us
	+information on any errors you might notice.
	+
	+
	+Directory Entity
	+
	+
	+CR-LF ::= Carriage Return Character followed by
	+Line Feed character.
	+
	+Tab ::= ASCII Tab character
	+
	+NUL ::= ASCII NUL character
	+
	+PLUS ::= ASCII '+' character
	+
	+LEFT ::= ASCII '<' character
	+
	+RIGHT ::= ASCII '>' character
	+
	+OCTET ::= $00 -> $ff
	+
	+UNASCII ::= OCTET - [Tab CR-LF NUL]
	+
	+UNASCIINOPLUS ::= UNASCII - [PLUS]
	+
	+UNASCIINOANGLE ::= UNASCII - [LEFT, RIGHT]
	+
	+Lastline ::= '.'CR-LF
	+
	+TextBlock ::= Block of ASCII text not containing
	+Lastline pattern.
	+
	+Type ::= UNASCII
	+
	+DisplayString ::= {UNASCII}
	+
	+Selector ::= {UNASCII}
	+
	+Otherflds ::= {UNASCII + TAB}
	+
	+Host ::= {{UNASCII - ['.']} '.'} {UNASCII -
	+['.']}
	+
	+
	+
	+Note: This is a Fully Qualified Domain Name as defined
	+in RFC 830. (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.
	+
	+
	+
	+Bool ::= '0' \| '1'
	+
	+G+Field ::= '+' \| '?'
	+
	+
	+Success ::= '+' \| '-'.
	+
	+Transfer ::= DigitSeq \| '-1' \| '-2'
	+
	+DataHead ::= Success Transfer CR-LF
	+
	+DataBlock ::= DataHead {OCTET}
	+
	+
	+
	+G1DirEntity ::= Type DisplayString Tab Selector Tab
	+Host Tab Port Tab Otherflds CR-LF
	+
	+G+DirEntity ::= Type DisplayString Tab Selector Tab
	+Host Tab Port Tab G+Field
	+
	+ CR-LF
	+
	+
	+
	+Notes:
	+
	+ It is highly recommended that the DisplayString
	+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. Warning! The Selector string can be longer
	+than 255 characters.
	+
	+
	+Menu Entity
	+
	+Menu ::= DataHead {G+DirEntity}.
	+
	+
	+Continues ::= Bool
	+
	+Representation ::= 'Text' \| 'List' \| 'Postscript' \|
	+'MacWriteII' \| 'RTF' \|{UNASCII}
	+
	+
	+
	+Retrieving a document/menu/etc.:
	+
	+
	+C: Opens Connection
	+
	+S: Accepts Connection
	+
	+C: Sends Selector String Tab '+' Representation [Tab
	+DataFlag]
	+
	+C: [Optional] Client sends a DataBlock depending on
	+value of DataFlag.
	+
	+S: Sends DataBlock
	+
	+Connection is closed by either client or server
	+(typically server).
	+
	+
	+Spaceline ::= ' ' {UNASCII} CR-LF
	+
	+Blockname ::= '+' {UNASCIINOPLUS}
	+
	+Attrblock ::= Blockname ' ' [G+Direntry] CR-LF
	+{Spaceline}
	+
	+Attrval ::= SPACE {UNASCII} CR-LF
	+
	+E-Mail ::= {UNASCII} s.t. it conforms to RFC 822
	+
	+Adminval ::= ' Admin:' {UNASCII} '<' E-Mailaddr
	+'>' CR-LF
	+
	+Dateval ::= ' Mod-Date:' {UNASCII} '<'
	+YYYYMMDDhhmmss '>' CR-LF
	+
	+AdminReq ::= AdminVal Dateval
	+
	+Infoblock ::= '+INFO: ' G+Direntry CR-LF
	+
	+AdminBlock ::= '+ADMIN: ' {G+Direntry} CR-LF
	+AdminReq {Attrval}
	+
	+Language ::= 'English' \| 'French' \| 'German' \|
	+{UNASCII}
	+
	+ViewVal ::= ' ' Representation [' ' Language] ":"
	+ASCIINOANGLE '<'
	+
	+ Size 'k>' CR-LF
	+
	+ViewBlock ::= '+VIEWS: ' {G+Direntry} CR-LF
	+{ViewVal}
	+
	+AttrBlocks ::= InfoBlock ViewBlock {AttrBlock}
	+
	+
	+
	+Retrieving item Information.
	+
	+
	+
	+For non-index server (non-type 7 items)
	+
	+
	+C: Opens Connection
	+
	+S: Accepts Connection
	+
	+C: Sends Selector String Tab '!' {BlockName}CR-LF
	+
	+S: Sends DataBlock with data in AttrrBlocks format.
	+
	+Connection is closed by either client or server
	+(typically server).
	+
	+
	+
	+For index server (type 7 items) the client asks the
	+search engine to so a search for nothing
	+
	+(i.e. the client does not provide any words to search
	+for) and appends a TAB and a "!" after the null-
	+search:
	+
	+
	+C: Opens Connection
	+
	+S: Accepts Connection
	+
	+C: Sends Selector String Tab Tab '!' {BlockName}CR-LF
	+
	+S: Sends DataBlock with data in AttrrBlocks format.
	+
	+Connection is closed by either client or server
	+(typically server).
	+
	+
	+Attributes ::= {AttrBlocks}
	+
	+
	+
	+Retrieving all Item Information entries for a
	+directory.
	+
	+
	+C: Opens Connection
	+
	+S: Accepts Connection
	+
	+C: Sends Selector String Tab '$'{BlockName} CR-LF
	+
	+S: Sends DataBlock with data in Attributes format.
	+
	+Connection is closed by either client or server
	+(typically server).
	+
	+
	+.
	diff --git a/references/rfc1436.txt b/references/rfc1436.txt
	@@ -0,0 +1,906 @@
	+
	+
	+
	+
	+
	+
	+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: [email protected]
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+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: [email protected]
	+
	+
	+ 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: [email protected]
	+
	+
	+ 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: [email protected]
	+
	+
	+ 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: [email protected]
	+
	+
	+ 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: [email protected]
	+
	+
	+
	+Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 16]
	+
	+
	+
	+
	+
	+
	+
	+
	diff --git a/references/rfc4266.txt b/references/rfc4266.txt
	@@ -0,0 +1,339 @@
	+
	+
	+
	+
	+
	+
	+Network Working Group P. Hoffman
	+Request for Comments: 4266 VPN Consortium
	+Obsoletes: 1738 November 2005
	+Category: Standards Track
	+
	+
	+ The gopher URI Scheme
	+
	+Status of This Memo
	+
	+ This document specifies an Internet standards track protocol for the
	+ Internet community, and requests discussion and suggestions for
	+ improvements. Please refer to the current edition of the "Internet
	+ Official Protocol Standards" (STD 1) for the standardization state
	+ and status of this protocol. Distribution of this memo is unlimited.
	+
	+Copyright Notice
	+
	+ Copyright (C) The Internet Society (2005).
	+
	+Abstract
	+
	+ This document specifies the gopher Uniform Resource Identifier (URI)
	+ scheme that was originally specified in RFC 1738. The purpose of
	+ this document is to allow RFC 1738 to be made obsolete while keeping
	+ the information about the scheme on standards track.
	+
	+1. Introduction
	+
	+ URIs were previously defined in RFC 2396 [RFC2396], which was updated
	+ by RFC 3986 [RFC3986]. Those documents also specify how to define
	+ schemes for URIs.
	+
	+ The first definition for many URI schemes appeared in RFC 1738
	+ [RFC1738]. Because that document has been made obsolete, this
	+ document copies the gopher URI scheme from it to allow that material
	+ to remain on standards track.
	+
	+2. Scheme Definition
	+
	+ The gopher URL scheme is used to designate Internet resources
	+ accessible using the Gopher protocol.
	+
	+ The base Gopher protocol is described in RFC 1436 [RFC1436] and
	+ supports items and collections of items (directories). The Gopher+
	+ protocol is a set of upward-compatible extensions to the base Gopher
	+ protocol and is described in [Gopher+]. Gopher+ supports associating
	+
	+
	+
	+
	+Hoffman Standards Track [Page 1]
	+
	+RFC 4266 The gopher URI Scheme November 2005
	+
	+
	+ arbitrary sets of attributes and alternate data representations with
	+ Gopher items. Gopher URLs accommodate both Gopher and Gopher+ items
	+ and item attributes.
	+
	+ Historical note: The Gopher protocol was widely implemented in the
	+ early 1990s, but few Gopher servers are in use today.
	+
	+2.1. Gopher URL Syntax
	+
	+ A Gopher URL takes the form:
	+
	+ gopher://<host>:<port>/<gopher-path>
	+
	+ where <gopher-path> is one of:
	+
	+ <gophertype><selector>
	+ <gophertype><selector>%09<search>
	+ <gophertype><selector>%09<search>%09<gopher+_string>
	+
	+ 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".
	+
	+ <selector> is the Gopher selector string. In the Gopher protocol,
	+ Gopher selector strings are a sequence of octets that may contain any
	+ octets except 09 hexadecimal (US-ASCII HT or tab), 0A hexadecimal
	+ (US-ASCII character LF), and 0D (US-ASCII character CR).
	+
	+ Gopher clients specify which item to retrieve by sending the Gopher
	+ selector string to a Gopher server.
	+
	+ Within the <gopher-path>, no characters are reserved.
	+
	+ 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.
	+
	+2.2. Specifying URLs for Gopher Search Engines
	+
	+ 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.
	+
	+
	+
	+Hoffman Standards Track [Page 2]
	+
	+RFC 4266 The gopher URI Scheme November 2005
	+
	+
	+2.3. URL Syntax for Gopher+ Items
	+
	+ Historical note: Gopher+ was uncommon even when Gopher was popular.
	+
	+ URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
	+ string. Note that in this case, the %09<search> string must be
	+ supplied, although the <search> element may be the empty string.
	+
	+ The <gopher+_string> is used to represent information required for
	+ retrieval of the Gopher+ item. Gopher+ items may have alternate
	+ views and arbitrary sets of attributes, and they may have electronic
	+ forms associated with them.
	+
	+ To retrieve the data associated with a Gopher+ URL, a client will
	+ connect to the server and send the Gopher selector, followed by a tab
	+ and the search string (which may be empty), followed by a tab and the
	+ Gopher+ commands.
	+
	+2.4. Default Gopher+ Data Representation
	+
	+ When a Gopher server returns a directory listing to a client, the
	+ Gopher+ items are tagged with either a "+" (denoting Gopher+ items)
	+ or a "?" (denoting Gopher+ items that have a +ASK form associated
	+ with them). A Gopher URL with a Gopher+ string consisting of only a
	+ "+" refers to the default view (data representation) of the item, and
	+ a Gopher+ string containing only a "?" refers to an item with a
	+ Gopher electronic form associated with it.
	+
	+2.5. Gopher+ Items with Electronic Forms
	+
	+ Gopher+ items that have a +ASK associated with them (i.e., Gopher+
	+ items tagged with a "?") require the client to fetch the item's +ASK
	+ attribute to get the form definition, and then ask the user to fill
	+ out the form and return the user's responses along with the selector
	+ string to retrieve the item. Gopher+ clients know how to do this but
	+ depend on the "?" tag in the Gopher+ item description to know when to
	+ handle this case. The "?" is used in the Gopher+ string to be
	+ consistent with Gopher+ protocol's use of this symbol.
	+
	+2.6. Gopher+ Item Attribute Collections
	+
	+ To refer to the Gopher+ attributes of an item, the Gopher URL's
	+ Gopher+ string consists of "!" or "$". "!" refers to all of a Gopher+
	+ item's attributes. "$" refers to all the item attributes for all
	+ items in a Gopher directory.
	+
	+
	+
	+
	+
	+
	+Hoffman Standards Track [Page 3]
	+
	+RFC 4266 The gopher URI Scheme November 2005
	+
	+
	+2.7. Referring to Specific Gopher+ Attributes
	+
	+ To refer to specific attributes, the URL's gopher+_string is
	+ "!<attribute_name>" or "$<attribute_name>". For example, to refer to
	+ the attribute containing the abstract of an item, the gopher+_string
	+ would be "!+ABSTRACT".
	+
	+ To refer to several attributes, the gopher+_string consists of the
	+ attribute names separated by coded spaces. For example,
	+ "!+ABSTRACT% 20+SMELL" refers to the +ABSTRACT and +SMELL attributes
	+ of an item.
	+
	+2.8. URL Syntax for Gopher+ Alternate Views
	+
	+ Gopher+ allows for optional alternate data representations (alternate
	+ views) of items. To retrieve a Gopher+ alternate view, a Gopher+
	+ client sends the appropriate view and language identifier (found in
	+ the item's +VIEW attribute). To refer to a specific Gopher+
	+ alternate view, the URL's Gopher+ string would be in the form:
	+
	+ +<view_name>%20<language_name>
	+
	+ For example, a Gopher+ string of "+application/postscript%20Es_ES"
	+ refers to the Spanish language postscript alternate view of a Gopher+
	+ item.
	+
	+2.9. URL Syntax for Gopher+ Electronic Forms
	+
	+ The gopher+_string for a URL that refers to an item referenced by a
	+ Gopher+ electronic form (an ASK block) filled out with specific
	+ values is a coded version of what the client sends to the server.
	+ The gopher+_string is of the form:
	+
	+ +%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A
	+ <ask_item2_value>%0D%0A.%0D%0A
	+
	+ To retrieve this item, the Gopher client sends the following text to
	+ the Gopher server.
	+
	+ <a_gopher_selector><tab>+<tab>1<cr><lf>
	+ +-1<cr><lf>
	+ <ask_item1_value><cr><lf>
	+ <ask_item2_value><cr><lf>
	+ .<cr><lf>
	+
	+
	+
	+
	+
	+
	+
	+Hoffman Standards Track [Page 4]
	+
	+RFC 4266 The gopher URI Scheme November 2005
	+
	+
	+3. Security Considerations
	+
	+ There are many security considerations for URI schemes discussed in
	+ [RFC3986]. The Gopher protocol uses passwords in the clear for
	+ authentication, and offers no privacy, both of which are considered
	+ extremely unsafe in current practice.
	+
	+4. Informative References
	+
	+ [Gopher+] Anklesaria, F., et al., "Gopher+: Upward compatible
	+ enhancements to the Internet Gopher protocol", University
	+ of Minnesota, July 1993, <ftp://boombox.micro.umn.edu/pub/
	+ gopher/gopher_protocol/Gopher+/Gopher+.txt>
	+
	+ [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
	+ Resource Locators (URL)", RFC 1738, December 1994.
	+
	+ [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
	+ August 1998.
	+
	+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	+ Resource Identifier (URI): Generic Syntax", STD 66,
	+ RFC 3986, January 2005.
	+
	+ [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
	+ Torrey, D., and B. Albert, "The Internet Gopher Protocol
	+ (a distributed document search and retrieval protocol)",
	+ RFC 1436, March 1993.
	+
	+Author's Address
	+
	+ Paul Hoffman
	+ VPN Consortium
	+ 127 Segre Place
	+ Santa Cruz, CA 95060
	+ US
	+
	+ EMail: [email protected]
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+Hoffman Standards Track [Page 5]
	+
	+RFC 4266 The gopher URI Scheme November 2005
	+
	+
	+Full Copyright Statement
	+
	+ Copyright (C) The Internet Society (2005).
	+
	+ This document is subject to the rights, licenses and restrictions
	+ contained in BCP 78, and except as set forth therein, the authors
	+ retain all their rights.
	+
	+ This document and the information contained herein are provided on an
	+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	+
	+Intellectual Property
	+
	+ The IETF takes no position regarding the validity or scope of any
	+ Intellectual Property Rights or other rights that might be claimed to
	+ pertain to the implementation or use of the technology described in
	+ this document or the extent to which any license under such rights
	+ might or might not be available; nor does it represent that it has
	+ made any independent effort to identify any such rights. Information
	+ on the procedures with respect to rights in RFC documents can be
	+ found in BCP 78 and BCP 79.
	+
	+ Copies of IPR disclosures made to the IETF Secretariat and any
	+ assurances of licenses to be made available, or the result of an
	+ attempt made to obtain a general license or permission for the use of
	+ such proprietary rights by implementers or users of this
	+ specification can be obtained from the IETF on-line IPR repository at
	+ http://www.ietf.org/ipr.
	+
	+ The IETF invites any interested party to bring to its attention any
	+ copyrights, patents or patent applications, or other proprietary
	+ rights that may cover technology that may be required to implement
	+ this standard. Please address the information to the IETF at ietf-
	+ [email protected].
	+
	+Acknowledgement
	+
	+ Funding for the RFC Editor function is currently provided by the
	+ Internet Society.
	+
	+
	+
	+
	+
	+
	+
	+Hoffman Standards Track [Page 6]
	+