gopherplus.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
---
gopherplus.txt (34845B)
---
1
2 Gopher+
3
4
5 upward compatible enhancements to
6 the Internet Gopher protocol
7
8
9
10 Farhad Anklesaria, Paul Lindner, Mark P. McCahill,
11 Daniel Torrey, David Johnson, Bob Alberti
12
13 Microcomputer and Workstation Networks Center /
14 Computer and Information Systems
15 University of Minnesota
16
17 July 30, 1993
18
19
20
21 gopher+ n. 1. Hardier strains of mammals of the
22 family Geomyidae. 2. (Amer. colloq.) Native or
23 inhabitant of Minnesota, the Gopher state, in full
24 winter regalia (see PARKA). 3. (Amer. colloq.)
25 Executive secretary. 4. (computer tech.) Software
26 following a simple protocol for burrowing through a
27 TCP/IP internet, made more powerful by simple
28 enhancements (see CREEPING FEATURISM).
29
30
31 Abstract
32
33 The internet Gopher protocol was designed for
34 distributed document search and retrieval. The
35 documents "The internet Gopher protocol: a
36 distributed document search and retrieval protocol"
37 and internet RFC 1436 describe the basic protocol and
38 has an overview of how to implement new client and
39 server applications. This document describes a set of
40 enhancements to the syntax, semantics and
41 functionality of the original Gopher protocol.
42
43
44 Distribution of this document is unlimited. Please
45 send comments to the Gopher development team:
46 <gopher@boombox.micro.umn.edu>. Implementation of
47 the mechanisms described here is encouraged.
48
49
50
51 1. Introduction
52
53 The Internet Gopher protocol was designed primarily to
54 act as a distributed document delivery system. It
55 has enjoyed increasing popularity, and is being used
56 for purposes that were not visualized when the
57 protocol was first outlined. The rest of this
58 document describes the Gopher+ enhancements in a non-
59 rigorous but easily read and understood way. There
60 is a short BNF-like section at the end for exact
61 syntax descriptions. Throughout the document, "F"
62 stands for the ASCII TAB character. There is an
63 implicit carriage return and linefeed at the ends of
64 lines; these will only be explicitly mentioned where
65 necessary to avoid confusion. To understand this
66 document, you really must be familiar with the basic
67 Gopher protocol.
68
69
70 Servers and clients understanding the Gopher+
71 extensions will transmit extra information at the ends
72 of list and request lines. Old, basic gopher clients
73 ignore such information. New Gopher+ aware servers
74 continue to work at their old level with unenhanced
75 clients. The extra information that can be
76 communicated by Gopher+ clients may be used to summon
77 new capabilities to bridge the most keenly felt
78 shortcomings of the venerable old Gopher.
79
80
81
82
83 2. How does Gopher+ work?
84
85 Gopher+ enhancements rely on transmitting an "extra"
86 tab delimited fields beyond what regular (old) Gopher
87 servers and clients now use. If most existing (old)
88 clients were to encounter extra stuff beyond the
89 "port" field in a list (directory), most would ignore
90 it. Gopher+ servers will return item descriptions in
91 this form:
92
93
94 1Display stringFselector stringFhostFportFextra
95 stuff<CRLF>
96
97
98 If an existing (old) client has problems with
99 additional information beyond the port, it should not
100 take much more than a simple tweak to have it discard
101 unneeded stuff.
102
103
104
105
106 2.1 Advisory issued to client maintainers.
107
108 If it does not do this already, your existing client
109 should be modified as soon as possible to ignore
110 extra fields beyond what it expects to find. This
111 will ensure thatyour clients does not break when it
112 encounters Gopher+ servers in gopherspace.
113
114
115 All the regular Gopher protocol info remains intact
116 except for:
117
118
119 (1) Instead of just a CRLF after the port field in
120 any item of a list (directory) there may be an
121 optional TAB followed by extra stuff as noted above
122 (explanation to follow).
123
124
125
126 (2) In the original Gopher protocol, there was
127 provision for a date-time descriptor (sec 3.6) to be
128 sent after the selector (for use by autoindexer
129 beasts). As far as we know, while the descriptor is
130 implemented in the Mac server, it is not in any other
131 server and no clients or daemons use it. This is a
132 good time to withdraw this feature. The basic gopher
133 protocol has been revised for the final time and will
134 be frozen.
135
136
137
138
139
140
141 2.2 Gopher+ item lists.
142
143 Gopher servers that can utilize the Gopher+
144 enhancements will send some additional stuff
145 (frequently the character "+") after the port field
146 describing any list item. eg:
147
148
149 1Some old directoryFfoo selectorFhost1Fport1
150
151 1Some new directoryFbar selectorFhost1Fport1F+
152
153 0Some file or otherFmoo selectorFhost2Fport2F+
154
155
156 The first line is the regular old gopher item
157 description. The second line is new Gopher+ item
158 description. The third line is a Gopher+ description
159 of a document. Old gopher clients can request the
160 latter two items using old format gopher selector
161 strings and retrieve the items. New, Gopher+ savvy
162 clients will notice the trailing + and know that they
163 can do extra things with these kinds of items.
164
165
166
167
168
169 2.3 Gopher+ data transfer.
170
171 If a client sends out a Gopher+ type request to a
172 server (by tagging on a tab and a "+" to the
173 request):
174
175
176 bar selectorF+
177
178
179 The server may return the response in one of three
180 ways; examples below:
181
182
183 +5340<CRLF><data>
184
185
186
187 +-1<CRLF><data><CRLF>.<CRLF>
188
189
190
191 +-2<CRLF><data>
192
193
194 The first response means: I am going to send exactly
195 5340 bytes at you and they will begin right after this
196 line. The second response means: I have no idea how
197 many bytes I have to send (or I am lazy), but I will
198 send a period on a line by itself when I am done.
199 The third means: I really have no idea how many
200 bytes I have to send, and what's more, they COULD
201 contain the <CRLF>.<CRLF> pattern, so just read until
202 I close the connection.
203
204
205 The first character of a response to a Gopher+ query
206 denotes success (+) or failure (-). Following that is
207 a token to be interpreted as a decimal number. If the
208 number is >= 0, it describes the length of the
209 dataBlock. If = -1, it means the data is period
210 terminated. If = -2, it means the data ends when the
211 connection closes.
212
213
214 The server may return an error also, as in:
215
216
217 --1<CRLF><data><CRLF>.<CRLF>
218
219
220 The (short!) error message will be in ASCII text in
221 the data part. The first token on the first line of
222 the error text (data) contains an error-code (an
223 integer). It is recommended that the first line also
224 contain the e-mail address of the administrator of
225 the server (in angle brackets). Both the error-code
226 and the email address may easily be extracted by the
227 client. Subsequent lines contain a short error
228 message that may be displayed to the user. Basic error
229 codes are:
230
231
232 1 Item is not available.
233
234 2 Try again later ("eg. My load is too high
235 right now.")
236
237 3 Item has moved. Following the error-code is
238 the gopher descriptor
239
240 of where it now lives.
241
242
243 More error codes may be defined as the need arises.
244
245
246
247 This should be obvious: if the client sends out an
248 "old" Gopher kind of request:
249
250
251
252 bar selector
253
254
255
256 the server will know that it is talking to an old
257 client and will respond in the old way. This means
258 that old gopher clients can still access information
259 on Gopher+ servers.
260
261
262
263
264 2.4 Gopher+ client requests.
265
266
267 Clients can send requests to retrieve the contents of
268 an item in this form:
269
270
271
272 selectorstringF+[representation][FdataFlag]<CRLF>[dat
273 ablock]
274
275
276 If dataFlag is '0', or nonexistent, then the client
277 will not send any data besides the selector string.
278 If the dataFlag is '1' then a block of data will
279 follow in the same format as Section 2.3. The client
280 can send a large amount of data to the server in the
281 dataBlock. Representations or alternative views of an
282 item's contents may be discovered by interrogating the
283 server about the item's attribute information; this is
284 explained below.
285
286
287 Note that in the original Gopher protocol, a query
288 submitted to an index server might have a selector
289 string followed by a TAB and the words for which the
290 index server was being asked to search. In Gopher+,
291 the extra TAB and Gopher+ information follow the words
292 for which the server is being asked to search. Gopher+
293 client have to be smart enough to know that in the
294 case of a type 7 item (an index server) they append
295 the Gopher+ information after the words being searched
296 for.
297
298
299
300 2.5 Gopher+ Item Attribute Information.
301
302
303 The most basic enhancement of Gopher+ items is the
304 ability to associate information about an item such
305 as size, alternative views, the administrator, an
306 abstract, etc. with the item. To get Attribute
307 Information, a client can send out a request to the
308 gopher server that looks like this:
309
310
311 selector stringF!<CRLF>
312
313
314 (think of "!" as an upside-down i for "information").
315 To the server this means "Instead of returning the
316 contents of the item, return the item's Attribute
317 Information". The Attribute Information is returned as
318 an ASCII text stream containing blocks of
319 information.For example, a server might return:
320
321
322 +INFO: 0Some file or otherFmoo
323 selectorFhost2Fport2F+
324
325 +ADMIN:
326
327 Admin: Frodo Gophermeister <fng@bogus.edu>
328
329 Mod-Date: Wed Jul 28 17:02:01 1993
330 <19930728170201>
331
332 +VIEWS:
333
334 Text/plain: <10k>
335
336 application/postscript: <100k>
337
338 Text/plain De_DE: <15k>
339
340 application/MacWriteII: <45K>
341
342 +ABSTRACT:
343
344 This is a short (but multi-line) abstract about
345 the
346
347 item. Two or three lines ought to be enough
348
349
350 The beginning of a block of information is denoted by
351 a "+" in column 1 of a line. Another way to think of
352 it is: the name of each block begins with a + and the
353 rest of the name cannot contain a +. Each line of
354 information within a block begins with a space so
355 that it is easy to locate the beginning of a block.
356
357
358 There can be multiple blocks of information about an
359 item, but the first block must be the one-line +INFO
360 block containing the keyword +INFO followed by the
361 gopher item description. This is done to make it easy
362 to associate informational attributes with the gopher
363 items to which they refer (see section 2.7 for some
364 good reasons for doing this). The very first line of
365 Attribute Information for an item contains a one-line
366 +INFO block containing the gopher descriptor for the
367 item. All Gopher+ servers must return an "+INFO"
368 block for all items listed by the server. Also
369 present may be an +ADMIN block that can be many lines
370 long. The server must also send an +ADMIN block when
371 asked to send all the item's attributes (as in the
372 example above). The +ADMIN block must contain at
373 least an Admin attribute and Mod-Date attributes,
374 though there may be many other administrative items
375 also present in the +ADMIN block. The Admin (the
376 administrator of the item) and Date (the date of the
377 item's last modification) attributes are required to
378 be returned by the server, and other optional
379 attributes may be returned as well. In this example,
380 there are two pieces of information within the +ADMIN
381 block (Admin and Mod-Date). The Admin attribute must
382 contain the e-mail address of an administrator inside
383 angle brackets. The Admin line might also contain the
384 administrator's name and phone number. The Date line
385 must contain the modification date in angle brackets.
386 The format of the date is <YYYYMMDDhhmmss> where YYYY
387 is year, MM is month, DD is day, hh is hours, mm is
388 minutes, and ss is seconds.
389
390
391 The third block in the example is the +VIEWS block.
392 This block lists different formats in which the
393 document can be retrieved. The first format listed is
394 what the server believes to be the preferred format.
395 A gopher client might display the list of possible
396 view labels of the item to the user and let the user
397 select the view they prefer. Alternatively, a smart
398 client might look at the content of the labels and
399 preferentially retrieve Postscript views of items.
400 Note that the view labels are structured. View labels
401 specify a Content-Type (application/Postscript,
402 Text/plain, etc.), an optional language (En_US, De_DE,
403 etc.) and an optional size. Note that the View labels
404 for content type use the MIME content types to specify
405 names of the variious views. The optional language
406 descriptors use the ISO-639 codes for representing
407 languages to name the language. Smart clients might
408 want to translate these rather cryptic codes into
409 something mere mortals can read and understand.
410
411
412 The client software can pick off the size of each
413 view IF there are any angle brackets on the line.
414 There might not be a size that the server cares to
415 tell you about. Also this might NOT be the exact size
416 that the server will wind up delivering to you if you
417 ask for it... but it should be reasonably close. This
418 information makes it possible for clever clients to
419 select views based on size, data representation, or
420 language. See section 2.6 for how alternate
421 representations (views) are retrieved.
422
423
424 The next block in the example is an (optional)
425 +ABSTRACT. Here the block consists of lines of text
426 that might be displayed to the user.
427
428
429 Other blocks of information can defined and added as
430 the need arises. For instance, a Neuromancer-esque 3-D
431 cyberspace attribute might be accommodated by
432 including a 3D-ICON block (with an image to display
433 in 3-space) and a 3D-COORDINATE block (with y,x, and
434 z coordinates). More immediate needs can also
435 addressed by defining other information blocks. For
436 instance, a SCRIPT block would be a natural place to
437 put information for scripting telnet sessions.
438 Information blocks give us an extensible way of
439 adding attributes (or what Macintosh programmers call
440 resources) to gopher items.
441
442
443 Some of the really cool ideas we have for information
444 attributes may require sending large amounts of data,
445 some of which may not be easily represented as ASCII
446 text, but the idea of the attributes information is
447 that it is a relatively compact list of attributes.
448 These somewhat conflicting desires can be reconciled
449 by allowing references to gopher items in an
450 attribute. For example, an +ABSTRACT block might be
451 returned this way:
452
453
454 +ABSTRACT: 0long abstractFselectorFhost2Fport2F+
455
456
457 In this example, the abstract is a document that
458 resides on a gopher server. By allowing references to
459 to gopher items, we can also accommodate data that
460 must be sent in an 8-bit clear stream by using the
461 Gopher+ methods for retrieving binary data.
462
463
464 If both a reference to an attribute and an explicit
465 value for the attribute are present in an attribute
466 list, the preferred version is the explicit value. In
467 the example below, the preferred version is "the
468 short abstract goes here".
469
470
471 +ABSTRACT: 0long abstractFselectorFhost2Fport2F+
472
473 the short abstract goes here
474
475
476 Note that if you want to have several views of (for
477 example) an +ABSTRACT this is possible by using a
478 reference to a item residing on a gopher server
479 because the item can have its own attributes.
480
481
482 Attributes names are case sensitive (easier to match
483 and more of them). There is no need to "preregister"
484 all possible attributes since we cannot anticipate
485 all possible future needs. However it would be
486 reasonable to maintain a registry for implementors
487 and administrators so duplication can be avoided.
488 Server implementors or administrators can request that
489 new attributes be included in the attribute registry.
490
491
492 Dream on: What gets us excited are alternate
493 representations for directory lists. Sure, the
494 standard representation for a gopher directory list
495 is known to us all. But isn't hypertext (in a WWW
496 sense) an alternate kind of directory list? We also
497 envisioned a "geographical view" (GView?) mapping
498 servers onto a map of the world (throw up a gif
499 picture and then overlay dots based on latitude and
500 longitude or xy coordinates). OK. Dream off.
501
502
503 Note that interested parties outside gopherspace have
504 long and complex wish-lists for "attributes" that all
505 well-dressed Internet citizens should have. We don't
506 want to comment on the use or value of these laundry-
507 lists. Suffice it to say that nothing precludes
508 server administrators from including whatever
509 attributes they see fit to include. Certainly IAFA
510 blocks are desirable, bearing UDIs, URL's or whatever
511 else is desired. The gopher community will probably
512 arrive at a list of "recommended" attributes that
513 server administrators should try to support. Because
514 not every server administrator sees advantage to
515 cluttering Attribute Info files with information
516 their primary users will never need, it does not seem
517 fair to "force" folks to include them; most will
518 just ignore the harsh protocol guideline and the
519 value of the protocol will be diminished. We want to
520 mandate as little as we possibly can.
521
522
523
524
525
526 2.6 Using Attribute Info: Alternate
527 representations (+VIEWS).
528
529
530 The user may locate a document and wonder if there are
531 representations of it besides, say, the standard Text.
532 Using the appropriate client incantation (Option
533 Double-Click? or whatever) the user indicates a wish
534 to see what's available. The client retrieves the
535 Attribute Information, displays the list of views to
536 the user in some kind of scrolling list dialog. User
537 selects a line and client now requests the document
538 in say, Postscript representation:
539
540
541 the selectorF+application/Postscript
542
543
544
545 Smart clients are not precluded from doing things like
546 "Always get Postscript if you can" or "Always get
547 Postscript if that is less than 700K in size." etc.
548 And the "smarter" you make it, the hairier your
549 client will become - unless you are a user interface
550 wizard of awesome proportions. While the example
551 above is of fetching a document's postscript view,
552 there is nothing precluding having different views
553 for directories. In the dream sequence earlier, we
554 imagined a geographic view of a directory. For a
555 client to fetch that view, it would say this:
556
557
558 the selectorF+GView
559
560
561
562 2.7 Getting attributes for all items in a
563 directory in one transaction.
564
565
566 Heavyweight/clever/special-purpose clients may want to
567 know all the attributes of items in a given directory
568 in one transaction. The "$" command is used to
569 request all the attributes of a directory at once.
570 For instance, a client might sent the request:
571
572
573 selector stringF$
574
575
576 and the server might return this:
577
578
579 +INFO: 0Salmon dogsFsome selectorFhost2Fport2F+
580
581 +ADMIN:
582
583 Admin: Frodo Gophermeister <fng@bogus.edu>
584
585 Mod-Date: August 15, 1992 <19920815185503>
586
587 +VIEWS:
588
589 Text/plain: <10k>
590
591 application/Postscript De_DE: <100k>
592
593 +ABSTRACT:
594
595 A great recipe for making salmon
596
597 +INFO: 0Hot pupsFother selectorFhost3Fport3F+
598
599 +ADMIN:
600
601 Admin: Bilbo Gophernovice <bng@bogus.edu>
602
603 Date: <19910101080003>
604
605
606 In this example, the server returned the attribute
607 lists for two items because there were only two items
608 in the directory.. The client software can easily
609 separate the attributes for the items since each
610 attribute list starts with "+INFO". It is also easy
611 for the client to use the "$" command to get
612 directory listings since the gopher item descriptor is
613 on the +INFO line for each item.
614
615
616 Note that the $ command is the only way to find the
617 administrator of a remote link. To get the full
618 attribute information for a link on another machine
619 may require asking the master machine for the item
620 information. It is possible to append which
621 attributes you are interested in retrieving after the
622 $, eg:
623
624
625 some directory selectorF$+VIEWS
626
627 or
628
629 other directory selectorF$+VIEWS+ABSTRACT
630
631
632
633 The $ command makes it possible for a client that does
634 not mind burning bandwidth to get attribute
635 information for all items as the user navigates
636 gopherspace. Clients using 2400 bps SLIP links will
637 probably not use this method... but clients on
638 Ethernet may not mind. This command may also be useful
639 for building smart indexes of items in gopherspace.
640 Note that the specific requested attributes are only
641 suggestions to the server that the client would like
642 less than a full set of attributes. The server may
643 choose to ignore the request (if it is not capable of
644 extracting the required attributes) and return the
645 client the full set anyway. Other caveats: even if
646 the attributes requested are not available, the
647 server WILL NOT return an error, but will send
648 whatever IS available. It is the client's
649 responsibility inspect the returned attributes.
650
651
652 Analogous to use of the $ command, the ! command can
653 also be used to request certain attribute blocks.
654
655
656
657
658 2.8 Gopher+ Interactive Query items.
659
660
661 The principle here is based on Roland Schemer's "Q/q"
662 type ideas. We're calling it the Interactive Query
663 enhancements...
664
665
666 The server may list items that have a "?" following
667 the port field:
668
669
670 0A fileFfile selectorFhostFportF?
671
672 1A directoryFdir selectorFhostFportF?
673
674
675 Now the fact that there's something after the port
676 field means that these are Gopher+ items. Old clients
677 will still be able to show such items in lists, but
678 if they simply send the old style plain selector
679 string to retrieve them, the server will respond with
680 an old style error telling them to get an updated
681 client. New clients will know that before getting one
682 of these items, it will be necessary to retrieve
683 questions from the server, have the user answer them,
684 and then feed the answers back to the server along
685 with the selector. The questions to be asked of the
686 user are retrieved from the server by looking at the
687 +ASK attribute in the item's attribute information.
688
689
690
691
692 When the user selects a query item, the client quickly
693 connects to the server and requests the Attribute
694 Information for the item. Then the client extracts
695 the information in the +ASK attribute block. Here's
696 an example:
697
698
699 +INFO: 0inquisitiveFmoo moo
700 selectorFhost2Fport2F+
701
702 +ADMIN
703
704 Admin: Frank Gophermeister <fng@bogus.edu>
705
706 Mod-Date: August 15, 1992 <19920815185503>
707
708 +ASK:
709
710 Ask: How many volts?
711
712 Choose: Deliver electric shock to administrator
713 now?FYesFNot!
714
715
716
717
718
719 The client will use all lines in the order they appear
720 in the +ASK attribute block. The content will be
721 presented to the user as questions or prompts or
722 dialogs or something like that.
723
724
725 The "Ask" presents the user with a question, supplies
726 a default text answer if it exists and allows the
727 user to enter a one-line responce.
728
729
730 The "AskP" presents the user with a question, and
731 bullets out the responce typed in by the user so that
732 someone watching over the user's sholder cannot read
733 the responce.
734
735
736 The "AskL" presents the user with a question, and
737 ideally should allo the user to enter several lines of
738 responce.
739
740
741 The "AskF" requests the user for a new local filename,
742 presumably for stashing the response returned by the
743 server. It may supply a default filename.
744
745
746 The "Select" presents the user with a set of options
747 from which the use can select one or many. This is
748 equivalent to Macintosh check boxes.
749
750
751 The "Choose" presents the user with a few short
752 choices only one of which may be selected at a time.
753 This is equivalent to Macintosh radio buttons.
754
755
756 The "ChooseF" requests that the user select an
757 existing local file, presumably for sending to the
758 server. On some systems, the client writer or
759 administrator might want to restrict the selection of
760 such files to the current directory (ie. not allow
761 paths in the filename to prevent sending things like
762 password files).
763
764
765 The n responses harvested from the user are sent on to
766 the server as the first n lines in the dataBlock.
767 There can only be one file sent, and it will be the
768 remainder of the dataBlock if any. If there is an
769 AskL the responce is returned with a count of the
770 number of lines entered by the user on a line by
771 itself, followed by the lines entered by the user.
772
773
774 Gopher was originally designed as an essentially
775 anonymous document retrieval protocol to facilitate
776 easy access to information rather than limited
777 access. Various kinds of restrictive mechanisms have
778 been implemented at the server end (for example,
779 access restriction by source IP address); however if
780 you have sensitive information, we emphasize that
781 putting it under a Gopher's nose is not a good idea.
782
783
784
785
786 The folks with a hirsute tendency will have noticed
787 that all these interactions are static rather than
788 truly dynamic and interactive. In other words, the
789 server cannot ask different questions in response to
790 different answers. +ASK does not constitute a
791 scripting language by any means.
792
793
794 To do "true" scripting, we have to do one of two
795 things
796
797
798 1. Write a full language parser/interpreter into
799 clients. The server loads a whole script into the
800 client's brain, and the client "runs" it. This
801 rather grossly violates the spirit of simplicity in
802 cross-platform gopher implementation. However, when
803 and if a standard scripting language is adopted,
804 there will be room for it in a SCRIPT attribute block.
805
806
807 2. Client enters a complex back-and-forth transaction
808 with the server. This requires the server, client, or
809 both to save rather a lot of state. NOPE! Server
810 saving state means holding open a connection or
811 (worse) the server retaining tokens between
812 connections. Client saving state means the server
813 has an even worse job to do.
814
815
816 As Opus the Penguin would say: a Hairball.
817
818
819
820 2.9 Gopher+ Pictures, Sounds, Movies.
821
822
823 A lot of folks need ability to retrieve and display
824 pictures, but there is no real consensus on ONE format
825 for these pictures. We don't want to define a type
826 character for every oddball picture type. Gopher+
827 handles Pictures, Movies, and Sounds by defining
828 three item types: ":" for bitmap images, ";" for
829 movies, and "<" for sounds (originally I, M, and S
830 were suggested, but they were informally in use in
831 other ways; the only thing magic about ":", ";", and
832 "<", is that they are the first characters after '9')
833
834
835 Note that there is NO default format for Pictures,
836 Movies and Sounds; the specific format of the image,
837 movie, or sound must be gleaned from the +VIEWS
838 information for the item (eg. Gif, PICT, TIFF, etc.).
839
840
841
842
843 Appendix I
844
845
846 Required attributes and suggested attributes.
847
848
849
850 A1.0 The +INFO attribute block
851
852
853 The +INFO atttribute block is sent whenever an item's
854 attributes are requested. It is required that the
855 Attribute Information list for an item must contain a
856 one-line +INFO attribute, and the +INFO attribute
857 must contain the gopher+ descriptor for the item.
858
859
860 +INFO: 1Nice stuffF/selectorFhostFportF+
861
862
863
864 A2.0 The +ADMIN attribute
865
866
867 A Gopher+ server is required to have an +ADMIN block
868 for every item and the +ADMIN block must contain
869 Admin and a Mod-Date lines:
870
871
872 +ADMIN:
873
874 Admin: [comments] <administrator e-mail address>
875
876 Mod-Date: [comments] <YYYYMMDDhhmmss>
877
878
879 In addition to the required lines, we recommend that
880 the +ADMIN attribute of items returned by a full-text
881 search engine contain a SCORE attribute. The SCORE
882 attribute should contain the relevance ranking (an
883 integer) of the item.
884
885
886 Score: relevance-ranking
887
888
889 We recommend that the +ADMIN attribute of a full-text
890 search engine contain a Score-Range attribute. This
891 attribute is used to specify the range of values
892 taken on by the relevance ranking scores of items
893 returned by the search engine. The Score-Range makes
894 it possible to normalize scores from different search
895 engine technologies. The first number is the lower
896 bound, the second number is the upper bound.
897
898
899 Score-range: lower-bound upper-bound
900
901
902 We also recommend that the +ADMIN attribute for the
903 root of the server (i.e. what you get back when you
904 ask for the attributes of the item with the empty
905 selector string) also contain these fields:
906
907
908 Site: the name of the site
909
910 Org: organization or group owning the site
911
912 Loc: city, state, country
913
914 Geog: latitude longitude
915
916 TZ: timezone as gmt-offset
917
918
919 Other useful attributes might include:
920
921
922 Provider: who provided this item
923
924 Author: who wrote this item
925
926 Creation-Date: when it was born <YYYYMMDDhhmmss>
927
928 Expiration-Date: when it expires <YYYYMMDDhhmmss>
929
930
931
932 A3.0 The +VIEWS attribute
933
934
935 The +VIEWS attribute is used to specify alternative
936 representations of an item. The form of the +VIEWS
937 attribute is:
938
939
940 +VIEWS: [gopher descriptor]
941
942 Content-Type[ viewLanguage]: [<56K>]
943
944 Content-Type[ viewLanguage]: [<93K>]
945
946 Content-Type[ viewLanguage]: [<77K>]
947
948
949 Some values for Content-Type are
950
951
952 Text/plain, application/Postscript, image/Gif,
953 image/jpeg,
954
955
956 Content Types are defined by the Internet Assigned
957 Numbers Authority (IANA). To register a new content
958 type send e-mail to IANA@isi.edu. For a
959 comprehensive list, consult the most up-to-date MIME
960 Request for Comments (RFC). A list of currently
961 defined views may be retrieved by anonymous ftp from
962 isi.edu in the directory
963
964
965 /pub/in-notes/MIME/mime-types
966
967
968 All gopher servers must support the Text/plain view
969 for readable documents and the application/gopher-
970 menu view (the basic Gopher+ directory list) for
971 directories. These are the views that must be
972 returned by default. If all a server supports is the
973 default views, then it may omit the +VIEWS attribute
974 block (although we suggest that it not do so).
975
976
977 The viewLanguage is defined as a concatanation of two
978 ISO standard values, the ISO 639 language code and
979 the ISO-3166 country code.
980
981
982 Some values for viewLanguage are:
983
984
985 En_US, De_DE, Es_ES, Se_SE
986
987
988
989 A4.0 The +ABSTRACT attribute
990
991
992 The +ABSTRACT attribute is used to specify a short
993 abstract for the item. The form of the +ABSTRACT
994 attribute is:
995
996
997 +ABSTRACT: [gopher reference]
998
999 A line of text<CRLF>
1000
1001 another line of text<CRLF>
1002
1003 still another line of text.<CRLF>
1004
1005
1006 We recommend that a description of the sorts of
1007 information at the site, a postal address, a phone
1008 number, and the administrator name for the site be
1009 included in the +ABSTRACT attribute for the server
1010 root (i.e. what you get when you ask for the
1011 attribute list of the server with no selector
1012 string).
1013
1014
1015
1016
1017
1018 Appendix II
1019
1020
1021 Paul's NQBNF (Not Quite BNF) for the Gopher+
1022 Enhancements.
1023
1024
1025
1026 Note: This is modified BNF (as used by the Pascal
1027 people) with a few English modifiers thrown in.
1028 Stuff enclosed in '{}' can be repeated zero or more
1029 times. Stuff in '[]' denotes a set of items. The '-
1030 ' operator denotes set subtraction.
1031
1032
1033 This section is not quite solid yet. Please send us
1034 information on any errors you might notice.
1035
1036
1037 Directory Entity
1038
1039
1040 CR-LF ::= Carriage Return Character followed by
1041 Line Feed character.
1042
1043 Tab ::= ASCII Tab character
1044
1045 NUL ::= ASCII NUL character
1046
1047 PLUS ::= ASCII '+' character
1048
1049 LEFT ::= ASCII '<' character
1050
1051 RIGHT ::= ASCII '>' character
1052
1053 OCTET ::= $00 -> $ff
1054
1055 UNASCII ::= OCTET - [Tab CR-LF NUL]
1056
1057 UNASCIINOPLUS ::= UNASCII - [PLUS]
1058
1059 UNASCIINOANGLE ::= UNASCII - [LEFT, RIGHT]
1060
1061 Lastline ::= '.'CR-LF
1062
1063 TextBlock ::= Block of ASCII text not containing
1064 Lastline pattern.
1065
1066 Type ::= UNASCII
1067
1068 DisplayString ::= {UNASCII}
1069
1070 Selector ::= {UNASCII}
1071
1072 Otherflds ::= {UNASCII + TAB}
1073
1074 Host ::= {{UNASCII - ['.']} '.'} {UNASCII -
1075 ['.']}
1076
1077
1078
1079 Note: This is a Fully Qualified Domain Name as defined
1080 in RFC 830. (e.g. gopher.micro.umn.edu) Hosts that
1081 have a CR-LF TAB or NUL in their name get what they
1082 deserve.
1083
1084
1085 Digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6'
1086 | '7' | '8' | '9'
1087
1088 DigitSeq ::= digit {digit}.
1089
1090 Port ::= DigitSeq.
1091
1092
1093 Note: Port corresponds the the TCP Port Number, its
1094 value should be in the range [0..65535]; port 70 is
1095 officially assigned to gopher.
1096
1097
1098
1099 Bool ::= '0' | '1'
1100
1101 G+Field ::= '+' | '?'
1102
1103
1104 Success ::= '+' | '-'.
1105
1106 Transfer ::= DigitSeq | '-1' | '-2'
1107
1108 DataHead ::= Success Transfer CR-LF
1109
1110 DataBlock ::= DataHead {OCTET}
1111
1112
1113
1114 G1DirEntity ::= Type DisplayString Tab Selector Tab
1115 Host Tab Port Tab Otherflds CR-LF
1116
1117 G+DirEntity ::= Type DisplayString Tab Selector Tab
1118 Host Tab Port Tab G+Field
1119
1120 CR-LF
1121
1122
1123
1124 Notes:
1125
1126 It is *highly* recommended that the DisplayString
1127 field contain only printable characters, since many
1128 different clients will be using it. However if eight
1129 bit characters are used, the characters should
1130 conform with the ISO-Latin1 Character Set. The length
1131 of the User displayable line should be less than 70
1132 Characters; longer lines may not fit across some
1133 screens. Warning! The Selector string can be longer
1134 than 255 characters.
1135
1136
1137 Menu Entity
1138
1139 Menu ::= DataHead {G+DirEntity}.
1140
1141
1142 Continues ::= Bool
1143
1144 Representation ::= 'Text' | 'List' | 'Postscript' |
1145 'MacWriteII' | 'RTF' |{UNASCII}
1146
1147
1148
1149 Retrieving a document/menu/etc.:
1150
1151
1152 C: Opens Connection
1153
1154 S: Accepts Connection
1155
1156 C: Sends Selector String Tab '+' Representation [Tab
1157 DataFlag]
1158
1159 C: [Optional] Client sends a DataBlock depending on
1160 value of DataFlag.
1161
1162 S: Sends DataBlock
1163
1164 Connection is closed by either client or server
1165 (typically server).
1166
1167
1168 Spaceline ::= ' ' {UNASCII} CR-LF
1169
1170 Blockname ::= '+' {UNASCIINOPLUS}
1171
1172 Attrblock ::= Blockname ' ' [G+Direntry] CR-LF
1173 {Spaceline}
1174
1175 Attrval ::= SPACE {UNASCII} CR-LF
1176
1177 E-Mail ::= {UNASCII} s.t. it conforms to RFC 822
1178
1179 Adminval ::= ' Admin:' {UNASCII} '<' E-Mailaddr
1180 '>' CR-LF
1181
1182 Dateval ::= ' Mod-Date:' {UNASCII} '<'
1183 YYYYMMDDhhmmss '>' CR-LF
1184
1185 AdminReq ::= AdminVal Dateval
1186
1187 Infoblock ::= '+INFO: ' G+Direntry CR-LF
1188
1189 AdminBlock ::= '+ADMIN: ' {G+Direntry} CR-LF
1190 AdminReq {Attrval}
1191
1192 Language ::= 'English' | 'French' | 'German' |
1193 {UNASCII}
1194
1195 ViewVal ::= ' ' Representation [' ' Language] ":"
1196 ASCIINOANGLE '<'
1197
1198 Size 'k>' CR-LF
1199
1200 ViewBlock ::= '+VIEWS: ' {G+Direntry} CR-LF
1201 {ViewVal}
1202
1203 AttrBlocks ::= InfoBlock ViewBlock {AttrBlock}
1204
1205
1206
1207 Retrieving item Information.
1208
1209
1210
1211 For non-index server (non-type 7 items)
1212
1213
1214 C: Opens Connection
1215
1216 S: Accepts Connection
1217
1218 C: Sends Selector String Tab '!' {BlockName}CR-LF
1219
1220 S: Sends DataBlock with data in AttrrBlocks format.
1221
1222 Connection is closed by either client or server
1223 (typically server).
1224
1225
1226
1227 For index server (type 7 items) the client asks the
1228 search engine to so a search for nothing
1229
1230 (i.e. the client does not provide any words to search
1231 for) and appends a TAB and a "!" after the null-
1232 search:
1233
1234
1235 C: Opens Connection
1236
1237 S: Accepts Connection
1238
1239 C: Sends Selector String Tab Tab '!' {BlockName}CR-LF
1240
1241 S: Sends DataBlock with data in AttrrBlocks format.
1242
1243 Connection is closed by either client or server
1244 (typically server).
1245
1246
1247 Attributes ::= {AttrBlocks}
1248
1249
1250
1251 Retrieving all Item Information entries for a
1252 directory.
1253
1254
1255 C: Opens Connection
1256
1257 S: Accepts Connection
1258
1259 C: Sends Selector String Tab '$'{BlockName} CR-LF
1260
1261 S: Sends DataBlock with data in Attributes format.
1262
1263 Connection is closed by either client or server
1264 (typically server).
1265
1266
1267 .