[gopher] A Sunday morning diatribe

[JumpJet Mailbox <jumpjetinfo@xxxxxxxxx>]

Please allow me to indulge in a bit of Sunday morning musing and 
pontificating.  Thanks.
 
MINDSET:
 
Comparing the WWW to Gopher is "wrong thought".  It starts the conversation 
from a faulty predisposition and it never entirely breaks free.  The WWW was 
designed in isolation from, and is in no way associated with, Gopher.  Even 
saying that the WWW does things better than Gopher is a misnomer. Yes people 
may claim that for the "modern" WWW, but that isn't how the WWW looked in the 
beginning when Gopher was king... See for yourself by viewing your website 
using an emulator of the original pre-Mosaic Web client (yes, contrary to what 
the revisionists say over and over again, there were clients before Mosaic) at: 
http://www.dejavu.org/1992win.htm
 
Gopher was developed by a University as a way to provide their students a way 
to access the Universities data in a manner that was superior, both in 
presentation and safety, to the "File Transfer Protocol" (FTP).  Gopher is 
actually a SuperSet of Anonymous FTP!!!
 
When you start a conversation comparing Gopher to FTP, this is "right 
thought".  Now the conversation takes on a different tone, and the whole 
thought process changes.  Without the WWW baggage, the mind leaps to new 
concepts about ways to do things.  Now thoughts of logical file structure, 
speed, universality, and subject threads, suddenly spring into mind.
 

RFC 1436:
 
The first paragraph says it all:  "It (RFC 1436) does not specify an Internet 
standard."
 
This is a very important statement.  From a historical standpoint, it confirms 
that Gopher was developed independently, away from the mainstream "Internet" 
development team (CERN being the 800-pound gorilla).  It also, unfortunately 
(or fortunately, depending on your perspective), means that the Gopher 
standards have yet to be written in stone.  
 
At first, everyone looked to the guys at UMN to provide direction.  However, 
with UMN washing their hands of Gopher in 2001 (Gopher Software made public 
domain, the "Mother Gopher" having its plug-pulled, and the BoomBox FTP servers 
files becoming corrupted), there is NO Official Source (like W3C) to turn to in 
regards to Gopher "best practices".  
 
At this time, it looks as if participants to this NewsGroup, and the operators 
of the Super Gopher Servers, are the ones to whom the mantle of determining 
"best practices" fall.

 
COMPATABILITY:
 
New portable platforms (such as cellphones, etc.) are limited to a more 
streamlined approach in regards to Internet data capturing and display.  Rural 
communities are limited to Dial-up or slow Satellite links.  Older platforms 
are limited to file display capabilities (will someone PLEASE!!! make an 
up-to-date PDF file viewer for DOS!?!).  Gopher is an ideal protocol for 
delivering content to these end users.
 
However... as there are no fixed Gopher standards (Gopher+ doesn't even rate an 
RFC), we must be very careful about how we build future software, particularly 
Servers, so that we do NOT leave older Clients behind.  Just as importantly, we 
must also configure our existing servers so that Clients from ALL platforms 
(not just Unix-based ones) can take full advantage of the data presented (just 
a your Web site should work with Lynx and WebTV).
 
For example:  While most Unix-based platforms do not use "dot-plus-three" file 
content description extensions; Tandy, DOS, and Windows platforms DO.  Would it 
be such an intolerable burden to include file extensions when you post a file 
on Gopher, even if you and your friends may not use them?  It sure would be 
helpful to others if you did.  
 

PORTS:
 
The beauty of the Internet is that you can transmit data on any port you like 
(in fact, there are actually TOO MANY ports to choose from).  For example, 
while most persons choose to use Port 80 to transmit the HTTP protocol (because 
most Web pages are for public consumption, and IANA has reserved Port 80 for 
public consumption HTTP), you could transmit the data on some other port of 
your choosing.  
 
The same goes for Gopher.  There are legitimate reasons why one might not want 
to transmit on a commonly used port (such as for server testing).  However, 
IANA has reserved Port 70 for exclusive use by the Gopher protocol, for 
transmitting public consumption Gopher.  Why not use Port 70 for your server, 
even if you could do otherwise?  Some reasons include:
* For nearly all Server operators, using Port 70 is NOT an intolerable burden.
* Port 70 has been reserved by IANA for your use, so there are no "conflict" 
considerations.
* Many Routers are pre-configured OPEN on Ports 21, 70, and 80 (but block other 
Ports).
* Many Clients (and Servers) have been improperly "hard wired" to look only to 
Port 70.  Not using Port 70 would therefore prevent a large contingent of users 
from accessing the information on your Server.  
 

ITEM TYPES:
 
Item Types are a unique feature of Gopher.  Other than with "file extensions", 
FTP did not contain a way to designate the format of a file.  FTP also did not 
"link", so there was now also a need to tell the Client how to process a link.
 
Today, the Web Browsers have incorporated the email system of "Multipurpose 
Internet Mail Extensions" (MIME).  http://www.mhonarc.org/~ehood/MIME/
Gopher did it through a system called "Item Types".  ALL Clients and Servers 
support Item Types of "0" [plain text file], "1" [directory listing], and "9" 
[binary file].  I strongly urge that all future Clients and Servers continue to 
support Item Types 0, 1, and 9.  
 
Note:  For a long time, the JumpJet Server served any file that contained human 
readable body text when printed on a TeleType machine (regardless if it 
included advanced presentation "garbage" mixed in with the text) as Type 0.  I 
now see that this is not quite in the spirit of Type 0, and have modified the 
Server to only serve TRUE "plain text" content (such as *.txt files) as Type 
0.  
 
Item Type "3" [error message] was stillborn.  Many Clients and Servers do not 
recognize it.
 
Item Type "i" [informational message] is a late comer to the game; thrown in as 
a perceived need, that was not considered in the original implementation of 
Gopher.  The output of Type "i" is unique to Gopher, and is not consistently 
implemented.  Too often Type "i" is used as a crutch, to supplement an unclear 
file title, or to substitute for an "About.txt" file.  Properly implemented 
however, it can be an extremely useful Gopher enhancement.  I, with reserve, 
recommend Type "i" support in future Clients, Servers, and multi-protocol 
Browsers.
 
Gopher and HTTP are not the only public protocols used on the Internet 
network.  See 
http://home.jumpjet.info/Gopher/access.htm
Item Types "2" [CSO search query], "7" [search engine query], and "8" [telnet 
session pointer] were reserved for three of these protocols.  Type 2 and Type 8 
were included only for the convenience of UMN students (so they wouldn't have 
to use another Client just to access popular UMN resources).  As such, Type 2 
and Type 8, although still remaining reserved Item Types, could be dropped and 
not incorporated.  Type "7" is an important service (think "Veronica"), and 
SHOULD be incorporated into future Clients and Servers.
 
An attempt has been make to break-out common file categories (sound files, 
graphics files, binary archive files, etc.) from the Item Type 9 category, by 
incorporating new Item Type designators (Type "s", Type "g", Type "5", etc.).  
BEWARE.  Not all Clients and Servers support these Item Types, even if they 
appear in RFC 1436.  Nor has the question been settled as to whether they 
should even BE included (the use of "extensions", for example, can in most 
instances serve the same purpose as using one of these singular Item Types)!  
 
Problem:  There has been talk of breaking down all files into their most basic 
components.  A document file, which might include both a photo and text, should 
be broken into a Type "0" *.txt text file, and a Type "g" *.gif photo file.  
While this is commendable, what do you do about *.pdf files?  Many of these can 
NOT be broken into separate segments (or even converted into picture files).  
Should Type "d" [PDF file] be incorporated into future Clients and Servers?  In 
the interim, should most non-PDF files indeed BE broken apart?  
 
Another problem:  If new (or even existing) file defining Item Types (such as 
"4", "5", "6", "d", "g", "h", "I", and "s") DO get the nod for inclusion, they 
must WAIT until Server software can support them (remember, Gopher is a Smart 
Server, Dumb Client, model).  For example; there is only ONE choice for a 
native "services" Gopher Server for Windows... GopherS.  Until a replacement 
becomes available, the ONLY Item Types that can be served from a Windows 
platform are (besides hierarchy file management Types "1" and "i"), Types "0", 
"4", "5", "6", "7", "9", "s", "I", "g", and "h".  
 

TALK IS CHEAP:
 
If I encounter one more link to the "Gopher Manifesto", I think I will commit 
Seppuku.  Even this NewsGroup goes on and on with great ideas (as it should, 
that is indeed productive, and it is one of the reasons this NewsGroup exists); 
but NOTHING is being done through channels that are already in place.
 
For example:  Links are external in Gopher.  A recent discussion on this 
NewsGroup debated using only focused (genus-like) links (only linking to 
information directly relating to the subject, regardless of where in the 
Internet it is located), vs. using "up options" to create broader (family-like) 
links (also including links to information of a more global relationship to the 
subject, so the end-user would not have to manually type a URL to move to a 
shallower level on a linked Server).  
 
What seems to have been overlooked is that there are ALREADY links to the more 
broad-based information stockpiles.  They are listed in "Gopher Jewels 2".  
However NO ONE has sent a single link to be included in Gopher Jewels 2 (even 
though contact information is included and link suggestions are actively 
solicited).  Come on people... send links to these repositories.  This way, if 
you wanted to link "broader", you could just include the appropriate GJ2 URL!
 
Another example: There have been endless debates about Ports and Item Types and 
Presentation appearance, and File handling.  Yet no one seems to have looked to 
see what is actually being supported by the existing Gopher Clients and 
Servers.  Come on people... there are only a handful of Clients and Servers, 
almost all being archived on JumpJet
gopher://home.jumpjet.info/11\Begin_Here
 
Grab some, load them on your computer, do a few quick tests, and write a 
paragraph or two review about them.  I will post these reviews on JumpJet, so 
this way everyone will actually KNOW what is or is not supported!!!