
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:  
<gopher@boombox.micro.umn.edu>.  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 <fng@bogus.edu> 

         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 <fng@bogus.edu> 

         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 <bng@bogus.edu> 

         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 <fng@bogus.edu>

         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  IANA@isi.edu.  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).


