+ Page 1 + ----------------------------------------------------------------- The Public-Access Computer Systems Review Volume 4, Number 2 (1993) ISSN 1048-6542 ----------------------------------------------------------------- To retrieve an article file as an e-mail message, send the GET command given after the article information to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet). To retrieve the article as a file, omit "F=MAIL" from the end of the GET command. CONTENTS COMMUNICATIONS The University of Minnesota's Internet Gopher System: A Tool for Accessing Network-Based Electronic Information By Rich Wiggins (pp. 4-60) To retrieve this file: GET WIGGINS1 PRV4N2 F=MAIL GET WIGGINS2 PRV4N2 F=MAIL This article describes the Internet Gopher: why it is needed, how it is used, its genesis and early evolution, the underlying protocol (and the new Gopher+ protocol), Gopher's role as a campus-wide information system (CWIS), and its emerging role as an Internet-wide information system. The article also discusses navigational enhancements (e.g., Veronica), organization and quality of service issues, privacy and security concerns, electronic publishing issues, distribution of multimedia information, related client and network information technologies, and Gopher's future. COLUMNS Casting the Net Cataloging Internet Resources By Priscilla Caplan (pp. 61-66) To retrieve this file: GET CAPLAN PRV4N2 F=MAIL + Page 2 + ----------------------------------------------------------------- The Public-Access Computer Systems Review ----------------------------------------------------------------- Editor-in-Chief Charles W. Bailey, Jr. University Libraries University of Houston Houston, TX 77204-2091 (713) 743-9804 LIB3@UHUPVM1 (BITNET) or LIB3@UHUPVM1.UH.EDU (Internet) Associate Editors Columns: Leslie Pearse, OCLC Communications: Dana Rooks, University of Houston Reviews: Roy Tennant, University of California, Berkeley Editorial Board Ralph Alberico, University of Texas, Austin George H. Brett II, Clearinghouse for Networked Information Discovery and Retrieval Steve Cisler, Apple Computer, Inc. Walt Crawford, Research Libraries Group Lorcan Dempsey, University of Bath Nancy Evans, Pennsylvania State University, Ogontz Charles Hildreth, University of Washington Ronald Larsen, University of Maryland Clifford Lynch, Division of Library Automation, University of California David R. McDonald, Tufts University R. Bruce Miller, University of California, San Diego Paul Evan Peters, Coalition for Networked Information Mike Ridley, University of Waterloo Peggy Seiden, Skidmore College Peter Stone, University of Sussex John E. Ulmschneider, North Carolina State University Technical Support Tahereh Jafari, University of Houston + Page 3 + Publication Information Published on an irregular basis by the University Libraries, University of Houston. Technical support is provided by the Information Technology Division, University of Houston. Circulation: 6,403 subscribers in 56 countries (PACS-L) and 1,428 subscribers in 42 countries (PACS-P). Back issues are available from LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet). To obtain a list of all available files, send the following e-mail message to the LISTSERV: INDEX PACS-L F=MAIL. The name of each issue's table of contents file begins with the word "CONTENTS." The first two volumes of The Public-Access Computer Systems Review are also available in book form from the American Library Association's Library and Information Technology Association (LITA). The price of each volume is $17 for LITA members and $20 for non-LITA members. To order, contact: ALA Publishing Services, Order Department, 50 East Huron Street, Chicago, IL 60611-2729, (800) 545-2433. ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive two electronic newsletters: Current Cites and Public- Access Computer Systems News. The Public-Access Computer Systems Review is Copyright (C) 1993 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. ----------------------------------------------------------------- + Page 61 + ----------------------------------------------------------------- Casting the Net ----------------------------------------------------------------- ----------------------------------------------------------------- Caplan, Priscilla. "Cataloging Internet Resources." The Public- Access Computer Systems Review 4, no. 2 (1993): 61-66. To retrieve this file, send the following e-mail message to LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET CAPLAN PRV4N2 F=MAIL. ----------------------------------------------------------------- Let Archie Do It? How do we accommodate networked electronic information when our cataloging rules are designed to describe physical items owned by and residing in libraries? How do we provide access to that information? Do we let Archie do it instead? Questions like these must be addressed before we can move into the future and provide our patrons with information the way they are coming to expect it. It isn't sufficient that we simply debate these issues at conferences and write about them in the literature. Action is needed, and well-established rules and practices must be changed. All of that is easy to agree with, but deciding how to change established rules and practices is another matter, not to mention actually revising them. What Are Online Information Resources? MARBI is an ALA committee that advises the Library of Congress on additions and changes to the USMARC formats. Usually, MARBI deals with issues like where to record the International Standard Music Number and whether to add new coded values for Betacam videocassettes to the Physical Description Fixed Field. Last winter, however, a new proposal generated quite a bit of attention. Proposal 93-4 recommended changes to the bibliographic format to accommodate electronic data resources such as e-journals and documents available over the Internet. + Page 62 + Proposal 93-4 can trace its roots back to the summer of 1991 when MARBI Discussion Paper 49 proposed a set of data elements that might be useful in describing online information resources. Discussion of that paper, however, revealed some uncertainty about exactly what was being described. Was "online-ness" the salient quality, and if so, what did it mean to be online? Was it network accessibility? The property of being in electronic form? Over the next year, some progress was made in sorting these things out. It became clear, for example, that remote access was the defining and unifying quality of these materials--the fact that they could not be held in the hand, physically described, pointed to on a shelf, or checked out to patrons. It was also agreed that for the sake of simplicity the universe of remotely accessed entities could be divided into two categories: (1) data resources (e.g., software, text and data files, and bibliographic databases) and (2) systems or services (e.g., campus-wide information systems, library catalog systems, and bulletin boards). A rough but intuitive analog might be those things that one could FTP and those to which one could Telnet. Since electronic data resources more closely resemble what libraries are accustomed to cataloging than online systems do, MARBI decided in the winter of 1992 to concentrate on these first. Joint Cataloging Project Meanwhile, OCLC's Office of Research had received a grant from the Department of Education to investigate the nature of electronic information available over the Internet. OCLC's project staff had already collected and categorized more than 1,500 files. In the spring of 1992, representatives from the OCLC Internet Resources Project, MARBI, the Library of Congress, and the Online Audiovisual Catalogers teamed up for an experiment in cataloging electronic data resources. The group started with the hope that the existing USMARC computer files format could be used for remote data resources without too many modifications. This may sound simple, but for historical reasons the computer files format is surprisingly limited in its ability to describe computer files. It was originally designed with only a single type of file in mind--statistical data sets like Harris survey responses or the census. Later it was expanded to handle the microcomputer software that libraries had begun to collect. As such, it's like a house with only two rooms: a kitchen and a bedroom. OK until you want to take a bath. + Page 63 + Anyway, the project group took a sample of 300 data resources (mostly documents), drafted some preliminary cataloging guidelines, and sent the samples and guidelines to 30 volunteer catalogers so that each resource would be cataloged independently by three different catalogers. The volunteers were instructed to use the USMARC computer files format and AACR2 cataloging rules as best they could, and to keep a log of their particular problems, questions, and suggestions. The results were then compared, analyzed, and used to indicate where people were confused and where the format or the rules were deficient. The end products were a revised, more extensive set of cataloging guidelines and some recommended changes to the computer files format in the form of MARBI Proposal 93-4. Recommended Changes The recommended changes to the format for descriptive purposes were not extensive, but they required a modification to the cataloging rules. An existing MARC field called "File Characteristics" (256) is governed by AACR2 Chapter 9, which specifies that one of three terms must be used: "computer data," "computer program(s)," or "computer data and program(s)" (kitchen, bedroom, kitchen and bedroom). Proposal 93-4 recommended extending the set of allowable terms to include such descriptors as "electronic document," "electronic journal," "bibliographic database," "graphic," and "computer sounds." (A parallel set of coded values was defined in a fixed field data element to allow retrieval or reporting by these same concepts.) The rationale was simply to give brief, clear, descriptive information to the library patron, who might not intuitively think of an e-journal, for example, as "computer data." Alas, expansion of the "File Characteristics" field was not approved by MARBI, on the grounds that the cataloging change must precede the format change. The issue was referred to CC:DA, another ALA committee that stands in very roughly the same relation to the cataloging rules as MARBI does to the USMARC format. As far as I know, CC:DA has not yet pronounced on this issue. Meanwhile, "computer data" it is. + Page 64 + The biggest change proposed in Proposal 93-4 was not for the purpose of description but rather of location. In effect, it was decided that FTP sites, list servers, and the like constituted electronic locations that conceptually parallel physical ones. The paper form of a document might be on a shelf in a library, while a bitmapped form might be available from a file server on the Internet. A new field was invented for "Electronic Location and Access" (856), including data elements for type of access (e.g., e-mail, FTP, and Telnet), host name, path name, file name, and similar information necessary to access or retrieve a data resource over the network. Although much more radical an idea than the expanded list of file characteristics, this recommendation was independent of cataloging rules and so passed in slightly modified form at the January 1993 MARBI meeting. The "Electronic Location and Access" field is now formally part of the USMARC format. Points to Ponder At this point, it might be a good idea to pause and ask ourselves some questions. First, does it make sense for libraries to be cataloging Internet materials to begin with? Even if it does, is MARC the way to go about it? In fact, a vast number of data resources are available via the Internet, most of them uncontrolled, unverified, and of limited or ephemeral interest. (PACS-L readers may be reminded of the recent flap over an incomplete version of the Periodic Table.) Libraries are likely to have interest in only a small subset of this universe. For this subset, however, network access may actually be used to replace or supplement library ownership and physical access. Certainly, libraries will want these materials fully described. Similarly, such description or cataloging should be available in the same online catalog systems as the rest of the libraries' holdings, which implies that the records should be in the same format and follow the same rules as other bibliographic data. + Page 65 + Won't network tools like Archie and Gopher supersede library catalogs for electronic data resources? These are wonderful tools, but they do have limitations we wouldn't tolerate for more traditional library materials. To quote another MARBI discussion paper (No. 69, April 30, 1993): Many do not give you any indication of which servers they actually searched and which were unavailable for one reason or another. They do not discriminate between various versions of data in terms of usefulness or completeness. They are poor at locating known items, as opposed to possibly relevant things. In addition, the subject analysis available in USMARC records is lacking in these other tools. . . . Such tools could complement rather than replace USMARC records as a source for locating online objects. But electronic addresses change often as documents move from server to server and from format to format. Does it make sense to actually imbed location information in the descriptive record itself? Well, probably not. In fact, the Internet Engineering Task Force is working on a much more efficient scheme. A Universal Resource Identifier (URI)--much like the ISBN--would be assigned to each object by the originating agency. A Universal Resource Locator (URL), similar in concept to the Electronic Location and Access field, would identify a location. Only URIs would be imbedded in the bibliographic description, and computers would associate the URI with one or more URLs in much the same way an Internet host name (HARVARDA.HARVARD.EDU) is associated with its IP address (128.103.60.11) by the name server system. However, someone needs to do all this; an infrastructure needs to be developed and responsible agencies in agreement on responsibilities and procedures. Once this mechanism is in place, we can decide what to do next with the Electronic Location and Access field. Meanwhile, it allows us to begin building records and testing the feasibility of catalog access to electronic data resources. Finally, can we really separate data resources from systems/services? Is there a distinction between a database and the retrieval system required to access it? Probably not. Although a useful distinction to get the project going, the line between these concepts was fuzzy to begin with and gets fuzzier the more you think about it. + Page 66 + Next Steps The next step is clearly to try to accommodate online systems and services in USMARC as well. Some of the relevant data elements such as hours of service and cost for use don't currently exist in the bibliographic formats, but they are defined in the new USMARC Community Information Format. We may end up with a hybrid that seems "bibliographic" in some respects and like a program or agency in others. Discussion Paper no. 69, "Accommodating Online Systems and Services in USMARC," addresses these issues. It will come up for discussion when MARBI meets at the ALA annual conference in New Orleans. You can request the paper by sending this e-mail message: GET DP69 DOC to LISTSERV@MAINE.MAINE.EDU. Or, as the Electronic Location and Access field would have it: 856 0 $a maine.maine.edu $f dp69 doc $h listserv $i get About the Author Priscilla Caplan, Head, Analysis and Programming Division, Office for Information Systems, Harvard University Library. Internet: COTTON@HARVARDA.HARVARD.EDU. ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive two electronic newsletters: Current Cites and Public- Access Computer Systems News. This article is Copyright (C) 1993 by Priscilla Caplan. All Rights Reserved. The Public-Access Computer Systems Review is Copyright (C) 1993 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. ----------------------------------------------------------------- + Page 4 + ----------------------------------------------------------------- Wiggins, Rich. "The University of Minnesota's Internet Gopher System: A Tool for Accessing Network-Based Electronic Information." The Public-Access Computer Systems Review 4, no. 2 (1993): 4-60. To retrieve this file, send the following e-mail messages to LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET WIGGINS1 PRV4N2 F=MAIL and GET WIGGINS2 PRV4N2 F=MAIL. ----------------------------------------------------------------- 1.0 Introduction Late in 1991, a new creature began burrowing its way around the Internet. This new critter helps people browse many of the resources available on local campus networks or on the worldwide Internet. Called the Internet Gopher, this tool was developed at the University of Minnesota. Pioneering sites began deploying Gopher servers in December 1991. In the short time since, the Gopher system (henceforth called "Gopher") has been deployed at many institutions around the world. A worldwide community of "Gophernauts" has come into being, with various sites contributing ideas, utility tools, bits of code, and schemes for cooperative registry efforts. Gopher now accounts for a substantial fraction of the traffic on the Internet. Gopher servers are delivering text, index searches, still images, audio, public domain software, and more to users all over the world. With Gopher, a user can: o Find out what movies are playing in Aachen, Germany. o Learn what earthquakes took place yesterday. o Read today's student newspaper from a school 2,000 miles away. o Pick up a quote from Paradise Lost for a term paper. o Read the city council meeting minutes from Wellington, New Zealand. o Listen to the final U.S. Presidential Debate of 1992. o See what Michigan State's campus looks like in spring. o Read about the Human Genome Project. o Learn about Federal grants. o Download public domain software. + Page 5 + The above examples are a tiny sample of the kinds of information Gopher can deliver. An illustration of the value of Gopher comes from a user who works at Michigan State University: I wanted to drop a quick line and tell you how much Gopher means to me. I discovered Gopher about two months ago and cannot believe how much information is out there. I have found the new Veronica option very helpful as it allows me to build a directory of items that are specific to my interest. This is undoubtedly a great service for anyone who finds it. However, for me it is unbelievable. I am legally blind and I have always said that the most difficult aspect of blindness is the lack of readily available information. Gopher has the ability to change all of that. For the first time, I feel like I can easily and independently access important campus and worldwide information. . . . I use a speech synthesizer and a PC compatible computer to access the Gopher system. This article describes the Internet Gopher: why it is needed, how it is used, its genesis and early evolution, the underlying protocol (and the new Gopher+ protocol), Gopher's role as a campus-wide information system (CWIS), and its emerging role as an Internet-wide information system. The article also discusses navigational enhancements (e.g., Veronica), organization and quality of service issues, privacy and security concerns, electronic publishing issues, distribution of multimedia information, related client and network information technologies, and Gopher's future. 2.0 The Internet and the Need for Navigation Tools Today, many computer users at universities, government agencies, and commercial firms are connected in one way or another to the Internet. The Internet is a worldwide network of networks. Campus Ethernets and other local area networks are connected together by a complex web under the aegis of regional networks, national networks, or in some countries, the PTTs (postal/telephone authorities). The constituent networks all use the TCP/IP protocol family; the result is a worldwide network of computers that can communicate with one another. The Internet evolved from the old Defense Advanced Research Projects Agency network (ARPANET). ARPANET sites consisted mainly of Department of Defense research installations and affiliated research institutes and universities. Many thousands of host computers and user workstations now have Internet connectivity. The number of computer users with Internet access is estimated to exceed 10 million. + Page 6 + As a "network of networks," the Internet can be thought of as the aggregation of various campus, corporate, and other networks. Other than following certain rules known as "acceptable use policies," institutions on the Internet are generally autonomous. Therefore, services that are offered on these campus networks are provided because some local service provider believes it's worthwhile to do so. Often, the motivation is to serve local users. For example, a campus library puts its online catalog on the campus network for the sake of local patrons, not primarily for the benefit of Internet users. As multiple campuses mounted similar services to satisfy the needs of their own communities, Internet users began to find value in using online resources from other institutions. For instance it might be useful to scan the online catalog of a partner interlibrary loan institution. But without a list of host names (or IP addresses) of the various online catalogs on the Internet, each individual user has to maintain his or her own listing: picture a wall of Post-it notes listing names and addresses next to a user's PC. Online catalogs aren't the only list of Internet services a user would want to keep up with; all sorts of services are available on the Internet. Examples include: o List servers and discussion groups. o USENET News (a sort of distributed discussion facility). o Anonymous FTP archives, containing public domain software and other offerings. o Tools and services for finding people. o Host computers that require assigned passwords. o Databases that allow logins via Telnet. o Databases that support the client/server model (the chief example is WAIS). o Archives of electronic journals and books--the nascent virtual library. + Page 7 + The need for an "Internet address book" applies to all of these kinds of services. Several tools are evolving to help bring order to the Internet. Various Internet navigation tools have different goals and capabilities: o HYTELNET provides a hypertext database of online catalogs and other systems. o Archie serves as an index of FTP sites, identifying sites that hold particular files. o WAIS allows users to search one or more databases using natural language queries; it presents ranked search results. o World-Wide Web supports networked hypertext. All of these tools will be discussed later in this paper. For now, the focus is Gopher. In a nutshell, Gopher offers access to files and interactive systems using a hierarchical menu system. The organization of the menu is defined by the administrator of each server. The resources that each menu item describes, such as ASCII files, Telnet sessions to other computers, and submenus, are called "documents." The scope of a Gopher server could be limited to a campus or to a subject area. Or, a Gopher server could include a catalog of a variety of Internet resources. The following section depicts a "walk-through" of "Gopherspace," showing how Gopher operates along the way. 3.0 Overview of Gopher from the User's Point of View Gopher serves as a menu system for networked information. The user connects to one of the thousands of Gopher servers now in production around the world and receives an initial (or "root") menu. When you use a tool like Archie, you are asking the server a specific question (e.g., "Tell me what FTP sites can provide a copy of the program named PKZIP"). When you connect to a Gopher server, you are asking it "Give me a menu listing the resources you have to offer." The menu can include submenus. Each Gopher server presents a hierarchy established by the local administrator. + Page 8 + Gopher follows the client/server model. This model divides the labor between the program the user invokes (the "client") and a program running on a host computer, such as a UNIX workstation or a mainframe (the "server"). It's best to run Gopher with client software installed on the user's workstation because it provides a superior user interface and opens up the world of still images, audio files, and other resources. But a user who has not installed a client can still use Gopher: the developers have provided a sort of central client software, and many Gopher sites offer public client services. The public client software is sometimes known as the "curses" client, after the UNIX screen management tool of that name. Users connect to these public client services via Telnet (or, depending on their local network services, via a VT 100 dial-up session). The following initial tour of Gopherspace will use sample screens from a public client service. This example will connect to the service offered at the home of Gopher, the University of Minnesota. To connect to the public client service at "Gopher Central," one would type the following: telnet consultant.micro.umn.edu gopher [Type "gopher" in response to login prompt.] The user's Telnet program must be capable of VT 100-style full- screen operations (virtually all are). The client service will respond as shown in Figure 1. ----------------------------------------------------------------- Figure 1. Choosing the Terminal Type ----------------------------------------------------------------- TERM = (vt100) [Press Enter at this prompt.] Erase is Ctrl-H Kill is Ctrl-U Interrupt is Ctrl-C I think you're on a vt100 terminal ----------------------------------------------------------------- At this point, the user should hit the Enter key. Having made this connection, the user would see the root menu of the University of Minnesota's Gopher service (see Figure 2). + Page 9 + ----------------------------------------------------------------- Figure 2. The University of Minnesota Gopher's Root Menu ----------------------------------------------------------------- Internet Gopher Information Client v1.12 Root gopher server: gopher.tc.umn.edu --> 1. Information About Gopher/ 2. Computer Information/ 3. Internet file server (ftp) sites/ 4. Fun & Games/ 5. Libraries/ 6. Mailing Lists/ 7. UofM Campus Information/ 8. News/ 9. Other Gopher and Information Servers/ 10. Phone Books/ 11. Search lots of places at the U of M Press ? for Help, q to Quit, u to go up a menu Page:1/1 ----------------------------------------------------------------- As noted above, Gopher presents a hierarchical menu; titles ending in a slash ("/") are submenus (or "subdirectories" or "folders") that list additional choices. For example, if the user presses Enter while the cursor points at the first menu item, a submenu of resources about Gopher will appear. The user can choose among the menu items by using the cursor keys or by typing in the number of the desired menu item. If the menu is longer than will fit on one screen, the "Page: n/m" field in the lower right corner so indicates. After selecting the "Information About Gopher" menu item, Gopher responds with the menu shown in Figure 3. + Page 10 + ----------------------------------------------------------------- Figure 3. Information About Gopher Menu ----------------------------------------------------------------- Internet Gopher Information Client v1.12 Information About Gopher --> 1. About Gopher. 2. Search Gopher News 3. Gopher News Archive/ 4. comp.infosystems.gopher (USENET newsgroup)/ 5. Gopher Software Distribution/ 6. Gopher Protocol Information/ 7. Frequently Asked Questions about Gopher. 8. Gopher+ example server/ 9. How to get your information into Gopher. 10. New Stuff in Gopher. 11. Reporting Problems or Feedback. 12. big Ann Arbor gopher conference picture.gif 13. gopher93/ Press ? for Help, q to Quit, u to go up a menu Page:1/1 ----------------------------------------------------------------- This menu in the University of Minnesota Gopher server is the definitive place to learn about Gopher. Note that menu items for ASCII text files are listed with a period at the end. Upon selecting the first menu item ("About Gopher"), the file shown in Figure 4 would appear. + Page 11 + ----------------------------------------------------------------- Figure 4. About Gopher File ----------------------------------------------------------------- This is the University of Minnesota Computer & Information Services Gopher Consultant service. gopher n. 1. Any of various short tailed, burrowing mammals of the family Geomyidae, of North America. 2. (Amer. colloq.) Native or inhabitant of Minnesota: the Gopher State. 3. (Amer. colloq.) One who runs errands, does odd-jobs, fetches or delivers documents for office staff. 4. (computer tech.) Software following a simple protocol for tunneling through a TCP/IP internet. If you have questions or comments, you can get in contact with the Gopher development team by sending e-mail to: gopher@boombox.micro.umn.edu If you are interested in news about new gopher servers and software you can subscribe to the gopher-news mailing list by sending e-mail to: gopher-news-request@boombox.micro.umn.edu There is also a USENET news discussion group called comp.infosystems.gopher where Internet Gopher is discussed. If you want to get the most recent releases of the gopher software, you can get these via anonymous ftp from boombox.micro.umn.edu in the /pub/gopher directory. Press to continue, to mail: ----------------------------------------------------------------- In the above example, the curses client leaves the text of the selected text file on the screen until the user types Enter. After that, the "Information About Gopher" menu will be redisplayed. Because Gopher is organized hierarchically, you need a way to move back a level in the directory tree. With the public "curses" client the user simply types "u" for "up." No matter how deep in the hierarchy the user travels, the client is able to back up, one menu at a time, until the root menu is redisplayed. + Page 12 + The "Information About Gopher" menu above included a menu item entitled "2. Search Gopher News "; this menu item offers an index search, as denoted by the question mark. Gopher servers generally implement indexing using the public domain WAIS (Wide Area Information Servers) search engine. (A common exception: servers implemented on NeXT workstations often exploit the Digital Librarian delivered with NeXTStep.) Upon selecting this menu item, the user is prompted to enter a keyword (see Figure 5). ----------------------------------------------------------------- Figure 5. Search Gopher News ----------------------------------------------------------------- +-------------------Search Gopher News--------------------+ | | | Words to search for: indiana | | | | [Cancel ^G] [Accept - Enter] | | | +---------------------------------------------------------+ ----------------------------------------------------------------- Note that most Gopher clients will highlight the sought keyword within the text of the displayed document. This makes it easy to find the occurrences of the keyword in context. Searching is not currently as flexible as one would like. In particular, the standard release with the WAIS engine does not provide for Boolean or proximity searches. In November 1992, Don Gilbert of Indiana University announced modifications to the WAIS indexing engine normally used with Gopher servers. His enhancements include Boolean, partial word search, and literal phrase searching. His biology-oriented Gopher (located at ftp.bio.indiana.edu, port 70) allows testing of these search features. Examples of the kinds of searches possible include: o Boolean: red and green not blue. Result: just those records with both the words "red" and "green," excluding all records with the word "blue." o Partial words: hum*. Result: all records with "hum" (e.g., "hummingbird," "human," and "humbug"). + Page 13 + o Literal phrases: red rooster-39. Result: only those records with the full string "red rooster-39" will be retrieved. The scope of a Gopher index is determined by the administrator. The administrator can choose to index one file, all files in a subdirectory, or all files in a directory and its subdirectories. Often a large file is broken up into a series of small files so that it can be loaded into Gopher. This will allow the user to selectively retrieve sections of interest. Usually, the wording of the Gopher menu item makes it clear what the scope of a given index is. It's the administrator's job to make sure this is the case. You can best learn more about Gopher by browsing through various servers: connect to "Gopher Central" (gopher.tc.umn.edu, port 70) and follow the list of Gophers. Alternatively, you might use the global title index at Michigan State's central Gopher to look up these Gopher servers (or any others of interest) by keyword. (The index of Gopher server names is on gopher.msu.edu, port 70; look under the "More About Gopher/Other Gopher Servers" menu item.) Also, you may want to try Veronica (discussed below) as a way to locate specific Gopher documents. 4.0 Gopher Clients Recall that the above examples came from using the public client. The best access to Gopher documents requires use of Gopher client software running on the user's workstation. Gopher clients have been implemented on a variety of platforms. The University of Minnesota keeps an archive of commonly used clients, developed there or elsewhere, on its anonymous FTP service, which is located on boombox.micro.umn.edu. Common clients include: o PC Gopher III--the University of Minnesota's PC client, which was written using Borland's TurboVision. It provides a quasi-graphical interface complete with mouse support. PC Gopher is a relatively large program. Since memory use on networked PCs is tight, the program's size has been problematic. + Page 14 + o UGOPHER--a PC client from the University of Texas Medical School at Houston. It is a port of the UNIX curses client. It provides a very simple interface, but it demands little memory. It supports special data types such as TN3270 and still-image files. o Novell LWP client--a PC client from the University of Michigan Medical School. This client works with Novell's LAN Work Place for DOS. It supports images and audio as well as TN3270. It sports a friendly graphical interface with more options than the standard client. As of this writing, it does not support a mouse. o Gopher Book--a Windows client from the Clearinghouse for Networked Information Discovery and Retrieval. Gopher Book runs under Microsoft Windows and implements a book-like view of Gopherspace. The Gopher community has long wanted a good Windows client; this could be it. (Users may want to FTP to sunsite.unc.edu and look under pub/micro/pc-stuff/ms-windows/winsock for Gopher Book and related tools, such as the Winsock DLL.) o TurboGopher for the Macintosh--a Macintosh client from the University of Minnesota. Various Mac Gophers have been implemented, at the University of Utah, Brown University, and at other sites. TurboGopher appears to be highly functional, robust, and efficient, and it is on its way to superseding the other Mac offerings. o Curses client--a generic client for UNIX workstations. It is also used at many Gopher sites to provide Telnet access to the Gopher world for users who haven't yet obtained client software for their workstations. Users installing the curses client on their UNIX workstations must build the client from source code on the target machine (as is commonly true with UNIX software offerings). A version of this client can also be compiled for use under the DEC VMS operating system. + Page 15 + o NeXT Gopher Client--a NeXT client from the University of Minnesota and the University of St. Thomas. This client makes good use of the NeXT's large windows, and it leaves the last two or more menus on the screen, providing useful contextual information. Recent modifications have been implemented by Jim Lebay of Michigan State (icon support, bug fixes, better handling of windows, and support for image files) and David Lacey of the University of Iowa (support for the MIME protocol). o Xgopher--a client from Allan Tuchman at the University of Illinois that runs under X-based UNIX systems. (The X release must be later than X11 Release 3.) Xgopher supports multiple active items and an easy-to-use graphical user interface. It is highly configurable. A C compiler is needed to build the client for the target user's machine. o Rice University CMS Client--a client that allows users of VM/CMS mainframes to connect to Gopher servers. The host must have outbound VT 100 Telnet to function well when connecting to Unix-based services. (The IBM 3270 terminal protocol does not lend itself well to outbound connections to byte-oriented hosts; check with local support personnel to determine if such access is available at your site.) o MVS Gopher Client--a client from Draper Laboratory for TSO users on MVS mainframes. This client can provide 3270 terminals with access to Gopher services. An experimental OS/2 client has been announced by David Singer of IBM Almaden (look for os2gopher.zip on boombox.micro.umn.edu). Gopher clients vary widely in their appearance and features. The same documents may be displayed to users in quite different form, depending on which client is used. Ultimately, the information is the same, even though the display format varies. (Marshall McLuhan would have a field day.) Some clients allow the user to print an entire document. With the PC client, the document goes to a locally attached printer; however, the NeXT client assumes its printer is a PostScript device, which might be connected over the local Ethernet. Some clients let the user save a document to the local workstation's disk; others allow the user to send a document via e-mail to the destination of choice. + Page 16 + Gopher clients need a way to display files on the user's screen. This can be done by code within the client program itself. Alternatively, the client may launch an external tool, often called a "browser" or a "pager." For instance, UGOPHER has a relatively limited built-in browser. The user can install a superior file display tool, such as the popular shareware tool LIST from Vernon D. Buerg, and tell UGOPHER to use it instead. Similarly, clients may launch separate programs to open Telnet sessions, do CSO searches, play audio files, and so forth. The user must install all the needed external tools and configure the client to use them. Installation instructions are provided with every client. A useful feature in many clients is the "bookmark." Upon finding an item of particular interest, the user sets a bookmark. The client software stores the bookmark on the client workstation's disk. In a later session, the user can call up the list of bookmarks and immediately jump to items of particular interest without having to navigate the menus. Because resources of interest could be buried deep within Gopher servers, the bookmark option lets the user build a customized view of Gopherspace. (Some users have suggested the need for hierarchical bookmarks; the current bookmarks provide a simple flat list.) Most clients also have the ability to save documents themselves on the user workstation. Some information providers have found that Gopher makes a very efficient mechanism for delivering files to users. At least one software archive encourages its users to obtain software via Gopher instead of anonymous FTP. (The Stanford University Macintosh archive, Sumex, suggests users choose Gopher over FTP or other methods.) Gopher was originally written with the assumption that the user would be resident on the Internet, with a permanently assigned IP address, and have client software on his or her workstation. This model does not always provide dial-up users (users dialing in over a phone line using asynchronous ASCII terminal emulators) with the same level of service as on-campus users receive. Many institutions are experimenting with schemes to allow dial-up users to appear to be on the Ethernet, using protocols such as SLIP (Serial Line IP) and PPP (Point-to-Point Protocol). Under SLIP or PPP, the user can run a standard Gopher client, which works as if it were on a local TCP/IP network. (Of course, data is delivered more slowly; even today's high-speed modems don't match local area network speeds.) Because these dynamic IP assignment schemes are relatively new and they are not widely used, traditional dial-up users must usually rely on the public curses client. + Page 17 + In general, users who run Gopher clients benefit from a superior environment and have access to more data types. However, recent versions of the public curses client make it possible for users to download files for viewing outside of their terminal session. To download a file, one strikes a "D" (that's a capital "D"; use lower "d" at your peril, for that says you want to delete a bookmark) with the cursor on the document title. When this option is invoked, the public client service asks the user which protocol to use (i.e., raw text, Kermit, XMODEM, YMODEM, or ZMODEM). Assuming the user's terminal emulator can handle one of these protocols, this allows the dial-up user to obtain a copy of a file, such as a still-image file, that otherwise could not be displayed using the curses service. 5.0 Obtaining a Gopher Client Via FTP A common way to obtain a client is by use of anonymous FTP. The University of Minnesota's software archive resides on boombox.micro.umn.edu. Other sites also maintain their own archives, which may include local fixes or enhancements. In particular, sites may configure clients to point to local Gopher servers by default, or they may make changes to allow the clients to work properly with the local network environment. New Gopher users should consult with local computer support staff to determine where best to obtain a client. The following is an example of obtaining the University of Minnesota's client for MS-DOS (see Figure 6). It assumes that the user has a copy of PKZIP, a popular file compression shareware tool. + Page 18 + ----------------------------------------------------------------- Figure 6. Example FTP Session to Download a Gopher Client ----------------------------------------------------------------- C:\GOPHER: ftp boombox.micro.umn.edu Connected to boombox.micro.umn.edu. Connected to boombox.micro.umn.edu. 220 boombox FTP server (Version 4.1 Tue Apr 10 05:15:32 PDT 1990) ready. Name (boombox.micro.umn.edu:rww): ftp 331 Guest login ok, send ident as password. Password:wiggins.msu.edu 230 Guest login ok, access restrictions apply. ftp> cd pub/gopher/PC_client 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls (0 bytes). total 1352 -rw-r--r-- 1 bin 385 Apr 1 15:43 00readme -rw-r--r-- 1 bin 0 Mar 22 17:29 FTP_THESE_FILES_IN_BINARY_MODE -rw-r--r-- 1 bin 75376 Apr 1 15:43 bmkcvt.exe -rw-r--r-- 1 bin 2151 Apr 1 15:43 bmkcvt.txt -rw-r--r-- 1 bin 370 Apr 1 15:43 gopher.bmk -rw-r--r-- 1 bin 182910 Apr 1 15:43 gopher.exe -rw-r--r-- 1 bin 75711 Apr 1 15:43 gopher.ovr drwxr-xr-x 2 bin 512 Mar 22 17:29 icky_old_client -rw-r--r-- 1 bin 643 Apr 1 15:43 manifest.101 drwxr-xr-x 2 bin 512 Mar 22 17:29 packet_drivers -rw-r--r-- 1 bin 41929 Apr 1 15:43 pcg3.txt -rw-r--r-- 1 bin 62341 Apr 1 15:43 pcg3.worddoc -rw-r--r-- 1 bin 211699 Apr 1 15:43 pcg3.zip -rw-r--r-- 1 bin 2999 Apr 1 15:43 release.101 226 Transfer complete. 838 bytes received in 0.31 seconds (2.66 Kbytes/s) ftp> bin 200 Type set to I. ftp> get pcg3.zip 200 PORT command successful. 150 Opening BINARY mode data connection for pcg3.zip (211699 bytes). 226 Transfer complete. local: pcg3.zip remote: pcg3.zip 211699 bytes received in 6 seconds (34.47 Kbytes/s) ftp> quit 221 Goodbye. C:\gopher: pkunzip pcg3 ----------------------------------------------------------------- + Page 19 + At this point, the client software is on your PC's disk. Before you can use it, you must configure it. This includes specifying the IP address of your workstation as well as your local "netmask." If the correct answers for these values are not obvious to you, contact local computer support for assistance. Once you have configured the client, you can invoke it by typing "gopher." Future sessions do not require configuration (unless you want to change a setting, for instance to choose a different Gopher server). Unfortunately, use of campus or corporate computer networks is not as simple as plugging a cable into an outlet. There are many local variations. Some sites use public domain TCP/IP packages; some have site licenses for commercial products. Some departments have local area networks that are gatewayed into the larger Internet environment. Technical support varies based on computing platform. New Gopher users should consult local network support specialists for assistance. 6.0 How the Gopher Protocol Works The Gopher protocol rests on the metaphor of a file system. As we've seen, a Gopher server delivers a menu in the form of a list of menu items. When a Gopher client connects to a server, it opens a TCP connection to a specified "well-known port"--typically port 70. Once the connection is established, the client then transmits a "selector string" that specifies what it wants to see. If it is the initial connection to a Gopher, the client sends a null selector string. This tells the server to deliver the highest level, or root, menu to the client. Once the server has finished sending the list of items, the connection is closed. The client then displays the document titles on the user's console, and the user is free to click on items of choice. The information sent by the server includes the following fields: . + Page 20 + One line of this form is delivered for each document. The initial field is a one-byte document type identifier. The type field is concatenated with the beginning of the title field; other fields are separated by the ASCII tab character. The Document Title field is the descriptive text that the client should display for each item. The "selector string" is a string of characters, usually derived from the location of the document in the server's file system, that can be used to uniquely identify the document for retrieval. The server domain name is simply the domain address of the server. The port number is a concept common in TCP/IP server nomenclature; the Gopher server "listens" on a specified port for transactions. (The Internet Assigned Numbers Authority, or IANA, which concerns itself with such issues, has assigned Port 70 as the standard Gopher port, though a given server may use another port--or ports, if a single machine runs multiple Gopher services.) For each document descriptor delivered by the server, the client inspects the one-byte type designation. If a document is of a type the client can't handle, the client simply omits that document from its list of titles. For instance, audio files are not currently supported via PC Gopher III. If a user points PC Gopher III at a directory that contains such files, those titles will not be shown to the user. Since the user can't select it, there's no frustration with impossible requests. (Although the protocol specification calls for this behavior, some clients, such as the public curses client, do not in fact omit such items. This may be useful in some cases. For instance, the user may want to download an item via the curses client for later use outside the Gopher session.) The process used by Gopher clients and servers can be envisioned in Figure 7. + Page 21 + ----------------------------------------------------------------- Figure 7. Gopher Client/Server Interaction ----------------------------------------------------------------- Client sends "selector string" to server via TCP to port 70. ===============================================>>> _______________ ________________ ____________ | | ( ) | | | Client | ( Campus Ethernet ) | Gopher | | (user | ( or ) | Server | | workstation) | ( The Internet ) | | | | ( ) | | |_______________| ________________ |____________| <<<================================================ Server sends back document to client, then disconnects. ---------------------------------------------------------------- The selector string tells the server what the user wants to see. The delivered document selectors, in turn, are the unique identifiers needed to cause the server to deliver each upon request. Once the server has delivered a document (whether it be folder, plain text, or otherwise), it has done its job for this transaction, so it disconnects. The Gopher server does not retain any information about the client across transactions--it is said to be "stateless." This aspect of the Gopher design is the key to Gopher's efficiency--the server is only connected to the user long enough to serve a particular request, and it does not pay the high overhead cost of having hundreds or thousands of users "logged in" at once. This highly efficient model allows relatively small workstations to function as Gopher servers, handling millions of requests per week from thousands of users across the Internet. + Page 22 + 7.0 Gopher Document Types The Gopher document types that have been defined so far are shown in Table 1. ----------------------------------------------------------------- Table 1. Gopher Document Types ----------------------------------------------------------------- 0 File 1 Directory 2 CSO phone-book server 3 Error 4 BinHexed Macintosh file 5 DOS binary archive 6 Item is a UNIX unencoded file 7 Index-Search server 8 Text-based Telnet session 9 Binary file + Redundant server T Text-based TN3270 session g GIF format graphics file I Image file Source: Internet Request For Comments document, RFC 1436. ----------------------------------------------------------------- In practice, other document types have also been adopted (e.g., "M" has been used for MIME mail documents). As Table 1 illustrates, the term "document" is used broadly to include any type of resource that can be accessed by the Gopher. Here is a more detailed explanation of some of the important document types. o File. This is a simple ASCII text file, which is displayed on the user's workstation using some sort of file browser. o Directory. This is a list of documents that is used to construct a Gopher menu. When a directory item is selected, the server sends the client the list of items in that directory. Included with each item is the information that the client will need in order to fetch the document when the user requests it. + Page 23 + o CSO phone book server. Named after the Computing Services Organization at the University of Illinois, CSO provides a client/server protocol for searching a phone database. Gopher recognizes this protocol and lets the user interact with a CSO server in order to look up information. o Text-based Telnet session. This document type allows a Gopher to present a list of host services that accept Telnet as a remote access protocol. For instance, a list of Internet-accessible online catalogs. o Text-based TN3270 session. A variant of Telnet, TN3270, is required to connect to IBM mainframe hosts. Support for this form of connection was incomplete early in the life of Gopher but has become pervasive in the last several months. (TN3270 support is important because many online catalogs and other database services reside on IBM mainframes. These days, when traditional mainframe-based services are looked upon with derision by some in the networked information community, mainframes are sometimes referred to as "legacy systems." But a lot of valuable information is still stored on those legacy systems, so connectivity to them is necessary.) There are also document types for PC (DOS binary archive), Macintosh (BinHex file), and UNIX (unencoded file) files; graphic files (GIF); searchable databases (index-search server); and backup Gopher servers (redundant server). Note that the case of the document type identifier is significant. Because each document descriptor line contains the name of the server where that document is located, it is easy for a Gopher server to point to documents stored far and wide. For instance, a Gopher server at Mythical State University might set up the document types for a root menu as shown in Table 2. + Page 24 + ----------------------------------------------------------------- Table 2. Example Document Types ---------------------------------------------------------------- Type: 0 Document Title: About this Gopher Selector: 0/about_MSU Server: gopher.mythical.edu Port: 70 Type: 1 Document Title: Fun & Games Selector: 1/fun Server: gopher.tc.umn.edu Port: 70 Type: 1 Document Title: MSU Campus Events Selector: events Server: events.mythical.edu Port: 70 Type: 2 Document Title: MSU Telephone Directory Selector: [blank] Server: cso.mythical.edu Port: 105 Type: 7 Document Title: Search MSU Gopher Selector: titles 7/ts Server: gopher.mythical.edu Port: 70 ----------------------------------------------------------------- Note that the Document Title is the only field that clients display by default. The combination of Selector, Server, and Port describes the document uniquely. Note also that the selector string consists of whatever text the server wants to receive in order to deliver a document. For Unix-based servers, this string is prefixed by the type of the document and a slash. Finally, note the variety of servers shown in this example. Often a Gopher administrator will store items peculiar to his or her domain on the same server machine as the Gopher server, but this is not essential. It is common for documents of local interest to reside on several servers, as shown above. Theoretically, a server could offer only documents that reside on other Gopher servers. + Page 25 + Because the Gopher design calls for a simple protocol built on TCP/IP, it is possible to test the behavior of servers without even using a client. The reader might want to try connecting to a Gopher server "manually" to see how this works. For instance, if you were to open a Telnet session to "gopher.micro.umn.edu 70" and then press the return key, you would see the initial menu for the main University of Minnesota server displayed in raw form. Most Gopher clients provide an "Item Info" option that displays the selector string that pulls up the current document. This can be useful when you want to know where a given document originates. It also makes it easy for a Gopher administrator to add a local pointer to a newly discovered, useful item. 8.0 Setting Up a Gopher Service It is relatively easy for a developer to implement Gopher client or server software. The protocol is also very efficient in its demands on the server and the network. This simplicity extends to establishing a new Gopher service: it is also easy for an information provider to set up a Gopher server. Some Gopher administrators report being able to bring a server online within an hour or two of downloading the server installation kit. Typical Gopher servers are UNIX workstations of one sort or another. The University of Minnesota relies upon Macintoshes running A/UX and NeXT workstations for the most part. Other popular server platforms include Sun workstations and IBM RS/6000s. The Gopher server code has also been implemented on the PC, but this platform is relatively uncommon as a server. Servers have even been implemented on IBM mainframes, both under the VM/CMS and MVS operating systems. + Page 26 + The standard Unix-based server code is written in C. It can be found at the same repository as the client code (boombox.micro.umn.edu), and it can be installed on a variety of platforms with little modification. The Frequently Asked Questions (FAQ) file often includes tidbits on peculiarities of installation on particular platforms. The news group (comp.infosystems.gopher) also contains discussions of installation issues. New server administrators will want to consult the news group archive (see Figure 3). Numerous tools have been created that assist in managing Gopher servers. For example, tools that analyze logs, improve indexes, and extend support delivery of calendar-based information are available. Some of these tools can be retrieved from the University of Minnesota's FTP server. Others, particularly short Perl scripts, are posted by the authors on comp.infosystems.gopher. Thus, the discussion group is not only a source of accumulated wisdom. It also is a repository of helpful tools. Gopher administrators announce new servers on the following lists: gopher@ebone.net (European servers) gopher@boombox.micro.umn.edu (All other servers) The announcement should include the name of the Gopher server, its Internet address, and its port number. The name can include labels such as "(experimental)" or "(Under Construction)" as appropriate. New administrators may want to review Gopher server names listed in "All the Gopher servers in the world" to see what sort of names others have chosen before picking their own. Gopher administrators face many challenges. One of these is how to effectively organize the Gopher menu hierarchy. Another challenge is how to convert documents from whatever format the owner of the information prefers to flat ASCII, which is currently the least common denominator document format--the format that all computing platforms can cope with. Prospects for delivering documents in PostScript are discussed below; in the absence of that sort of advance, perhaps the best advice for the Gopher administrator is to insist that document owners do the translation to flat ASCII, rather than taking on that chore as a part of running a Gopher service. + Page 27 + 9.0 Gopher's Origins Computer Center staff at the University of Minnesota began discussing the need for something like Gopher in early 1991. They wanted an online mechanism for "publishing" hints on computing services at the university. Mark McCahill, project leader for the group that developed Gopher, says the goal was to find a scheme that was more efficient than one-to-one consulting or conventional handouts and short courses. At the time, another group at the university was proposing a mainframe-based solution for campus document delivery. The group designing Gopher wanted a simple, network-based scheme that supported browsing of available documents. They also wanted to build a service that was fun to use, so that a critical mass of users would develop. The original Gopher team included Farhad Anklesaria, Paul Lindner, Daniel Torrey, Bob Alberti, and Mark McCahill. The developers' earliest discussions produced a goal of a simple protocol--easy to understand, describe, and implement. They decided upon a client/server model: a client would open a Telnet connection to the server, request specific information, receive and display the information, and disconnect. The initial model called for only two document types: text files and folders (subdirectories). Thus, from the beginning, the developers envisioned a mechanism that would deliver lists of files and directories upon request. The client/server model would provide for sessions lasting only long enough to deliver that list to the user's client software. These aspects of the Gopher model have endured. The University of Minnesota design team held their first serious meetings during the first week of April 1991. The Gopher team proceeded to work on implementing the first servers and clients. The goal at this point was to build a working prototype that could readily be discarded; the team assumed that whatever they produced might be replaced by something better within a year. The team spent quite a few 16-hour days on the project. By the last week of that month, they had prototype Gopher clients and servers working. Initially, there was a Macintosh client and server, a UNIX client and server, and a PC client. By late April, the Gopher developers decided that some sort of search mechanism was also needed. NeXT workstations were seen as an appropriate choice for servers, because the built-in Digital Librarian offered a highly functional search engine. The developers also decided Gopher should support telephone directory searches, and they settled upon the CSO telephone directory search protocol, already in use at numerous universities, as the best way to implement online phone books. + Page 28 + These different document types--text, folders, and CSO searches--would be sufficient to define a Gopher that could deliver documents stored on a single server. But, from the start, the protocol allowed a server to point to another server as the physical home of a given document. This allows a Gopher to include services that may be scattered across the Internet all in one list. It also makes possible a directory of other Gophers, any of which is a keystroke or a mouse click away. But the developers thought about providing ways to connect to existing database servers on campus, such as a university's online catalog. They decided to include a document type that was itself a Telnet session to another host computer. To round out the collection, a document type for transferring Macintosh or PC binary files was included. The original protocol was designed to be extensible; the one-byte data type field could potentially support 255 different data types. A draft Gopher protocol specification was released in spring 1991. The original Gopher team divided their development efforts. Torrey implemented the client for MS-DOS, and Bob Alberti wrote the first UNIX curses client. Anklesaria wrote the initial server and client for the Macintosh. Lindner developed the initial UNIX server code. Besides serving as project leader, McCahill set up the first index server using the Digital Librarian tool on the NeXT and assisted with early development of the Macintosh client. Despite this division of labor, the group worked as a team on problem solving and common issues. Delivery of sound via Gopher was born during the early development phase. One weekend the team member doing most of the server code, Paul Lindner, wanted to hear some music in his office, which is several rooms away from the communal CD player. His NeXT workstation was capable of playing sounds, and there was a CD player available on a workstation in another room. A few hours later he had implemented the sound data type, and Gopher was capable of playing music across a real-time Internet link. The first Gopher production services were in place at the University of Minnesota by late summer of 1991. Gopher was announced to the world via the campus-wide information systems mailing list (CWIS-L@WUVMD) in July 1991. A USENET news group, alt.gopher, was started. Computer system administrators from around the Internet began to learn about Gopher. The code was made available for others to try, and Gopher servers began popping up in various places. By early 1992, Gopher was no longer a prototype but was becoming a tool of choice as universities sought ways to implement campus-wide information systems. Steve Worona of Cornell Information Technologies says that Cornell was about to design a protocol that would allow them to move their pioneering CUINFO mainframe campus information service to a network/workstation environment, "but then we found out about Gopher, and it was exactly what we were looking for." [1] + Page 29 + The new TurboGopher client for the Macintosh provided a learning experience for the developers, because much of the testing took place over 2400 bps dial-up SLIP connections. This slow link exposed the ways in which the client blocked efficient transfer of data. The client was modified, and it now offers very impressive performance on high-speed networks. The University of Minnesota team believes this to be the fastest client now in service. Recent work on TurboGopher has been done by University of Minnesota staffer Dave Johnson; additions include foreign language support. 10.0 Gopher+ In August 1992, the regional computer network CICNet sponsored a Gopher Workshop in Ann Arbor, Michigan. Invited attendees included Gopher implementers at the various CICNet institutions as well as Gophernauts from Brown, Yale, Cornell, Princeton, Rice, the University of Washington, the University of North Texas, and other institutions. Mark McCahill and Farhad Anklesaria attended from the University of Minnesota. At that conference, the University of Minnesota developers presented Gopher+, their vision for how to extend Gopher beyond its original design. The original Gopher design, with its one-byte document type, was adequate to meet many of the needs of the community. But there were many demands for additions to the protocol, to handle everything from PostScript files and various image files (e.g., GIF and JPEG) to global document attributes, such as author name and document expiration date. Rather than embed each and every requested extension in the protocol, the University of Minnesota team devised a mechanism to support general ways to add them to the protocol. McCahill says that the team had been working on Gopher+ throughout 1992, but the advent of the workshop caused their ideas to gel. Gopher+ adds new, named fields to the simple one-byte item descriptor in basic Gopher. If a client appends an exclamation mark to a selector string, the Gopher server is expected to deliver an Attribute Information block. The first named field, +INFO, is required; it resembles the descriptive line sent by the old protocol. Other named fields that have been suggested for Gopher+ include +ABSTRACT, which would be a textual abstract describing the document; +ADMIN, which would be the name of the owner of the document; and +DATE, which would be the date the document was last modified. These global document attributes would help administrators maintain and describe documents, and, after appropriate client enhancements, would help users select documents of interest. + Page 30 + The University of Minnesota announced it would act as a central registry of Gopher+ data types; anyone proposing to implement a new named attribute field will submit it for registration to the Gopher team. This model allows cooperative uses of new fields as agreed to by the Gopher community. It also potentially allows a given site to implement a particular field in its clients and servers that would be of no interest to anyone else. As always, a client would only handle the information it knows how to deal with. If someone adds a +HAIRCOLOR attribute, a Gopher+ client would be free to ignore it. Note that a Gopher+ field could be a simple textual value, or, like a document under the basic protocol, it could point to another Gopher+ server. Besides providing a mechanism for supporting global document attributes, Gopher+ is intended to support alternate views to a document. For instance, a special named field called +VIEWS will support versions of a document in different languages. With +VIEWS a document could be offered in a variety of formats, from flat ASCII to PostScript. Beyond the global attributes and alternate views functions, Gopher+ also provides a mechanism for interactive queries. A Gopher+ server can interrogate a user for specific information such as a password, or it could even serve as an interface between a user and an interactive process on another host. This +ASK support includes options for prompting for file names or for the user to make a choice among a range of options. In February 1993, the University of Minnesota Gopher team announced the first clients implementing the Gopher+ protocol--a version of TurboGopher (for the Mac) and a version of the UNIX client. Server code is also available, and the production version of the University of Minnesota's Gopher points to a demonstration Gopher+ server. Users with non-Gopher+ clients can safely point to Gopher+ servers, but they will not be able to view the Gopher+ documents. There has been some criticism of the Gopher+ protocol extensions. In particular, some have argued that instead of defining the +VIEWS scheme under Gopher+, the Gopher community should rely upon MIME (Multipurpose Internet Mail Extensions). Originally proposed as a way to allow arbitrary 8-bit files to survive transit over Internet (SMTP) mail, MIME is being deployed widely and may serve as a standard way to handle multimedia files on a variety of platforms, whether the files are delivered via e-mail or otherwise. Others question whether there really needs to be a Gopher+ registry. If it does need to exist, some argue it should be at the official Internet registry, the IANA. In April 1993, the University of Minnesota sponsored a second Gopher Workshop and Conference. Participants at the Workshop urged the developers to consider adoption of the MIME content types and registry scheme instead of "rolling their own" types and registry. The Gopher team agreed to "strongly consider" use of MIME content type attributes. + Page 31 + In the short term, the University of Minnesota intends to act as the registry for other global document attributes (such as the owner of a document), but they have stated their willingness to use IANA eventually. Whether Gopher+ is deployed in its current form or with changes to the syntax and registration process, it is clear that it will allow Gopher to be extended to handle document types that have not yet been envisioned. It will improve the ability of Gopher administrators to organize documents. It will also allow basic improvements in the technology, providing a framework for improved navigation and interfacing to interactive services. An RFC describing the base Gopher protocol has been issued (RFC 1436). Mark McCahill says that, after minor corrections are made to that document, the base protocol will be frozen. Gopher+ is considerably more fluid. It will be interesting to watch its evolution. Along with Gopher+, the University of Minnesota team has also developed a mechanism for allowing "lightweight" authentication of users for access to protected documents. For instance, some vendors may insist that their documents can only be read when users have typed in a unique password assigned to them. The AdmitOne Authentication scheme lets a user obtain a "ticket" that allows access to restricted documents. The AdmitOne scheme uses encryption to avoid sending passwords over the network. It also provides a way that a client can reuse a ticket for subsequent transactions. Critics of AdmitOne have pointed out schemes for defeating the security of AdmitOne, some rather elaborate. One claim is that security cannot be provided by a client and a server alone--a trusted third party is required. 11.0 Organizational Issues The greatest strength of Gopher--its ability to easily present a single menu whose constituent documents reside far and wide on the Internet--also presents some interesting challenges. Gopher is being used at many universities to implement campus-wide information systems (usually referred to by the acronym CWIS, pronounced "kwis"). Each site setting up a CWIS under Gopher faces the challenge of devising an organizational scheme that embraces all the local documents and host services of interest as well as the many documents and services available over the Internet. + Page 32 + Some sites have adopted a simple model for the root menu. This yields a short and simple initial menu, such as: About Gopher The Campus The Community The World This elegant approach is appealing in its simplicity. Of course, to some extent, the scheme simply moves the problem of where best to put various documents downstream. Even with these simple categories, some items can be hard to place. Where do you put a gateway to your student e-mail service? What if you have an events calendar that integrates campus and community happenings? Where does the local weather go? At the other end of the spectrum, a site might choose to have a broad set of offerings on the root menu, making more documents accessible with fewer mouse clicks. Such a menu structure might look like this: 1. Gopher at Michigan State University. 2. More About Gopher (Documents & Navigation Tools)/ 3. Keyword Search of Titles in MSU's Gopher 4. About Michigan State University/ 5. MSU Campus Events/ 6. News & Weather/ 7. Phone Books & Other Directories/ 8. Information for the MSU Community/ 9. Computing & Technology Services/ 10. Libraries/ 11. MSU Services & Facilities/ 12. Outreach / Extension / Community Affairs/ 13. Network & Database Resources/ + Page 33 + This sort of scheme tries to bring commonly accessed documents to the front. The user need not search through multiple menus to find today's weather or the campus phone book. The very first item is a text file with introductory material, so the new user doesn't face a menu full of folders. A keyword title search allows users to find documents no matter where they are stored in the hierarchy. On the other hand, the user confronts a much busier initial screen, which may be daunting in its length and complexity. Depending on the client's default window size, the initial screen may not even fit on the menu window, forcing the user to scroll to see all choices. Users may find the bookmark facility offered by most clients to be a useful way to customize their view of a Gopher. Gopher administrators can also make liberal use of indexes--both document title indexes and full-text indexes--in order to make it easy for users to quickly locate data without having to hunt through the hierarchy. These tools can help, but a balanced hierarchy that reflects local needs is a worthwhile goal, even though there is no universal agreement on basic issues such as whether a depth-first or breadth-first organization is best. In any case, the process of building a CWIS under Gopher is much more likely to succeed if a campus-wide committee helps design the structure. For instance, a site might want to include staff from the central computing organization, the library, university relations, departments that run their own Gophers, and so forth. A committee can help ensure needs of various campus constituencies are met. While an organizational scheme for a CWIS must address the peculiar needs of each campus, most Gophers also allocate part of their directory tree to "Internet Resources" (or some similar name to serve the same purpose). Gopher administrators are beginning to realize that it does not make sense for each of them to come up with a local scheme for organizing all the online resources of the Internet. First, this is not practical; second, if a common organizational scheme can be devised for all of Gopherspace, then users will not confront wildly differing Internet directory structures as they move from campus to campus. Note that not all Gophers aspire to the scope of a campus-wide system. In some cases, the documents on a Gopher are mostly related to the special purpose of the sponsoring institution (e.g., the Electronic Frontier Foundation, the Well, and the National Institutes of Health). Such Gophers are inherently more narrowly focused than a university's CWIS tends to be. + Page 34 + Other administrators are mounting "subject Gophers" that may cover a single subject or a variety of subjects of general interest to users, but not documents pertaining to a particular campus. For instance, Don Gilbert of Indiana University has deployed a Gopher that is dedicated to materials on biology, and this server is becoming a useful resource for the biological sciences community. Sue Davidsen of the University of Michigan Graduate Library has built a subject Gopher that delivers census, business, and social science data. Known as Go M-Link, this Gopher mainly serves public libraries in Michigan. Subject Gophers in many cases have the most intuitive organization schemes. The use of the Internet to deliver electronic journals presents a special organizational challenge for the Gopher community. Discussions on how to manage and organize a set of e-journals are underway. Some propose the venerable Dewey Decimal Classification; some suggest the Library of Congress Classification Schedules; others like the Universal Decimal Classification; and others are experimenting with schemes of their own devising. CICNet has announced a project to archive electronic journals via their Gopher. Billy Barron of the University of Texas at Dallas is building this archive, and he is experimenting with organizational issues. [2] His initial effort uses the LC Classification scheme. One group of Gopher administrators and librarians from CICNet, NYSERNet, and other institutions are exploring alternative approaches to Gopher taxonomy. Some librarians contend that any attempt to fit documents drawn from all areas of human endeavor into a formal classification scheme is not an appropriate model for mounting networked information. Marty Courtois, a librarian and database coordinator at Michigan State University, observes: "Library classification schemes such as the Dewey Decimal System and the Library of Congress classification are good systems for finding materials on the shelf and are necessitated by the fact that a single book can only be placed in one location." [3] With a system like Gopher, cross-references can be set up as simple alternate links. Thus, a set of subject headings based on a controlled vocabulary can make materials far more accessible to the user. As Courtois puts it: It's simply easier to browse a classification list to look for "Biological Sciences" than to have to know that "QH300" represents that field. It's like giving the user a chance to look in the card catalog and the shelves at the same time. [4] + Page 35 + The world of networked information is new and evolving. Some organizational schemes that seem obvious to an administrator may be suboptimal for the user. For instance, there is a tendency to categorize networked information servers based on their location or on the underlying technology. For instance, you might find a Gopher menu that offers: Other Gopher Servers Non-Gopher Campus Wide Information Systems WAIS-based information World-Wide Web The user of course is interested in information, not the technology that presents it. In the long run, providers of networked information resources need to find ways to organize materials by subject matter, not by whether the data resides in a Gopher, WWW, WAIS, or some other technology. As Marie-Christine Mahe of Yale University observes, "A Gopher that splits CWISes along technical lines is equivalent to a supermarket that would shelve tomato sauce in different aisles, according to whether it was in a can or in a glass jar." [5] Mahe believes that when Gopher uses standards such as Z39.58, it will be easier to provide uniform access to data stored under disparate systems. In the meantime, she argues that Gopher administrators should use topical organization whenever possible. One could imagine a division of labor among Gophers, as follows: (1) publisher Gophers would distribute original material in one or more subject areas; (2) single-subject Gophers would organize and provide access to network resources for a subject area; (3) index Gophers, such as Veronica, would allow users to search for resources by keyword instead of browsing; (4) master Gophers would link users to single-subject and index Gopher servers; and (5) CWIS Gophers would specialize in documents and services that pertain to each campus (they would have links to master Gophers to provide access to Internet resources). Whether this happens or not, it is clear that there must be more recognition of the specialized roles that Gophers can play. If every Gopher administrator tries to provide both original documents and organized links to Internet resources, these efforts are doomed to fail. + Page 36 + 12.0 Navigational Enhancements Gopher provides an effective mechanism to allow an administrator to provide a hierarchical browsing list, for a campus, for the Internet, or both. But the organizational scheme carefully designed during months of deliberation by a campus menu design team may bear no relation whatsoever to the organization of a given user's brain. Even when the organizational scheme is suited to the user, the process of searching for information across many Gophers can be tedious. Recent developments have addressed both concerns. 12.1 "Road Map" and TS/TB In July 1992, Dennis Boone of Michigan State University implemented a "Road Map"--a representation of an entire Gopher's directory structure in a single text document. This allows users to read the map and get a feel for the lay of the land. Also that month, Boone implemented a Gopher title search tool. Known as "ts/tb," the title search allows the administrator to prepare keyword search indexes for the entire Gopher tree or for any part thereof. The user wanting to find the schedule for the campus opera society can do a keyword search on "opera," and all titles including that word will be served up as a menu. The title search tool has been adopted for use at a number of sites. One shortcoming is that document titles are pulled up from wherever they appear in the menu hierarchy, and they are presented without putting them in the context of the menu hierarchy. However, this usually does not lead to confusion. 12.2 Veronica In November 1992, Steven Foster and Fred Barrie of the University of Nevada announced a service that could search document titles across many Gopher servers. Their original code was a modification of Boone's title search. Where Boone's index deliberately limits itself to one Gopher server, they devised a mechanism to provide a single title index that could span many Gopher servers. The Nevada team christened their tool Veronica, which they say is an acronym for "Very Easy Rodent-Oriented Netwide Index to Computerized Archives." Just as Archie surveys anonymous FTP servers for their list of holdings, Veronica must go out and poll its target servers periodically in order to build a database. A user connecting to Veronica specifies a keyword to search for, say for the word "biology," and gets a list of document titles from throughout Gopherspace that match. + Page 37 + At this point, Veronica is not without its problems. The most noticeable problem is performance. As of this writing, there are two Veronica servers for the entire Internet and these servers are often quite busy. It can take several minutes to get a response to a Veronica query at busy times. Of course, if the search eliminates many minutes (or hours) of manual browsing, a wait of several minutes may well be worth it. Steve Foster observes that users have told him they are willing to wait for the results of a search of all of Gopherspace, assuming the results are accurate. Another concern is discerning the meaning of titles listed as the result of a Veronica search. As with the single-Gopher title search, the document titles are shown stripped of their hierarchical context. Within one Gopher server this is not necessarily daunting. Do a Veronica search on "presidential," however, and you'll find items ranging from the 1992 Presidential debates to presidential searches at various campuses. The labels may not provide enough context to make clear the location or purpose of a given document. The user ends up having to select unwanted documents just to determine what they contain, and even then there may not be sufficient context within the document. Initially, Veronica did not resolve multiple references to a given document down to one listed item. Popular items are pointed to by many Gophers, so a Veronica search might yield 100 pointers to the same document. The Veronica developers modified the software in December 1992 to fix this problem: all references to a particular selector string/host are collapsed to one listing. This does not solve the problem of sites that make separate local copies of documents they find on the network; each such copy is indexed separately by Veronica. The only hope for solving that problem is widespread adoption of a Uniform Resource Number scheme. (The Internet Engineering Task Force is working to define such a numbering scheme, which, with companion Uniform Resource Locators, would allow for agreed-upon ways to number and to locate Internet documents and services.) Finally, Veronica is not currently consistent in the search results it delivers to the user. Part of the problem is that Veronica, like most Gopher indexes, relies on the public domain WAIS search code, which returns a "relevance score" rather than an absolute answer as to whether something was found. At one point, the two existing Veronica servers yielded differing results for the same searches. Inconsistent results may also arise from the fact that Veronica may be unable to do its periodic survey of a given server. One proposal for addressing this problem calls for a new Gopher document type, the Veronica index, which would be delivered to a polling Veronica server in one operation. This would be a much simpler, more efficient transaction than having the Veronica server manually traverse the entire directory tree of each Gopher server whose titles it wants to survey. + Page 38 + Despite these shortcomings, Veronica represents an exciting development. Already users are finding it far more efficient than browsing innumerable menus when searching for specific resources in Gopherspace. Proof comes from the results of recent Internet Hunts. These monthly quizzes, issued by Rick Gates of the University of California at Santa Barbara, challenge users to find out what information servers on the Net can answer particularly arcane questions. (For example, "Who is the author of the only book held by Victoria University of Wellington on the training of sheep dogs?") Increasingly, the winners of the Hunt have exploited the power of Veronica to enhance their burrowing through Gopherspace. Many Gopher servers now provide a pointer to Veronica under "Other Gophers" or an equivalent folder. (The Nevada server is located at veronica.scs.unr.edu, port 70; use the selector string "1/veronica" to access the server.) The Veronica developers are exploring setting up several servers around the Internet, to balance out load factors. With the number of Gopher servers growing daily, the list of servers in production has become a management issue in its own right--there are currently over 1,100 servers. Recently the staff at the University of Minnesota reorganized the "list of all Gopher servers in North America," breaking it up by state. This makes browsing easier for some purposes, but if you are looking for, say, Johns Hopkins University, and you do not know it is located in Maryland, you may want a different path. (Indeed, for most purposes, the geographical location of the server is irrelevant to the user's query.) Dennis Boone has implemented a global keyword index of Gopher site names to allow a user to quickly find a known site regardless of where it is located. (This service is available as "7/internet/others/ts" on the gopher.msu.edu server. Gopher administrators may want to add pointers to this index.) 12.3 Jughead In March 1993, Rhett Jones of the University of Utah announced a Gopher title search tool called "Jughead." Jughead can index a single Gopher or all of Gopherspace, as Veronica does. John Doyle of Washington and Lee University has used Jughead to create several indexes of Gopherspace by document type (e.g., Telnet session, CSO phone book, and index). His Jughead server is found at liberty.uc.wlu.edu, port 3002. 13.0 Quality of Service Concerns Gopher has come a very long way in a very short time. Because servers have been deployed around the Net for only about sixteen months, many services are still experimental. A user may stumble upon a document that sounds just right using Veronica, only to discover in dismay that the needed server is consistently down. + Page 39 + To some extent, this is inherent in networked information. And perhaps users should learn to expect to find resources that are unavailable from time to time. As Nancy John of the University of Illinois at Chicago has observed, patrons of libraries have long been used to the idea of locating a particular book they want, only to find that book has been checked out by another patron. [6] Still, administrators confront choices that may affect reliability of service. The Gopher model encourages distributed deployment of services across many servers. It is tempting to place documents on a wide variety of Gopher servers, across a campus and even within departments. But as Joel Cooper of Notre Dame University points out, some forms of information are vital "corporate data"--data that must be reliably provided for the good of the enterprise. [7] For instance, Gopher presents real opportunities for saving trees by replacing printed matter. But if the phone book server is located in a locked office that is inaccessible at night, who will reboot it when it crashes? Gopher administrators may well want to put documents that are vital to their institutions' business on a central server, perhaps in an area staffed by full-time computer operators. By using automated document posting processes (either via e-mail or FTP), the administrator can make posting easy for information providers, while utilizing carefully managed servers. Even the best maintained server will experience outages. Gopher clients determine that a server is down simply by "time- out" criteria--they wait for a predetermined period of time and display an error message if the Gopher server doesn't respond. Some clients allow interruption of a query if the user does not want to wait for the entire time-out interval. It would be desirable if all clients allowed the user to configure the time- out interval. The Gopher protocol provides a mechanism whereby a server can deliver two selector strings for a given document. In this way, a site could offer a primary and an alternate server for critical information. So far, this feature of Gopher has not been widely exploited, but it is worth noting that the University of Minnesota now runs a server that replicates the documents offered at Gopher Central. (The backup is gopher2.tc.umn.edu, port 70.) Prudent Gopher administrators will also provide for regular backup of the server software and data files. Any production data resource demands regularly scheduled incremental and full backups. Again, centrally located servers may be in the best position to be backed up, perhaps by staff who already perform such backups for other production hosts on a daily basis. + Page 40 + Reliability of service is one issue; quality of content is another. In many cases, Gopher administrators view themselves as publishers, and they rely on the original providers of documents to provide high-quality information. Of course, the quality of documents delivered can vary wildly. Administrators can try to set standards for quality of content and for currency of information, but these can be hard to enforce. In some cases, removal of documents, while a blunt instrument, is the only answer to this problem. Again, the ability of Gopher to point to other documents becomes an issue. Just about anyone can declare an electronic serial to be an e-journal. By what standard do we decide whether to point to it in a Gopher? Include all journals? Those that manage to produce two issues? Those with ISSNs? Those that appear to be "scholarly"? Those that are peer reviewed? Over time, librarians will probably have to apply the same sort of collection development procedures to online information as they do for their print holdings. Although most e-journals are currently delivered without a fee, there are costs to including substandard material--the human and machine costs of mounting the material as well as the time the patron spends avoiding the chaff. Librarians face the interesting question of deciding whether to list networked information resources in general, and Gopher-based services in particular, in their online catalogs. Already some libraries have included selected e-journals in their online catalogs. With the proliferation of networked resources, each library undertaking to catalog the Internet faces the same issues of what ought to be included in the virtual collection that confront Gopher administrators. Moreover, the effort involved in preparing a catalog record exceeds by a considerable margin the cost of adding a Gopher link. In fact, Martin Dillon, Director of Research at OCLC, has proposed a four-tier approach to cataloging Internet resources, with the effort expended proportional to the scholarly value of the item being cataloged. In brief, these levels are: 1. Cataloging is equivalent to that used for scholarly materials today. 2. "Brief record" cataloging as used by libraries for materials not of the highest rank. 3. Cataloging by automated means, supplemented by some human editing. 4. Catalog record is supplied by item's creator and collected automatically. [8] + Page 41 + Should libraries undertake to catalog networked resources, they may wish to adopt a scheme such as Dillon proposes. Moreover, they may decide to use consortia and specialization so that not every library takes on the task of cataloging the entire Internet. 14.0 Privacy and Security Issues Like many networked information servers, Gopher servers maintain logs of what documents have been accessed at what time from what computer. These log records contain the Internet address of the originating user's computer. These days, many workstations have only one regular user. Therefore, an Internet address can correspond to a single human being. Just as libraries have long had policies to avoid tracking information about an individual patron's reading habits, Gopher administrators need to take steps to ensure that users' privacy is not violated. Some institutions have issued formal Gopher privacy policies. Two of these institutions are Rice University and Michigan State. (At the latter, logs are periodically "sanitized"--information is summarized so that individual accesses are no longer discernible.) Some applications in Gopher could best be handled given a scripting facility. Such a tool could allow a server to cause a program to execute on the user's workstation. A very simple example would be to have the workstation's Telnet program type essential login information after a session is opened (e.g., a command all users must type to connect to a service on a given host; for instance, "DIAL VTAM"). However this sort of facility poses risks: an unscrupulous Gopher administrator could devise a script that is dangerous or even malicious in execution. Even a PostScript interpreter could be dangerous, as PostScript is a language in its own right, able to open and modify files on disk; the only protection would be a PostScript browser known not to be able to write to disk. + Page 42 + Administrators also face problems with users who try to use Gopher as a pathway into machines where they are not welcome. Any Gopher administrator can trivially add a link to a host that may prefer not to be made visible. There is a need for a registry of what sites are willing to accept Telnet sessions from random users across the Internet--these sites would be considered fair game for pointers in Gopherspace. (In practice this has not been a source of widespread concern so far.) Conversely, Gopher administrators may find that with tools like Veronica, their documents may take on greater visibility than desired. For instance a departmental Gopher might offer information intended for local consumption (e.g., minutes of a faculty meeting) that is sensitive if viewed from other sites. Where necessary, it is possible for an administrator to restrict access to readers on a local network. This is essential for delivery of restricted licensed information, such as electronic newspapers. 15.0 Electronic Publishing Gopher is sometimes labeled an Internet document delivery system. Yet, we are currently forced, for the most part, to deliver Gopher documents as flat ASCII files. This is because we cannot assume that there is software on the user's desktop to allow display of anything more sophisticated. As a result, Gopher administrators must spend considerable effort "undesktop publishing" documents that have been carefully made ornate by information providers. Not only does this slow the posting of information, it also denies the end user the benefits of well-designed material. These are serious concerns for Gopher administrators. Some sites have begun to experiment with delivering documents in PostScript form. A public domain viewer for PostScript is available from the GNU project. It is called Ghostscript. At this point, this public domain tool has not been widely deployed, and it does not appear to be a practical solution for all computing platforms. + Page 43 + Early in 1993, the Adobe Corporation announced a product called Acrobat, which will be a multi-platform PostScript viewer. Acrobat revolves around a special "distilled" PostScript file type that is said to yield documents only 25% larger than equivalent ASCII files. Additionally, Acrobat will include the ability to display embedded JPEG images. Acrobat is a promising tool for moving the online information world into true electronic publishing, with font changes and embedded images efficiently delivered. It would make an ideal browser for Gopher-delivered documents. The key question is whether Acrobat (or competitive tools) will be priced low enough so as to allow near-universal distribution. 16.0 Multimedia The Gopher community has already begun providing networked multimedia. Early examples include the ability to deliver audio over the Internet. This has been demonstrated, but it is currently limited to NeXT or Sun workstations and it requires fast Internet paths (at least 64 kilobytes per second). Michigan State University has posted samples from its extensive Vincent Voice Library, such as Nixon's resignation speech and Kennedy's inaugural. Most recently, Michigan State mounted audio of the entire 1992 Presidential debate that was held on its campus, along with photos of the event, a transcript, and coverage from the student newspaper. Many sites have begun using Gopher to deliver still images. The Fine Arts School of the University of Victoria uses Gopher to deliver art images to its students. Jeremy Kargon, a consultant at Johns Hopkins University, has mounted a series of architectural images via Gopher. The Instituto Tecnologico y de Estudios Superiores de Monterrey delivers Mexican scenes via Gopher. Ohio State University will make available a set of building diagrams for use by their campus community, for instance to assist in wiring buildings for the campus computer network. Medical schools are exploring the idea of using Gopher-delivered images for instructional purposes. The University of Virginia has "Gopherized" two still-image collections from the Library of Congress--a set of recent Soviet documents and a collection of historical items from the Vatican. + Page 44 + Two formats are most commonly used for still image delivery over computer networks: GIF and JPEG. GIF is the Graphics Interchange Format popularized by the information utility CompuServe. JPEG (Joint Photographic Experts Group) is another standard file format for digital still images, which allows efficient storage and fairly accurate reproduction. GIF viewers have been implemented in many commercial, shareware, and public domain programs on all common computer platforms. JPEG is a newer standard that is catching up to GIF in terms of prevalence of viewers. Under current usage, Gopher type "I" refers to GIF or JPEG files; type "g" refers specifically to a GIF file. There are two factors to consider when evaluating whether delivery of still images via Gopher is practical: disk space consumed and time required to display the image. The GIF format typically requires 100 KB to 200 KB of storage per image, but the cost of disk storage is plummeting--large SCSI drives can now be obtained for less than $1.50 per megabyte. However, even if cost of disk storage can be borne, one would probably not want to use GIF or other bitmapped image formats as a medium for delivery of multiple page documents: GIF viewers are usually too slow to allow for rapid paging through image files. Depending on the hardware and the GIF viewer, it can take 5 to 30 seconds to paint an image. (All other things being equal, JPEG files generally take more time to interpret and display.) In addition to the time it takes a viewer to decode an image for display on the screen, an administrator must also consider the network overhead of moving 100 KB files for each end-user selection. With favorable trends in the cost of disk, the speed of processors, and the bandwidth of networks, Gopher-mediated delivery of still images will become more viable over time. Recently, there have been efforts to support network delivery of multimedia documents. David Lacey of the University of Iowa has integrated a browser that implements the MIME protocol. Sample documents mounted at Iowa include photographs of artifacts from a campus museum, along with descriptive text. Viewed on color NeXT workstations, these multimedia documents are rich and crisp. In the PC environment, the UGOPHER client is capable of launching software that can play audio, and it can also play MIME files if the user has the Metamail tool installed. Experiments with compressed motion video are beginning; one site is experimenting with delivery of Macintosh QuickTime files via Gopher. Apple has announced a QuickTime viewer for Microsoft Windows. + Page 45 + The biggest challenge in delivering multimedia information is the proliferation of formats. In the still-image arena, there are more formats than there are 35mm camera lens mounts. Fortunately the GIF format has been popular enough for viewers to become available for all common workstation platforms. The JPEG format may soon become deployed as widely. A Gopher administrator wanting to provide images to the broadest audience will use GIF at this point. There is a similar proliferation of audio file formats. The 8 kilohertz mulaw format currently used for Gopher audio delivery is readily supported on Sun and NeXT workstations. Other platforms, such as the Macintosh or the PC with Sound Blaster cards, assume other formats. Some sites are offering files in Sound Blaster format for PCs so equipped, but these are not usable on machines that lack that hardware. Gopher+ may make it possible for a server to hold a file in one form but deliver it in the format best suited for the user's client software. For instance, translation among various audio formats is possible with software such as the public domain Sox utility. It may be possible with Gopher+ (and a little effort) to devise ways to archive audio in one canonical form, but deliver it in the appropriate machine-specific format. Large, complex documents in Gopher reveal one shortcoming of the current technology: Gopher needs a mechanism for delivering a document in "chunks." Currently an entire document is delivered when the title is selected by the user. Consequently, a book or other large text must be artificially split into separate chapter documents (or further). An audio document must be split either by arbitrary time slice or based on content. It would be better if large, complicated documents could be treated as a single document, or, at the user's choice, viewed based on underlying structure. Some sort of table of contents field, analogous to the index markers on compact discs, might be used. With the deployment of Gopher+, there is the potential for adding this sort of support. + Page 46 + 17.0 Non-Gopher Client Technologies We saw earlier that Gopher is best utilized when the user takes advantage of specialized client software. Recent developments in the area of non-Gopher client technology are worth noting. At the Fall 1992 meeting of the Coalition for Networked Information, VTLS demonstrated a prototype online catalog that could retrieve information from Internet systems. The prototype system added information resembling the Gopher document descriptor to standard MARC records. This is a promising concept. As we saw earlier, the Gopher community has already struggled with the question of how to organize information about Internet systems, including online catalogs. At the same time, some libraries have begun adding networked information resources to their online catalogs, and integrated library system vendors are providing links to remote systems from online catalogs. It is only logical to expect that someday we will see a merging of these two streams of activity. Ideally, the user would interact with a single user interface that searches for networked information: the user does not care whether it is a Gopher linked to an OPAC, or an OPAC linked to a Gopher. Another alternative client development is a tool for the X Windows environment called NCSA Mosaic. Written by the National Center for Supercomputing Applications, Mosaic is a sort of "super client" that supports connections to a variety of servers: World-Wide Web, Gopher, USENET News, FTP, and others. Mosaic has been deployed as a beta release as of this writing. Mosaic supports numerous document types including various image formats, audio, and PostScript. Mosaic and similar clients could be an important advance in networked information, freeing the user from having to obtain a separate client for each kind of primary server he or she wants to connect to. Mosaic aspires to provide the user with a customizable hypertext view of the networked universe. + Page 47 + Naturally, with its generality, Mosaic presents the user with considerably more options to consider than does the typical Gopher client. Moreover, the X platform is used on comparatively few computers (compared to PCs and Macintoshes), even at universities. However, this client has generated considerable enthusiasm among those who have seen it. Besides serving as a unifying client, Mosaic also provides helpful navigation aids such as a complete history of where a user has been in her wanderings through the Internet; it even uses color to highlight menu items selected earlier in a session. When Mosaic is ported to more common computing platforms, it could become an important unified client. NCSA intends to deploy Mosaic on Macintoshes and perhaps under Microsoft Windows. Another attempt at a unified client is under development at the Cornell Law School. A tool called Cello is being developed for Microsoft Windows. Not all clients have the straightforward goal of simple retrieval of documents for the user to read. In May 1992, Steve Ludtke of Rice University announced a 3-D Gopher client for NeXT workstations. Dubbed "A Gopher in a Forest," the client presents a 3-D rendering of IP address space, and it updates the image in real time as the user moves from server to server or down the menu hierarchy. This tool generated considerable excitement, but no one was able to identify a practical use for it. Because IP address space doesn't correspond to geography, it was not a way to visualize where in the world documents were coming from, but it did inspire the idea of a client that could depict a geographical view of Gopherspace. (Such a client is yet to be written.) Perhaps the most exotic alternative Gopher client is the MOO Gopher. An interactive, multiuser game called Mud--a sort of network-based Dungeons and Dragons--has been popular on the Internet for some time now. The Xerox Palo Alto Research Center has created a variant of Mud called MOO, which provides an object-oriented language for Mud. MOO is rich enough to support implementation of a Gopher client, and this has been done. In some MOO games, the player uses the MOO Gopher to browse the Internet for answers to questions in order to advance in play. Opinion is divided as to whether this is of research/educational value or a waste of time and bandwidth. + Page 48 + 18.0 Related Networked Information Server Technologies Gopher is one of several emerging technologies that help people to navigate the Internet. It overlaps with the other tools in two ways: (1) Gopher can serve the same functions as some of the other technologies, and (2) Gopher can serve as a gateway into the other services. For instance, a Gopher can offer a menu of WAIS services. Each pointer to a WAIS server can be presented as a Gopher index search item. As a distributed menu system, Gopher is strong in its support of "resource discovery." Users can browse through a Gopher and learn about resources available on the Internet they never dreamed existed. This is an advantage over a tool like Archie. With Archie, you have to know the file name before you do your search. When a site "Gopherizes" its FTP service, it makes the list of files far easier for users to browse. Like Gopher, HYTELNET is a tool that helps users identify needed Internet systems. Several years ago, Billy Barron (then of the University of North Texas) compiled a list of online catalogs available on the Internet. Building on this list, Peter Scott of the University of Saskatchewan created HYTELNET, a PC- based hypertext directory. Over time, the scope of HYTELNET was expanded to include a wide variety of Internet systems, such as CWISes. A colleague of Mr. Scott's, Earl Fogel, created UNIX and VMS versions of HYTELNET that permitted Telnet sessions to Internet systems. Mr. Scott issues frequent updates about new Internet systems on a mailing list. By letting users browse through a list of Internet systems, HYTELNET fills the role of a resource discovery tool. However, HYTELNET only identifies and links users to Internet systems; it does not retrieve files or perform index searches like Gopher. Another tool, WAIS (Wide Area Information Servers), is a distributed networked database system. It is based upon an extension of the NISO Z39.50-1988 standard, which describes a model for an "originating application" (a client) to query databases at one or more "targets" (servers). WAIS allows a user to do keyword searches for documents, scanning a single server or multiple servers. WAIS responds to a search with a list of documents sorted by a weighted score--the higher the score, the better the match to the search. WAIS is strong in its ability to allow users to sift through a large body of documents stored in servers across the Internet. It is more appropriate for finding a small set of documents among a large set of candidates than for serving as a menuing or browsing tool. WAIS has enjoyed a fair amount of attention in the general press lately, because its developers have launched a commercial firm to market it. + Page 49 + Yet another tool, World-Wide Web, evolved in the physics community, and it is being increasingly recognized as a general networked information retrieval tool. WWW is a distributed hypertext system. Information providers can deliver documents defined in a type of markup language (a subset of the Standard Generalized Markup Language, SGML, called HTML) that can be perused by users who need not know the physical location of the parts of the document they are reading. As a hypertext system, WWW frees the user from the confines of a rigid hierarchy. Advocates of WWW claim that this is an essential feature--the only effective way to deliver documents chosen from a vast universe of information is via hypertext. They point out that providing pointers within the text of documents can make it far easier for users to find and peruse materials of interest. The WWW model lets users seamlessly cruise from server to server and from topic to topic. It allows the user to retrace steps as well. Like Gopher, WWW can launch Telnet sessions to connect to online services. WWW can serve as a browsing tool much as Gopher does. Under Gopher, it is common for a document to include pointers such as "Look in the 'Campus Eateries' folder for more information." To follow that advice, the user must leave the current document and open the folder in question. Under WWW, the pointer text could highlight "Campus Eateries" within every document where it would be helpful to mention it; a click on the embedded title would open the referenced document. Such multiple links are unobtrusive and do not require the user to hunt through other folders. It is hard to deny that embedded links are easier for the user to navigate. Hypertext services need not require a great deal of editorial investment. For instance, one site has built a cross-referenced set of UNIX "man" pages under World Wide-Web. ("Man" pages are brief descriptions of UNIX commands and their options, one per command.) Every mention of another "man" page within a document is shown as a link; the user can jump from page to page at will. This sort of process can be implemented by means of an automated script, without a great deal of programming or editorial time required. + Page 50 + These disparate technologies have been exploited at varying rates. Although numerous subject-specific WAIS databases have been made available and World-Wide Web has been deployed at quite a few sites, Gopher seems to be the dominant tool for campus-wide information systems and for some subject-specific services. In terms of traffic generated, Gopher is leading the pack. For instance, counts of packet load on the NSFNET backbone reveal Gopher is high on the list of network traffic generators (see Table 3). ----------------------------------------------------------------- Table 3. NSFNET Backbone Traffic Distribution by Service, March 1993. (Extracted and summarized from ftp://nic.merit.edu/statistics/nsf-9303.ports) ----------------------------------------------------------------- Packet Total: 34,874,064,400 Byte Total: 6,502,203,065,800 Service Name Port Packet Count % Pkts Byte Count % Bytes Gopher 70 327717650 0.940 79023945150 1.215 Z39.50 210 19506350 0.056 5415741150 0.083 WWW 80 11294550 0.032 3613584700 0.056 ---------------------------------------------------------------- Gopher has grown dramatically in its ranking in these statistics over the last several months. Of course, WAIS and WWW are also growing rapidly as new users come to rely on these tools. To some extent, these figures overstate Gopher's dominance. For instance, the use of WAIS to deliver data via Gopher is masked. Also, since WWW has enjoyed more initial success in Europe, the use of these U.S. numbers understates its impact somewhat. Not surprisingly, the relative number of servers deployed for the major tools shows Gopher with a wide lead as well. Whereas there are over 1,100 Gopher servers on the Internet, there are about 118 WAIS servers (supporting over 425 databases) and about 50 WWW servers. (Of course, these numbers are not directly comparable. Just as the Library of Congress holds more books than a small public library, it could be the case that a given WAIS server holds more data than several Gopher servers.) + Page 51 + Why is Gopher so popular? One reason is the relative ease with which an information provider can set up a server. As Steve Worona of Cornell University observes, "Compared to other Internet navigation tools, a Gopher server is quite easy to set up. As a result of the low 'entry costs' for setting up a Gopher service, it has become a very popular tool across the Internet in a very short time." [9] Another reason is that Gopher clients have been deployed on the most popular computing platforms--PC compatibles and Macintoshes. And for those users who lack client software, Gopher is fully accessible via dial-up and Telnet paths; WWW, for instance, lacked a good curses client until recently. (The University of Kansas offers a public curses client for WWW in support of their CWIS, Lynx.) The distinctions among these technologies may blur over time. Groups within the IETF are working to define standards that will allow an information provider to offer standard abstract information in order to describe the purpose and content of a network resource as well as standardized location descriptions so that users or automated processes can connect to that resource. For instance, an FTP site could offer descriptions of all its files, and Archie could allow users to do keyword searches of those abstracts. Already, the Gopher developers have announced their intent to support these new standards. Gopher could thus take on some of the role currently filled by Archie. The Gopher team have also said they intend to embrace the Z39.50 standard. As Mark McCahill of the Gopher team notes, Gopher and other tools may become much more similar with these enhancements and similar ones. It is important to bear in mind that these technologies can interoperate today. Therefore, a site need not use one to the exclusion of another. For instance, a site might mount a WAIS database that meets a specific need, while using Gopher as a campus-wide information system. The Gopher CWIS can include the WAIS database as a document. In fact, the combination of Gopher as a CWIS and WAIS as the server for one or more databases is becoming quite common. + Page 52 + Nor is WAIS the only "back-end" database technology deployed behind a Gopher "front-end." For example, Tim Howes of the University of Michigan has implemented a gateway between Gopher and X.500 directory servers, making it easy for users to browse a list of X.500 "phone books" from around the world. Similarly, Ohio State University had an existing telephone directory server on their campus network; they implemented a gateway from Gopher to that server rather than building a separate CSO database. (Some users find CSO telephone searches overly complex compared to a Gopher index.) Gopher administrators are implementing databases using a variety of other engines, with Gopher as a primary or secondary interface to the data. The UNIX Gopher server also makes it easy for a Gopher administrator to point a folder to an FTP site or even to a collection of mail messages. 19.0 Gopher's Future Gopher has existed just about two years, its developers are only able to work on it part-time, and documentation on how to build a Gopher service is somewhat spotty. Yet, it has grown into a production service at dozens of sites around the world. Clearly it meets a real need--it provides a distributed menu system that allows users to browse the Internet. Although Gopher faces competition from rival technologies such as World-Wide Web, its future seems assured. The Gopher+ protocol promises powerful extensions to the basic Gopher concept. The Gopher clients and servers that we will see next year may have significantly greater capabilities than today's software. True, Gopher is not unique among Internet technologies in its ability to deliver networked information. What makes Gopher special is that it can deliver a browsing list of such documents and services in a package that's easy to administer and accessible to users. Via Gopher, users can move from server to server, quickly seeing what's available and learning about documents and services they'd never dreamed of. With Veronica searches, the user can search for documents across multiple Gopher servers. The user has the choice of browsing or doing a focused search. Gopher's most serious competitor is probably the World-Wide Web. Some critics of WWW point out that there is the threat that a hypertext service can degenerate into a "twisty maze of passages all alike" and that users will get lost. WWW advocates respond that the hierarchical model of a Gopher is mathematically a subset of the WWW hypertext; an administrator can design a web to look just like a Gopher hierarchy. (However, a WWW adherent might ask why an information provider would choose to limit a service to a hierarchical view.) + Page 53 + As WWW clients become available on more platforms and as superclients such as Mosaic and Cello are deployed, WWW will become accessible and attractive to many more users. Tim Berners-Lee, the main architect of WWW, has stated plans to make it easier to install a WWW server and to "join the Web." With broader user access and more servers online, WWW could become more competitive with Gopher. The University of Minnesota and the Gopher community could face pressure to provide hypertext support within Gopher. The question is whether Gopher can retain its ease of setup and use if it embraces hypertext. Gopher/WWW interoperation is already common. The UNIX Gopher server can offer a Gopher hierarchy to the Web. The developers of Mosaic and NCSA have stated their intent to deliver a unified Gopher/WWW server that is capable of serving a Gopher hierarchy directly to WWW clients. These developments could encourage merging of the tools. The Internet Engineering Task Force has formed a working group that is looking at integration of resource discovery tools such as Gopher and WWW. Recent statements from the University of Minnesota indicate that, if Gopher is used for commercial purposes, such use will require a license agreement. The University of Minnesota intends to continue to make Gopher available free of charge for nonprofit academic use. Much of the development of Gopher has been possible because of the keen interest of a supportive community. Will that community continue to contribute to a corpus for someone else's financial benefit? Already the announcement of licensing fees has spurred one site to offer a free Gopher server implemented in a few hundred lines of code (written in Perl). Another site is offering a "GNU Gopher" server. (The GNU project is a movement dedicated to providing free versions of UNIX and related tools.) Note that related tools have also "gone commercial" recently. This is the case with Archie, now to be developed by Bunyip Information Systems, and WAIS, to be enhanced and marketed by a private company. (Note that as of this writing WWW is offered under similar terms to the new Gopher license; commercial users are expected to contribute development effort or pay a fee.) It will be interesting to watch the effect of commercialization on all of these products. + Page 54 + For the present, Gopher enjoys overwhelmingly superior market penetration compared to competitive tools. It is impossible to gauge the impact of all the economic and technical developments in the Gopher community and in the networked information field at large. Over the long run, Gopher might remain a dominant player, or it might merge with another technology. It is a safe bet that it will be an important tool for the next several years at least. In the short run, no single networked information retrieval scheme will meet all of the needs of the fast-growing body of Internet users. Notes 1. Steve Worona, personal e-mail message, 25 February 1993. 2. Billy Barron, personal e-mail message, 10 March 1993. 3. Marty Courtois, personal e-mail message, 26 February 1993. 4. Ibid. 5. Marie-Christine Mahe, personal e-mail message, 9 March 1993. 6. Nancy John, personal e-mail message, 2 March 1993. 7. Joel Cooper, personal e-mail message, 1 March 1993. 8. Martin Dillon, personal e-mail message, 9 March 1993. 9. Steve Worona, personal e-mail message, 25 February 1993. Bibliography Deutsch, Peter. "Resource Discovery in an Internet Environment-- The Archie Approach." Electronic Networking: Research, Applications and Policy 2, no. 1 (1992): 45-51. Berners-Lee, Tim et al. "World-Wide Web: The Information Universe." Electronic Networking: Research, Applications and Policy 2, no. 1 (1992): 52-58. Kahle, Brewster et al. "Wide Area Information Servers: An Executive Information System for Unstructured Files." Electronic Networking: Research, Applications and Policy 2, no. 1 (1992): 59-68. Lynch, Clifford A. "Information Retrieval as a Network Application." Library Hi Tech 8, no. 4 (1990): 57-72. + Page 55 + Scott, Peter. "Using HYTELNET to Access Internet Resources." The Public-Access Computer Systems Review 3, no. 4 (1992): 15-21. To retrieve this file, send the following e-mail message to LISTSERV@UHUPVM1.UH.EDU: GET SCOTT PRV3N4 F=MAIL. Glossary Anonymous FTP. Anonymous FTP servers allow users to retrieve files without the need for assigned user IDs (literally the word "anonymous" is used as the login ID). This service is offered by many sites on the Internet. Archie. A network service that allows users to discover which anonymous FTP sites house particular files of interest. Developed at McGill University (and now Bunyip Information Systems), future versions of Archie may allow searching for resources by abstract, author name, and other criteria. ASCII file. A file encoded in the 128-character ASCII (American Standard Code for Information Interchange) character set. The term "flat ASCII file" is often used to refer to a simple text file, with no embedded special formatting codes or binary data. In FTP transfers, "text" and "ASCII" are synonymous. Binary file. Binary files consist of streams of bytes whose meaning is defined by some external format standard. For example, executable computer programs are binary files. In FTP transfers, a binary file is specified by "bin" or "image" settings. Client/Server. A model for distributing system functions between client software, residing on a user's workstation, and server software, residing on a host. The host could be a UNIX workstation, a mainframe, or another type of computer. The client handles most of the information presentation functions, and the server handles most of the database functions. A protocol specifies how the two should communicate. The client/server model is growing in popularity as workstations and networks grow in power. CWIS (Campus-Wide Information System). A university or college information system that offers integrated access to documents (e.g., course schedules, lists of current events, and academic job openings) and systems (e.g., online catalog). CWISes began on mainframes and are now commonly implemented under the client/server model. Gopher and WWW are commonly used for CWISes; other CWISes exist (for instance, the TechInfo software from MIT). + Page 56 + CSO. A protocol that allows client/server searching of simple databases such as phone books. Named after the Computing Services Organization at the University of Illinois, the CSO protocol enjoys widespread usage in the Gopher community, despite more elaborate standards for such "white pages" services. (Sometimes called "CCSO.") Curses. A software feature under UNIX that allows a programmer to support full-screen terminal sessions. Said to be a play on words referring to the cursor keys. FAQ (Frequently Asked Question). Documents that list such questions and their answers are referred to as FAQs. Much of the documentation in the USENET world resides in FAQ files. FTP (File Transfer Protocol). A standard protocol for sending files from one computer to another on TCP/IP networks, such as the Internet. This is also the command the user usually types to start an FTP session. GIF (Graphics Interchange Format). A still-image file format promoted by CompuServe. Software to view GIF images is commonly available for most computing environments in the form of public domain, shareware, or commercial products. GNU. A project to deliver UNIX operating system clones and related tools as freely available software. (Stands for "GNU is Not UNIX.") Hypertext. A scheme for supporting embedded links within documents. While browsing a document with hypertext links, a user can select one of those links and quickly move to the document it points to. Popularized by the HyperCard Macintosh program. HYTELNET. A hypertext database of Internet systems, such as online catalogs and CWISes. The PC version of the program is available from Peter Scott at the University of Saskatchewan. The UNIX and VMS versions can make Internet connections to listed systems; the PC version cannot. IANA (Internet Assigned Numbers Authority). Internet protocol writers must agree upon standard values for fields used within the protocols. IANA is the organization that registers these standard numbers. For instance, IANA assigned TCP port 70 to Gopher. IANA will register MIME content types. + Page 57 + IETF (Internet Engineering Task Force). IETF devises new and updated protocols to be used on the Internet. It is an informal body composed of Working Groups that carry on discussions over the Internet and in periodic meetings. IP address. A unique number assigned to a computer on a TCP/IP network. Conventions have been set up to assign IP numbers in a systematic fashion across the Internet. Whether a machine is a large server or a small PC, if it is to be on the Internet, it must have an assigned IP address. IP addresses look like "35.8.2.61." There are always four numeric values, separated by periods, in IP addresses. JPEG (Joint Photographic Experts Group). A still-image file format that allows efficient compression. The JPEG compression scheme is "lossy"; it does not preserve all of the data, but it can yield significant space savings with little perceptible loss. JPEG viewers are relatively slow compared to GIF viewers. MIME (Multipurpose Internet Mail Extensions). Initially, an extension of Internet mail standards to allow binary data to be embedded in SMTP mail. Since its introduction in 1992, MIME has been implemented on several computer platforms (often under the name "Metamail"), and it is increasingly viewed as the appropriate standard for handling multimedia information to be moved across dissimilar computing environments, whether sent via e-mail or otherwise. Mosaic. An integrated client program developed by the National Center for Supercomputing Applications. Mosaic acts as a client for multiple Internet services, including Gopher, WAIS, WWW, USENET News, and FTP. Currently implemented on UNIX systems supporting X Windows and Motif. Versions of Mosaic for the Macintosh and Microsoft Windows are expected. PostScript. A printer description language from Adobe. PostScript is the dominant format used for desktop publishing. Documents in PostScript format are commonly shared across the Internet and printed on laser printers after retrieval from a remote archive. + Page 58 + PPP (Point-to-Point Protocol). A relatively new protocol that allows dial-up users to connect to the Internet. With PPP (or similar functionality) a user can use Internet client software, such as a Gopher client, in a dial-up session. Without PPP, the user must dial into a host or public client service via a terminal session (usually VT 100). RFC (Request for Comments). Documents that define both proposed and adopted Internet protocol standards. RFCs are numbered in an ordinal fashion. SGML (Standard Generalized Markup Language). SGML is a scheme (and an ISO standard) for embedding structural information within a document. SGML is popular in scholarly and electronic publishing as a way to support multiple views of a document. An SGML-compliant set of structures called HTML is used by World- Wide Web. SLIP (Serial Line IP). A protocol that allows dial-up users to connect to the Internet. Being supplanted by PPP. SMTP (Simple Mail Transfer Protocol). A protocol for sending e- mail messages between computers on TCP/IP networks, such as the Internet. The user does not run a program named SMTP; instead, various e-mail packages know how to utilize this protocol. TCP/IP (Transmission Control Protocol/Internet Protocol). Technically, TCP and IP are separate protocols; together they allow computers on the Internet to communicate by providing a reliable way for bytes to be delivered in order over a network connection. Connections are made to TCP "ports," allowing multiple connections per machine. A port is described by a number (e.g., Gopher servers typically use port 70). Telnet. The TCP/IP protocol for remote terminal sessions. Usually implemented as a command of the same name. TN3270. A variant of Telnet that allows TCP/IP connections to IBM mainframes that utilize 3270 terminal conventions. Uniform Resource Identifier. An umbrella term for standards that describe Internet resources in a uniform way. The IETF is considering a Uniform Resource Locator, which will a standard way to name a particular document on a particular network server. Another proposed standard, the Uniform Resource Number, will be a unique number (analogous to an ISBN) assigned to a document or resource regardless of its location and other resource descriptors. + Page 59 + USENET News. A distributed discussion list system, much of whose traffic is carried over the Internet. USENET News services consist of news "feeds" typically provided by one or more servers on a campus network, and news "readers" (i.e., client software that communicates with the server over a news delivery protocol). Veronica. A service that provides a Internet-wide index of Gopher document titles. Developed at the University of Nevada, Veronica servers periodically poll all the Gopher servers they can connect to and build a title index that can, in turn, be pointed to as a standard Gopher index. VT 100. The dominant communications protocol for full-screen terminal sessions. The VT 100 standard was defined by the Digital Equipment Corporation in the 70s. Most terminal emulation software packages (e.g., Kermit and PROCOMM) implement VT 100 or its descendants. WAIS (Wide Area Information Servers). Based on an extension the Z39.50-1988 standard, WAIS allows searches of documents on one or more WAIS servers. Originally promulgated by Thinking Machines Corporation, WAIS is now offered in a commercial version (by WAIS, Inc.) and a public domain version (by the Clearinghouse for Networked Information Discovery and Retrieval). The WAIS search engine is commonly used by Gopher servers. An index document under the UNIX Gopher server can point to a stand-alone WAIS server. World-Wide Web. A network-based hypertext document delivery system. Developed at CERN in Switzerland, WWW is growing in popularity. WWW supports embedded links to documents. Z39.50. A NISO standard defining a client/server model for searching bibliographic and other databases. Z39.58. A NISO standard describing a Common Command Language for online catalogs. + Page 60 + Note From the Author After this document has been distributed via The Public-Access Computer Systems Review, it will be made available on the central Gopher at Michigan State University (gopher.msu.edu, port 70). It will be placed under the "More About Gopher" folder. About the Author Rich Wiggins, Gopher Coordinator, Michigan State University Computer Laboratory. Voice: (517) 353-4955. Internet: RWWMAINT@MSU.EDU. ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive two electronic newsletters: Current Cites and Public- Access Computer Systems News. This article is Copyright (C) 1993 by Rich Wiggins. All Rights Reserved. The Public-Access Computer Systems Review is Copyright (C) 1993 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. -----------------------------------------------------------------