
July 30, 1993                                               page
                           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, "Æ" 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 stringÆselector stringÆhostÆportÆextra
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 directoryÆfoo selectorÆhost1Æport1
1Some new directoryÆbar selectorÆhost1Æport1Æ+
0Some file or otherÆmoo selectorÆhost2Æport2Æ+

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 selectorÆ+

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:


selectorstringÆ+[representation][ÆdataFlag]<CRLF>[datablock
]

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 stringÆ!<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 otherÆmoo selectorÆhost2Æport2Æ+
     +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 abstractÆselectorÆhost2Æport2Æ+

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 abstractÆselectorÆhost2Æport2Æ+
       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 selectorÆ+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 selectorÆ+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 stringÆ$

 and the server might return this:

     +INFO: 0Salmon dogsÆsome selectorÆhost2Æport2Æ+
     +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 pupsÆother selectorÆhost3Æport3Æ+
     +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 selectorÆ$+VIEWS
or
     other directory selectorÆ$+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 fileÆfile selectorÆhostÆportÆ?
   1A directoryÆdir selectorÆhostÆportÆ?

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: 0inquisitiveÆmoo moo selectorÆhost2Æport2Æ+
     +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?ÆYesÆNot!


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 stuffÆ/selectorÆhostÆportÆ+


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).


.
