A Beginner's Guide to the Internet/INTERNET.ISO/text/faqs/v6.txt

Text File | 1996-05-06 | 85.7 KB | 1,627 lines

Exploring the Power of the Internet Gopher

UU     UU  II  UU     UU   CCCCCC  NN    NN  EEEEEEE  TTTTTTTT
UU     UU  II  UU     UU  CCCCCCC  NNN   NN  EEEEEEE  TTTTTTTT
UU     UU  II  UU     UU  CC       NNNN  NN  EE          TT
UU     UU  II  UU     UU  CC       NN NN NN  EEEEE       TT
UU     UU  II  UU     UU  CC       NN  NNNN  EE          TT
 UUUUUUU   II   UUUUUUU   CCCCCCC  NN   NNN  EEEEEEE     TT
  UUUUU    II    UUUUU     CCCCCC  NN    NN  EEEEEEE     TT

Dec. 1992 - Jan. 1993  Vol. 6, No. 1

This is an ASCII version of the University of Illinois publication
UIUCnet, a newsletter covering campus networking issues.  This
newsletter is also disseminated in hard copy (which is the
preferred format for distribution) and will eventually be
available in postscript format as well.  Although the articles
contained herein may make references to page numbers, figures,
and/or tables, these references generally refer to items in the
typeset version and do not apply to the ASCII distribution of the
newsletter.  Moreover, special typographical effects such as
italics, boldface, underline, etc., which served to clarify or
emphasize particular textual passages in the typeset version, have
necessarily been lost in the ASCII conversion process.  Attempts
have been made to compensate for the latter shortcoming through
the use of quotation marks, uppercase letters, and other special
formatting effects available within the confines of the ASCII
character set.

This and other issues of the UIUCnet newsletter are available for
download via anonymous ftp from the host: ftp.cso.uiuc.edu in the
directory doc/net/uiucnet.  The file naming convention vol#no#.txt
is used to indicate the volume and number of a given issue.  For
example, vol5no1.txt contains the ASCII version of UIUCnet, volume
5, no. 1.

If you would like to subscribe to and receive the typeset version
of the UIUCnet newsletter, send an e-mail request to:
[e-mail].  Include your full name and U.S. or
International mailing address (or campus address and mail code
for UIUC students, faculty, and staff).

Subscription requests can also be made by sending a letter or
postcard with your full name and mailing address to:

     UIUCnet
     1120 Digital Computer Laboratory
     1304 W. Springfield Ave.
     Urbana, IL 61801

Permission to reprint all or part of UIUCnet for non-profit
purposes is granted, provided full acknowledgement of the original
source (publication name, vol. #, issue #, and author's name) is
given.

******************************************************************

           Exploring the Power of the Internet Gopher

By now, most UIUCnet users have at least heard about gopher.  The
furry little rodent who burrows through gopherspace on the
Internet has been featured twice in CCSO's "Updates" newsletter
(vol. 3 no. 4 and vol. 3 no. 8) and once in the semi-monthly UIUC
faculty/staff newspaper "Inside Illinois" (vol. 12 no. 11).
National publications for computing and networking professionals
and hobbyists (e.g., "MacWeek," "Network World," "Computer
Shopper") have also been tracking the development of this
increasingly popular and ubiquitous Internet tool. So, why another
article about gopher?  Well first, if you haven't yet read about
or seen gopher, you should make a point of it.  Gopher is the only
application that truly makes navigating and using many services on
the Internet as natural as choosing an entree from a dinner menu.
Yet, for all its elegant simplicity, there is tremendous power
behind gopher's intuitive interface.  Unleashing this power is a
matter of understanding a little bit about how gopher works and
discovering some of its less obvious capabilities.

Back to Basics
--------------
For the sake of the uninitiated, let's review a little bit about
the history and nature of the Internet gopher.  Gopher was born at
the University of Minnesota (home of the Golden Gophers) in an
effort to provide the UM students and staff with a flexible
Campus-Wide Information System (CWIS) for disseminating news,
announcements, and other kinds of information to the university
community.  In order to make it easy for departmental information
providers to maintain control over their own data, the gopher team
sought to develop a "distributed document delivery system"--that
is, a system in which the data could physically reside on multiple
computers in multiple locations.  Their solution was a TCP/IP-
based client-server protocol and a set of applications that
provided for the coordination and linking of multiple information
servers across campus, while at the same time presenting that
information to the end-user in a way such that it all appears to
come from the same place.

Over the last two years, gopher has evolved from a system
primarily intended to distribute text documents to a highly
customizable environment for providing access to many different
types of files and popular network services.  Gopher has been
adopted by hundreds of sites across the Internet--including the
University of Illinois--as the CWIS/information server of choice.
Today, the same method that was used to link multiple servers at
the University of Minnesota campus is now used to link gopher
servers all over the globe.  The result is a seamless network of
information servers, all of which can be easily accessed through a
single, menu-driven interface.

Due to the superhuman efforts of co-administrators Paul Gibbs and
Lynn Bilger, the University of Illinois gopher service is now
internationally recognized as one of the best in gopherspace.
Later on, we'll investigate some of its features in detail.  But,
if you haven't yet had a chance to access gopher or want to know
how you can use it to distribute your own information, get a copy
of the document called "Gopher at the University of Illinois,"
available in the rack just outside the CCSO Resource Center, 1420
DCL (you can also request a copy by sending an e-mail message with
your campus mail address to uiucnet @uiuc.edu).  This document
provides all the information necessary to get started with gopher.
It describes what gopher is, summarizes what's contained in the
UIUC gopher server, outlines the numerous methods for accessing
gopher, and enumerates the many options for getting information
into gopher.

Gopher Server(s) and Clients
----------------------------
Like so many networked applications today, gopher exploits the
client-server model.  The server is the machine that holds and
organizes the data.  To a certain extent, what you can do with
gopher depends on your server.  A very simple server might only
hold plain text files.  By linking this simple server to another
gopher server, however, users have access to information and
services on both the simple server and the server to which it is
linked.  Today most servers contain more than just text files and
links to other servers.  In addition to holding hundreds of text
files, the main gopher server here at UIUC (a NeXT workstation)
includes an engine for browsing and downloading files from popular
ftp sites, gateways to the archie file archive database and the
WAIS (Wide Area Information Servers) distributed-database system,
direct links to several types of electronic phone books, the
ability to do full-text searches on many of the documents archived
on our local server and remote text databases, preconfigured
telnet sessions for connecting to popular electronic library
catalogs and information servers across the Internet, and, of
course, links to every other gopher server in the world and all
the unrestricted services they offer.

The Minnesota gopher development team is constantly working on
expanding the capabilities of the server software.  In order to
maintain a state-of-the-art gopher server, the server
administrator must keep abreast of the latest server software
releases and be willing to upgrade the server as necessary.
Although the Unix-based server is the most powerful, it is also
possible to set up a gopher server with limited capabilities on a
Macintosh or PC.  Such servers might be appropriate for a small
department that wants to publish its own text-based information
but does not have the resources to purchase and maintain a complex
Unix workstation.

Now let's consider the client side of gopher.  The client is the
computer and software that communicates with the server.  It
provides a friendly front-end for the end-user to view and select
the services available on the server and all its links.  Gopher
clients have been developed for many different types of computers
and operating systems  and often differ in terms of "look and
feel" (see the related article on page 8, "How Six Gopher Clients
Stack Up").  Nevertheless, all gopher clients have several
features in common.

The most obvious similarity among gopher clients is that the
information and services available on the server are presented to
the end-user as a series of nested menus.  This type of menu
structure is intended to resemble a hierarchical file system, a
concept already familiar to most computer users.  When a user
first connects to a server, he or she sees the top-level menu.
This is more or less equivalent to the "root" directory of a tree-
structured file system.  Like a root directory, the top-level menu
often contains files and other menus, which are analogous to
subdirectories (or folders) in a file system.  These submenus may,
in turn, contain files, additional submenus, or other kinds of
objects (such as telnet sessions, index searches, links to ph
servers, etc.), and so on.

The gopher file system metaphor is more obvious in some clients
than others.  For example, menu items that contain submenus in the
Unix curses client terminate with a slash (/), the standard symbol
for a directory in the Unix environment.  TurboGopher for the Mac
and NeXT Gopher 1.3 represent the menu hierarchy as folders within
folders.  Other clients identify menus in some consistent but less
intuitive manner.  All menus in the X Window System client, for
instance, are preceded by a "H" symbol, and PC Gopher II for DOS
uses the symbol "<D>", which stands for directory.

Another characteristic shared by gopher clients is their ability
to speak and interpret the gopher client-server protocol. While
this might seem self-evident, it's important to note that as new
options and services are added to gopher, new terms are added to
the gopher vocabulary (in fact, a full-fledged extension to the
gopher protocol called Gopher+ has been proposed).  An older
client will not know what to do if a message from the server
includes a term it doesn't understand.  This won't necessarily
result in something catastrophic.  It just means that your client
may not be able to make use of all of the services available
through gopher.  Additionally, even the most up-to-date client may
have limited functionality due to the hardware constraints of the
machine on which it is installed.  For example, some gopher
clients (NeXT Gopher, Xgopher 1.2, Unix curses, etc.) can actually
play sound files.  The CMS client on VMD can display the names of
sound files and assigns the label <sound> to them, but cannot play
them.  PC Gopher II, on the other hand, doesn't even know about
sound files.  It can neither display their names nor play them.
Suffice it to say, not all gopher servers and clients are created
equal.

A Gopher Conversation
---------------------
Before leaving the topic of clients and servers, it's worth taking
a few moments to consider what actually takes place during a
gopher session.  When you start gopher, your client opens a TCP
connection with a gopher server (usually the server at the address
specified in the client's configuration file).  The client sends a
carriage-return/line-feed to the server, which in gophertalk
means,  "Tell me what you've got to offer."  The server responds
by returning a stream of carefully formatted text about the
contents of the top-level menu, after which the TCP connection is
closed.  Yes, closed!  Even though it appears as if your client is
maintaining a continuous connection with the server, client-server
conversations in gopher are typically very brief.  The server
returns just enough information to the client so that the client
can initiate another TCP connection and perform another action
such as retrieving a file or opening a menu.  For example, when
you connect to the U of I Gopher server with the Unix curses
client you see the menu:

   1.  Welcome to the U of Illinois Gopher.
   2.  Campus Announcements (12/1/92)/
   3.  What's New? (12/3/92).
   4.  Information about Gopher/
   5.  Keyword Search of Gopher Menus <?>
   6.  U of Illinois Campus Information/
   7.  Champaign-Urbana & Regional Information/
   8.  Computer Documentation/
   9.  Libraries/
   10. Newspapers, Newsletters, and Weather/
   11. Other Gopher and Information Servers/
   12. Phone Books (PH)/
   13. Internet File Server (ftp) Sites/

The client actually receives much more information about each item
in the menu than is displayed on the screen.  For each menu
choice, the server sends five separate pieces of information:  1)
the object type, 2) the specific text that should be displayed in
the menu on the client, 3) a selector string for retrieving the
object (usually the directory or path in which the object is
located), 4) the domain name of the host on which the object
resides, and 5) the telnet port number that listens for requests
on that host.  The raw information transmitted from server to
client for item 1 in the menu above looks like this:

   0Welcome to the U of Illinois Gopher     0/Welcome
   gopher.uiuc.edu   70

The first symbol in the text stream is the object type, in this
case "0".  Every item displayed in a gopher menu has an object
type associated with it.  It is the object type that tells the
client what the specific item is.  The client uses this
information to determine how to display the item in the menu (for
example, graphical clients typically display text documents as
pieces of paper, menus as folders, ph searches as telephones, and
so on) and what to do with the item, should the user decide to
select it.  Type 0 is a text file (see the table below for the
list of object identifiers and the types they represent).

Table:  Gopher Object Types

   Normal Types:
   ------------

   0   Item is a file
   1   Item is a directory
   2   Item is a CSO (qi) phone-book server
   3   Error
   4   Item is a BinHexed Macintosh file
   5   Item is DOS binary archive of some sort
   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
   T   TN3270 connection

   Experimental Types:
   -------------------

   s   Sound type.  Data stream is a mulaw sound.
   g   GIF type.
   M   MIME type.  Item contains MIME (Multipurpose Internet
       Mail Extensions) data.
   h   html type. (HyperText Markup Language used by the
       World Wide Web, a hypertext application for finding and
       accessing resources on the Internet)
   I   Image type.
   i   "inline" text type (used by panda, a proprietary version
       of gopher used at the University of Iowa)


Immediately following the object type is the actual text that is
displayed in the menu.  The next three pieces of information tell
the client how to access item 1 on the menu.  If you select menu
item number 1, your client would open a TCP session with the host
named "gopher.uiuc.edu" at port "70."  Once connected, the client
would send the selector string "0/Welcome" to the server.  The
server would respond by sending the complete text of the welcome
message back to your client.

As it happens, gopher.uiuc.edu is the alias of UIUC's main gopher
server, so selecting item 1 would initiate another brief
interaction with our local server .  But not all menu items on our
local server point to objects that reside locally.  For example,
if you were to select the menu item called "12. Phone Books
(PH)/," the following information would be displayed:

   1.  U of Illinois at Urbana-Champaign <CSO>
   2.  Internet-wide e-mail address searches/
   3.  Phone books at other institutions/
   4.  WHOIS Searches/
   5.  X.500 Gateway (experimental)/

If you then selected item number 2, the raw information sent back
from the server would be:

   1Internet-wide e-mail address searches /Phone Books/.other
   gopher.micro.umn.edu   70

Object type 1 means that the item is a menu (or directory).  The
domain name "gopher.micro.umn.edu" indicates that by selecting
this item, you would not be opening a connection with our local
server.  Rather choosing this item will point your client to a
menu on the server at the University of Minnesota. The menu
appears as if it is on our local server, but in reality it comes
from somewhere else.  This is how gopher establishes transparent
"links" with other servers.

Why should you care about any of this?  I can think of several
good reasons.  First, there may be an occasion when you want to
know where the information in gopher actually originates,
something that is not necessarily apparent from the menu entry.
Many gopher clients have the ability to display the raw
information that lies behind a menu choice.  With the Unix curses
client, you can view this information by pressing the = (equal)
sign.  Second, occasionally a server will identify an object
incorrectly.  If you try to retrieve a binary file with your
client, and the server has told your client that the file is
plain text, the transfer will be unsuccessful.  Having access to
raw server data can help diagnose problems such as this.  It's
also fascinating to consider how effortlessly one can hop from one
server to another in gopher without thinking about a single
network address.

Integrated Services
-------------------
Gopher's strongest selling point is its ability to integrate a
variety of network services into a single application, so that
users don't have to learn multiple software packages, commands,
and network addresses to take advantage of them--a revolutionary
step towards making the Internet accessible to the common man.
However, if you've ever had experience with commercially available
integrated software--the kind that combines word processing,
database, spreadsheet, graphics, and telecommunications
capabilities into a single package--you may have observed that the
functionality and sophistication of the individual components are
often sacrificed for the convenience of inter-application
compatibility and ease of use.  Is the same thing true for
gopher's implementation of well-known Internet services such as
ftp, telnet, archie, WAIS, etc.?  Well, that's a difficult
question to answer.  For many services, the answer depends
specifically on which gopher client you are using.  Some services
are "client intensive," and if the gopher client doesn't do it's
job well, it will pale when compared to a stand-alone counterpart.
But there are at least a few instances where gopher's ability to
pull together multiple resources actually makes it more powerful
than using a stand-alone application.  Let's take a closer look at
several of the services offered through gopher and determine how
they measure up to alternative methods of access.

Gopher as Document Delivery System
----------------------------------
From the outset, gopher was conceived as a document delivery
system, and it's fair to say that this is one of the things that
gopher does best.  All gopher servers and clients, no matter how
primitive, know how to handle text documents.  Most clients can
display text documents on the screen, save them to a file, and/or
print them.  A few clients also offer the option of mailing the
document to another person on the Internet.

Here at UIUC, gopher's text delivery talents are fully exploited.
There is hardly a local event, announcement, or news item that
doesn't make it into gopher.  "Special Campus Announcements" have
their own top level entry on our gopher menu.  One could spend
hours, if not days, browsing through the menu called "U of
Illinois Campus Information."  Lurking beneath this menu choice is
literally everything you wanted to know about the U of I, but were
afraid to ask, neatly organized into menus and submenus.  The full
text of several local publications including "The Daily Illini,"
"Inside Illinois," "the Campus Crime Bulletin," and others can be
found under the "Newspapers, Newsletters, and Weather" menu.
Gopher is rapidly becoming the official vehicle for disseminating
important UIUC text-based information.

Gopher as FTP Client
--------------------
Ftp, the TCP/IP file transfer protocol, is one of the areas in
which gopher shines--that is, if you have the right client.  On
UIUC's gopher server, the ftp option is listed on the main menu
with the title "Internet File Server (ftp) Sites."  Several
popular ftp sites are listed by name.  Additionally, most of the
well-known ftp sites in the world are organized alphabetically
into submenus in this same menu.  For most of the sites in the
alphabetical listing, a brief summary of what the site contains is
provided.  The same method used to move up and down through
gopher's menu hierarchy (usually point and shoot or point and
click) can be used to browse the directory contents of any ftp
site in the list.  And, if you've got the right client, you can
use the same technique to transfer any file from the remote ftp
server to your client machine.

All gopher ftp transactions involve three computers: 1) the remote
ftp host, 2) the gopher server providing access to that host, and
3) your client.  Problems can occur anywhere along this pipe,
but the most common problem is that many gopher clients can only
display and transfer text files.  So, when you are browsing an ftp
site, it may look as if there are very few files available, when
in fact, your client is only showing you the files types that it
can actually transfer.  For example, PC Gopher II cannot handle
binary file transfers.  When browsing ftp sites with this client,
you will only see files with object type 0 (plain text).  Then
there are clients that will only show you the files it thinks you
want to know about.  The Unix curses client can transfer binary
files, but it only displays files that it thinks will be of
interest to a Unix user. Thus, files with the extensions .zip,
.exe, .sit, etc. are not visible when browsing ftp sites with
this Unix client.  Finally, there are clients, such as the CMS
software on VMD, that can display the names of all file types,
but can only transfer ASCII files.  This client is good for
browsing ftp sites, but you have to exit gopher and run a separate
ftp application to actually fetch the file.  The only clients I
know of that can successfully display and transfer all types of
binary files are TurboGopher for the Mac and Xgopher 1.2.  It's a
good bet that most gopher clients will be able to display and
transfer all file types as software development continues.  But
for now, gopher's ftp capabilities are definitely limited by the
versatility of your client.

Gopher as Archie Client
-----------------------
Gopher's implementation of the archie service exemplifies how the
integration of applications can improve performance. The archie
service, called "Search of Most FTP Sites (archie)," can be found
beneath the main menu item "Internet File Server (ftp) Sites."
Archie is a searchable database of the file holdings of all major
anonymous ftp sites on the Internet.  You can feed archie a
filename (or part of a filename) and archie will return a list of
all the ftp sites that have a file matching your query.  Prior to
gopher, the only way to query archie was to telnet to one of
several archie servers or use a stand-alone archie client.  Archie
would send back the desired information.  Then, if you wanted to
actually get the file, you would have to open an ftp connection
with one of the sites listed by archie, change to the specified
directory, and execute the proper ftp commands.

The gopher archie gateway is integrated with its ftp engine.
Thus, performing an archie query on gopher will not only provide
you with a list of ftp sites and directories, but can literally
take you to one of those ftp sites. And, if your gopher client
knows how to transfer the file, you can grab it during the same
transaction.

Comparing an archie query using the Unix stand-alone client with
the same query on gopher will demonstrate exactly how powerful
gopher's archie service is.  Suppose you wanted to locate the well
know e-mail package called Eudora.  Figure 1 on this page shows
part of the results returned by doing an archie query on the
character string "eudora" using the stand-alone archie client on
one of CCSO's Unix mainframes.  Once archie has listed all the ftp
hosts on which a file or directory named "eudora" resides, the
transaction is over.

The gopher archie service can take you several steps further.
Figure 2 shows the information returned by gopher on the same
query.  Every item followed by a double slash (//) is a directory.
By selecting item 10 in the menu, you can view the entire contents
of the "mac/eudora" directory on "ux1.cso.uiuc.edu" as shown in
Figure 3.  At this point, you have actually opened an ftp
connection with ux1 and are inside the "mac/eudora" directory.
From here, if your client permits, you can transfer any of the
files listed in the directory to your local computer.
Unfortunately, because ftp and archie are tied together on gopher,
many of the same limitations that apply to ftp also apply to
archie.

Gopher as Telnet and Tn3270 Tool
--------------------------------
Gopher has the ability to launch pre-configured telnet sessions.
Many gopher servers, including our own, provide access to on-line
library catalogs and other kinds of information servers.  With
gopher, you can easily access these systems without knowing their
domain name or IP address by simply making a menu choice.
However, when you select a telnet session from a gopher menu, it
is important to realize that your gopher client is not actually
opening the telnet session.  In fact, choosing a telnet session
will cause you to temporarily leave gopher.  The gopher client
will look for the telnet application on your client machine and
pass the necessary address information off to the telnet program.
Gopher will also display any special information you need to know,
such as the login id and password to give the remote host.  Your
telnet program will then try to contact the specified host using
the information provided by gopher.  When you close the session,
you will be returned to gopher.

Whether a telnet session is successful or not depends on several
factors.  Most critical is making sure that your gopher client
knows how to find your telnet client.  The gopher clients on CCSO
machines have been configured to launch telnet sessions for you.
If you install a gopher client on your desktop computer, you may
have to do something special so that gopher knows how to find
telnet.

Gopher can also launch remote login sessions with computers that
require 3270 terminal emulation, such as IBM mainframes.  In
principle, tn3270 sessions work just like telnet sessions in
gopher and are subject to the same restrictions.  Thus, gopher
must be able to find the tn3270 program on your client machine.
Additionally, your gopher client must know about the tn3270 object
type.  Neither PC Gopher II nor the CMS Gopher on VMD recognize
the tn3270 object type.  The DOS client simply does not display
tn3270 sessions in its menu system.  The CMS client displays the
session as type "T" but returns the message "cannot process this
type."

In general, the ability to open telnet and tn3270 sessions with
gopher is a tremendous convenience.  The gopher server at the
University of North Texas, which you can find under "Other Gopher
and Information Servers/Recommended Gopher Servers for
Exploration/University of North Texas/," has an exhaustive menu of
telnet and tn3270 sessions to reach library catalogs all over the
world.  Although it is not possible to open a remote login session
with a host that is not listed in a gopher menu, if you would like
certain libraries or information servers added to the list of
libraries and terminal-based sessions on the UIUC gopher server,
simply send an e-mail request to our local gopher administrator at
the address [e-mail].

Gopher as WAIS Client
---------------------
Among the many services offered by gopher is a gateway to the WAIS
(Wide-Area Information Servers) databases.  WAIS is a collection
of distributed databases, which can be searched by keyword and
cover a wide variety of subjects.  (A detailed description of WAIS
and how it works is given in the October 1992 issue of "UIUCnet,"
vol. 5 no 6.)  The gopher implementation of WAIS lacks many of
the features found in dedicated WAIS clients.  Most notably, with
gopher you can only search one WAIS database at a time, and WAIS's
unique search refining tool called relevance feedback is not
available.  However, gopher does offer one feature that most WAIS
clients do not: it allows you to see the names and search all of
the public WAIS databases that are available.  Perhaps someday, a
full-featured WAIS client will be built in to the gopher software.

Gopher as Electronic Phone Book
-------------------------------
Under the menu item "Phone Books (PH)" is a collection of
electronic phone directories (often called white pages) that can
be used to look up the e-mail address and/or other information
about people on the Internet.  The first item in this menu, "U of
Illinois at Urbana-Champaign," provides access to our local CCSO
Nameserver, also known as ph.  Many other institutions have used
the ph program to set up their own electronic directory services.
They can be found mixed in with other types of electronic
directories in the submenu "Phonebooks at other institutions."

Each gopher client represents ph directories in some consistent
way.  Some clients use the term "CSO," which stands for CSO
Nameserver.  Others use an icon resembling a telephone or
telephone book.  In any case, ph searches comprise a specific
object type in gopher and are handled somewhat uniquely.  Most
searches conducted in gopher are actually handled by a gopher
server--that is, the client asks you to enter a search string, it
then sends your search string to a gopher server, the server looks
for items matching your search string, and finally the results of
the search are returned to your client.  Ph queries, on the other
hand, involve a direct conversation between the gopher client and
a ph server; a gopher server does not participate in these
transactions (except to provide the address of the ph server).  In
order for a gopher client to conduct a ph search, it must know how
to speak the ph protocol, which is something quite different than
the gopher protocol.  Most gopher clients today have a built-in ph
client.  Some are easy to use but not very powerful, others are
powerful but not very intuitive, and a few simply don't work.
Also, unlike many stand-alone clients, the ph clients built in to
gopher do not allow a user to log in to a Nameserver to modify his
or her own entry.  Despite these minor shortcomings, between the
many ph Nameservers and other electronic directory services (such
as whois databases, the experimental X.500 directory, and the
utility called netfind), gopher offers a set of comprehensive
tools for finding someone on the Internet, unmatched by any other
client-server application.

Gopher as File Viewer/Player
----------------------------
If you are fortunate enough to have the right software and
hardware, gopher can be used to view images and play sounds.
Sounds and images are experimental object types in Gopher and only
a few clients know what to do with them.  Moreover, like the
telnet function in gopher, sound and image files are not actually
played or viewed by the gopher client.  The client looks for
another program on the client machine that knows how to process
the file.  For example, if the application Giffer is installed on
your Mac, when you download a GIF (graphics interchange format)
file, TurboGopher will ask you if you would like Giffer to display
it for you.  Similarly, Xgopher 1.2 will pass GIF files off to the
X application called xloadimage.

Finding Things in Gopher
------------------------
Well, after many words and pages, we've only begun to scratch the
surface of gopher, which leads us to the last major topic in this
article--with so much information on so many gopher servers all
over the world, how does one actually find specific information in
gopher, and once found, how can one keep track of where the
information is located?  Gopher actually provides several tools
for locating information.  There is a special object type in
gopher called an index-search server.  Index searches often have
the word "search" as part of their menu entry and, like other
object types in gopher, have a distinctive abbreviation or icon
associated with them.  A gopher administrator can create an index
search for any large body of text contained in a gopher menu.
This can help you to rapidly zero in on the documents of interest.
For example, if you are searching the electronic version of the
"Daily Illini" for all recent articles about the women's
volleyball team, you could go to the "Daily Illini Newspaper" menu
and choose the "Word Search of Latest Month" item.  When asked to
enter a search string, enter the word "volleyball."  All "DI"
articles from the last month that contain the word "volleyball"
will be listed as a separate menu.

But how did we find the "Daily Illini" in the first place?  The
UIUC main gopher server has a wonderfully useful resource on the
top level menu called "Keyword Search of Gopher Menus."  This item
contains an index of the titles of every menu on our server.  To
find the Daily Illini amidst the megabytes of information and
multitudes of menus on the server, do a "Keyword Search of Gopher
Menus" on the string "daily illini."  Or, suppose you know that
there is a link to a searchable version of Roget's Thesaurus
somewhere on our server, but you haven't a clue where to look.
Just do a keyword search on the word "thesaurus" and you will be
taken directly to the "Roget's Thesaurus" menu.

VERONICA
--------
The Keyword Search of Gopher Menus handles searching menus on our
own gopher server, but what about the hundreds of other servers on
the Internet? Let me introduce you to VERONICA.  VERONICA stands
for "very easy rodent-oriented net-wide index to computerized
archives" and does for gopher what archie does for anonymous ftp
archives (now we're all waiting for Betty, Reggie, and Jughead to
appear on the Internet).  VERONICA is a utility that indexes the
titles of all levels of menus for most gopher sites on the
Internet.  VERONICA works like any other index search.  You enter
a word or group of words that you are looking for, and VERONICA
creates a custom menu of all titles on all menus throughout
gopherspace that match your query.  By selecting an item in the
custom menu, you are transparently connected to the gopher server
on which it is located.

VERONICA is a relatively new service and there are still a few
problems to be worked out.  First of all, VERONICA is very slow
and bound to become slower as more users begin to use it.
Developers are hoping to eventually distribute VERONICA searches
among multiple servers, which should lessen the burden of any
single VERONICA server.  Secondly, many gopher servers point to
popular items on other gopher servers leading to a great deal of
redundancy among servers.  VERONICA does not eliminate duplicate
items, so a given search can result in many repetitions of the
same service, document, or menu.  Finally, VERONICA does not tell
you where each title comes from.  If your client has the ability
to show the technical information behind each menu item (as
described earlier in this article), then you can find out the
domain name of the source, but not all clients have this
capability and not all users know how to interpret this
information. VERONICA can be found on our local server by doing a
"Keyword Search of Gopher Menus" on the string "veronica" or by
browsing the menu called "Other Gopher and Information Servers."

Bookmarks
---------
Navigating gopher is normally an up or down proposition.  You can
gradually work your way down through a series of menus and wend
your way back up again, but lateral movement is generally not
possible.  Suppose you find a file or service in gopher that you
know you'll want to access time and time again in a menu far
removed from the top.  Most gopher clients allow you to create and
save so-called bookmarks.  A bookmark keeps track of exactly where
a gopher item is located, regardless of whether it resides on your
local server or a remote gopher server.  To go to that item again,
you need only ask gopher to display your bookmarks and select the
bookmark as you would any other gopher item.  Creating a
collection of bookmarks is like creating your own customized
gopher menu.  The commands for creating, viewing, and selecting
bookmarks vary from client to client.   In Turbo Gopher for the
Mac, for instance, bookmarks are created by selecting a gopher
menu item and then choosing the "Set Bookmark..." option from the
Gopher menu  (see Figure 4 on this page).  Consult the on-line
help or written documentation of your gopher client for more
details on bookmarks.

Gopher Broke?
-------------
As we've seen, a gopher session can involve many computers and
many applications.  It's not uncommon, however,  for things to go
wrong in gopher.  Occasionally a specific server function like ftp
will go down, or a server can go down altogether.  And, of course,
certain clients simply cannot perform specific tasks.  As you
become well acquainted with your gopher client, you'll get a sense
of what it can and cannot do.  If you perform an operation
regularly and suddenly it doesn't work, the problem probably lies
with the server.  If on the other hand, you've never had success
doing something like a tn3270 session with your client, chances
are that it does not support this function or is improperly
configured.  Hopefully the foregoing explanation of what takes
place during various types of gopher transactions will help you to
determine the source of any difficulties you might encounter.  If
you suspect that there is a problem with our local server, send an
e-mail message to [e-mail] (you can also send comments and
suggestions about gopher to this address).

Despite occasional problems, gopher is likely to open up the
Internet to a much wider audience.  Whether you are a power user
or network neophyte, this rapidly evolving network tool has much
to offer.  In its infancy, gopher was called a distributed
document delivery system.  Today it is referred to as a
distributed "information" delivery system. Who knows what tomorrow
may bring?

-Lynn Ward

******************************************************************

               How Six Gopher Clients Stack Up

The cover story of this issue describes how the Internet gopher
can be a very powerful tool if you're using the right client
software and if that client is properly configured.  Over the last
several months, I've had the opportunity to work with about ten
different gopher clients, several of which have already been
superseded by new, more powerful applications.  To describe each
of these clients in detail would fill a book, and for most gopher
clients there is a user's guide, on-line help, and/or a man page
that gives technical information and instructions for use.  Below
is a brief sketch of six gopher clients, each for a different
computing platform.  This review highlights the strengths and
weaknesses of each client and, in a few cases, provides some
important undocumented technical information.  All of the clients
discussed in this review can be downloaded from the anonymous ftp
host "boombox.micro.umn.edu."  They are located in subdirectories
(named according to platform) under the "/pub/gopher" directory.
Several clients are also available at the CCSO Resource Center,
1420 DCL.

Note: The comments below refer to the specific version of the
client that was reviewed.  Since many developers continue to work
at improving their software, some of the bugs and other
peculiarities described here may have been or will be fixed in a
later release.

Xgopher 1.2--the Latest and Greatest
-----------------------------------
One of the newest kids on the block is the latest release of
Xgopher, an X Window System client written by Allan Tuchman,
senior research programmer here at CCSO.  Xgopher can handle just
about any gopher function that's currently available.  The
interface is very simple to use (see Figure 1 on page 9).  Most
commands are available by clicking on buttons in the main window.
Less commonly used commands are tucked away in a pull-down menu
called Other Commands.

Xgopher provides support for a variety of different file or object
types including: image files (image files are displayed by
xloadimage, a separate utility that can display many different
types of graphics file formats), sound files (sound files can be
played if Xgopher is installed on a workstation that supports
sound), Unix binary files, ph queries, index searches, and telnet
and tn3270 sessions.  An options panel under the Other Commands
menu allows you to tell Xgopher whether you want to see all files
or just the file types that it knows about.  If you opt to see all
files, Xgopher will display unknown types with a <???> prefix.
Any file type in a gopher menu or directory, even unknown types,
can be transferred to the client machine (for unknown file types,
Xgopher defaults to binary transfer mode) with the copy selected
item to file command.

The bookmarks option is also extremely flexible in Xgopher 1.2.
Xgopher can maintain multiple bookmark files, any of which may be
loaded during a single session.  Also, the bookmark file is
compatible with the Unix curses client, so you can use the same
bookmarks when dialing in from home.

The ph client in Xgopher is fairly powerful, but not quite as
intuitive as other implementations.  The user is prompted to enter
a query in the "Query name" field and results are displayed in the
box below.  A "Show Fields" menu displays the names of the fields
available on the selected ph server and the intended contents of
those fields.  There is some minimal on-line help, but in order do
anything more complex than a simple query on the "name" field, one
must already be well acquainted with the syntax of ph commands.

X Window System gurus can totally customize Xgopher by modifying
the application resources file called "Xgopher."  This plain text
file contains all the settings for Xgopher, including the host
name of the default gopher server; the name of the default
bookmarks file; the prefixes used for each gopher object type; the
default screen colors; the default fonts; the specific text used
for all menus, buttons, and dialog boxes; the specific
applications used to play sound files, display image files, and
conduct telnet and tn3270 sessions, and many other parameters.
Any of the default settings can be changed to suit the
preferences of the end-user.

Xgopher is installed on ux1, ux2, ux4, uxa, and uxh and can be
accessed by anyone with an X terminal or a desktop computer
running an X server application such as MacX.  Questions and
comments about Xgopher should be directed via e-mail to Allan
Tuchman at the address [e-mail].

TurboGopher 1.0.5 for the Mac
-----------------------------
Although there are several gopher clients available for the
Macintosh, TurboGopher 1.0.5 stands out among the crowd.
TurboGopher cannot play sound files or display raw gopher
information, but it handles almost every other gopher operation
with the greatest of ease and speed.  The ftp function works
particularly well.  To transfer a file to your Mac, just double
click on its icon.  If the file is BinHexed, TurboGopher will un-
BinHex it as it transfers the file to your local disk.  This
gopher client even recognizes Unix and DOS binary files and will
intuitively transfer them in binary mode.

When you get your copy of TurboGopher, be sure to download the
helper-applications SitExpand, CptExpand, and Giffer.  If these
programs are installed on your Mac, TurboGopher will offer to
decompress files that have been archived with the StuffIt or
Compactor utilities (files with a .sit or .cpt extension) and
display GIF image files immediately after such files have been
downloaded.

The ph client in TurboGopher is very easy to use.  Unfortunately
it has a major bug.  You can only enter a single name when doing a
search on the "name" field.  If you enter a first and a last name,
the client sends the query to the server improperly and you'll
get the message "501: No matches to your query."  Since the "name"
field is the most common field for doing ph lookups, this is a big
problem.  In order to do a query with TurboGopher's ph client, the
person you are looking for must either have a very unique last
name or you must know some additional information about the
person, such as his or her phone number or address.

TurboGopher supports both telnet and tn3270 sessions only if the
appropriate applications (NCSA Telnet and Brown's TN3270) have
been installed on your hard disk.  Additionally, in order to
conduct a tn3270 session, a copy of your "config.tel" file must be
located in your System Folder.

TurboGopher is installed on all of the Macs at CCSO's computing
sites and is also available at the CCSO Resource Center.  The
software is copyrighted by the University of Minnesota, but can be
copied and distributed freely.

NeXT Gopher 1.3
---------------
For those fortunate enough to have a NeXT workstation sitting on
their desk, NeXT Gopher 1.3 offers a slick interface and good
overall functionality.  Two noticeable shortcomings are its
inability to successfully display and transfer files other than
plain text (supposedly, unsupported object types can be displayed
by typing a special command at the terminal prompt, but this
doesn't seem to work) and the absence of a bookmarks option.
With the help of supporting applications, sound files can be
played with exquisite clarity and GIF files can be viewed.  Gopher
files can also be mailed to other users with the NeXT client.
One curious aspect of NeXT Gopher is that it does not have a
built-in ph client.  Instead it relies on a separate program, NeXT
Ph, which comes bundled with the distribution.  All in all, NeXT
Gopher is probably the "prettiest" client around, but it still has
some catching up to do in order to match the X and Mac clients.

The Unix Curses Client 1.01
---------------------------
The Unix curses gopher client was designed to run on dumb
terminals, so there are no fancy icons or mouse support.
Navigating menus involves either moving the cursor to the desired
item or entering its number and then pressing the <return> key.
But don't let this simple interface mislead you.  The curses
client is fairly intelligent, although sometimes uncooperative.
When installed on a Unix workstation, this gopher client can
display image files and play sound files.  Remote users with dumb
terminals or terminal emulators can use the curses client to
conduct archie searches, telnet and tn3270 sessions, ph queries,
and index searches.  Unfortunately, although the ftp client is
capable of transferring any type of binary file, it only displays
the names of ASCII files, BinHexed files, and Unix binaries.  This
can be very misleading when browsing ftp sites.  Strangely enough,
other types of files such as DOS executable and archived files
will be displayed if you do an archie search, and these files can
be successfully ftp'd once they are displayed.

Version 1.01 of the curses client doesn't do a very good job at
recognizing object types.  When it displays executable DOS files
during an archie search, it assigns them an <HQX> type, which
stands for BinHex.  Tn3270 sessions work, but there is no type
identifier next to them.

If you are new to the Unix curses client, be sure to check out the
on-line help with the "?" command.  It will tell you how to
display technical information on an item, navigate menus, add
bookmarks, and customize your gopher environment.  You can change
the program defaults of the curses client by executing the "O"
(options) command.  Within the options menu, you can specify the
default pager, print command, mail command, etc.  Bookmarks and
your program defaults are saved in a ".gopherrc" file located in
your home directory.

The curses gopher client installed on CCSO Unix machines is
supported by CCSO staff.  If you have a question or problem, send
an e-mail message to [e-mail] or call the CCSO systems
consultants at 333-6133.

PC Gopher II 1.05r3
-------------------
While there are several Gopher clients available for the DOS
environment, PC Gopher II is the only one that does not require
the user to load a commercial TCP/IP stack such as FTP Software's
PC/TCP kernel or Novell's LAN Workplace for DOS.  This client uses
the extended IBM character set to create a pseudo-graphical
interface, complete with pull-down menus, sizable windows with
scroll bars, and support for a Microsoft-compatible mouse.  Let's
first consider the strong points of the DOS client.  PC Gopher II
supports index searches, has a respectable and fully functional ph
client, can display the technical information about an item, and
supports bookmarks.  Unfortunately, the bookmarks feature is
limited to selecting menus only, not items within menus such as an
index search.

PC Gopher II also supports telnet sessions if it is properly
configured.  Be sure the "Allow Telnet Sessions" box is checked in
the configuration window.  Also, in order to conduct a telnet
session, you must set a DOS environment variable so that gopher
knows where to find your telnet application.  To accomplish this,
a line can be added to your "autoexec.bat" file or the batch file
that starts gopher.The general syntax of the line should be:

   set g_tel=c:\telnet_directory\telnet_app
-h c:\telnet_directory\ config.tel %%a %%p

where telnet_directory is replaced by the name of the directory in
which your telnet program is stored and telnet_app is the name of
your telnet program's main executable file (e.g., "telbin.exe,"
"tn.exe," etc.).  When telnet is invoked by PC Gopher II, the
parameters "%a" and "%p" are replaced with the IP address and port
information provided by the gopher server (if you type the set
command at the DOS command prompt instead of including it in a
batch file, use a single percent sign in front of the "a" and "p"
parameters [e.g., "%a %p"]).  When using PC Gopher II in
conjunction with Clarkson and NCSA telnet, it may be necessary to
surround the "%%a %%p" parameters with double quotes in order for
telnet to properly recognize a port number.  For example, the
"g_tel" variable in my "autoexec.bat" file looks like this:

   set g_tel=c:\telnet\telbin.exe -h c:\telnet\ config.tel
"%%a %%p"

PC Gopher II is a memory hog and does not support or display
tn3270 sessions, so there is no reason to use the larger
application "tn3270.exe" as the telnet program file.

There is still much work to be done before PC Gopher II can
compete with the clients mentioned above.  This client only
recognizes, displays, and transfers ASCII text files.  Thus, file
transfers are extremely limited and archie queries produce
unpredictable results.  Also, occasionally binary files (such as
GIF files) are misconstrued as text files and PC Gopher II tries
to display them.  Additionally, the memory constraints of PC
Gopher II prevent it from displaying the complete text of even
moderately sized files.  Such files must be saved to disk and read
or printed with a text editor or word processor.  Hopefully, many
of these problems will be ironed out in the next incarnation of
this DOS client.  In the meantime, if you have a Unix account, you
may prefer to use the Unix curses client instead.

CMS Gopher 2.2.0
----------------
CMS Gopher 2.2.0 is quirky, to say the least.  On the one hand, it
recognizes and displays the names of almost all object types.
However, it can only display and transfer plain text files.  To
save a text file, the file must first be loaded into the XEDIT
editor (there is no "save" command in gopher itself).  Although
the client supports ph and archie searches, with a few rare
exceptions index searches fail and return an error message.  The
most ironic shortcoming of this client developed for IBM
mainframes is that, while it can launch telnet sessions and
communicate clumsily with Unix hosts, it does not support tn3270
sessions with other IBM mainframes. An attempt to launch such a
session will result in the error message "Can't process this file
type."  A new version of CMS Gopher is available, but as of this
writing, has not been installed on VMD.  Perhaps some of the
oddities just noted are corrected in release 2.3.

For More Information
--------------------
For the most up-to-date information about gopher and the gopher
software distribution, browse the documents and the "Gopher
Software Distribution" menu under the "Information about Gopher"
menu on UIUC's main gopher server.

-Lynn Ward

******************************************************************

                 The ACN is on the Move Again

Computers, like people, occasionally relocate.  In the case of
networked systems, this often means that the computer, again like
a person, will have a new address.  Such is the case for the
MVS/CAS system on the Administrative Computing Network (ACN).  In
mid-December,  the TCP/IP interface for the ACN's MVS/CAS system
was moved to a router on the FDDI ring at the University of
Illinois at Chicago.  By connecting this computer to the FDDI
ring, AISS hopes to improve the performance of the MVS/CAS system
on the network and to increase the number of possible TCP/IP
connections it can handle.  However, the move also means that the
IP address for accessing this system via ftp and telnet will
already have changed by the time this article hits the streets.
For this reason, AISS encourages all clients to begin using the
fully-qualified domain name "UICMVSA.AISS.UIC.EDU" when accessing
the MVS/CAS system rather than using its numerical IP address.
And, in general, users are urged to always use the hostname as
opposed to the IP address, because the IP address might change
again sometime in the future, whereas the hostname for this
machine will never change.

If you are accustomed to accessing the ACN by typing its IP
address when you invoke your TCP/IP applications (e.g., telnet,
ftp, etc.), simply substitute UICMVSA.AISS.UIC.EDU for the
numerical IP address when issuing commands to open a session on
the MVS/CAS system.  For example, if you ordinarily open a session
by typing the command "tn3270 131.193.163.4", use the command
"tn3270 uicmvsa.aiss.uic.edu" instead.

In addition, all references to the ACN's old numerical IP address
(131.193.163.4) in batch files, login scripts, telnet
configuration files, and user documentation should be replaced
with the host name UICMVSA.AISS.UIC.EDU.  This step is especially
important because, during the transition of moving the ACN's
telnet server from the VM/PROFS machine to the MVS/CAS system last
year, there was initially a problem accessing the latter system
with the host name.  Thus, many network administrators and end-
users may have quite intentionally configured their software to
use the IP address in order to bypass this problem.  However, the
domain name problems of the MVS/CAS computer have long since been
resolved, and now the use of the hostname is desirable, if not
imperative.

The new IP address for the MVS/CAS system will be announced in
January, but AISS will continue to discourage clients from using
it, except in cases where there is a temporary problem with the
domain name service.  Finally, these changes will in no way affect
ftp and outgoing telnet sessions on the VM/PROFS system.  Nor will
it affect the Internet or BITNET electronic mail addresses of
PROFS users.

-Lynn Ward

******************************************************************


       CCSO Beefs Up Network Support Staff and Services

UIUCnet is no longer just a tool for engineers and computer
scientists.  Thousands of students, faculty, and staff use the
network every day for routine activities.  CCSO is increasingly
aware of the need to provide high-quality support services to end-
users and network administrators.  Two new staff members, David
Ruby and Steven Hinkle, were hired this fall to augment existing
support staff.

David Ruby, a U of I graduate with a major in Spanish and minor in
computer science, comes to CCSO from the UIUC College of Liberal
Arts and Sciences, where for two years he served as the network
administrator for one of the largest and most complex in-building
networks on campus--the 400+ node network in Lincoln Hall.  While
managing the Lincoln Hall site, Dave worked extensively with PCs
and Macs on Token Ring, Ethernet, and LocalTalk networks.  David
is now part of CCSO's User Services group and holds the title
Research Programmer/Network Consultant.  Currently, he is
assisting Randy Cotton, network consultant for the Network Design
Office, with a backlog of troubleshooting requests.  Dave's
responsibilities at CCSO will evolve as needs dictate.  It is
anticipated that he will be a primary source for the support and
training of network administrators.  Dave will also provide
information and instruction to CCSO's full and part-time
consultants in order to keep them up to date on network
applications and technologies.

Steven Hinkle, CCSO's other new hire, will concentrate on the end-
user side of networking.  Steven, now a Research
Programmer/Systems Consultant for User Services, received his B.S.
in computer science from the University of Buffalo in August of
'92.  At Buffalo, while working toward his degree, he also served
as a consultant for a variety of computer systems, including PCs
and Macs, IBM CMS mainframes, DEC VAX clusters running VMS, and
Sun clusters running SunOS.  As a newcomer to the U of I and CCSO,
Steven is still in the process of acquainting himself with our
network, systems, and services.  His role in User Services will
include offering short courses for end-users on how to use the
network, writing end-user documentation, consulting on network-
related problems, and supporting popular network applications for
PCs and Macs such as NCSA Telnet, Eudora, NUPop, Trumpet, etc.

David and Steven make a fine complement to CCSO's existing network
support staff, Randy Cotton of the NDO, Declan Fleming and Leslie
Rankin (manager and assistant manager of the CCSO sites), and the
many CCSO staff members involved with LAN maintenance.  Recently,
Declan has been working with faculty to make instructional
software available at CCSO's networked sites.  He also started a
Novell Users group, which provides a forum for Novell LAN
administrators to share information and discuss specific topics of
interest (for more information on the Novell Users group, send e-
mail to Declan at [e-mail]).

CCSO systems consultants are also spreading the gospel of UIUCnet.
Through a relatively new "outreach" program, consultants are
providing on-site seminars to faculty and staff about the services
and applications available on UIUCnet, with an eye toward offering
special courses on how to use the network for teaching and
research.  Meanwhile, CCSO managers are taking a fresh look at how
to best meet the ongoing network support needs of this campus.
Their goal is to develop a flexible, well-rounded program that
will maximize the effect of CCSO's support and training efforts.

-Lynn Ward

******************************************************************

        MacTCP 1.1.1 Available at CCSO Resource Center

This fall, Apple Computer rolled out several new models of desktop
and portable computer and, with them, an incremental upgrade of
the Macintosh operating system.  The new OS, called System 7.1,
reportedly offers better font handling, improved stability and
performance, improved support for new CPUs (so that system
upgrades are not required when new products are introduced), and
the incorporation of Apple's multimedia technology known as
QuickTime.

One thing that System 7.1 does not offer, however, is
compatibility with MacTCP versions 1.1 and earlier.  MacTCP,
Apple's implementation of the TCP/IP protocol suite, provides a
standard interface for developing TCP/IP-based software (e.g.,
NCSA Telnet, Fetch, Eudora, etc.) for the Mac.  Virtually every
Macintosh connected to the campus backbone has a copy of MacTCP
installed in its System folder as a control panel device.

To address the compatibility problem between System 7.1 and
MacTCP, Apple has released MacTCP 1.1.1.  MacTCP 1.1.1 is
available free to University staff and students through a product
site license.  All UIUCnet users who have ordered or received a
new Macintosh with System 7.1 pre-installed, as well as users who
have upgraded an older Mac to System 7.1, should obtain and
install this latest version of MacTCP.  The software is available
on all of the Macintoshes in the CCSO Resource Center, 1420 DCL.
It is located in the AppleShare volume called "RC_MACs" in the
folders "/Public/Communications/Eudora 1.3b109/Mac TCP Software"
and "/Public/Communications/Network/Mac TCP/ver 1.1.1."  Remember
to bring your own floppy disks (double-sided, double density will
do) to copy the files.

According to a press release, in addition to providing
compatibility with System 7.1, the new MacTCP offers "better
support for extension products, such as AppleTalk Remote Access
(ARA), SLIP (Serial Line IP) and PPP (Point-to-Point Protocol)
drivers, as well as support for larger 'Hosts' files."

Installing MacTCP 1.1.1 for the First Time
------------------------------------------
If you don't already have a copy of MacTCP on your system (as will
be the case for individuals who have purchased new Macs), ask your
building network administrator to assist you with the installation
of the software.  He or she can help you determine whether your IP
address will be static or server-allocated and whether the address
needs to be registered with the UIUCnet hostmaster (the person who
keeps track of IP addresses and domain names for all systems
attached to UIUCnet).

Upgrading to MacTCP 1.1.1
-------------------------
Mac TCP 1.1.1 is downwardly compatible with earlier versions of
the Macintosh operating system and can be installed on Macs
running System 6.x, 7.0, and 7.0.1.  Before installing the new
version of MacTCP, open your existing copy of MacTCP through the
Control Panel and record the current settings of the software.
First, if there is a LocalTalk icon and an Ethernet icon in the
MacTCP window, note which one is selected.  If the LocalTalk icon
is selected, record the name of the AppleTalk zone that appears
beneath it (if a name appears).  Then, write down the number given
as the "IP Address."  Click on the "More..." button and you should
see a window that looks like Figure 1 on this page.  Write down
the information entered in the boxes labeled "Obtain Address,
Routing Information," "IP Address" (class and subnet address), and
"Domain Nameserver Information."  All of this information must be
entered in the new version of MacTCP when you install it.

Once you have recorded this configuration information, you can
throw the files named "MacTCP," "AdminTCP" and "MacTCP Prep" in
the Trash (you may, however, want to first copy these files to a
floppy disk in case your installation runs amuck).  Then, copy the
new "MacTCP" and "AdminTCP" files into your System folder.  For
Macs running System 7 or higher, place the files in the Control
Panels folder within your System folder.  Once the new files are
in place, open MacTCP though the Control Panel and configure the
software to match the settings you recorded from your previous
version.  If you have any problems with the installation or you
install it and discover that your network applications do not
work, contact your building network administrator for assistance.

- Lynn Ward

******************************************************************


             Customizing Telnet Sessions on a PC

Although telnet, the TCP/IP remote login application, is probably
one of the first pieces of software to which new UIUCnet/Internet
users are introduced, very few people have the time or inclination
to learn about and exercise all of the options available in the
software.  In fact, it's probably safe to say that most people on
campus don't even have the complete documentation for the version
of telnet they use.  This is unfortunate.  While you may not have
time to read the manual from cover to cover, browsing the table of
contents or index could expose you to some features that you might
find very useful.  This month's Net Tip focuses on customizing the
telnet environment on a DOS-based PC so that you can easily
connect to a specific host without having to remember its full
domain name or IP address and preconfigure various session
parameters with such hosts.  (In the next issue of UIUCnet, we
will look at the equivalent procedures for the Macintosh.)

About the Config.tel File
----------------------
Normally, unless someone has carefully preconfigured your telnet
software for you, when you open a remote login session with NCSA
or Clarkson Telnet, you must type the name of the executable file
that starts the telnet software followed by the full domain name
or IP address of the remote host (e.g., "telbin
ux1.cso.uiuc.edu").  Additionally, the screen colors, keyboard
mappings, scrollback settings, echo mode, and other parameters
will be the same for every session.  You can simplify the login
process and customize the parameters that govern the sessions with
specific hosts by modifying the telnet configuration file called
"config.tel."

The config.tel file is a plain text file that contains the default
settings used by the Telnet software.  The format of the file is
quite straightforward.  Lines that contain a parameter name
followed by an equal sign and a value (in the form "keyword=
value") are read and used by the Telnet software (and related
utilities) when opening a session and communicating with a remote
host.  The meaning of each parameter is described in detail in the
user's manual and briefly in a comment on the same line in the
config.tel file.  Lines or parts of lines that begin with a pound
sign (#) are comments.

The beginning of the config.tel file contains important
information about the network configuration of your machine and
default settings for the Telnet software. Many of these parameters
were probably preset by your network administrator (or whoever
installed the software), and it's generally best not to fuss with
them if your software is working properly.  Somewhere toward the
middle of the file, however, you should see groups of lines with
each group headed by a line beginning with the keyword "name"
(e.g., name=ux1)  Each of these groups describes the parameters
to be used when communicating with a specific machine on the
network and the keyword "name" is used as a delimiter to separate
one machine-specific entry from the next (as well as to provide a
short, descriptive name for each system, which can be used in lieu
of its IP address or domain name).  Generally, the first "name"
entry begins with the text "name=default."  This entry contains
the default values used for any session that doesn't have a
specific "name" entry in your config.tel file and also determines
the settings of parameters that are not otherwise specified in a
named entry.  If you are not satisfied with the default values for
screen colors, the scrollback mode, the default keyboard map,
etc., you can change them.  Any changes you make will affect all
sessions that do not have a specific entry in your config.tel
file.

Following the default settings for telnet, you should see several
other machine-specific entries in your config.tel file.
Remember, each machine-specific entry begins with the line
"name=value" where value is replaced with a descriptive name for
the system.  The parameters following the keyword "name" may be on
separate lines, or they may be on the same line, each separated
from the next by a semi-colon, colon, or space.  In addition to
the systems already specified in your config.tel file, you can add
entries for the machines you access on a regular basis.  The
example in Table 1 shows three machine-specific entries in a
config.tel file (with comments)--one for accessing the on-line
library system (beginning with "name=library"), one for accessing
the CCSO Unix machine ux1 (beginning with "name=ux1") , and one
for accessing the CCSO IBM mainframe VMD (beginning with
name=vmd).

Table 1: Machine-Specific Entries in a Sample Config.tel File

name=library                   #descriptive name for library
                               #system
host="garcon.cso.uiuc.edu:625" #domain name and port number
                               #of library system
hostip=128.174.5.58            #IP address of library system
nfcolor=WHITE                  #screen color settings for all
                               #sessions with library
nbcolor=blue
rfcolor=red
rbcolor=cyan
ufcolor=black
ubcolor=white
scrollback=200
name=ux1                       #descriptive/short name
                               #for ux1
hostip=128.174.5.59            #IP address for ux1
erase=backspace                #backspace key functions as
                               #standard backspace
copyfrom=library               #borrow other parameters from
                               #entry named library
name=vmd                       #descriptive/short name
                               #for VMD
host=vmd.cso.uiuc.edu          #domain name for VMD
keymap=vmd.tbl                 #use custom keyboard map file
                               #called vmd.tbl for this
                               #session.

Once you have added machine-specific entries to your config.tel
file, you can access these systems by typing the name of your
telnet executable file followed by the value entered for the name
of the entry.  For example, to open a session with the library,
you could type: "telbin library".  The Telnet software will look
in your config.tel file for an entry with the name "library" and
use the parameters specified after name=library until it
encounters the next "name=value" entry in the file--in the case of
our example, "name=ux1."  Note that the entry for VMD only
contains values for "name," "host," and "keymap."  When parameters
are not specified in an entry, the values defined in the entry
"name=default" will prevail.  Thus a machine-specific entry can be
very brief, containing only values for the keywords "name" and
"host" or "hostip;" or the entry can be quite extensive,
containing custom values for every possible parameter.

You can add as many machine specific entries to your config.tel
file as you like.  Most users find it convenient to add the names
of systems that they access regularly via telnet or ftp.  A list
and description of some of the parameters that you can include in
each entry are given in Table 2.  The list is taken from the
config.tel parameters for Clarkson Telnet (CUTCP) version 2.2D.
If you use NCSA Telnet 2.3, you will notice some slight
differences in the way certain parameters are handled.  Consult
the user's manual for the complete list of machine-specific
parameters for each application.

Table 2: A Partial List of Machine Specific Parameters for the
Config.tel File

Parameter                          Description
---------                          -----------
name=value                         User-assigned name for
                                   system.  Replace value
                                   with a short name you can
                                   remember easily.

host=fully.qualified.domain.name   The domain name for the
                                   system you want to reach.
                                   Replace fully.qualified.
                                   domain.name with the
                                   actual domain name of the
                                   host you want to contact.
                                   If you want to designate a
                                   port number as well,
                                   separate it from the
                                   domain name with a colon
                                   and surround the entire
                                   value with double
                                   quotation marks (e.g.,
                                   host ="garcon.cso.
                                   uiuc.edu:625").

hostip=###.###.###.###             The IP address of the host
                                   you want to contact.  If
                                   the IP address is not
                                   included, telnet will
                                   contact one of the
                                   nameservers listed in your
                                   config.tel file to resolve
                                   the domain name given with
                                   the host parameter.
                                   Including the IP address
                                   will generally speed up
                                   the time it takes to
                                   connect to the specified
                                   host.

erase=(backspace or delete)        Determines the function of
                                   the backspace key for the
                                   session.  Some hosts
                                   prefer the backspace key
                                   to be delete and others
                                   prefer the backspace key
                                   to be backspace.  Set this
                                   parameter to erase=
                                   backspace or erase=delete.

scrollback=numeric value           Determines the number of
                                   lines that can be viewed
                                   in scrollback mode.
                                   Scrollback uses 86 bytes
                                   per line saved.  Set your
                                   scrollback value to a
                                   small number if you are
                                   concerned about running
                                   out of memory.  The
                                   typical range is 100 to
                                   200 (e.g., scrollback=
                                   200).


                                   The following parameters
                                   set the screen colors for
                                   the session.  Possible
                                   colors are black, green,
                                   blue, magenta, cyan, red,
                                   yellow, and white.  When
                                   typed in upper case,
                                   foreground colors will
                                   appear in high-intensity
                                   and background colors will
                                   blink.

nfcolor=color                      normal foreground color
nbcolor=color                      normal background color
rfcolor=color                      reverse foreground color
rbcolor=color                      reverse background color
ufcolor=color                      underline foreground color
ubcolor=color                      underline background color

copyfrom=name                      Causes the session to use
                                   the same parameters
                                   specified in another named
                                   session in the config.tel
                                   file.  For example,
                                   copyfrom=ux1 would cause
                                   the current entry to use
                                   the same parameters as
                                   those specified for the
                                   session named ux1 unless
                                   alternative parameters
                                   were explicitly
                                   designated.

keymap=filename.tbl                Uses the custom keyboard
                                   mapping as specified by
                                   the value entered for
                                   filename.tbl.  Clarkson
                                   Telnet provides the user
                                   with a default keymap for
                                   vt100 sessions and a 3270
                                   keymap for tn3270
                                   sessions.  The user can
                                   create additional custom
                                   keyboard mappings and
                                   associate them with a
                                   particular session by
                                   using this parameter.
                                   Otherwise "default.tbl"
                                   will be used for sessions
                                   using vt100 emulation and
                                   "tn3270.tbl" for sessions
                                   using 3270 emulation.

Editing the Config.tel File
------------------------
The config.tel file can be edited with a plain text editor or word
processor.  If you use a word processor such as WordPerfect or
Microsoft Word, you must export the edited file to ASCII format
when saving your changes, in order to remove any application-
specific codes that may have been added to the file by your word
processor.  Here are some additional pointers to keep in mind when
editing the file:

- Before editing any line in your config.tel file, be sure to make
a copy of the original file with a name like config.old or some
other unique name (do not use the name config.bak because your
text editor may use it as a default backup name, and you could
potentially overwrite your original during the editing process).
Taking this precaution will enable you to resurrect your original
telnet configuration in the event that your modifications cause
Telnet to malfunction.

- Do not modify or delete any line in the config.tel file if you
are uncertain about its function.

- In the machine-specific section of the file you are likely to
encounter entries with parameters such as "nameserver=#" and
"gateway=#."  These entries have probably been preconfigured by
the person who installed your telnet software and should not be
changed unless you are certain that they are incorrect.  The
"nameserver" entries instruct telnet to ask specific machines on
the campus net to translate domain names into IP addresses.  The
"gateway" entry specifies the address of the machine that connects
your building network to the campus backbone.

- If a comment wraps around to a second or third line, be sure
that each line begins with a pound sign (#).

- Even if you do not have a copy of the entire Telnet user's
guide, have the section pertaining to the config.tel file on hand
for reference as you make your changes.

- Finally, editing a config.tel file for the first time can be a
little intimidating.  If you are uncertain about what you are
doing, your building network administrator can probably provide
some assistance.  Additionally, the CCSO microcomputer consultants
are well-versed on Clarkson and NCSA Telnet and can be reached at
244-0608.

- Lynn Ward

******************************************************************

              Navigating and Using the Internet:
                A Hands-on Course with a Heart


A new course will be offered through the Graduate School of
Library and Information Science this spring: "LIS450CC, Advanced
Problems in Librarianship--Telecommunications."  The course
combines the learning of real-world skills for navigating the
Internet with a survey of the major uses of and issues related to
the Internet.  Professor Greg Newby will teach the course.  Newby,
who presented a similar course at Syracuse University, also hopes
to offer LIS450CC to students at remote networked sites through
UIUC's extramural program in the fall of '93.

Professor Newby's course will concentrate on computer networking
as a medium for human communication.  Familiar forms of human
communication--the telephone, postal service, and face-to-face
interaction--will be compared and contrasted with networked
communication.  Computer networking shares qualities with
traditional communications media, but also has important
differences. The norms and standards of networked communication
are not yet well established, and the channels of communication--
for example, ftp, mailing lists, and various information services-
-are not always easy to understand and/or access.

A thread that runs throughout the course is the rather gray area
of what constitutes acceptable and unacceptable behavior on the
Internet.  For spoken communication and the printed word, there
are both well-defined social rules for interaction and a body of
law to deal with transgressions.  In the datasphere, however, few
laws exist and the norms of conduct are still being formed.  A
class session will be devoted to topics such as the Morris
Internet Worm and the West German hacker who was caught by Cliff
Stoll.  These and other examples will lead to discussions about
how the end-user can better recognize and be prepared to deal with
situations requiring ethical judgment within a networked
environment

During the first seven sessions, students will spend about half of
each class in a computer lab acquiring hands-on experience.  The
Unix operating system, electronic mail, and other basic network
tools such as telnet and ftp will be covered in detail.  Students
will also have the opportunity to investigate more specialized
applications, such as Gopher, the World-Wide Web (WWW--a hypertext
application used for locating and accessing information on the
Internet), WAIS, Archie, and Hytelnet (a hypertext application for
facilitating telnet sessions with on-line library catalogs and
information servers).

Throughout, the focus is on using network-based resources to
extend each student's personal and professional information
resources. Students will be encouraged to identify ftp sites,
databases, or mailing lists and newsgroups containing information
pertinent to them.  They will also be encouraged to interact with
their peers or experts in various fields by using network tools,
and to consider the electronic dissemination of their thoughts,
findings, and papers.

The balance of the course is a survey of various perspectives on
computer networking.  First, a foundation in human communication
theory and practice will be laid, and, from there, various aspects
of computer networking will be addressed.  The history of
networking and many types of computer networks and protocols for
data transfer will be treated in detail.  Corporate communication,
information storage and retrieval services, and public access to
networked services will also be covered.  Finally, the course will
address questions about the future of computer networking--e.g.,
how NREN (the National Research and Education Network) and an
increased network presence in libraries and K-12 schools might
change the users and uses of Internet.

LIS450CC will meet on Mondays from 12:00P3:00 p.m. during the
spring semester.  Non-LIS grad students and auditors are invited
to attend, space permitting.  Many of the readings for the course
as well as the syllabus may be obtained via anonymous ftp from the
host "gpx.lis.uiuc.edu".  These materials are located in the
directory "pub/netinfo".  Specific questions about the course can
be directed to [e-mail].

- Greg Newby


.