RFC1436 日本語訳
1436 The Internet Gopher Protocol (a distributed document search andretrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D.Johnson, D. Torrey, B. Albert. March 1993. (Format: TXT=36493 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Anklesaria
Request for Comments: 1436 M. McCahill
P. Lindner
D. Johnson
D. Torrey
B. Alberti
University of Minnesota
March 1993
Anklesariaがコメントのために要求するワーキンググループF.をネットワークでつないでください: 1436 1993年のM.McCahill P.リントナーのD.ペニスD.トーリーのB.アルベルティミネソタ大学の行進
The Internet Gopher Protocol
(a distributed document search and retrieval protocol)
インターネットゴーファープロトコル(分配されたドキュメント検索と検索プロトコル)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
The Internet Gopher protocol is designed for distributed document search and retrieval. This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This document is adapted from the basic Internet Gopher protocol document first issued by the Microcomputer Center at the University of Minnesota in 1991.
インターネットゴーファープロトコルは分配されたドキュメント検索と検索のために設計されています。 このドキュメントは、プロトコルについて説明して、現在利用可能な実装のいくつかを記載して、どう新しいクライアントとサーバ・アプリケーションを実装するかに関する概要を持っています。 このドキュメントは1991年に最初にミネソタ大学のMicrocomputerセンターによって発行された基本のインターネットゴーファープロトコルドキュメントから翻案されます。
Introduction
序論
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.
リスn。 1. ファミリーGeomyidae、北アメリカの様々な短い尾の、そして、穴の哺乳動物のいずれも。 2. (アメアcolloq。) ミネソタのネイティブか住民: 米国ミネソタ州の俗称。 3. (アメアcolloq。) 使い走りするか、雑務、フェッチをするか、または職員のために書類を引き渡す人。 4. (コンピュータ技術者。) TCP/IPインターネットを通して穴を堀るための簡単なプロトコルに従うソフトウェア。
The Internet Gopher protocol and software follow a client-server model. This protocol assumes a reliable data stream; TCP is assumed. Gopher servers should listen on port 70 (port 70 is assigned to Internet Gopher by IANA). Documents reside on many autonomous servers on the Internet. Users run client software on their desktop systems, connecting to a server and sending the server a selector (a line of text, which may be empty) via a TCP connection at a well- known port. The server responds with a block of text terminated by a period on a line by itself and closes the connection. No state is retained by the server.
インターネットゴーファープロトコルとソフトウェアはクライアント・サーバモデルに続きます。 このプロトコルは確実な資料ストリームを仮定します。 TCPは想定されます。 ゴーファーサーバはポート70の上で聴かれるべきです(ポート70はIANAによってインターネットゴーファーに割り当てられます)。 ドキュメントはインターネットの多くの自動サーバにあります。 ユーザはクライアントソフトウェアを彼らのデスクトップ型に動かします、サーバに接続して、よく知られているポートでのTCP接続でセレクタ(人影がないかもしれないテキスト行)をサーバに送って。 サーバは、1ブロックのテキストが期間までに系列でそれ自体で終えられている状態で応じて、接続を終えます。 状態は全くサーバによって保有されません。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 1] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[1ページ]RFC1436ゴーファー行進
While documents (and services) reside on many servers, Gopher client software presents users with a hierarchy of items and directories much like a file system. The Gopher interface is designed to resemble a file system since a file system is a good model for organizing documents and services; the user sees what amounts to one big networked information system containing primarily document items, directory items, and search items (the latter allowing searches for documents across subsets of the information base).
ドキュメント(そして、サービス)が多くのサーバにある間、ゴーファークライアントソフトウェアはファイルシステムのような項目とディレクトリの階層構造をユーザに与えます。 ゴーファーインタフェースはファイルシステムがドキュメントとサービスをまとめるための良いモデルであるのでファイルシステムに類似するように設計されています。 ユーザは主として、ドキュメントの品目、ディレクトリの品目、および検索項目(情報ベースの部分集合の向こう側にドキュメントの検索を許す後者)を含む1個の大きいネットワークでつながれた情報システムに達するものを見ます。
Servers return either directory lists or documents. Each item in a directory is identified by a type (the kind of object the item is), user-visible name (used to browse and select from listings), an opaque selector string (typically containing a pathname used by the destination host to locate the desired object), a host name (which host to contact to obtain this item), and an IP port number (the port at which the server process listens for connections). The user only sees the user-visible name. The client software can locate and retrieve any item by the trio of selector, hostname, and port.
サーバはディレクトリリストかドキュメントのどちらかを返します。 ディレクトリの各個条がタイプによって特定される、(種類、オブジェクトでは、項目がそうである、)、不透明なセレクタストリング(必要なオブジェクトの場所を見つけるのにあて先ホストによって使用されたパス名を通常含んでいる)、ホスト名(この商品を入手する接触へのどのホスト)、およびIPポートは付番するか(サーバプロセスが接続の聞こうとするポート)目に見えるユーザが、命名する(リストをブラウズして、以前はよく選び抜いていました)。 ユーザは目に見えるユーザ名を見るだけです。 クライアントソフトウェアは、セレクタ、ホスト名、およびポートの三つ組でどんな項目も場所を見つけて、検索できます。
To use a search item, the client submits a query to a special kind of Gopher server: a search server. In this case, the client sends the selector string (if any) and the list of words to be matched. The response yields "virtual directory listings" that contain items matching the search criteria.
検索項目を使用するために、クライアントは特別な種類のゴーファーサーバに質問を提出します: a検索サーバこの場合、クライアントは、合わせられるためにセレクタストリング(もしあれば)と単語のリストを送ります。 応答は検索評価基準に合っている項目を含む「仮想ディレクトリリスト」をもたらします。
Gopher servers and clients exist for all popular platforms. Because the protocol is so sparse and simple, writing servers or clients is quick and straightforward.
ゴーファーサーバとクライアントはすべてのポピュラーなプラットホームに存在します。プロトコルが非常にまばらであって、簡単であるので、サーバかクライアントに書くのは、迅速であって、簡単です。
1. Introduction
1. 序論
The Internet Gopher protocol is designed primarily to act as a distributed document delivery system. While documents (and services) reside on many servers, Gopher client software presents users with a hierarchy of items and directories much like a file system. In fact, the Gopher interface is designed to resemble a file system since a file system is a good model for locating documents and services. Why model a campus-wide information system after a file system? Several reasons:
インターネットゴーファープロトコルは、主として分配された文書の配信システムとして機能するように設計されています。 ドキュメント(そして、サービス)が多くのサーバにある間、ゴーファークライアントソフトウェアはファイルシステムのような項目とディレクトリの階層構造をユーザに与えます。 事実上、ゴーファーインタフェースは、ファイルシステムがドキュメントとサービスの場所を見つけるための良いモデルであるのでファイルシステムに類似するように設計されています。 なぜキャンパス全体の情報システムにファイルシステムに倣いますか? いくつかの理由:
(a) A hierarchical arrangement of information is familiar to many
users. Hierarchical directories containing items (such as
documents, servers, and subdirectories) are widely used in
electronic bulletin boards and other campus-wide information
systems. People who access a campus-wide information server will
expect some sort of hierarchical organization to the information
presented.
(a) 多くのユーザにとって、情報の階層的配列は身近です。 項目(ドキュメントや、サーバや、サブディレクトリなどの)を含む階層化ディレクトリが電子掲示板と他のキャンパス全体の情報システムで広く使用されます。キャンパス全体の情報サーバにアクセスする人々は、情報へのある種の階層的な組織が提示したと予想するでしょう。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 2] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[2ページ]RFC1436ゴーファー行進
(b) A file-system style hierarchy can be expressed in a simple
syntax. The syntax used for the internet Gopher protocol is
easily understandable, and was designed to make debugging servers
and clients easy. You can use Telnet to simulate an internet
Gopher client's requests and observe the responses from a server.
Special purpose software tools are not required. By keeping the
syntax of the pseudo-file system client/server protocol simple, we
can also achieve better performance for a very common user
activity: browsing through the directory hierarchy.
(b) 簡単な構文でファイルシステムスタイル階層構造を表すことができます。 インターネットゴーファープロトコルに使用される構文は、容易に理解できて、デバッグサーバとクライアントを簡単にするように設計されました。 あなたは、インターネットゴーファークライアントの要求をシミュレートして、サーバから応答を観測するのにTelnetを使用できます。専用ソフトウェアツールは必要ではありません。 また、疑似ファイルシステムクライアント/サーバプロトコルの構文を簡単に保つことによって、私たちは非常に一般的なユーザ活動のための、より良い性能を達成できます: ディレクトリ階層構造をブラウズします。
(c) Since Gopher originated in a University setting, one of the
goals was for departments to have the option of publishing
information from their inexpensive desktop machines, and since
much of the information can be presented as simple text files
arranged in directories, a protocol modeled after a file system
has immediate utility. Because there can be a direct mapping from
the file system on the user's desktop machine to the directory
structure published via the Gopher protocol, the problem of
writing server software for slow desktop systems is minimized.
簡単なテキストファイルがディレクトリで手配されたので情報の多くを提示できるので、部では、(c) ゴーファーが大学設定で起こったので、目標の1つがそれらの安価なデスクトップマシンからの情報を発表するオプションがあることであり、ファイルシステムに倣われたプロトコルは即座のユーティリティを持っています。 ユーザのデスクトップマシンの上のファイルシステムからゴーファープロトコルで発行されたディレクトリ構造までダイレクトマッピングがあることができるので、遅いデスクトップ型のためのサーバソフトウェアを書くという問題は最小にされます。
(d) A file system metaphor is extensible. By giving a "type"
attribute to items in the pseudo-file system, it is possible to
accommodate documents other than simple text documents. Complex
database services can be handled as a separate type of item. A
file-system metaphor does not rule out search or database-style
queries for access to documents. A search-server type is also
defined in this pseudo-file system. Such servers return "virtual
directories" or list of documents matching user specified
criteria.
(d) ファイルシステム比喩は広げることができます。 「タイプ」属性を疑似ファイルシステムの項目に与えることによって、簡単なテキストドキュメント以外のドキュメントに対応するのは可能です。 別々のタイプの項目として複雑なデータベース・サービスを扱うことができます。 ファイルシステム比喩はドキュメントへのアクセスのために検索かデータベーススタイル質問を除外しません。 また、検索サーバタイプはこの疑似ファイルシステムで定義されます。 そのようなサーバはユーザの指定された評価基準に合っているドキュメントの「仮想ディレクトリ」かリストを返します。
2. The internet Gopher Model
2. インターネットゴーファーModel
A detailed BNF rendering of the internet Gopher syntax is available in the appendix...but a close reading of the appendix may not be necessary to understand the internet Gopher protocol.
インターネットゴーファー構文の詳細なBNFレンダリングは付録で利用可能です…しかし、付録の近い読みは、インターネットゴーファープロトコルを理解するのに必要でないかもしれません。
In essence, the Gopher protocol consists of a client connecting to a server and sending the server a selector (a line of text, which may be empty) via a TCP connection. The server responds with a block of text terminated with a period on a line by itself, and closes the connection. No state is retained by the server between transactions with a client. The simple nature of the protocol stems from the need to implement servers and clients for the slow, smaller desktop computers (1 MB Macs and DOS machines), quickly, and efficiently.
本質では、ゴーファープロトコルはサーバに接続して、セレクタをサーバに送るクライアント(人影がないかもしれないテキスト行)からTCP接続で成ります。 サーバは、1ブロックのテキストが系列に関する期間でそれ自体で終えられている状態で応じて、接続を終えます。 状態は全くクライアントと共にトランザクションの間でサーバによって保有されません。 プロトコルの控えめな性質は遅くて、より小さいデスクトップコンピュータ(1MBのMacsとDOSマシン)のためにすぐに、効率的にサーバとクライアントを実装する必要性によります。
Below is a simple example of a client/server interaction; more complex interactions are dealt with later. Assume that a "well- known" Gopher server (this may be duplicated, details are discussed
以下に、クライアント/サーバ相互作用の簡単な例があります。 より複雑な相互作用は後で対処されています。 それが「よく知られている」ゴーファーサーバであると仮定してください。(これがコピーされてもよい、詳細について議論します。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 3] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[3ページ]RFC1436ゴーファー行進
later) listens at a well known port for the campus (much like a domain-name server). The only configuration information the client software retains is this server's name and port number (in this example that machine is rawBits.micro.umn.edu and the port 70). In the example below the F character denotes the TAB character.
後で)、よく知られているポートでは、キャンパス(ドメイン名サーバのような)まで聴きます。 クライアントソフトウェアが保有する唯一の設定情報が、このサーバの名前とポートナンバー(この例では、そのマシンは、rawBits.micro.umn.eduとポート70である)です。 Fの下の例では、キャラクタはTABキャラクタを指示します。
Client: {Opens connection to rawBits.micro.umn.edu at port 70}
クライアント: ポート70でrawBits.micro.umn.eduに接続を開きます。
Server: {Accepts connection but says nothing}
サーバ: 接続を受け入れますが、沈黙します。
Client: <CR><LF> {Sends an empty line: Meaning "list what you have"}
クライアント: <CR><LF>。空の系列: 「あなたが持っているものを記載します」と意味するのを送ります。
Server: {Sends a series of lines, each ending with 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.....}
. {Period on a line by itself}
{Server closes connection}
サーバ: CR LFと共にそれぞれ終わって、一連の系列を送る、0AboutインターネットGopherFStuff: MinnesotaFZのusFrawBits.micro.umn.eduF70 1Around大学、5692年頃に、AUMFunderdog.micro.umn.eduF70 1Microcomputer News&PricesFPrices/Fpserver.bookstore.umn.eduF70 1Courses(Schedules)はDirectoriesFFuinfo.ais.umn.eduF70 1Departmental PublicationsFStuff: DPをCalendarsFFevents.ais.umn.eduF9120 1Student配置します:、FrawBits.micro.umn.eduF70、…、など… . それ自体で系列に関する期間サーバは接続を終えます。
The first character on each line tells whether the line describes a document, directory, or search service (characters '0', '1', '7'; there are a handful more of these characters described later). The succeeding characters up to the tab form a user display string to be shown to the user for use in selecting this document (or directory) for retrieval. The first character of the line is really defining the type of item described on this line. In nearly every case, the Gopher client software will give the users some sort of idea about what type of item this is (by displaying an icon, a short text tag, or the like).
各系列の最初のキャラクタは、系列がドキュメント、ディレクトリ、またはサーチサービス(キャラクタ'0'、'1'、'7'; これらの一層のキャラクタが後で説明した一握りがある)について説明するかどうか言います。 タブまでの続くキャラクタはこのドキュメント(または、ディレクトリ)を選択することにおける、検索の使用のためにユーザに見せられるユーザディスプレイストリングを形成します。 系列の最初のキャラクタは本当にこの系列で説明された項目のタイプを定義しています。 ほとんどあらゆる場合では、ゴーファークライアントソフトウェアはこれがどんなタイプの項目に関するそうであるかという考え(アイコン、短いテキストタグ、または同様のものを表示するのによる)についてある種をユーザに与えるでしょう。
The characters following the tab, up to the next tab form a selector string that the client software must send to the server to retrieve the document (or directory listing). The selector string should mean nothing to the client software; it should never be modified by the client. In practice, the selector string is often a pathname or other file selector used by the server to locate the item desired. The next two tab delimited fields denote the domain-name of the host that has this document (or directory), and the port at which to connect. If there are yet other tab delimited fields, the basic Gopher client should ignore them. A CR LF denotes the end of the item.
タブ(次のタブフォームまでのクライアントソフトウェアがドキュメント(または、ディレクトリリスト)を検索するためにサーバに送らなければならないセレクタストリング)の後をつけるキャラクタ。 セレクタストリングはクライアントソフトウェアに何も意味するはずがありません。 それはクライアントによって決して変更されるべきではありません。 セレクタストリングは、実際には、サーバによって使用される、望まれていた項目の場所を見つけるしばしばパス名か他のファイルセレクタです。 次の2つのタブの区切られた分野がこのドキュメント(または、ディレクトリ)、および接続するポートを持っているホストのドメイン名を指示します。 他のタブの区切られた分野がまだあれば、基本的なゴーファークライアントはそれらを無視するべきです。 CR LFは項目の端を指示します。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 4] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[4ページ]RFC1436ゴーファー行進
In the example, line 1 describes a document the user will see as "About internet Gopher". To retrieve this document, the client software must send the retrieval string: "Stuff:About us" to rawBits.micro.umn.edu at port 70. If the client does this, the server will respond with the contents of the document, terminated by a period on a line by itself. A client might present the user with a view of the world something like the following list of items:
例では、系列1はユーザが「インターネットゴーファー」とみなすドキュメントについて説明します。 このドキュメントを検索するために、クライアントソフトウェアは検索ストリングを送らなければなりません: ポート70のrawBits.micro.umn.eduへの「私たちに関して以下を詰めてください。」 クライアントがこれをすると、サーバは期間までに系列でそれ自体で終えられたドキュメントのコンテンツで反応するでしょう。 クライアントは項目の以下のリストのような世界観をユーザに与えるかもしれません:
About Internet Gopher
Around the University of Minnesota...
Microcomputer News & Prices...
Courses, Schedules, Calendars...
Student-Staff Directories...
Departmental Publications...
ミネソタ大学の周りのインターネットゴーファーに関して… マイクロコンピュータニュースと価格… コース、スケジュール、カレンダー… 学生スタッフディレクトリ… 部門の刊行物…
In this case, directories are displayed with an ellipsis and files are displayed without any. However, depending on the platform the client is written for and the author's taste, item types could be denoted by other text tags or by icons. For example, the UNIX curses-based client displays directories with a slash (/) following the name; Macintosh clients display directories alongside an icon of a folder.
この場合、省略と共にディレクトリを表示します、そして、いずれなしでもファイルを表示します。 しかしながら、クライアントが書かれているプラットホームと作者の趣味によって、他のテキストタグかアイコンは項目タイプを指示できました。 例えば、UNIXの呪いのベースのクライアントはスラッシュ(/)が名前に従っているディレクトリを表示します。 マッキントッシュクライアントはフォルダーのアイコンと並んでディレクトリを表示します。
The user does not know or care that the items up for selection may reside on many different machines anywhere on the Internet.
ユーザは、選択において、候補になっている項目がインターネットでどこでも多くの異なったマシンの上にあるかもしれないのを知りもしませんし、気にかけもしません。
Suppose the user selects the line "Microcomputer News & Prices...". This appears to be a directory, and so the user expects to see contents of the directory upon request that it be fetched. The following lines illustrate the ensuing client-server interaction:
ユーザが系列「マイクロコンピュータニュースと価格」を選択すると仮定してください… これがディレクトリであるように見えるので、ユーザは、それがとって来られるという要求でのディレクトリのコンテンツを見ると予想します。 以下の系列は続いているクライアント/サーバ相互作用を例証します:
Client: (Connects to pserver.bookstore.umn.edu at port 70)
Server: (Accepts connection but says nothing)
Client: Prices/ (Sends the magic string terminated by CRLF)
Server: (Sends a series of lines, each ending with 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.....)
. (Period on a line by itself)
(Server closes connection)
クライアント: (ポート70でpserver.bookstore.umn.eduに接続します) サーバ: (接続を受け入れますが、沈黙します) クライアント: 価格/(CRLFによって終えられた魔法のストリングを送ります)サーバ: (CR LFと共にそれぞれ終わって、一連の系列を送ります) 0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70 0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70 0IBM PricesFPrices/IckFpserver.bookstore.umn.eduF70 0Printerと周囲のPricesFPrices/PPPFpserver.bookstore.umn.eduF70、(…、など) . (それ自体で系列に関する期間) (サーバは接続を終えます)
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 5] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[5ページ]RFC1436ゴーファー行進
3. More details
3. その他の詳細
3.1 Locating services
3.1 サービスの場所を見つけること。
Documents (or other services that may be viewed ultimately as documents, such as a student-staff phonebook) are linked to the machine they are on by the trio of selector string, machine domain- name, and IP port. It is assumed that there will be one well-known top-level or root server for an institution or campus. The information on this server may be duplicated by one or more other servers to avoid a single point of failure and to spread the load over several servers. Departments that wish to put up their own departmental servers need to register the machine name and port with the administrators of the top-level Gopher server, much the same way as they register a machine name with the campus domain-name server. An entry which points to the departmental server will then be made at the top level server. This ensures that users will be able to navigate their way down what amounts to a virtual hierarchical file system with a well known root to any campus server if they desire.
ドキュメント(または、結局学生スタッフphonebookなどのドキュメントとして見なされるかもしれない他のサービス)はマシンドメインそれらがセレクタストリングの三つ組であるマシン、名前、およびIPポートにリンクされます。 団体かキャンパスへの1つのよく知られるトップレベルかルートサーバーがあると思われます。 このサーバの情報は他の1つ以上のサーバによってコピーされて、1ポイントの失敗を避けて、いくつかのサーバの上に負荷を広げるかもしれません。 それら自身の部門のサーバを提供したがっている部は、トップレベルゴーファーサーバの管理者にマシン名とポートを登録する必要があります、ずっと彼らがキャンパスドメイン名サーバのマシン名を登録するのに、似たり寄ったりです; そして部門のサーバへのそれのポイントが. これが確実にするユーザがナビゲートできるトップ平らなサーバで作られていて、何で、彼らの方法で、願望が彼らであるならどんなキャンパスサーバへのよく知られている根でも仮想の階層ファイルシステムに達しているかということであるエントリー。
Note that there is no requirement that a department register secondary servers with the central top-level server; they may just place a link to the secondary servers in their own primary servers. They may indeed place links to any servers they desire in their own server, thus creating a customized view of thethe Gopher information universe; links can of course point back at the top-level server. The virtual (networked) file system is therefore an arbitrary graph structure and not necessarily a rooted tree. The top-level node is merely one convenient, well-known point of entry. A set of Gopher servers linked in this manner may function as a campus-wide information system.
部が主要なトップレベルサーバにセカンダリサーバを登録するという要件が全くないことに注意してください。 彼らはただそれら自身のプライマリサーバのセカンダリサーバへのリンクを置くかもしれません。 本当に、彼らは彼らがそれら自身のサーバで望んでいるどんなサーバへのリンクも置くかもしれません、その結果、thetheゴーファー情報宇宙のカスタム設計された視点を作成します。 リンクはもちろんトップレベルサーバで後ろの方を指差すことができます。したがって、仮想(ネットワークでつながれる)のファイルシステムは必ず根づいている木ではなく、任意のグラフ構造です。 トップレベルノードは単に便利で、よく知られる1ポイントのエントリーです。 この様にリンクされた1セットのゴーファーサーバはキャンパス全体の情報システムとして機能するかもしれません。
Servers may of course point links at other than secondary servers. Indeed servers may point at other servers offering useful services anywhere on the internet. Viewed in this manner, Gopher can be seen as an Internet-wide information system.
セカンダリサーバを除いて、サーバはもちろんリンクを指すかもしれません。 本当に、サーバは、役に立つサービスをインターネットでどこでも提供しながら、他のサーバを指し示すかもしれません。 この様に見られて、ゴーファーをインターネット全体の情報システムと考えることができます。
3.2 Server portability and naming
3.2 サーバの移植性と命名
It is recommended that all registered servers have alias names (domain name system CNAME) that are used by Gopher clients to locate them. Links to these servers should use these alias names rather than the primary names. If information needs to be moved from one machine to another, a simple change of domain name system alias (CNAME) allows this to occur without any reconfiguration of clients in the field. In short, the domain name system may be used to re-map a server to a new address. There is nothing to prevent secondary servers or services from running on otherwise named servers or ports
すべての登録されたサーバには彼らの居場所を見つけるのにゴーファークライアントによって使用される別名(ドメイン名システムCNAME)があるのは、お勧めです。 これらのサーバへのリンクはプライマリ名前よりむしろこれらの別名を使用するはずです。 情報が、1台のマシンから別のマシンまで動かされる必要があるなら、ドメイン名システム別名(CNAME)の簡単な変化で、これはその分野でのクライアントの少しも再構成なしで起こります。 要するに、ドメイン名システムは、新しい住所にサーバを再写像するのに使用されるかもしれません。 何もセカンダリサーバを防ぐものがなかったか、またはそうでなければ、稼働からのサービスはサーバかポートを命名しました。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 6] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[6ページ]RFC1436ゴーファー行進
other than 70, however these should be reachable via a primary server.
しかしながら、70を除いて、これらはプライマリサーバで届いているべきです。
3.3 Contacting server administrators
3.3 サーバアドミニストレータに連絡すること。
It is recommended that every server administrator have a document called something like: "About Bogus University's Gopher server" as the first item in their server's top level directory. In this document should be a short description of what the server holds, as well as name, address, phone, and an e-mail address of the person who administers the server. This provides a way for users to get word to the administrator of a server that has inaccurate information or is not running correctly. It is also recommended that administrators place the date of last update in files for which such information matters to the users.
すべてのサーバアドミニストレータには以下のように呼ばれるドキュメントがあることが勧められます。 彼らのサーバのトップ平らなディレクトリにおける最初の項目としての「Bogus大学のゴーファーサーバ。」 本書ではサーバ船倉、および名前が扱うことに関する短い記述と、電話と、サーバを管理する人のEメールアドレスであるべきです。これはユーザが不正確な情報を持っているか、または正しく稼働していないサーバの管理者に単語を届ける方法を提供します。 また、管理者がそのような情報がユーザに重要であるファイルのアップデートの日付を置くのも、お勧めです。
3.4 Modular addition of services
3.4 モジュールのサービスの追加
The first character of each line in a server-supplied directory listing indicates whether the item is a file (character '0'), a directory (character '1'), or a search (character '7'). This is the base set of item types in the Gopher protocol. It is desirable for clients to be able to use different services and speak different protocols (simple ones such as finger; others such as CSO phonebook service, or Telnet, or X.500 directory service) as needs dictate. CSO phonebook service is a client/server phonebook system typically used at Universities to publish names, e-mail addresses, and so on. The CSO phonebook software was developed at the University of Illinois and is also sometimes refered to as ph or qi. For example, if a server-supplied directory listing marks a certain item with type character '2', then it means that to use this item, the client must speak the CSO protocol. This removes the need to be able to anticipate all future needs and hard-wire them in the basic Internet Gopher protocol; it keeps the basic protocol extremely simple. In spite of this simplicity, the scheme has the capability to expand and change with the times by adding an agreed upon type-character for a new service. This also allows the client implementations to evolve in a modular fashion, simply by dropping in a module (or launching a new process) for some new service. The servers for the new service of course have to know nothing about Internet Gopher; they can just be off-the shelf CSO, X.500, or other servers. We do not however, encourage arbitrary or machine-specific proliferation of service types in the basic Gopher protocol.
サーバで供給されたディレクトリリストにおける、それぞれの系列の最初のキャラクタは、項目がファイル(キャラクタ'0')、ディレクトリ(キャラクタ'1')、または検索(キャラクタ'7')であるかを示します。 これはゴーファープロトコルの項目タイプの基底集合です。 クライアントが異なったサービスを利用して、必要性が決めるように異なったプロトコル(指などの簡単な1つ; CSO phonebookサービス、Telnet、またはX.500ディレクトリサービスなどの他のもの)を話すことができるのは、望ましいです。 CSO phonebookサービスは名前、Eメールアドレスなどを発表するのに大学で通常使用されるクライアント/サーバphonebookシステムです。 CSO phonebookソフトウェアにイリノイ大学で開発されて、また、phか気として時々referedされます。 例えば、サーバで供給されたディレクトリリストがタイプキャラクタ'2'をある項目に付けるなら、それは、この項目を使用するために、クライアントがCSOプロトコルを話さなければならないことを意味します。 これは基本的なインターネットゴーファープロトコルですべての将来の必要性を予期して、それらを配線できる必要性を取り除きます。 それは非常に簡単に基本プロトコルを保ちます。 この簡単さにもかかわらず、体系には広がって、加えることによって時代と共に変わる能力がある、新しいサービスのためにタイプキャラクタに同意しました。 また、これで、クライアント実装はモジュール方式で発展します、単に何らかの新しいサービスのためにモジュールをちょっと立ち寄らせることによって(ニュープロセスを始めて)。 新しいサービスのためのサーバはもちろんインターネットゴーファーに関して何も知ってはいけません。 それらは、まさしくすぐ入手できるCSO、X.500、または他のサーバであるかもしれません。 しかしながらでない、私たちはして、基本的なゴーファープロトコルにおける、サービスタイプの任意の、または、マシン特有の増殖を奨励してください。
On the other hand, subsets of other document retrieval schemes may be mapped onto the Gopher protocol by means of "gateway-servers". Examples of such servers include Gopher-to-FTP gateways, Gopher-to- archie gateways, Gopher-to-WAIS gateways, etc. There are a number of
他方では、他の文献検索体系の部分集合は「ゲートウェイサーバ」によってゴーファープロトコルに写像されるかもしれません。 そのようなサーバに関する例が含んでいる、FTPへのゴーファー、ゲートウェイ、ゴーファーからarchieゲートウェイ、ゴーファーからWAISへのゲートウェイなど 数があります。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 7] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[7ページ]RFC1436ゴーファー行進
advantages of such mechanisms. First, a relatively powerful server machine inherits both the intelligence and work, rather than the more modest, inexpensive desktop system that typically runs client software or basic server software. Equally important, clients do not have to be modified to take advantage of a new resource.
そのようなメカニズム1番目の利点、比較的強力なサーバマシンは知性とクライアントソフトウェアか基幹サーバソフトウェアを通常動かすより穏やかで、安価なデスクトップ型よりむしろ仕事の両方を引き継ぎます。 等しく重要であることで、クライアントは、新しいリソースを利用するように変更される必要はありません。
3.5 Building clients
3.5 ビルクライアント
A client simply sends the retrieval string to a server if it wants to retrieve a document or view the contents of a directory. Of course, each host may have pointers to other hosts, resulting in a "graph" (not necessarily a rooted tree) of hosts. The client software may save (or rather "stack") the locations that it has visited in search of a document. The user could therefore back out of the current location by unwinding the stack. Alternatively, a client with multiple-window capability might just be able to display more than one directory or document at the same time.
それがドキュメントを検索したいか、またはディレクトリのコンテンツを見たいなら、クライアントは単に検索ストリングをサーバに送ります。 もちろん、各ホストは他のホストに指針を持っているかもしれません、ホストの「グラフ」(必ず根づいている木であるというわけではない)をもたらして。 クライアントソフトウェアはそれがドキュメントを求めて訪問した位置を節約するかもしれません(または、むしろ、「積み重ねます」)。 したがって、ユーザは、現在の位置からスタックを解くことによって、バックして出ることができるでしょう。 あるいはまた、連窓能力があるクライアントは同時に、ただ1通以上のディレクトリかドキュメントを表示できるかもしれません。
A smart client could cache the contents of visited directories (rather than just the directory's item descriptor), thus avoiding network transactions if the information has been previously retrieved.
賢いクライアントは訪問されたディレクトリ(まさしくディレクトリの項目記述子よりむしろ)のコンテンツをキャッシュできました、その結果、以前に情報を検索してあるなら、ネットワークトランザクションを避けます。
If a client does not understand what a say, type 'B' item (not a core item) is, then it may simply ignore the item in the directory listing; the user never even has to see it. Alternatively, the item could be displayed as an unknown type.
クライアントが、言いたい事、タイプ'B'項目(コア項目でない)が何であるかを理解していないなら、ディレクトリリストで単に項目を無視するかもしれません。 ユーザはそれを決して見る必要さえありません。 あるいはまた、未知のタイプとして項目を表示できました。
Top-level or primary servers for a campus are likely to get more traffic than secondary servers, and it would be less tolerable for such primary servers to be down for any long time. So it makes sense to "clone" such important servers and construct clients that can randomly choose between two such equivalent primary servers when they first connect (to balance server load), moving to one if the other seems to be down. In fact, smart client implementations do this clone server and load balancing. Alternatively, it may make sense to have the domain name system return one of a set of redundant of server's IP address to load balance betwen redundant sets of important servers.
キャンパスへのトップレベルの、または、プライマリのサーバは長い何時でも、セカンダリサーバ、およびそれより多くのトラフィックを得るのがそのようなプライマリサーバは、より許容できない傾向があります。 それで、そのような2つの同等なプライマリサーバの間でそれらが最初にいつ接続するかを(サーバ負荷のバランスをとる)手当たりしだいに選ぶことができるそのような重要なサーバと構造物クライアントの「クローンを作る」意味になります、もう片方が下がっているように思えるなら1つに移行して。 事実上、賢いクライアント実装はこのクローンサーバとロードバランシングをします。 あるいはまた、それはドメイン名システムにバランスbetwenを積み込むためにサーバのIPアドレスで余分の1セットの1つを返させる意味を余分なセットの重要なサーバにするかもしれません。
3.6 Building ordinary internet Gopher servers
3.6 普通のインターネットゴーファーサーバを組立てること。
The retrieval string sent to the server might be a path to a file or directory. It might be the name of a script, an application or even a query that generates the document or directory returned. The basic server uses the string it gets up to but not including a CR-LF or a TAB, whichever comes first.
サーバに送られた検索ストリングはファイルかディレクトリへの経路であるかもしれません。 それはスクリプト、アプリケーションの名前であるかもしれませんかドキュメントかディレクトリを作る質問さえ戻りました。 基幹サーバは上がりますが、それをCR-LFかTABを含んでいないストリングを使用します、どれが一番になっても。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 8] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[8ページ]RFC1436ゴーファー行進
All intelligence is carried by the server implementation rather than the protocol. What you build into more exotic servers is up to you. Server implementations may grow as needs dictate and time allows.
すべての知性がプロトコルよりむしろサーバ実装によって運ばれます。 あなたが、よりエキゾチックなサーバに築き上げるものはあなた次第です。 必要性が決めて、時間が許容するようにサーバ実装は成長するかもしれません。
3.7 Special purpose servers
3.7 専用サーバ
There are two special server types (beyond the normal Gopher server) also discussed below:
また、以下で議論した2つの特別なサーバタイプ(正常なゴーファーサーバを超えた)があります:
1. A server directory listing can point at a CSO nameserver (the
server returns a type character of '2') to allow a campus
student-staff phonebook lookup service. This may show up on the
user's list of choices, perhaps preceded by the icon of a phone-
book. If this item is selected, the client software must resort
to a pure CSO nameserver protocol when it connects to the
appropriate host.
1. サーバディレクトリリストは、キャンパス学生スタッフphonebookルックアップサービスを許すために、CSOネームサーバ(サーバは'2'のタイプキャラクタを返す)を指し示すことができます。 これはユーザの電話の本のアイコンが恐らく先行した選択のリストに現れるかもしれません。 適切なホストに接するとき、この項目が選択されるなら、クライアントソフトウェアは純粋なCSOネームサーバプロトコルに訴えなければなりません。
2. A server can also point at a "search server" (returns a first
character of '7'). Such servers may implement campus network (or
subnet) wide searching capability. The most common search servers
maintain full-text indexes on the contents of text documents held
by some subset of Gopher servers. Such a "full-text search
server" responds to client requests with a list of all documents
that contain one or more words (the search criteria). The client
sends the server the selector string, a tab, and the search string
(words to search for). If the selector string is empty, the client
merely sends the search string. The server returns the equivalent
of a directory listing for documents matching the search criteria.
Spaces between words are usually implied Boolean ANDs (although in
different implementations or search types, this may not
necessarily be true).
2. また、サーバは「検索サーバ」('7'の最初のキャラクタを返す)を指し示すことができます。 そのようなサーバは、キャンパスネットワーク(または、サブネット)が広い探す能力であると実装するかもしれません。 最も一般的な検索サーバは、テキストドキュメントのコンテンツに関する全文インデックスがゴーファーサーバの何らかの部分集合を固守したと主張します。 そのような「全文検索サーバ」は1つ以上の単語(検索評価基準)を含むすべてのドキュメントのリストでクライアント要求に応じます。 クライアントはセレクタストリング、タブ、および検索ストリング(検索する単語)をサーバに送ります。 セレクタストリングが空であるなら、クライアントは単に検索ストリングを送ります。 サーバは検索評価基準に合っているドキュメントのためにリストアップされているディレクトリの同等物を返します。 単語の間の空間は通常暗示しているブールANDs(異なった実装か検索タイプに、これは必ず当てはまるかもしれないというわけではありませんが)です。
The CSO addition exists for historical reasons: at time of design, the campus phone-book servers at the University of Minnesota used the CSO protocol and it seemed simplest to just engulf them. The index- server is however very much a Gopher in spirit, albeit with a slight twist in the meaning of the selector-string. Index servers are a natural place to incorperate gateways to WAIS and WHOIS services.
CSO追加は歴史的な理由で存在しています: デザインの時に、ミネソタ大学のキャンパス電話帳サーバはCSOプロトコルを使用しました、そして、ただそれらを巻き込むのは最も簡単に思えました。 インデックスサーバはしかしながら、たいへん精神におけるゴーファーです、セレクタストリングの意味におけるわずかなねじれで。 インデックスサーバはWAISへのincorperateゲートウェイとWHOISサービスへの自然な場所です。
3.7.1 Building CSO-servers
3.7.1 ビルCSO-サーバ
A CSO Nameserver implementation for UNIX and associated documentation is available by anonymous ftp from uxa.cso.uiuc.edu. We do not anticipate implementing it on other machines.
UNIXと関連ドキュメンテーションのためのCSO Nameserver実装はuxa.cso.uiuc.eduからのアノニマスFTPで利用可能です。 私たちは、他のマシンの上でそれを実装すると予期しません。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 9] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[9ページ]RFC1436ゴーファー行進
3.7.2 Building full-text search servers
3.7.2 ビル全文検索サーバ
A full-text search server is a special-purpose server that knows about the Gopher scheme for retrieving documents. These servers maintain a full-text index of the contents of plain text documents on Gopher servers in some specified domain. A Gopher full-text search server was implemented using several NeXTstations because it was easy to take advantage of the full-text index/search engine built into the NeXT system software. A search server for generic UNIX systems based on the public domain WAIS search engine, is also available and currently an optional part of the UNIX gopher server. In addition, at least one implementation of the gopher server incorperates a gateway to WAIS servers by presenting the WAIS servers to gopherspace as full-text search servers. The gopher<->WAIS gateway servers does the work of translating from gopher protocol to WAIS so unmodified gopher clients can access WAIS servers via the gateway server.
全文検索サーバはドキュメントを検索することのゴーファー体系に関して知っている専用サーバです。 これらのサーバは何らかの指定されたドメインのゴーファーサーバのプレーンテキストドキュメントのコンテンツの全文インデックスを維持します。 ゴーファー全文検索サーバは、NeXTシステムソフトが組み込まれた全文インデックス/サーチエンジンを利用するのが簡単であったので数個のNeXTstationsを使用することで実装されました。 公共の場WAISサーチエンジンに基づくジェネリックUNIXシステムのための検索サーバは、また、利用可能であって、現在、UNIXリスサーバの任意の部分です。さらに、リスサーバの少なくとも1つの実装が、全文検索サーバとしてWAISサーバをgopherspaceに提示することによって、WAISサーバへのゲートウェイをincorperatesします。 WAISゲートウェイサーバがゲートウェイサーバで変更されていないリスクライアントがWAISサーバにアクセスできるようにリスプロトコルからWAISまで翻訳する仕事をするリス<->。
By using several index servers (rather than a monolithic index server) indexes may be searched in parallel (although the client software is not aware of this). While maintaining full-text indexes of documents distributed over many machines may seem a daunting task, the task can be broken into smaller pieces (update only a portion of the indexes, search several partial indexes in parallel) so that it is manageable. By spreading this task over several small, cheap (and fast) workstations it is possible to take advantage of fine-grain parallelism. Again, the client software is not aware of this. Client software only needs to know that it can send a search string to an index server and will receive a list of documents that contain the words in the search string.
いくつかのインデックスサーバ(一枚岩的なインデックスサーバよりむしろ)を使用することによって、インデックスは平行を捜されるかもしれません(クライアントソフトウェアがこれを意識していませんが)。 多くのマシンの上の配付資料の全文インデックスが困難な仕事に見えるかもしれないと主張している間、より小さい断片をタスクに細かく分けることができるので(インデックスの部分だけをアップデートしてください、そして、平行ないくつかの部分的なインデックスを捜してください)、それは処理しやすいです。 いくつかの小さくて、安い(速い)ワークステーションの上にこのタスクを広げることによって、細粒平行関係を利用するのは可能です。 一方、クライアントソフトウェアはこれを意識していません。 クライアントソフトウェアは、検索ストリングをインデックスサーバに送ることができて、検索ストリングに単語を含むドキュメントのリストを受け取るのを知る必要があるだけです。
3.8 Item type characters
3.8 項目タイプキャラクタ
The client software decides what items are available by looking at the first character of each line in a directory listing. Augmenting this list can extend the protocol. A list of defined item-type characters follows:
クライアントソフトウェアは、ディレクトリにおける、それぞれの系列の最初のキャラクタが記載するのを見ることによってどんな項目が利用可能であるかを決めます。 このリストを増大させると、プロトコルを広げることができます。 被定義項目タイプキャラクタのリストは従います:
0 Item is a file
1 Item is a directory
2 Item is a CSO phone-book server
3 Error
4 Item is a BinHexed Macintosh file.
5 Item is DOS binary archive of some sort.
Client must read until the TCP connection closes. Beware.
6 Item is a UNIX uuencoded file.
7 Item is an Index-Search server.
8 Item points to a text-based telnet session.
9 Item is a binary file!
1Itemがディレクトリです。0項目がファイルである、2ItemによるCSO電話帳サーバ3Error4ItemがBinHexedマッキントッシュファイルであるということです。 5項目はある種のDOSの2進のアーカイブです。 TCP接続が閉じるまで、クライアントは読まなければなりません。 注意してください。 6項目はUNIXがファイルをuuencodedしたということです。 7項目はIndex-検索サーバです。8Itemはテキストベースのtelnetセッションまで指します。 9項目はバイナリーファイルです!
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 10] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[10ページ]RFC1436ゴーファー行進
Client must read until the TCP connection closes. Beware.
+ Item is a redundant server
T Item points to a text-based tn3270 session.
g Item is a GIF format graphics file.
I Item is some kind of image file. Client decides how to display.
TCP接続が閉じるまで、クライアントは読まなければなりません。 注意してください。 + 項目はItemがテキストベースのtn3270セッションまで向ける余分なサーバTです。g ItemはGIF形式グラフィックスファイルです。 I Itemはある種のイメージ・ファイルです。 クライアントは表示する方法を決めます。
Characters '0' through 'Z' are reserved. Local experiments should use other characters. Machine-specific extensions are not encouraged. Note that for type 5 or type 9 the client must be prepared to read until the connection closes. There will be no period at the end of the file; the contents of these files are binary and the client must decide what to do with them based perhaps on the .xxx extension.
'Z'を通したキャラクター'0'は予約されています。 ローカルの実験は他のキャラクタを使用するべきです。 マシン特有の拡大は奨励されません。 タイプ5かタイプ9のために、クライアントが接続が閉じるまで読む用意ができていなければならないことに注意してください。 期間が全くファイルの端にないでしょう。 これらのファイルの中身は2進です、そして、クライアントは彼らが恐らく.xxx拡張子に基づいていて何をしたらよいかを決めなければなりません。
3.9 User display strings and server selector strings
3.9 ユーザディスプレイストリングとサーバセレクタストリング
User display strings are intended to be displayed on a line on a typical screen for a user's viewing pleasure. While many screens can accommodate 80 character lines, some space is needed to display a tag of some sort to tell the user what sort of item this is. Because of this, the user display string should be kept under 70 characters in length. Clients may truncate to a length convenient to them.
ユーザが喜びを見るための典型的なスクリーンに系列にユーザディスプレイストリングが表示されることを意図します。 多くのスクリーンが80個のハイライト線に対応できる間、何らかのスペースが、これがどういう項目であるかをユーザに言うためにある種のタグを表示するのに必要です。 これのために、ユーザディスプレイストリングは長さにおける70未満のキャラクタであることが保たれるべきです。 クライアントは彼らにとって、便利な長さに先端を切るかもしれません。
4. Simplicity is intentional
4. 簡単さは意図的です。
As far as possible we desire any new features to be carried as new protocols that will be hidden behind new document-types. The internet Gopher philosophy is:
できるだけ、私たちはどんな新しいドキュメントタイプの後ろに隠される新しいプロトコルとして運ばれるべき新機能も望んでいます。 インターネットゴーファー哲学は以下の通りです。
(a) Intelligence is held by the server. Clients have the option
of being able to access new document types (different, other types
of servers) by simply recognizing the document-type character.
Further intelligence to be borne by the protocol should be
minimized.
(a) 知性はサーバによって保持されます。クライアントには、単にドキュメントタイプキャラクタを見分けることによって新しいドキュメントタイプ(異なって、他のタイプのサーバ)にアクセスできるオプションがあります。 プロトコルで生まれるさらなる知性は最小にされるべきです。
(b) The well-tempered server ought to send "text" (unless a file
must be transferred as raw binary). Should this text include
tabs, formfeeds, frufru? Probably not, but rude servers will
probably send them anyway. Publishers of documents should be
given simple tools (filters) that will alert them if there are any
funny characters in the documents they wish to publish, and give
them the opportunity to strip the questionable characters out; the
publisher may well refuse.
(b) よく気質のサーバは「テキスト」を送るべきです(生のバイナリーとしてファイルを移してはいけないなら)。 本稿はタブ、formfeeds、frufruを含むべきですか? たぶんそうでない、失礼なサーバはたぶんとにかくそれらを送るでしょう。 それらが発表したがっているドキュメントに何かおかしいキャラクタがあればそれらを警告して、いかがわしい人物を取り除く機会をそれらに与える簡単なツール(フィルタ)をドキュメントの出版社に与えるべきです。 出版社はたぶん拒否するでしょう。
(c) The well-tempered client should do something reasonable with
funny characters received in text; filter them out, leave them in,
whatever.
(c) よく気質のクライアントはテキストに受け取っているおかしいキャラクタで何か妥当なことをするべきです。 何でもにそれらを無視してください、そして、中にそれらを残してください。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 11] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[11ページ]RFC1436ゴーファー行進
Appendix
付録
Paul's NQBNF (Not Quite BNF) for the Gopher Protocol.
ゴーファーのためのポールのNQBNF(全くBNFであるというわけではない)は議定書を作ります。
Note: This is modified BNF (as used by the Pascal people) with a few
English modifiers thrown in. Stuff enclosed in '{}' can be
repeated zero or more times. Stuff in '[]' denotes a set of
items. The '-' operator denotes set subtraction.
以下に注意してください。 これはいくつかのイギリスの修飾語が投げ入れられている変更されたBNF(パスカルの人々によって使用されるように)です。 同封のコネを詰めてください、'、'ゼロか、より多くの回繰り返すことができてください。 '[]'のものは1セットの項目を指示します。'--'オペレータはセット引き算を指示します。
Directory Entity
ディレクトリ実体
CR-LF ::= ASCII Carriage Return Character followed by Line Feed
character.
CR-LF:、:= ASCII Carriage Returnキャラクターは線Feedキャラクタで従いました。
Tab ::= ASCII Tab character.
以下にタブを付けてください:= ASCII Tabキャラクタ。
NUL ::= ASCII NUL character.
NUL:、:= ASCII NULキャラクタ。
UNASCII ::= ASCII - [Tab CR-LF NUL].
UNASCII:、:= ASCII--[タブCR-LF NUL。]
Lastline ::= '.'CR-LF.
Lastline:、:= '. 'CR-LF。
TextBlock ::= Block of ASCII text not containing Lastline pattern.
TextBlock:、:= Lastlineパターンを含まないASCIIテキストのブロック。
Type ::= UNASCII.
以下をタイプしてください:= UNASCII。
RedType ::= '+'.
RedType:、:= '+'.
User_Name ::= {UNASCII}.
ユーザ_は以下を命名します:= UNASCII。
Selector ::= {UNASCII}.
セレクタ:、:= UNASCII。
Host ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}.
以下を接待してください:= '、UNASCII--、['.'、]、'.'、UNASCII--、['.'、]
Note: This is a Fully Qualified Domain Name as defined in RFC 1034.
(e.g., gopher.micro.umn.edu) Hosts that have a CR-LF
TAB or NUL in their name get what they deserve.
以下に注意してください。 これはRFC1034で定義されるようにFully Qualified Domain Nameです。 (例えば、gopher.micro.umn.edu) 彼らの名前でCR-LF TABかNULを持っているホストが彼らが値するものを得ます。
Digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' .
ケタ:、:= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' .
DigitSeq ::= digit {digit}.
DigitSeq:、:= ケタケタ。
Port ::= DigitSeq.
以下を移植してください:= DigitSeq。
Note: Port corresponds the the TCP Port Number, its value should
be in the range [0..65535]; port 70 is officially assigned
to gopher.
以下に注意してください。 ポートは対応しています。TCP Port Numberであり、値が範囲[0 .65535]にあるべきです。 ポート70は公式にリスに割り当てられます。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 12] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[12ページ]RFC1436ゴーファー行進
DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF
{RedType User_Name Tab Selector Tab Host Tab Port CR-LF}
DirEntity:、:= ユーザ_名前タブセレクタタブホストタブポートCR-LFをタイプしてください。RedTypeユーザ_名前タブセレクタタブホストタブポートCR-LF
Notes:
注意:
It is *highly* recommended that the User_Name field contain only printable characters, since many different clients will be using it. However if eight bit characters are used, the characters should conform with the ISO Latin1 Character Set. The length of the User displayable line should be less than 70 Characters; longer lines may not fit across some screens.
*多くの異なったクライアントがそれを使用するので強く、*が、User_Name分野が印刷可能なキャラクタだけを含むことを勧めたということです。 しかしながら、8ビットのキャラクタが使用されているなら、キャラクタはISO Latin1文字コードに従うべきです。 User displayable系列の長さは70未満のキャラクターであるべきです。 より長い系列はいくつかのスクリーンの向こう側に合わないかもしれません。
The Selector string should be no longer than 255 characters.
Selectorストリングはもう255のキャラクタよりそうであるべきです。
Menu Entity
メニュー実体
Menu ::= {DirEntity} Lastline.
メニュー:、:= DirEntity、Lastline。
Menu Transaction (Type 1 item)
メニュートランザクション(タイプ1項目)
C: Opens Connection S: Accepts Connection C: Sends Selector String S: Sends Menu Entity
C: 接続Sを開きます: 接続Cは受け入れます: セレクタストリングSを送ります: メニュー実体を送ります。
Connection is closed by either client or server (typically server).
クライアントかサーバ(通常サーバ)のどちらかによって接続は閉店させられます。
Textfile Entity
Textfile実体
TextFile ::= {TextBlock} Lastline
TextFile:、:= TextBlock、Lastline
Note: Lines beginning with periods must be prepended with an extra
period to ensure that the transmission is not terminated early.
The client should strip extra periods at the beginning of the line.
以下に注意してください。 延長ピリオドで期間で始まる線をprependedして、トランスミッションが早く終えられないのを保証しなければなりません。 クライアントは始めの延長ピリオドから系列を奪い取るべきです。
TextFile Transaction (Type 0 item)
TextFileトランザクション(タイプ0項目)
C: Opens Connection. S: Accepts connection C: Sends Selector String. S: Sends TextFile Entity.
C: 接続を開きます。 S: 接続Cは受け入れます: セレクタストリングを送ります。 S: 実体をTextFileに送ります。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 13] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[13ページ]RFC1436ゴーファー行進
Connection is closed by either client or server (typically server).
クライアントかサーバ(通常サーバ)のどちらかによって接続は閉店させられます。
Note: The client should be prepared for the server closing the
connection without sending the Lastline. This allows the
client to use fingerd servers.
以下に注意してください。 クライアントはLastlineを送らないで接続を終えるサーバのために用意ができているべきです。 これで、クライアントはfingerdサーバを使用できます。
Full-Text Search Transaction (Type 7 item)
全文検索トランザクション(タイプ7項目)
Word ::= {UNASCII - ' '}
BoolOp ::= 'and' | 'or' | 'not' | SPACE
SearchStr ::= Word {{SPACE BoolOp} SPACE Word}
以下を言い表してください:= UNASCII--、'、'、BoolOp:、:、'= 'and'| 'or'| 'not'| スペースSearchStr:、:= WordスペースBoolOpはWordを区切ります。
C: Opens Connection. C: Sends Selector String, Tab, Search String. S: Sends Menu Entity.
C: 接続を開きます。 C: セレクタストリング、タブに検索ストリングを送ります。 S: メニュー実体を送ります。
Note: In absence of 'and', 'or', or 'not' operators, a SPACE is
regarded as an implied 'and' operator. Expression is evaluated
left to right. Further, not all search engines or search
gateways currently implemented have the boolean operators
implemented.
以下に注意してください。 'and'、'or'、または'not'オペレータの欠如では、SPACEは暗示している'and'オペレータと見なされます。 式は左で右に評価されます。 さらにすべてではなく、エンジンを捜してください。さもないと、現在実装されている検索ゲートウェイは論理演算子オペレータを実装します。
Binary file Transaction (Type 9 or 5 item)
バイナリーファイルTransaction(タイプ9か5項目)
C: Opens Connection. S: Accepts connection C: Sends Selector String. S: Sends a binary file and closes connection when done.
C: 接続を開きます。 S: 接続Cは受け入れます: セレクタストリングを送ります。 S: バイナリーファイルを送って、すると、接続を終えます。
Syntactic Meaning for Directory Entities
ディレクトリ実体のための構文の意味
The client should interpret the type field as follows:
クライアントは以下のタイプ分野を解釈するべきです:
0 The item is a TextFile Entity.
Client should use a TextFile Transaction.
0 項目はTextFile Entityです。 クライアントはTextFile Transactionを使用するべきです。
1 The item is a Menu Entity.
Client should use a Menu Transaction.
1 項目はMenu Entityです。 クライアントはMenu Transactionを使用するべきです。
2 The information applies to a CSO phone book entity.
Client should talk CSO protocol.
2 情報はCSO電話帳実体に適用されます。 クライアントはCSOプロトコルについて話すべきです。
3 Signals an error condition.
3 エラー条件に合図します。
4 Item is a Macintosh file encoded in BINHEX format
4項目はBINHEX形式でコード化されたマッキントッシュファイルです。
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 14] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[14ページ]RFC1436ゴーファー行進
5 Item is PC-DOS binary file of some sort. Client gets to decide.
5項目はある種のPC-DOSバイナリーファイルです。 クライアントは、決め始めます。
6 Item is a uuencoded file.
6項目はuuencodedファイルです。
7 The information applies to a Index Server.
Client should use a FullText Search transaction.
情報はIndex Serverに適用されます。7 クライアントはFullText検索トランザクションを使用するべきです。
8 The information applies to a Telnet session.
Connect to given host at given port. The name to login as at this
host is in the selector string.
8 情報はTelnetセッションに適用されます。 与えられたポートで与えられたホストに接してください。 このホストのようにログインする名前がセレクタストリングにあります。
9 Item is a binary file. Client must decide what to do with it.
9項目はバイナリーファイルです。 クライアントは、それで何をしたらよいかを決めなければなりません。
+ The information applies to a duplicated server. The information
contained within is a duplicate of the primary server. The primary
server is defined as the last DirEntity that is has a non-plus
"Type" field. The client should use the transaction as defined by
the primary server Type field.
+ 情報はコピーされたサーバに適用されます。含まれて、プライマリサーバの写しが中にあります。プライマリサーバが最後のDirEntityと定義されるという情報には、非プラス「タイプ」分野があります。 クライアントはプライマリサーバType分野によって定義されるようにトランザクションを使用するべきです。
g Item is a GIF graphic file.
g項目はGIFのグラフィックファイルです。
I Item is some kind of image file. Client gets to decide.
I Itemはある種のイメージ・ファイルです。 クライアントは、決め始めます。
T The information applies to a tn3270 based telnet session.
Connect to given host at given port. The name to login as at this
host is in the selector string.
情報がtn3270に当てはまるTはtelnetセッションを基礎づけました。 与えられたポートで与えられたホストに接してください。 このホストのようにログインする名前がセレクタストリングにあります。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Farhad Anklesaria Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455
SEミネアポリス、ミネソタ大学部屋152羊飼い研究室100ユニオン・ストリートミネソタ Farhad Anklesariaコンピュータと情報サービス、55455
Phone: (612) 625 1300 EMail: fxa@boombox.micro.umn.edu
以下に電話をしてください。 (612) 625 1300はメールされます: fxa@boombox.micro.umn.edu
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 15] RFC 1436 Gopher March 1993
1993年のAnklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[15ページ]RFC1436ゴーファー行進
Mark McCahill Computer and Information Services, University of Minnesota Room 152 Shepherd Labs 100 Union Street SE Minneapolis, MN 55455
McCahillコンピュータと情報がサービスであるとマークしてください、そして、ミネソタ大学部屋152はSEミネアポリス、研究室100ユニオン・ストリートミネソタ 55455を見張ります。
Phone: (612) 625 1300 EMail: mpm@boombox.micro.umn.edu
以下に電話をしてください。 (612) 625 1300はメールされます: 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
ポールリントナーComputerと情報サービス、SEミネアポリス、ミネソタ大学部屋152羊飼い研究室100ユニオン・ストリートミネソタ 55455
Phone: (612) 625 1300 EMail: lindner@boombox.micro.umn.edu
以下に電話をしてください。 (612) 625 1300はメールされます: 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
SEミネアポリス、ミネソタ大学部屋152羊飼い研究室100ユニオン・ストリートミネソタ コンピュータと情報サービス、デヴィッドJohnson55455
Phone: (612) 625 1300 EMail: dmj@boombox.micro.umn.edu
以下に電話をしてください。 (612) 625 1300はメールされます: 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
ダニエルトーリーComputerと情報サービス、SEミネアポリス、ミネソタ大学部屋152羊飼い研究室100ユニオン・ストリートミネソタ 55455
Phone: (612) 625 1300 EMail: daniel@boombox.micro.umn.edu
以下に電話をしてください。 (612) 625 1300はメールされます: 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
ボブアルベルティComputerと情報サービス、SEミネアポリス、ミネソタ大学部屋152羊飼い研究室100ユニオン・ストリートミネソタ 55455
Phone: (612) 625 1300 EMail: alberti@boombox.micro.umn.edu
以下に電話をしてください。 (612) 625 1300はメールされます: alberti@boombox.micro.umn.edu
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 16]
Anklesari、McCahill、リントナー、ジョンソン、トーリー、およびアルベルティ[16ページ]
一覧
スポンサーリンク
