rfc1436.txt - gopher-protocol - Gopher Protocol Extension Project | |
git clone git://bitreich.org/gopher-protocol git://enlrupgkhuxnvlhsf6lc3fziv5h2… | |
Log | |
Files | |
Refs | |
Tags | |
README | |
LICENSE | |
--- | |
rfc1436.txt (36501B) | |
--- | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 Network Working Group F. Anklesaria | |
8 Request for Comments: 1436 M. McCahill | |
9 P. Lindner | |
10 D. Johnson | |
11 D. Torrey | |
12 B. Alberti | |
13 University of Minnesota | |
14 March 1993 | |
15 | |
16 | |
17 The Internet Gopher Protocol | |
18 (a distributed document search and retrieval protocol) | |
19 | |
20 Status of this Memo | |
21 | |
22 This memo provides information for the Internet community. It does | |
23 not specify an Internet standard. Distribution of this memo is | |
24 unlimited. | |
25 | |
26 Abstract | |
27 | |
28 The Internet Gopher protocol is designed for distributed document | |
29 search and retrieval. This document describes the protocol, lists | |
30 some of the implementations currently available, and has an overview | |
31 of how to implement new client and server applications. This | |
32 document is adapted from the basic Internet Gopher protocol document | |
33 first issued by the Microcomputer Center at the University of | |
34 Minnesota in 1991. | |
35 | |
36 Introduction | |
37 | |
38 gopher n. 1. Any of various short tailed, burrowing mammals of the | |
39 family Geomyidae, of North America. 2. (Amer. colloq.) Native or | |
40 inhabitant of Minnesota: the Gopher State. 3. (Amer. colloq.) One | |
41 who runs errands, does odd-jobs, fetches or delivers documents for | |
42 office staff. 4. (computer tech.) software following a simple | |
43 protocol for burrowing through a TCP/IP internet. | |
44 | |
45 The Internet Gopher protocol and software follow a client-server | |
46 model. This protocol assumes a reliable data stream; TCP is assumed. | |
47 Gopher servers should listen on port 70 (port 70 is assigned to | |
48 Internet Gopher by IANA). Documents reside on many autonomous | |
49 servers on the Internet. Users run client software on their desktop | |
50 systems, connecting to a server and sending the server a selector (a | |
51 line of text, which may be empty) via a TCP connection at a well- | |
52 known port. The server responds with a block of text terminated by a | |
53 period on a line by itself and closes the connection. No state is | |
54 retained by the server. | |
55 | |
56 | |
57 | |
58 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 1] | |
59 | |
60 RFC 1436 Gopher March 1993 | |
61 | |
62 | |
63 While documents (and services) reside on many servers, Gopher client | |
64 software presents users with a hierarchy of items and directories | |
65 much like a file system. The Gopher interface is designed to | |
66 resemble a file system since a file system is a good model for | |
67 organizing documents and services; the user sees what amounts to one | |
68 big networked information system containing primarily document items, | |
69 directory items, and search items (the latter allowing searches for | |
70 documents across subsets of the information base). | |
71 | |
72 Servers return either directory lists or documents. Each item in a | |
73 directory is identified by a type (the kind of object the item is), | |
74 user-visible name (used to browse and select from listings), an | |
75 opaque selector string (typically containing a pathname used by the | |
76 destination host to locate the desired object), a host name (which | |
77 host to contact to obtain this item), and an IP port number (the port | |
78 at which the server process listens for connections). The user only | |
79 sees the user-visible name. The client software can locate and | |
80 retrieve any item by the trio of selector, hostname, and port. | |
81 | |
82 To use a search item, the client submits a query to a special kind of | |
83 Gopher server: a search server. In this case, the client sends the | |
84 selector string (if any) and the list of words to be matched. The | |
85 response yields "virtual directory listings" that contain items | |
86 matching the search criteria. | |
87 | |
88 Gopher servers and clients exist for all popular platforms. Because | |
89 the protocol is so sparse and simple, writing servers or clients is | |
90 quick and straightforward. | |
91 | |
92 1. Introduction | |
93 | |
94 The Internet Gopher protocol is designed primarily to act as a | |
95 distributed document delivery system. While documents (and services) | |
96 reside on many servers, Gopher client software presents users with a | |
97 hierarchy of items and directories much like a file system. In fact, | |
98 the Gopher interface is designed to resemble a file system since a | |
99 file system is a good model for locating documents and services. Why | |
100 model a campus-wide information system after a file system? Several | |
101 reasons: | |
102 | |
103 (a) A hierarchical arrangement of information is familiar to many | |
104 users. Hierarchical directories containing items (such as | |
105 documents, servers, and subdirectories) are widely used in | |
106 electronic bulletin boards and other campus-wide information | |
107 systems. People who access a campus-wide information server will | |
108 expect some sort of hierarchical organization to the information | |
109 presented. | |
110 | |
111 | |
112 | |
113 | |
114 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 2] | |
115 | |
116 RFC 1436 Gopher March 1993 | |
117 | |
118 | |
119 (b) A file-system style hierarchy can be expressed in a simple | |
120 syntax. The syntax used for the internet Gopher protocol is | |
121 easily understandable, and was designed to make debugging servers | |
122 and clients easy. You can use Telnet to simulate an internet | |
123 Gopher client's requests and observe the responses from a server. | |
124 Special purpose software tools are not required. By keeping the | |
125 syntax of the pseudo-file system client/server protocol simple, we | |
126 can also achieve better performance for a very common user | |
127 activity: browsing through the directory hierarchy. | |
128 | |
129 (c) Since Gopher originated in a University setting, one of the | |
130 goals was for departments to have the option of publishing | |
131 information from their inexpensive desktop machines, and since | |
132 much of the information can be presented as simple text files | |
133 arranged in directories, a protocol modeled after a file system | |
134 has immediate utility. Because there can be a direct mapping from | |
135 the file system on the user's desktop machine to the directory | |
136 structure published via the Gopher protocol, the problem of | |
137 writing server software for slow desktop systems is minimized. | |
138 | |
139 (d) A file system metaphor is extensible. By giving a "type" | |
140 attribute to items in the pseudo-file system, it is possible to | |
141 accommodate documents other than simple text documents. Complex | |
142 database services can be handled as a separate type of item. A | |
143 file-system metaphor does not rule out search or database-style | |
144 queries for access to documents. A search-server type is also | |
145 defined in this pseudo-file system. Such servers return "virtual | |
146 directories" or list of documents matching user specified | |
147 criteria. | |
148 | |
149 2. The internet Gopher Model | |
150 | |
151 A detailed BNF rendering of the internet Gopher syntax is available | |
152 in the appendix...but a close reading of the appendix may not be | |
153 necessary to understand the internet Gopher protocol. | |
154 | |
155 In essence, the Gopher protocol consists of a client connecting to a | |
156 server and sending the server a selector (a line of text, which may | |
157 be empty) via a TCP connection. The server responds with a block of | |
158 text terminated with a period on a line by itself, and closes the | |
159 connection. No state is retained by the server between transactions | |
160 with a client. The simple nature of the protocol stems from the need | |
161 to implement servers and clients for the slow, smaller desktop | |
162 computers (1 MB Macs and DOS machines), quickly, and efficiently. | |
163 | |
164 Below is a simple example of a client/server interaction; more | |
165 complex interactions are dealt with later. Assume that a "well- | |
166 known" Gopher server (this may be duplicated, details are discussed | |
167 | |
168 | |
169 | |
170 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 3] | |
171 | |
172 RFC 1436 Gopher March 1993 | |
173 | |
174 | |
175 later) listens at a well known port for the campus (much like a | |
176 domain-name server). The only configuration information the client | |
177 software retains is this server's name and port number (in this | |
178 example that machine is rawBits.micro.umn.edu and the port 70). In | |
179 the example below the F character denotes the TAB character. | |
180 | |
181 Client: {Opens connection to rawBits.micro.umn.edu at port 70} | |
182 | |
183 Server: {Accepts connection but says nothing} | |
184 | |
185 Client: <CR><LF> {Sends an empty line: Meaning "list what you have"} | |
186 | |
187 Server: {Sends a series of lines, each ending with CR LF} | |
188 0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70 | |
189 1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70 | |
190 1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70 | |
191 1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120 | |
192 1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70 | |
193 1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70 | |
194 {.....etc.....} | |
195 . {Period on a line by itself} | |
196 {Server closes connection} | |
197 | |
198 | |
199 The first character on each line tells whether the line describes a | |
200 document, directory, or search service (characters '0', '1', '7'; | |
201 there are a handful more of these characters described later). The | |
202 succeeding characters up to the tab form a user display string to be | |
203 shown to the user for use in selecting this document (or directory) | |
204 for retrieval. The first character of the line is really defining | |
205 the type of item described on this line. In nearly every case, the | |
206 Gopher client software will give the users some sort of idea about | |
207 what type of item this is (by displaying an icon, a short text tag, | |
208 or the like). | |
209 | |
210 The characters following the tab, up to the next tab form a selector | |
211 string that the client software must send to the server to retrieve | |
212 the document (or directory listing). The selector string should mean | |
213 nothing to the client software; it should never be modified by the | |
214 client. In practice, the selector string is often a pathname or | |
215 other file selector used by the server to locate the item desired. | |
216 The next two tab delimited fields denote the domain-name of the host | |
217 that has this document (or directory), and the port at which to | |
218 connect. If there are yet other tab delimited fields, the basic | |
219 Gopher client should ignore them. A CR LF denotes the end of the | |
220 item. | |
221 | |
222 | |
223 | |
224 | |
225 | |
226 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 4] | |
227 | |
228 RFC 1436 Gopher March 1993 | |
229 | |
230 | |
231 In the example, line 1 describes a document the user will see as | |
232 "About internet Gopher". To retrieve this document, the client | |
233 software must send the retrieval string: "Stuff:About us" to | |
234 rawBits.micro.umn.edu at port 70. If the client does this, the | |
235 server will respond with the contents of the document, terminated by | |
236 a period on a line by itself. A client might present the user with a | |
237 view of the world something like the following list of items: | |
238 | |
239 | |
240 About Internet Gopher | |
241 Around the University of Minnesota... | |
242 Microcomputer News & Prices... | |
243 Courses, Schedules, Calendars... | |
244 Student-Staff Directories... | |
245 Departmental Publications... | |
246 | |
247 | |
248 | |
249 In this case, directories are displayed with an ellipsis and files | |
250 are displayed without any. However, depending on the platform the | |
251 client is written for and the author's taste, item types could be | |
252 denoted by other text tags or by icons. For example, the UNIX | |
253 curses-based client displays directories with a slash (/) following | |
254 the name; Macintosh clients display directories alongside an icon of | |
255 a folder. | |
256 | |
257 The user does not know or care that the items up for selection may | |
258 reside on many different machines anywhere on the Internet. | |
259 | |
260 Suppose the user selects the line "Microcomputer News & Prices...". | |
261 This appears to be a directory, and so the user expects to see | |
262 contents of the directory upon request that it be fetched. The | |
263 following lines illustrate the ensuing client-server interaction: | |
264 | |
265 | |
266 Client: (Connects to pserver.bookstore.umn.edu at port 70) | |
267 Server: (Accepts connection but says nothing) | |
268 Client: Prices/ (Sends the magic string terminated by CRLF) | |
269 Server: (Sends a series of lines, each ending with CR LF) | |
270 0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70 | |
271 0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70 | |
272 0IBM PricesFPrices/IckFpserver.bookstore.umn.eduF70 | |
273 0Printer & Peripheral PricesFPrices/PPPFpserver.bookstore.umn.eduF70 | |
274 (.....etc.....) | |
275 . (Period on a line by itself) | |
276 (Server closes connection) | |
277 | |
278 | |
279 | |
280 | |
281 | |
282 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 5] | |
283 | |
284 RFC 1436 Gopher March 1993 | |
285 | |
286 | |
287 3. More details | |
288 | |
289 3.1 Locating services | |
290 | |
291 Documents (or other services that may be viewed ultimately as | |
292 documents, such as a student-staff phonebook) are linked to the | |
293 machine they are on by the trio of selector string, machine domain- | |
294 name, and IP port. It is assumed that there will be one well-known | |
295 top-level or root server for an institution or campus. The | |
296 information on this server may be duplicated by one or more other | |
297 servers to avoid a single point of failure and to spread the load | |
298 over several servers. Departments that wish to put up their own | |
299 departmental servers need to register the machine name and port with | |
300 the administrators of the top-level Gopher server, much the same way | |
301 as they register a machine name with the campus domain-name server. | |
302 An entry which points to the departmental server will then be made at | |
303 the top level server. This ensures that users will be able to | |
304 navigate their way down what amounts to a virtual hierarchical file | |
305 system with a well known root to any campus server if they desire. | |
306 | |
307 Note that there is no requirement that a department register | |
308 secondary servers with the central top-level server; they may just | |
309 place a link to the secondary servers in their own primary servers. | |
310 They may indeed place links to any servers they desire in their own | |
311 server, thus creating a customized view of thethe Gopher information | |
312 universe; links can of course point back at the top-level server. | |
313 The virtual (networked) file system is therefore an arbitrary graph | |
314 structure and not necessarily a rooted tree. The top-level node is | |
315 merely one convenient, well-known point of entry. A set of Gopher | |
316 servers linked in this manner may function as a campus-wide | |
317 information system. | |
318 | |
319 Servers may of course point links at other than secondary servers. | |
320 Indeed servers may point at other servers offering useful services | |
321 anywhere on the internet. Viewed in this manner, Gopher can be seen | |
322 as an Internet-wide information system. | |
323 | |
324 3.2 Server portability and naming | |
325 | |
326 It is recommended that all registered servers have alias names | |
327 (domain name system CNAME) that are used by Gopher clients to locate | |
328 them. Links to these servers should use these alias names rather | |
329 than the primary names. If information needs to be moved from one | |
330 machine to another, a simple change of domain name system alias | |
331 (CNAME) allows this to occur without any reconfiguration of clients | |
332 in the field. In short, the domain name system may be used to re-map | |
333 a server to a new address. There is nothing to prevent secondary | |
334 servers or services from running on otherwise named servers or ports | |
335 | |
336 | |
337 | |
338 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 6] | |
339 | |
340 RFC 1436 Gopher March 1993 | |
341 | |
342 | |
343 other than 70, however these should be reachable via a primary | |
344 server. | |
345 | |
346 3.3 Contacting server administrators | |
347 | |
348 It is recommended that every server administrator have a document | |
349 called something like: "About Bogus University's Gopher server" as | |
350 the first item in their server's top level directory. In this | |
351 document should be a short description of what the server holds, as | |
352 well as name, address, phone, and an e-mail address of the person who | |
353 administers the server. This provides a way for users to get word to | |
354 the administrator of a server that has inaccurate information or is | |
355 not running correctly. It is also recommended that administrators | |
356 place the date of last update in files for which such information | |
357 matters to the users. | |
358 | |
359 3.4 Modular addition of services | |
360 | |
361 The first character of each line in a server-supplied directory | |
362 listing indicates whether the item is a file (character '0'), a | |
363 directory (character '1'), or a search (character '7'). This is the | |
364 base set of item types in the Gopher protocol. It is desirable for | |
365 clients to be able to use different services and speak different | |
366 protocols (simple ones such as finger; others such as CSO phonebook | |
367 service, or Telnet, or X.500 directory service) as needs dictate. | |
368 CSO phonebook service is a client/server phonebook system typically | |
369 used at Universities to publish names, e-mail addresses, and so on. | |
370 The CSO phonebook software was developed at the University of | |
371 Illinois and is also sometimes refered to as ph or qi. For example, | |
372 if a server-supplied directory listing marks a certain item with type | |
373 character '2', then it means that to use this item, the client must | |
374 speak the CSO protocol. This removes the need to be able to | |
375 anticipate all future needs and hard-wire them in the basic Internet | |
376 Gopher protocol; it keeps the basic protocol extremely simple. In | |
377 spite of this simplicity, the scheme has the capability to expand and | |
378 change with the times by adding an agreed upon type-character for a | |
379 new service. This also allows the client implementations to evolve | |
380 in a modular fashion, simply by dropping in a module (or launching a | |
381 new process) for some new service. The servers for the new service | |
382 of course have to know nothing about Internet Gopher; they can just | |
383 be off-the shelf CSO, X.500, or other servers. We do not however, | |
384 encourage arbitrary or machine-specific proliferation of service | |
385 types in the basic Gopher protocol. | |
386 | |
387 On the other hand, subsets of other document retrieval schemes may be | |
388 mapped onto the Gopher protocol by means of "gateway-servers". | |
389 Examples of such servers include Gopher-to-FTP gateways, Gopher-to- | |
390 archie gateways, Gopher-to-WAIS gateways, etc. There are a number of | |
391 | |
392 | |
393 | |
394 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 7] | |
395 | |
396 RFC 1436 Gopher March 1993 | |
397 | |
398 | |
399 advantages of such mechanisms. First, a relatively powerful server | |
400 machine inherits both the intelligence and work, rather than the more | |
401 modest, inexpensive desktop system that typically runs client | |
402 software or basic server software. Equally important, clients do not | |
403 have to be modified to take advantage of a new resource. | |
404 | |
405 3.5 Building clients | |
406 | |
407 A client simply sends the retrieval string to a server if it wants to | |
408 retrieve a document or view the contents of a directory. Of course, | |
409 each host may have pointers to other hosts, resulting in a "graph" | |
410 (not necessarily a rooted tree) of hosts. The client software may | |
411 save (or rather "stack") the locations that it has visited in search | |
412 of a document. The user could therefore back out of the current | |
413 location by unwinding the stack. Alternatively, a client with | |
414 multiple-window capability might just be able to display more than | |
415 one directory or document at the same time. | |
416 | |
417 A smart client could cache the contents of visited directories | |
418 (rather than just the directory's item descriptor), thus avoiding | |
419 network transactions if the information has been previously | |
420 retrieved. | |
421 | |
422 If a client does not understand what a say, type 'B' item (not a core | |
423 item) is, then it may simply ignore the item in the directory | |
424 listing; the user never even has to see it. Alternatively, the item | |
425 could be displayed as an unknown type. | |
426 | |
427 Top-level or primary servers for a campus are likely to get more | |
428 traffic than secondary servers, and it would be less tolerable for | |
429 such primary servers to be down for any long time. So it makes sense | |
430 to "clone" such important servers and construct clients that can | |
431 randomly choose between two such equivalent primary servers when they | |
432 first connect (to balance server load), moving to one if the other | |
433 seems to be down. In fact, smart client implementations do this | |
434 clone server and load balancing. Alternatively, it may make sense to | |
435 have the domain name system return one of a set of redundant of | |
436 server's IP address to load balance betwen redundant sets of | |
437 important servers. | |
438 | |
439 3.6 Building ordinary internet Gopher servers | |
440 | |
441 The retrieval string sent to the server might be a path to a file or | |
442 directory. It might be the name of a script, an application or even | |
443 a query that generates the document or directory returned. The basic | |
444 server uses the string it gets up to but not including a CR-LF or a | |
445 TAB, whichever comes first. | |
446 | |
447 | |
448 | |
449 | |
450 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 8] | |
451 | |
452 RFC 1436 Gopher March 1993 | |
453 | |
454 | |
455 All intelligence is carried by the server implementation rather than | |
456 the protocol. What you build into more exotic servers is up to you. | |
457 Server implementations may grow as needs dictate and time allows. | |
458 | |
459 3.7 Special purpose servers | |
460 | |
461 There are two special server types (beyond the normal Gopher server) | |
462 also discussed below: | |
463 | |
464 1. A server directory listing can point at a CSO nameserver (the | |
465 server returns a type character of '2') to allow a campus | |
466 student-staff phonebook lookup service. This may show up on the | |
467 user's list of choices, perhaps preceded by the icon of a phone- | |
468 book. If this item is selected, the client software must resort | |
469 to a pure CSO nameserver protocol when it connects to the | |
470 appropriate host. | |
471 | |
472 2. A server can also point at a "search server" (returns a first | |
473 character of '7'). Such servers may implement campus network (or | |
474 subnet) wide searching capability. The most common search servers | |
475 maintain full-text indexes on the contents of text documents held | |
476 by some subset of Gopher servers. Such a "full-text search | |
477 server" responds to client requests with a list of all documents | |
478 that contain one or more words (the search criteria). The client | |
479 sends the server the selector string, a tab, and the search string | |
480 (words to search for). If the selector string is empty, the client | |
481 merely sends the search string. The server returns the equivalent | |
482 of a directory listing for documents matching the search criteria. | |
483 Spaces between words are usually implied Boolean ANDs (although in | |
484 different implementations or search types, this may not | |
485 necessarily be true). | |
486 | |
487 The CSO addition exists for historical reasons: at time of design, | |
488 the campus phone-book servers at the University of Minnesota used the | |
489 CSO protocol and it seemed simplest to just engulf them. The index- | |
490 server is however very much a Gopher in spirit, albeit with a slight | |
491 twist in the meaning of the selector-string. Index servers are a | |
492 natural place to incorperate gateways to WAIS and WHOIS services. | |
493 | |
494 3.7.1 Building CSO-servers | |
495 | |
496 A CSO Nameserver implementation for UNIX and associated documentation | |
497 is available by anonymous ftp from uxa.cso.uiuc.edu. We do not | |
498 anticipate implementing it on other machines. | |
499 | |
500 | |
501 | |
502 | |
503 | |
504 | |
505 | |
506 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 9] | |
507 | |
508 RFC 1436 Gopher March 1993 | |
509 | |
510 | |
511 3.7.2 Building full-text search servers | |
512 | |
513 A full-text search server is a special-purpose server that knows | |
514 about the Gopher scheme for retrieving documents. These servers | |
515 maintain a full-text index of the contents of plain text documents on | |
516 Gopher servers in some specified domain. A Gopher full-text search | |
517 server was implemented using several NeXTstations because it was easy | |
518 to take advantage of the full-text index/search engine built into the | |
519 NeXT system software. A search server for generic UNIX systems based | |
520 on the public domain WAIS search engine, is also available and | |
521 currently an optional part of the UNIX gopher server. In addition, | |
522 at least one implementation of the gopher server incorperates a | |
523 gateway to WAIS servers by presenting the WAIS servers to gopherspace | |
524 as full-text search servers. The gopher<->WAIS gateway servers does | |
525 the work of translating from gopher protocol to WAIS so unmodified | |
526 gopher clients can access WAIS servers via the gateway server. | |
527 | |
528 By using several index servers (rather than a monolithic index | |
529 server) indexes may be searched in parallel (although the client | |
530 software is not aware of this). While maintaining full-text indexes | |
531 of documents distributed over many machines may seem a daunting task, | |
532 the task can be broken into smaller pieces (update only a portion of | |
533 the indexes, search several partial indexes in parallel) so that it | |
534 is manageable. By spreading this task over several small, cheap (and | |
535 fast) workstations it is possible to take advantage of fine-grain | |
536 parallelism. Again, the client software is not aware of this. Client | |
537 software only needs to know that it can send a search string to an | |
538 index server and will receive a list of documents that contain the | |
539 words in the search string. | |
540 | |
541 3.8 Item type characters | |
542 | |
543 The client software decides what items are available by looking at | |
544 the first character of each line in a directory listing. Augmenting | |
545 this list can extend the protocol. A list of defined item-type | |
546 characters follows: | |
547 | |
548 0 Item is a file | |
549 1 Item is a directory | |
550 2 Item is a CSO phone-book server | |
551 3 Error | |
552 4 Item is a BinHexed Macintosh file. | |
553 5 Item is DOS binary archive of some sort. | |
554 Client must read until the TCP connection closes. Beware. | |
555 6 Item is a UNIX uuencoded file. | |
556 7 Item is an Index-Search server. | |
557 8 Item points to a text-based telnet session. | |
558 9 Item is a binary file! | |
559 | |
560 | |
561 | |
562 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 10] | |
563 | |
564 RFC 1436 Gopher March 1993 | |
565 | |
566 | |
567 Client must read until the TCP connection closes. Beware. | |
568 + Item is a redundant server | |
569 T Item points to a text-based tn3270 session. | |
570 g Item is a GIF format graphics file. | |
571 I Item is some kind of image file. Client decides how to display. | |
572 | |
573 Characters '0' through 'Z' are reserved. Local experiments should | |
574 use other characters. Machine-specific extensions are not | |
575 encouraged. Note that for type 5 or type 9 the client must be | |
576 prepared to read until the connection closes. There will be no | |
577 period at the end of the file; the contents of these files are binary | |
578 and the client must decide what to do with them based perhaps on the | |
579 .xxx extension. | |
580 | |
581 3.9 User display strings and server selector strings | |
582 | |
583 User display strings are intended to be displayed on a line on a | |
584 typical screen for a user's viewing pleasure. While many screens can | |
585 accommodate 80 character lines, some space is needed to display a tag | |
586 of some sort to tell the user what sort of item this is. Because of | |
587 this, the user display string should be kept under 70 characters in | |
588 length. Clients may truncate to a length convenient to them. | |
589 | |
590 4. Simplicity is intentional | |
591 | |
592 As far as possible we desire any new features to be carried as new | |
593 protocols that will be hidden behind new document-types. The | |
594 internet Gopher philosophy is: | |
595 | |
596 (a) Intelligence is held by the server. Clients have the option | |
597 of being able to access new document types (different, other types | |
598 of servers) by simply recognizing the document-type character. | |
599 Further intelligence to be borne by the protocol should be | |
600 minimized. | |
601 | |
602 (b) The well-tempered server ought to send "text" (unless a file | |
603 must be transferred as raw binary). Should this text include | |
604 tabs, formfeeds, frufru? Probably not, but rude servers will | |
605 probably send them anyway. Publishers of documents should be | |
606 given simple tools (filters) that will alert them if there are any | |
607 funny characters in the documents they wish to publish, and give | |
608 them the opportunity to strip the questionable characters out; the | |
609 publisher may well refuse. | |
610 | |
611 (c) The well-tempered client should do something reasonable with | |
612 funny characters received in text; filter them out, leave them in, | |
613 whatever. | |
614 | |
615 | |
616 | |
617 | |
618 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 11] | |
619 | |
620 RFC 1436 Gopher March 1993 | |
621 | |
622 | |
623 Appendix | |
624 | |
625 Paul's NQBNF (Not Quite BNF) for the Gopher Protocol. | |
626 | |
627 Note: This is modified BNF (as used by the Pascal people) with a few | |
628 English modifiers thrown in. Stuff enclosed in '{}' can be | |
629 repeated zero or more times. Stuff in '[]' denotes a set of | |
630 items. The '-' operator denotes set subtraction. | |
631 | |
632 | |
633 Directory Entity | |
634 | |
635 CR-LF ::= ASCII Carriage Return Character followed by Line Feed | |
636 character. | |
637 | |
638 Tab ::= ASCII Tab character. | |
639 | |
640 NUL ::= ASCII NUL character. | |
641 | |
642 UNASCII ::= ASCII - [Tab CR-LF NUL]. | |
643 | |
644 Lastline ::= '.'CR-LF. | |
645 | |
646 TextBlock ::= Block of ASCII text not containing Lastline pattern. | |
647 | |
648 Type ::= UNASCII. | |
649 | |
650 RedType ::= '+'. | |
651 | |
652 User_Name ::= {UNASCII}. | |
653 | |
654 Selector ::= {UNASCII}. | |
655 | |
656 Host ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}. | |
657 | |
658 Note: This is a Fully Qualified Domain Name as defined in RFC 1034. | |
659 (e.g., gopher.micro.umn.edu) Hosts that have a CR-LF | |
660 TAB or NUL in their name get what they deserve. | |
661 | |
662 Digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' . | |
663 | |
664 DigitSeq ::= digit {digit}. | |
665 | |
666 Port ::= DigitSeq. | |
667 | |
668 Note: Port corresponds the the TCP Port Number, its value should | |
669 be in the range [0..65535]; port 70 is officially assigned | |
670 to gopher. | |
671 | |
672 | |
673 | |
674 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 12] | |
675 | |
676 RFC 1436 Gopher March 1993 | |
677 | |
678 | |
679 DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF | |
680 {RedType User_Name Tab Selector Tab Host Tab Port CR-LF} | |
681 | |
682 | |
683 | |
684 Notes: | |
685 | |
686 It is *highly* recommended that the User_Name field contain only | |
687 printable characters, since many different clients will be using | |
688 it. However if eight bit characters are used, the characters | |
689 should conform with the ISO Latin1 Character Set. The length of | |
690 the User displayable line should be less than 70 Characters; longer | |
691 lines may not fit across some screens. | |
692 | |
693 The Selector string should be no longer than 255 characters. | |
694 | |
695 | |
696 Menu Entity | |
697 | |
698 Menu ::= {DirEntity} Lastline. | |
699 | |
700 | |
701 Menu Transaction (Type 1 item) | |
702 | |
703 C: Opens Connection | |
704 S: Accepts Connection | |
705 C: Sends Selector String | |
706 S: Sends Menu Entity | |
707 | |
708 Connection is closed by either client or server (typically server). | |
709 | |
710 | |
711 Textfile Entity | |
712 | |
713 TextFile ::= {TextBlock} Lastline | |
714 | |
715 Note: Lines beginning with periods must be prepended with an extra | |
716 period to ensure that the transmission is not terminated early. | |
717 The client should strip extra periods at the beginning of the line. | |
718 | |
719 | |
720 TextFile Transaction (Type 0 item) | |
721 | |
722 C: Opens Connection. | |
723 S: Accepts connection | |
724 C: Sends Selector String. | |
725 S: Sends TextFile Entity. | |
726 | |
727 | |
728 | |
729 | |
730 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 13] | |
731 | |
732 RFC 1436 Gopher March 1993 | |
733 | |
734 | |
735 Connection is closed by either client or server (typically server). | |
736 | |
737 Note: The client should be prepared for the server closing the | |
738 connection without sending the Lastline. This allows the | |
739 client to use fingerd servers. | |
740 | |
741 | |
742 Full-Text Search Transaction (Type 7 item) | |
743 | |
744 Word ::= {UNASCII - ' '} | |
745 BoolOp ::= 'and' | 'or' | 'not' | SPACE | |
746 SearchStr ::= Word {{SPACE BoolOp} SPACE Word} | |
747 | |
748 C: Opens Connection. | |
749 C: Sends Selector String, Tab, Search String. | |
750 S: Sends Menu Entity. | |
751 | |
752 Note: In absence of 'and', 'or', or 'not' operators, a SPACE is | |
753 regarded as an implied 'and' operator. Expression is evaluated | |
754 left to right. Further, not all search engines or search | |
755 gateways currently implemented have the boolean operators | |
756 implemented. | |
757 | |
758 Binary file Transaction (Type 9 or 5 item) | |
759 | |
760 C: Opens Connection. | |
761 S: Accepts connection | |
762 C: Sends Selector String. | |
763 S: Sends a binary file and closes connection when done. | |
764 | |
765 | |
766 Syntactic Meaning for Directory Entities | |
767 | |
768 | |
769 The client should interpret the type field as follows: | |
770 | |
771 0 The item is a TextFile Entity. | |
772 Client should use a TextFile Transaction. | |
773 | |
774 1 The item is a Menu Entity. | |
775 Client should use a Menu Transaction. | |
776 | |
777 2 The information applies to a CSO phone book entity. | |
778 Client should talk CSO protocol. | |
779 | |
780 3 Signals an error condition. | |
781 | |
782 4 Item is a Macintosh file encoded in BINHEX format | |
783 | |
784 | |
785 | |
786 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 14] | |
787 | |
788 RFC 1436 Gopher March 1993 | |
789 | |
790 | |
791 5 Item is PC-DOS binary file of some sort. Client gets to decide. | |
792 | |
793 6 Item is a uuencoded file. | |
794 | |
795 7 The information applies to a Index Server. | |
796 Client should use a FullText Search transaction. | |
797 | |
798 8 The information applies to a Telnet session. | |
799 Connect to given host at given port. The name to login as at this | |
800 host is in the selector string. | |
801 | |
802 9 Item is a binary file. Client must decide what to do with it. | |
803 | |
804 + The information applies to a duplicated server. The information | |
805 contained within is a duplicate of the primary server. The primary | |
806 server is defined as the last DirEntity that is has a non-plus | |
807 "Type" field. The client should use the transaction as defined by | |
808 the primary server Type field. | |
809 | |
810 g Item is a GIF graphic file. | |
811 | |
812 I Item is some kind of image file. Client gets to decide. | |
813 | |
814 T The information applies to a tn3270 based telnet session. | |
815 Connect to given host at given port. The name to login as at this | |
816 host is in the selector string. | |
817 | |
818 Security Considerations | |
819 | |
820 Security issues are not discussed in this memo. | |
821 | |
822 Authors' Addresses | |
823 | |
824 Farhad Anklesaria | |
825 Computer and Information Services, University of Minnesota | |
826 Room 152 Shepherd Labs | |
827 100 Union Street SE | |
828 Minneapolis, MN 55455 | |
829 | |
830 Phone: (612) 625 1300 | |
831 EMail: [email protected] | |
832 | |
833 | |
834 | |
835 | |
836 | |
837 | |
838 | |
839 | |
840 | |
841 | |
842 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 15] | |
843 | |
844 RFC 1436 Gopher March 1993 | |
845 | |
846 | |
847 Mark McCahill | |
848 Computer and Information Services, University of Minnesota | |
849 Room 152 Shepherd Labs | |
850 100 Union Street SE | |
851 Minneapolis, MN 55455 | |
852 | |
853 Phone: (612) 625 1300 | |
854 EMail: [email protected] | |
855 | |
856 | |
857 Paul Lindner | |
858 Computer and Information Services, University of Minnesota | |
859 Room 152 Shepherd Labs | |
860 100 Union Street SE | |
861 Minneapolis, MN 55455 | |
862 | |
863 Phone: (612) 625 1300 | |
864 EMail: [email protected] | |
865 | |
866 | |
867 David Johnson | |
868 Computer and Information Services, University of Minnesota | |
869 Room 152 Shepherd Labs | |
870 100 Union Street SE | |
871 Minneapolis, MN 55455 | |
872 | |
873 Phone: (612) 625 1300 | |
874 EMail: [email protected] | |
875 | |
876 | |
877 Daniel Torrey | |
878 Computer and Information Services, University of Minnesota | |
879 Room 152 Shepherd Labs | |
880 100 Union Street SE | |
881 Minneapolis, MN 55455 | |
882 | |
883 Phone: (612) 625 1300 | |
884 EMail: [email protected] | |
885 | |
886 | |
887 Bob Alberti | |
888 Computer and Information Services, University of Minnesota | |
889 Room 152 Shepherd Labs | |
890 100 Union Street SE | |
891 Minneapolis, MN 55455 | |
892 | |
893 Phone: (612) 625 1300 | |
894 EMail: [email protected] | |
895 | |
896 | |
897 | |
898 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 16] | |
899 | |
900 | |
901 | |
902 | |
903 | |
904 | |
905 | |
906 |