rfc1436.txt - gopher-protocol - Gopher Protocol Extension Project
HTML git clone git://bitreich.org/gopher-protocol git://enlrupgkhuxnvlhsf6lc3fziv5h2hhfrinws65d7roiv6bfj7d652fid.onion/gopher-protocol
DIR Log
DIR Files
DIR Refs
DIR Tags
DIR README
DIR 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: fxa@boombox.micro.umn.edu
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: mpm@boombox.micro.umn.edu
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: lindner@boombox.micro.umn.edu
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: dmj@boombox.micro.umn.edu
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: daniel@boombox.micro.umn.edu
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: alberti@boombox.micro.umn.edu
895
896
897
898 Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 16]
899
900
901
902
903
904
905
906