The Internet Gopher Protocol
Takami Torao
<Network Working Group F. Anklesaria
Request for Comments: 1436 M. McCahill
P. Lindner
D. Johnson
D. Torrey
B. Alberti
University of Minnesota
March 1993
The Internet Gopher Protocol
(a distributed document search and retrieval protocol)
この記述の状態
この記述はインターネットコミュニティのための情報を供給する。それはイン
ターネット標準を詳述するのではない。この記述の配布は無制限である。
概要
インターネット Gopher プロトコルは配布されたドキュメントの探索と検索の
ために設計されている。このドキュメントはプロトコル、現在利用可能な実装
のいくつかのリストを記述し、新しいクライアントとサーバアプリケーション
の実装の仕方の外観を含んでいる。このドキュメントは 1991年にミネソタ大
学の Microcomputer Center により最初に配布された基礎的な Internet
Gopher プロトコルドキュメントに順応している。
イントロダクション
gopher n. 1. Any of various short tailed, burrowing mammals of the
family Geomyidae, of North America. 2. (Amer. colloq.) Native or
inhabitant of Minnesota: the Gopher State. 3. (Amer. colloq.) One
who runs errands, does odd-jobs, fetches or delivers documents for
office staff. 4. (computer tech.) software following a simple
protocol for burrowing through a TCP/IP internet.
Internet Gopher プロトコルとソフトウェアはクライアント-サーバモデルに
準じている。このプロトコルは信頼できるデータストリーム; TCP を仮定して
いる。Gopher サーバはポート 70 上 (ポート 70 は IANA により Internet
Gopher に割り当てられている) で接続待機しなければならない。ドキュメン
トはインターネット上のたくさんの独立したサーバ上に存在する。ユーザはそ
れぞれのデスクトップシステムでクライアントソフトウェアを実行し、well-
known ポートへの TCP 接続を経由してサーバに接続し、サーバにセレクタ
(テキストの行、これは空でも良い) を送信する。サーバはピリオドのみから
なる行で終了するテキストのブロックで答え、接続をクローズする。サーバに
よりどんな状態も保持されない。
ドキュメント (とサービス) が多くのサーバに存在している間、Gopher クラ
イアントソフトウェアはユーザにファイルシステムにとても良く似たアイテム
とディレクトリの階層を示す。Gopher インターフェースは、ファイルシステ
ムがドキュメントとサービスを管理するために都合の良いモデルであるため、
ファイルシステムに似るように設計されている。ユーザは主にドキュメントア
イテム、ディレクトリアイテム及び検索アイテム (後者は情報ベースのサブ
セットの向こう側のドキュメントに対する検索を許す) を含んでいる、ある巨
大にネットワーク化された情報システムと等しいものを見る。
サーバはディレクトリリストかドキュメントのどちらかを返す。ディレクトリ
内のそれぞれのアイテムはタイプ (アイテムが該当するオブジェクトの種類)、
ユーザ可視の名前 (閲覧やリストからの選択に使用される)、ホスト名 (この
アイテムを得るための目的ホスト)及び IP ポート番号 (サーバプロセスが接
続のために待機しているポート) により識別される。ユーザはユーザ可視の名
前のみを見る。クライアントソフトウェアはセレクタ、ホスト名、ポートの三
つにより、どんなアイテムも位置を特定し検索する事ができる。
検索アイテムを使うために、クライアントは特殊な種類の Gopher サーバ: 検
索サーバにクエリーを提出する。この場合、クライアントはセレクタ文字列
(複数可) と一致させる言葉のリストを送信する。レスポンスは検索の基準に
一致するアイテムを含んでいる "仮想ディレクトリリスト" を与える。
Gopher サーバとクライアントはすべての一般のプラットフォームに存在する。
プロトコルがとても少なく簡単であるため、サーバやクライアントを制作する
事は理解が早く容易である。
1. イントロダクション
Internet Gopher プロトコルは主に配布されるドキュメントの配達システムと
して動作するために設計されている。ドキュメント (及びサービス) が多くの
サーバに存在する間、Gopher クライアントソフトウェアはユーザにファイル
システムにとても良く似たアイテムとディレクトリの階層を示す。実際、
Gopher インターフェースは、ファイルシステムがドキュメントの位置確定と
サービスのためにとても良いモデルであるため、ファイルシステムに似せて設
計されている。なぜファイルシステムにちなんだキャンパスワイド情報システ
ムを作ったか? いくつかの理由は:
(a) 情報の階層的な整理は多くのユーザに良く知られている。(ドキュメ
ント、サービス及びサブディレクトリのような) アイテムを含んでいる階
層的ディレクトリは電子掲示板やその他のキャンパスワイド情報システム
において広く使われている。キャンパスワイド情報システムにアクセスす
る人たちは与えられた情報に階層的なまとまりのいくつかの種類を期待す
るだろう。
(b) ファイルシステムスタイル階層は簡単な構文で表す事ができる。
Internet Gopher システムで使用されている構文は理解しやすく、サーバ
やクライアントをデバッグしやすくさせるように設計された。Internet
Gopher クライアントのリクエストをシミュレートし、サーバからのレス
ポンスを見るために Telnet を使う事ができる。特別な目的のソフトウェ
アツールは必要ない。クライアント/サーバプロトコルの疑似ファイルシ
ステムの構文の簡潔さを維持する事により、とても一般的なユーザアク
ティビティ: ディレクトリ構造を通しての閲覧に対してのより良いパ
フォーマンスを達成する事もできる。
(c) Gopher は大学での開始を起源とするため、それらの安価なデスク
トップマシーンから情報を発行するオプションを持つための幾つかの部分
を目的の一つに持つ。そして、情報の多くがディレクトリに整理された単
純なテキストファイルとして表す事ができるため、ファイルシステムにち
なんで作られたプロトコルは直接的に有用である。ユーザのデスクトップ
マシーン上のファイルシステムから Gopher プロトコル経由で発行される
ディレクトリ構造への直接のマッピングが存在し得るため、遅いデスク
トップシステムに対するサーバソフトウェアの制作の問題は最小化される。
(d) ファイルシステムの比喩は拡張性がある。疑似ファイルシステムにお
いてアイテムの "type" 属性を与える事により、単純なテキストドキュメ
ントよりもよりドキュメントを適応させる事が可能である。複雑なデータ
ベースサービスはアイテムの独立したタイプとして操作される。ファイル
システムの比喩はドキュメントにアクセスするための検索やデータベース
スタイルクエリーを除外しない。検索サーバタイプもこの疑似ファイルシ
ステムで定義される。そのようなサーバは "仮想ディレクトリ" もしくは
ユーザの記述と一致するドキュメントのリストを返す。
2. インターネット Gopher モデル
インターネット Gopher 構文を表す詳細な BNF は付録において用意してある...
が、付録の忠実な読み出しがインターネット Gopher プロトコルを理解するた
めに必要というわけではない。
本質的に、Gopher プロトコルはサーバに接続するクライアントと TCP 接続経
由でセレクタ (空でも良いテキストの行) をサーバに送るクライアントで成り
立つ。サーバはピリオドの身からなる行で終了するテキストのブロックで応答
する。クライアントとのトランザクション間のサーバによる状態の保持はない。
プロトコルの簡単な性質は、デスクトップコンピュータ (1MB のマックや DOS
マシーン) のような遅いものに対してサーバやクライアントを早く、能率的に
実行するための必要性を起因とする。
以下はクライアント/サーバ相互作用の簡単な例である。もっと複雑な相互作
用は後に論じられる。"well-known" Gopher サーバ (これは増やされるだろう。
詳細は後に論じる) が (ドメインネームサーバにとても良く似ている) キャン
パスに対して well known ポートで接続待機していると仮定する。クライアン
トソフトウェアが保持している唯一の構成情報はサーバの名前とポート番号
(この例ではマシーンが rawBits.micro.umn.edu で ポート 70) である。この
例において以下の F 文字は TAB 文字を示す。
Client: {rawBits.micro.umn.edu にポート 70 で接続を開始}
Server: {接続を受け入れるが何も返さない}
Client: <CR><LF> {空行を送信する: 意味は "list what you have"}
Server: {CR LF でそれぞれ終了する行の連続を送信する}
0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70
1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70
1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70
1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120
1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70
1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70
{.....etc.....}
. {ピリオドのみからなる行}
{サーバは接続を閉じる}
それぞれの行の最初の文字は行がドキュメント、ディレクトリもしくは検索
サービス (文字 '0', '1', '7'; 後に記述される幾つかのこのような文字があ
る) のどれかを示している。タブの後に続く文字は、検索のためのこのドキュ
メント (もしくはディレクトリ) の選択に使うため、ユーザに示されるユーザ
ディスプレイ文字を形成している。行の最初の文字はこの行でかかれているア
イテムのタイプを実際に定義している。似たようなそれぞれの場合で、Gopher
クライアントソフトウェアは、このアイテムのタイプが何であるかについての
観念 (アイコンの表示、短いテキストタグのようなものによる) の幾つかの分
類をユーザに与えるだろう。
タブに続く、次のタブまでの文字列はドキュメント (もしくはディレクトリリ
スト) を検索するためにクライアントソフトウェアがサーバに送らなければな
らないセレクタ文字列を形成している。このセレクタ文字列はクライアントソ
フトウェアに何も意味しないべきである。クライアントにより決して置き換え
られないべきである。慣例として、セレクタ文字列はしばしば、要請されるア
イテムの位置を特定するためにサーバにより使用されるパス名もしくは別の
ファイルセレクタである。次のタブで区切られた二つのフィールドは、このド
キュメント (もしくはディレクトリ) を持つホストのドメイン名と接続するた
めのポート番号を示している。もしまだタブで区切られたフィールドが存在す
るなら、基本的な Gopher クライアントはそれらを無視すべきである。単一の
CR LF はアイテムの終わりを示す。
この例において、行 1 はユーザが "About internet Gopher" としてみるであ
ろうドキュメントを示している。このドキュメントを検索するために、クライ
アントソフトウェアは検索文字列: "Stuff:About us" を
rawBits.micro.umn.edu にポート 70 で送らなければならない。もしクライア
ントがこれを行うなら、サーバはピリオドのみからなる行で終了するドキュメ
ントの内容で応答するだろう。クライアントはユーザに以下のようなアイテム
のリストに似た何かを表示するかもしれない。
About Internet Gopher
Around the University of Minnesota...
Microcomputer News & Prices...
Courses, Schedules, Calendars...
Student-Staff Directories...
Departmental Publications...
この場合、ディレクトリは省略して表示され、ファイルはその他のものを除い
て表示される。しかしながら、クライアントが制作される対象となっているプ
ラットフォームに依存する事や製作者の趣味で、アイテムタイプは別のテキス
トタグやアイコンで示される事ができる。たとえば、コマンドラインベースの
UNIX クライアントでは名前の後に続くスラッシュ (/) でディレクトリを表示
するし、マッキントッシュクライアントはフォルダのアイコンとならべてディ
レクトリを表示する。
ユーザは選択に沿ったアイテムがインターネット上の多くの異なるマシーンの
どこに存在するかを知らないし気遣う事もない。
ユーザが行 "Microcomputer News & Prices..." を選択したとする。これは
ディレクトリのように思われ、取り出し要求でディレクトリの内容を見る事を
期待している。以下の行はクライアント-サーバ相互作用に引き続いて起こる
ことを例として示している。
Client: (pserver.bookstore.umn.edu にポート 70 で接続)
Server: (接続を受け入れるが何も返さない)
Client: Prices/ (CRLF で終わる呪文の文字を送信)
Server: (それぞれ CR LF で終わる行の連続を送信する)
0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70
0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70
0IBM PricesFPrices/IckFpserver.bookstore.umn.eduF70
0Printer & Peripheral PricesFPrices/PPPFpserver.bookstore.umn.eduF70
(.....etc.....)
. (ピリオドのみからなる行)
(サーバが接続をクローズする)
3. より詳細
3.1 位置特定のサービス
ドキュメント (もしくは、生徒と職員の電話帳のような、ドキュメントとして
最終的に表される別のサービス) はセレクタ文字列、マシーンドメイン名、IP
ポートの三つによるマシーンに結び付けられている。これは、機構やキャンパ
スのためのある well-known トップレベルもしくはルートサーバが存在するで
あろう事が仮定される。このサーバでの情報は失敗の単一点を回避し、幾つか
のサーバで負荷を分散するために一つかそれ以上の別のサーバに複製されるだ
ろう。それら自身に部門を立てる事を望む部分は、キャンパスドメインネーム
サーバにマシーン名を登録するのと同じような方法でトップレベル Gopher
サーバの管理者にマシーン名とポートを登録する必要がある。部門別のサーバ
へポイントするエントリはトップレベルサーバで作られる。これはもしユーザ
が望むのであれば、あらゆるキャンパスサーバへの well known 経路とともに
仮想階層ファイルシステムと同等なものに沿った方法で誘導する事ができる。
部門が二次的なサーバをセントラルトップレベルサーバに登録する必要がない
事に注意。それらは一時的なサーバ自身において二次的なサーバへのリンクが
置かれるだろう。それらは実はそのサーバ自身においてそれらが望むどんな
サーバへのリンクも置かれるだろう。従って Gopher 情報領域のカスタマイズ
されたビューを作り出す。リンクはもちろんトップレベルサーバに戻る事がで
きる。それゆえ、仮想 (ネットワーク化された) ファイルシステムは任意のグ
ラフ構造であり、ルートとなるツリーは必要ない。トップレベルノードは単に
一つの便利さ、エントリの well-known ポイントである。この方法でリンクさ
れた Gopher サーバのセットはキャンパスワイド情報システムとして機能する
だろう。
サーバはもちろんセカンダリサーバのほかにリンクをポイントするだろう。本
当に、サーバはインターネット上のどこでも有用なサービスを提供している別
のサーバをポイントするだろう。この方法で見られると、Gopher はインター
ネットワイド情報システムとしてみられる。
3.2 サーバの可搬性と名前付け
すべての登録されたサーバが、それらを位置づけるため Gopher クライアント
により使用されるエイリアス名 (ドメイン名システム CNAME) を持つ事が勧め
られる。これらのサーバへのリンクはプライマリ名よりもむしろこれらのエイ
リアス名を使うべきである。もし情報があるマシーンから別のマシーンに移動
する必要があれば、ドメイン名システムエイリアス (CNAME) の簡単な変更が
フィールド内のクライアントのどんな設定変更も行う事なしに行う事ができる。
簡単にすると、ドメイン名システムはサーバを新しいアドレスに再マップする
ために使用されるだろう。別の名前のサーバや 70 のほかのポートで実行して
いるものからセカンダリサーバやサービスを妨げる事はない。しかしながら、
これらはプライマリサーバ経由で届く事ができるべきである。
3.3 サーバ管理者への連絡
それぞれのサーバ管理者はそれらのサーバのトップレベルディレクトリの最初
のアイテムとして "About Bogus Universitiy's Gopher server" と呼ばれる
ような何かドキュメントを持つ事を勧める。この時、ドキュメントはサーバを
管理している人の名前、アドレス、電話及び E-mail アドレスのような、サー
バが保持しているものの短い記述であるべきである。これはユーザに不正確な
情報を持っていたり正しく動作していないサーバの管理者への知らせを与える
ための手だてを供給する。管理者はそのような情報がユーザにとって重要であ
るファイルの最終更新の日付を置く事も勧める。
3.4 サービスのモジュール式追加
サーバから供給されたディレクトリリストにおけるそれぞれの行の最初の文字
はアイテムがファイル (文字 '0')、ディレクトリ (文字 '1')、検索 (文字
'7') のいずれであるかを示す。これは Gopher プロトコルにおけるアイテム
タイプの基本セットである。クライアントのために別のサービスと必要な命令
として別のプロトコルでの通信 (finger のような簡単なものから CSO 電話帳
サービス、Telnet、X.500 ディレクトリサービスなど) を行える事が望ましい。
CSO 電話帳サービスは大学で名前、E-mail アドレスなどを発行するために典
型的に使用されるクライアント/サーバ電話帳システムである。CSO 電話帳ソ
フトウェアはイリノイ大学で開発され、しばしば ph もしくは qi としても参
照される。たとえば、サーバから供給されたディレクトリリストがタイプ文字
'2' を持つあるアイテムを示している場合、この時このアイテムを使用する事
を意味し、クライアントは CSO プロトコルで通信しなければならない。これ
は基本的な Internet Gopher プロトコルにおいて、すべての将来的なニーズ
を予想できるための必要性を取り除き、それらを硬く結び付ける。これは基本
プロトコルを極端に簡単に保つ。この簡略化の悪意において、スキームは拡大
するための能力を持ち、新しいサービスに対するタイプ文字に一致する追加に
より何度も変わる。これは、幾つかの新しいサービスに対して単純にモジュー
ルに落とす (もしくは新しいプロセスを始める) 事により、モジュラー様式で
進歩するためのクライアントインプリメンテーションも可能にする。新しい
サービスに対するサーバはもちろん Internet Gopher に付いて何も知る必要
はなく、それらは off-the shelf CSO, X.500 やその他のサービスであるだけ
で良い。しかしながら、われわれは基本 Gopher プロトコルにおいてサービス
タイプの任意のもしくはマシン記述の激増を推奨しない。
他方、別のドキュメント検索スキームのサブセットは "gateway-servers" に
よって Gopher プロトコル上で作られるかもしれない。そのようなサーバの例
は Gopher-to-FTP ゲートウェイ、Gopher-to-archie ゲートウェイ、Gopher-
to-WAIS ゲートウェイなどを含む。そのようなメカニズムの幾つかの利点があ
る。第一に、比較的能力の高いサーバマシンは、典型的にクライアントソフト
ウェアや基本サーバソフトウェアを実行する安価でより低い能力のデスクトッ
プマシンマシンの代わりに情報と仕事の両方を引き継ぐ。同じく重要な事に、
クライアントは新しいリソースの利点を受けるために置き換えられる必要はな
い。
3.5 クライアントの構築
もしクライアントがドキュメントの検索やディレクトリの内容を見る事を望む
なら、クライアントは単純にサーバに検索文字列を送る。もちろん、それぞれ
のホストは、ホストの "graph" (ツリーのルートを必要としない) を成すよう
に、別のホストへのポインタを持つだろう。クライアントソフトウェアはド
キュメントの検索において既に訪れた場所を保存 (むしろ "stack") しておく
だろう。それゆえユーザはスタックを解く事により現在の場所から戻る事がで
きる。択一的に、複合ウィンドウの能力を持つクライアントは同時に一つ以上
のディレクトリやドキュメントを表示する事ができるだろう。
きちんとしたクライアントは訪れたディレクトリの内容 (ディレクトリのアイ
テムディスクリプタに代わって) をキャッシュする事ができる。従って、もし
情報が前もって取り出してあれば、ネットワークトランザクションを回避でき
る。
もしクライアントがタイプ 'B' アイテム (コアアイテムではない) が何を意
味するのか分からなければ、ディレクトリリストにおいてそのアイテムを単純
に無視する事ができる。ユーザはそれを見る必要はない。択一的に、そのアイ
テムは不明なタイプとして表示する事もできる。
キャンパスに対するトップレベルもしくはプライマリサーバはセカンダリサー
バよりももっとトラフィックを得るかもしれない。そしてそのようなプライマ
リサーバが長い間ダウンしている事はほとんどできない。それでそのような重
要なサーバは意図的に "clone" させ、それらが最初にコンタクトしたときに
(サーバロードのバランスを保つために)、片方がダウンしているようであれば
他方に移動するような、二つのプライマリサーバと同等なものの間でランダム
に選択できるクライアントを作ることが意図される。事実、より良いクライア
ントインプリメンテーションはこのクローンサーバを行い、バランスを取りな
がらロードする。あるいは、重要なサーバの余分なセットの間でのロードバラ
ンスにサーバの IP アドレスの余分のセットの一つを返すドメイン名システム
を持つ事が意図される。
3.6 通常のインターネット Gopher サーバの構築
サーバへの検索文字列はファイルまたはディレクトリのパスであろう。それは
返信されるドキュメントやディレクトリを生成するスクリプト、アプリケー
ションもしくはクエリーの名前であろう。基本的なサーバは CR-LF や TAB を
構成要素のもつがそのどちらも先頭にこない文字列を使用する。
すべての情報はそのプロトコルよりもサーバインプリメンテーションにより支
えられる。あなたが作り上げたより珍しいサーバはあなたに逆らっているだろ
う。サーバインプリメンテーションは必要な命令と時間が許せば成長する。
3.7 特殊な目的のサーバ
以下に論議されているような二つの特殊なサーバタイプ (通常の Gopher サー
バのほかに) が存在する:
1. サーバディレクトリリストがキャンパスの生徒-職員電話帳検索サービ
スができるように CSO ネームサーバー (サーバはタイプ文字 '2' を返す)
をポイントできる。これは多分電話帳のアイコンになる選択のユーザのリ
ストを表示するだろう。もしこのアイテムが選択されたら、クライアント
は適切なホストへ接続するとき純粋な CSO ネームサーバープロトコルに
頼らなければならない
2. サーバは "search server" ('7' の先頭文字を返す) をポイントする
事もできる。このようなサーバはキャンパスネットワーク (もしくはそ
のサブネット) ワイドで検索する能力を実装するだろう。もっとも一般的
な検索サーバは gopher サーバの幾つかのサブセットにより保持されるテ
キストドキュメントの内容上のフルテキストインデックスを扱う。"full-
text search server" のようなものは一つかそれ以上の言葉 (検索基準と
なる) を含んでいるすべてのドキュメントのリストをクライアントリクエ
ストに返す。クライアントはサーバにセレクタ文字列、タブそして検索文
字列 (検索するための言葉) を送信する。もしセレクタ文字列が空ならば
クライアントは単に検索文字列を送る。サーバは検索基準に一致するド
キュメントのディレクトリリストに相当するものを返す。言葉の間の空白
は普通ブール代数 AND (とはいえ別のインプリメンテーションや検索タイ
プでは、これは真である必要がないかもしれない) を意味する。
CSO 追加は歴史的な理由から存在する。設計の段階で、ミネソタ大学のキャン
パス電話帳サーバは CSO プロトコルで使用され、それはそれらを含む事が簡
単のようであった。しかしながらインデックスサーバは Gopher 精神にとても
一致し、セレクタ文字列の意味においてわずかなねじれを albeit する。イン
デックスサーバは WAIS と WHOIS サービスへのゲートウェイを incorperate
するために本質的に置かれたものである。
3.7.1 CSO サーバの構築
UNIX と準ドキュメンテーションのための CSO ネームサーバインプリメンテー
ションは uxa.cso.uiuc.edu から anonymous FTP により利用可能である。わ
れわれは別のマシン上で実装されることを予期しない。
3.7.2 full-text 検索サーバの構築
full-text 検索サーバはドキュメントを検索するための Gopher スキームにつ
いて知っている特別な目的のサーバである。これらのサーバは幾つかの記述さ
れたドメインにおける Gopher サーバ上でのプレーンテキストドキュメントの
内容の full-text インデックスを扱う。Gopher full-text 検索サーバは
NeXT システムソフトウェアでの full-text インデックス/検索エンジンの長
所を簡単に応じるため、使用している幾つかの NeXT ステーションでインプリ
メントされている。パブリックドメイン WAIS 検索エンジンをベースとした一
般的な UNIX システムのための検索サーバも利用可能であり、現在 UNIX
gopher サーバのオプション的な部分としている。追加として、gopher サーバ
のもっとも最新のあるインプリメンテーションは WAIS サーバに full-text
検索サーバとしての gopher スペースを与える事により WAIS サーバへのゲー
トウェイを提供している。gopher<->WAIS ゲートウェイサーバは gopher プロ
トコルから WAIS への変換の作業を行い、修正されないままの gopher クライ
アントはゲートウェイサーバ経由で WAIS サーバにアクセスする事ができる。
幾つかのインデックスサーバ (むしろ単一のインデックスサーバ) を使う事に
より、インデックスは平行して (とはいえクライアントソフトウェアにその意
識はない) 検索されるだろう。タスクを威圧させるような多くのマシンで配布
されるドキュメントの full-text インデックスを扱う一方で、タスクを処理
しやすいようにより小さい部分 (インデックスの一部の更新、平行しての部分
的なインデックスの検索) に分解する事ができる。幾つかの小さく、安価な
(そして速い) ワークステーションにタスクを広げる事により、細かく粒にし
た平行の利点を得ることが可能である。再度、クライアントソフトウェアはこ
れに気づかない。クライアントソフトウェアはインデックスサーバに検索文字
列が送られることのみを知る必要があり、検索文字列内の文字を含むドキュメ
ントのリストを受信するだろう。
3.8 アイテムタイプ文字
クライアントソフトウェアはディレクトリリストにおけるそれぞれの行の先頭
の文字を見る事で、アイテムが利用できるかを決定する。このリストの増加は
プロトコルを拡張する事ができる。定義されているアイテムタイプ文字のリス
トは以下のようになる:
0 アイテムはファイルである
1 アイテムはディレクトリである
2 アイテムは CSO 電話帳サーバである
3 エラー
4 アイテムは Macintosh BinHex ファイルである
5 アイテムは幾つかの種類の DOS バイナリアーカイブである
クライアントは TCP 接続のクローズまで読み込まなければならない.注意
6 アイテムは UNIX uuencode ファイルである
7 アイテムはインデックス検索サーバである
8 アイテムはテキストベース telnet セッションを示す
9 アイテムはバイナリファイルである!
クライアントは TCP 接続のクローズまで読み込まなければならない.注意
+ アイテムは余分なサーバである
T アイテムはテキストベースの tn3270 セッションを示す
g アイテムは GIF フォーマットグラフィックファイルである
I アイテムは画像ファイルの幾つかの種類である.クライアントは表示方法を決める
文字 'O' から 'Z' は予約されている。ローカルな実験は別の文字を使うべき
である。マシン特有の拡張は奨励されない。タイプ 5 またはタイプ 9 に対し
てクライアントは接続が閉じるまで読み出しを用意しなければならないのに注
意。ファイルの終了にピリオドのみの行はない。これらのファイルの内容はバ
イナリであり、クライアントは多分 .xxx 拡張子を基として何をするかを決定
しなければならない。
3.9 ユーザ表示文字列とサーバセレクタ文字列
ユーザ表示文字列はユーザの表示の満足のため典型的にスクリーン上の行に表
示される目的を持つ。ほとんどのスクリーンが 80 文字行に対応しているため、
幾つかの空白はこれが何のアイテムの種類かをユーザに伝えるための幾つかの
分類のタグを表示する必要がある。これにより、ユーザ表示文字列は長さが 70
文字以下であるべきである。クライアントはそれらに長さ敵に都合が良くなる
ように断ち切るかもしれない。
4. 質素は意図的である
可能な限りわれわれは新しいドキュメントタイプに遅れる隠されるであろう新
しいプロトコルとして伝えられるための新しい機能を望んでいる。インター
ネット Gopher 哲学は:
(a) 情報はサーバによって保持される。クライアントはドキュメントタイプ
文字を簡単に認識することにより新しいドキュメントタイプ (サーバの別タ
イプ) にアクセスする事ができるオプションを持つ。その上プロトコルによ
り与えられる情報は最小化されるべきである。
(b) 良く調整されたサーバは "text" (ファイルが未加工で転送される以外)
で送信する。このテキストはタブ、フォームフィード、もろもろを含むべき
か? 多分そうではなく、失礼なサーバは多分それらをいいかげんに送るだろ
う。ドキュメントの発行者は公開する事を望むドキュメントに疑わしい文字
があるならばそれらを警告する簡単なツール (フィルタ) を与え、疑わしい
文字を取り除く機会を与えるべきである。発行者はよくこれを拒む。
(c) 良く調整されたクライアントはテキスト中の受け取った疑わしい文字を
合理的に処理すべきである。どんなものでもフィルタで取り除くかそのまま
残すかである。
付録
Gopher プロトコルにおける Paul の NQBNF (Not Quite BNF)
注意: これはおまけとしてつけられる幾つかの英語修飾子付き BNF (Pascal
の人たちが使うような) に修正されている。'{}' により囲まれている
ものはゼロかそれ以上の回数繰り返す事ができる。 '[]' で囲まれたも
のはアイテムのセットを示す。'-' オペレータは減算セットを示す。
ディレクトリエンティティ
CR-LF ::= ラインフィード文字が後に続く ASCII キャリッジリターン文字
Tab ::= ASCII タブ文字
NUL ::= ASCII NUL 文字
UNASCII ::= ASCII - [Tab CR-LF NUL]
Lastline ::= '.'CR-LF
TextBlock ::= Lastline パターンを除く ASCII テキストのブロック
Type ::= UNASCII
RedType ::= '+'
User_Name ::= {UNASCII}
Selector ::= {UNASCII}
Host ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}
注意: これは RFC 1034 で定義されているような Fully Qualified Domain Name
(gopher.micro.umn.edu のような) である。それらの名前に CR-LF, TAB
もしくは NUL を持つホストはそれらが値することを得る。
Digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
DigitSeq ::= digit {digit}
Port ::= DigitSeq
注意: Port は TCP ポート番号に相当し、その値は [0..65535] の範囲であるべき
である。ポート 70 は gopher に対して公式に割り当てられている。
DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF
{RedType User_Name Tab Selector Tab Host Tab Port CR-LF}
注意: 多くの異なるクライアントがそれを使用してるため、User_Name フィールド
が印字可能文字のみを含む事が *強く* 勧められる。しかしながらもし 8
ビット文字が使われているなら、文字は ISO Latin1 文字セットに順応すべ
きである。ユーザが表示可能な行の長さは 70文字以下であり、それよりも
長いものは幾つかのスクリーンを横切ってフィットしないだろう。セレクタ
文字列は 255 文字を超えるべきではない。
メニューエンティティ
Menu ::= {DirEntity} Lastline.
メニュートランザクション (タイプ 1 アイテム)
C: 接続を開く
S: 接続を受け入れる
C: セレクタ文字列を送信する
S: メニューエンティティを送信する
接続はクライアントかサーバのどちらか (典型的にはサーバ) によりクローズ
される
テキストファイルエンティティ
TextFile ::= {TextBlock} Lastline
注意: 転送が終了よりも早く終わらないことを保証するため、ピリオドで始まって
いる行は余分なピリオドをつけなければならない。クライアントは行頭の余
分なピリオドを取り除くべきである。
テキストファイルトランザクション (タイプ 0 アイテム)
C: 接続を開く
S: 接続を受け入れる
C: セレクタ文字列を送信する
S: テキストファイルエンティティを送信する
接続はクライアントかサーバのどちらか (典型的にはサーバ) によりクローズ
される
注意: クライアントはサーバに Lastline が送信される事を除いて接続をクローズ
する準備をさせられるべきである。これはクライアントが finger サーバを
使用できるようにする。
Full-Text 検索トランザクション (タイプ 7 アイテム)
Word ::= {UNASCII - ' '}
BoolOp ::= 'and' | 'or' | 'not' | SPACE
SearchStr ::= Word {{SPACE BoolOp} SPACE Word}
C: 接続を開く
C: セレクタ文字列、タブ、検索文字列を送信する
S: メニューエンティティを送信する
注意: 'and', 'or' 及び 'not' の欠如において、SPACE は 'and' 演算子を暗に意
味するとみなされる。構文は左から右に評価される。さらに、現在インプリ
メントされているすべての検索エンジン及び検索ゲートウェイがブール演算
子を持っているわけではない。
バイナリテキストトランザクション (タイプ 9 及び 5 アイテム)
C: 接続を開く
S: 接続を受け入れる
C: セレクタ文字列を送信する
S: バイナリファイルを送信し実行されたら接続をクローズする
ディレクトリエンティティの構文的意味
クライアントは以下のようなタイプフィールドを解釈すべきである:
0 アイテムはテキストファイルエンティティである
クライアントはテキストファイルトランザクションを使用する
1 アイテムはメニューエンティティである
クライアントはメニュートランザクションを使用する
2 CSO 電話帳エンティティに適応する情報である。
クライアントは CSO プロトコルで通信すべきである。
3 エラー状態のシグナル
4 アイテムは BINHEX フォーマットで符号化された Macintosh ファイルである
5 アイテムは何種類かの PC-DOS のバイナリファイルである
クライアントは決定する事ができる
6 アイテムは uuencode で符号化されたファイルである
7 インデックスサーバに適応する情報である
クライアントは FullText 検索トランザクションを使用する
8 Telnet セッションに適応する情報である
与えられたホストとポートに接続する
このホストへのログイン名はセレクタ文字列となる
9 アイテムはバイナリファイルである
クライアントはそれに付いて何をするかを決めなければならない
+ 複製されたサーバに適応する情報である
内部に含まれる情報はプライマリサーバの複製である
プライマリサーバはプラスでない "Type" フィールドを持つ最後の DirEntity
として定義される。クライアントはプライマリサーバ Type フィールドによっ
て定義されるようなトランザクションを使用すべきである。
g アイテムは GIF グラフィックファイルである
I アイテムは画像ファイルの何種類かである
クライアントは決定する事ができる
T tn3270 ベースの telnet セッションに適応される情報である
与えられたホストとポートに接続する。このホストへのログイン名はセレクタ
文字列となる。
セキュリティ考察
セキュリティ問題はこの記述では論議されない。
著者のアドレス
Farhad Anklesaria
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: fxa@boombox.micro.umn.edu
Mark McCahill
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: mpm@boombox.micro.umn.edu
Paul Lindner
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: lindner@boombox.micro.umn.edu
David Johnson
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: dmj@boombox.micro.umn.edu
Daniel Torrey
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: daniel@boombox.micro.umn.edu
Bob Alberti
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: alberti@boombox.micro.umn.edu