Network Working Group R. Faith
Request for Comments: 2229 U. North Carolina, Chapel Hill
Category: Informational B. Martin
Miranda Productions
October 1997
A Dictionary Server Protocol
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
著作権（C）インターネット協会（1997）。全著作権所有。
Abstract
抽象
The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.
辞書サーバプロトコル（DICT）は、クライアントが、自然言語の辞書データベースのセットから辞書定義にアクセスすることを可能にするTCPトランザクションベースのクエリ/応答プロトコルです。
Table of Contents
目次
1. Introduction ......................................... 2
1.1. Requirements ......................................... 3
2. Protocol Overview .................................... 3
2.1. Link Level ........................................... 3
2.2. Lexical Tokens ....................................... 3
2.3. Commands ............................................. 4
2.4. Responses ............................................ 5
2.4.1. Status Responses ..................................... 5
2.4.2. General Status Responses ............................. 6
2.4.3. Text Responses ....................................... 6
3. Command and Response Details ......................... 7
3.1. Initial Connection ................................... 7
3.2. The DEFINE Command ................................... 9
3.3. The MATCH Command .................................... 10
3.4. A Note on Virtual Databases .......................... 12
3.5. The SHOW Command ..................................... 13
3.5.1. SHOW DB .............................................. 13
3.5.2. SHOW STRAT ........................................... 13
3.5.3. SHOW INFO ............................................ 14
3.5.4. SHOW SERVER .......................................... 14
3.6. The CLIENT Command ................................... 15
3.7. The STATUS Command ................................... 15
3.8. The HELP Command ..................................... 15
3.9. The QUIT Command ..................................... 16
3.10. The OPTION Command ................................... 16
3.10.1. OPTION MIME .......................................... 16
3.11. The AUTH Command ..................................... 18
3.12. The SASLAUTH Command ................................. 18
4. Command Pipelining ................................... 20
5. URL Specification .................................... 20
6. Extensions ........................................... 22
6.1. Experimental Command Syntax .......................... 22
6.2. Experimental Commands and Pipelining ................. 22
7. Summary of Response Codes ............................ 23
8. Sample Conversations ................................. 23
8.1. Sample 1 - HELP, DEFINE, and QUIT commands ........... 24
8.2. Sample 2 - SHOW commands, MATCH command .............. 25
8.3. Sample 3 - Server downtime ........................... 26
8.4. Sample 4 - Authentication ............................ 26
9. Security Considerations .............................. 26
10. References ........................................... 27
11. Acknowledgements ..................................... 29
12. Authors' Addresses ................................... 29
13. Full Copyright Statement ............................. 30
For many years, the Internet community has relied on the "webster" protocol for access to natural language definitions. The webster protocol supports access to a single dictionary and (optionally) to a single thesaurus. In recent years, the number of publicly available webster servers on the Internet has dramatically decreased.
長年にわたり、インターネットコミュニティには、自然言語の定義にアクセスするための「ウェブスター」プロトコルに依存してきました。ウェブスター・プロトコルは、単一のシソーラスに単一の辞書と（必要に応じて）へのアクセスをサポートします。近年では、インターネット上で公に利用可能なウェブスターサーバーの数は劇的に減少しています。
Fortunately, several freely-distributable dictionaries and lexicons have recently become available on the Internet. However, these freely-distributable databases are not accessible via a uniform interface, and are not accessible from a single site. They are often small and incomplete individually, but would collectively provide an interesting and useful database of English words. Examples include the Jargon file [JARGON], the WordNet database [WORDNET], MICRA's version of the 1913 Webster's Revised Unabridged Dictionary [WEB1913], and the Free Online Dictionary of Computing [FOLDOC]. Translating and non-English dictionaries are also becoming available (for example, the FOLDOC dictionary is being translated into Spanish).
幸いなことに、いくつかの自由に配布可能な辞書や辞書は最近、インターネット上で利用可能になりました。しかし、これらの自由に配布可能なデータベースは、統一されたインタフェースを介してアクセスされず、単一のサイトからアクセスすることはできません。彼らは、個別に、多くの場合、小型かつ不完全ですが、総称して英語の単語の興味深い、有用なデータベースを提供します。例としては、専門用語には、[専門用語を]ファイルWordNetのデータベース[WORDNET]、1913ウェブスターの改訂大辞典辞書[WEB1913]、およびコンピューティングの無料のオンライン辞書[FOLDOC]のMICRAのバージョンあります。翻訳と英語以外の辞書も利用可能になりつつある（例えば、FOLDOC辞書はスペイン語に翻訳されています）。
The webster protocol is not suitable for providing access to a large number of separate dictionary databases, and extensions to the current webster protocol were not felt to be a clean solution to the dictionary database problem.
ウェブスター・プロトコルは、別の辞書データベースの多数へのアクセスを提供するには適していない、と現在のウェブスター・プロトコルへの拡張は、辞書データベースの問題にクリーン溶液であることが感じられませんでした。
The DICT protocol is designed to provide access to multiple databases. Word definitions can be requested, the word index can be searched (using an easily extended set of algorithms), information about the server can be provided (e.g., which index search strategies are supported, or which databases are available), and information about a database can be provided (e.g., copyright, citation, or distribution information). Further, the DICT protocol has hooks that can be used to restrict access to some or all of the databases.
DICTプロトコルは、複数のデータベースへのアクセスを提供するように設計されています。単語の定義は、単語インデックスは（アルゴリズムの簡単拡張セットを使用して）検索することができ、要求することができ、サーバに関する情報を提供することができる（例えば、インデックス検索戦略はサポートされている、またはそのデータベースが利用可能である）について、情報データベースは、（例えば、著作権、引用、または分布情報）を提供することができます。さらに、DICTプロトコルは、データベースの一部またはすべてへのアクセスを制限するために使用することができますフックを持っています。
In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122] of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
この文書では、我々は資産言葉MUST、REQUIRED、SHOULD、推奨、MAY、この文書で指定された各特定の要件の重要性を定義するには、オプションを使用しての[RFC1122]のセクション1.3.2で説明した規則を採用します。
In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that his item is optional, and may be omitted without careful consideration.
簡単に説明する：「MUST」（または「REQUIRED」）は、アイテムが仕様の絶対的な要件であることを意味します。 「SHOULD」（または「推奨」）があり、この項目を無視する正当な理由が存在するかもしれないが、完全な意味合いがそうする前に理解すべきである意味します。そして「MAY」（または「オプション」）彼の項目がオプションであることを意味し、慎重に検討することなく、省略することができます。
The DICT protocol assumes a reliable data stream such as provided by TCP. When TCP is used, a DICT server listens on port 2628.
DICTプロトコルはTCPによって提供されるような信頼性の高いデータストリームを想定しています。 TCPを使用する場合は、DICTサーバは、ポート2628でリッスンします。
This server is only an interface between programs and the dictionary databases. It does not perform any user interaction or presentation-level functions.
このサーバは、プログラムと辞書データベース間の唯一のインタフェースです。これは、任意のユーザーとの対話やプレゼンテーションレベルの機能を実行しません。
Commands and replies are composed of characters from the UCS character set [ISO10646] using the UTF-8 [RFC2044] encoding. More specifically, using the grammar conventions from [RFC822]:
コマンド及び応答は、UTF-8 [RFC2044]エンコードを使用して、UCS文字セット[ISO10646]の文字から構成されています。より具体的には、[RFC822]から文法規則を使用して：
; ( Octal, Decimal.)
CHAR = <any UTF-8 character (1 to 6 octets)>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
<'> = <ASCII single quote mark> ; ( 47, 39.)
CRLF = CR LF
WS = 1*(SPACE / HTAB)
dqstring = <"> *(dqtext/quoted-pair) <">
dqtext = <any CHAR except <">, "\", and CTLs>
sqstring = <'> *(dqtext/quoted-pair) <'>
sqtext = <any CHAR except <'>, "\", and CTLs>
quoted-pair = "\" CHAR
atom = 1*<any CHAR except SPACE, CTLs, <'>, <">, and "\">
string = *<dqstring / sqstring / quoted-pair>
word = *<atom / string>
description = *<word / WS>
text = *<word / WS>
Commands consist of a command word followed by zero or more parameters. Commands with parameters must separate the parameters from each other and from the command by one or more space or tab characters. Command lines must be complete with all required parameters, and may not contain more than one command.
コマンドは、ゼロ以上のパラメータに続くコマンドワードから成ります。パラメータを持つコマンドは、一つ以上のスペースまたはタブ文字で互いから、コマンドからパラメータを区切る必要があります。コマンドラインは、すべての必要なパラメータを完備しなければならず、複数のコマンドを含めることはできません。
Each command line must be terminated by a CRLF.
各コマンドラインはCRLFで終了する必要があります。
The grammar for commands is:
コマンドの文法は次のとおりです。
command = cmd-word *<WS cmd-param>
cmd-word = atom
cmd-param = database / strategy / word
database = atom
strategy = atom
Commands are not case sensitive.
コマンドは大文字と小文字を区別しません。
Command lines MUST NOT exceed 1024 characters in length, counting all characters including spaces, separators, punctuation, and the trailing CRLF. There is no provision for the continuation of command lines. Since UTF-8 may encode a character using up to 6 octets, the command line buffer MUST be able to accept up to 6144 octets.
コマンドラインには、スペース、セパレータ、句読点、および末尾のCRLFを含むすべての文字を数え、長さが1024文字を超えてはなりません。コマンドラインの継続のための規定はありません。 UTF-8は、6つのオクテットまで使用して文字を符号化することができるので、コマンドラインバッファは6144オクテットまで受け入れることができなければなりません。
Responses are of two kinds, status and textual.
応答は2種類、状態とテキストです。
Status responses indicate the server's response to the last command received from the client.
ステータス応答がクライアントから受信した最後のコマンドに対するサーバの応答を示します。
Status response lines begin with a 3 digit numeric code which is sufficient to distinguish all responses. Some of these may herald the subsequent transmission of text.
ステータス応答ラインはすべての応答を区別するのに十分である3桁の数字コードで始まります。これらのいくつかは、テキストの次の送信を告げることがあります。
The first digit of the response broadly indicates the success, failure, or progress of the previous command (based generally on [RFC640,RFC821]):
応答の最初の桁は、広く成功、失敗、または（[RFC640、RFC821]に一般に基づいて）前のコマンドの進行を示します。
1yz - Positive Preliminary reply
2yz - Positive Completion reply
3yz - Positive Intermediate reply
4yz - Transient Negative Completion reply
5yz - Permanent Negative Completion reply
The next digit in the code indicates the response category:
コード内の次の桁は応答カテゴリを示します。
x0z - Syntax
x1z - Information (e.g., help)
x2z - Connections
x3z - Authentication
x4z - Unspecified as yet
x5z - DICT System (These replies indicate the status of the
receiver DICT system vis-a-vis the requested transfer
or other DICT system action.)
x8z - Nonstandard (private implementation) extensions
The exact response codes that should be expected from each command are detailed in the description of that command.
各コマンドから予想されるべき正確な応答コードは、そのコマンドの説明に詳述されています。
Certain status responses contain parameters such as numbers and strings. The number and type of such parameters is fixed for each response code to simplify interpretation of the response. Other status responses do not require specific text identifiers. Parameter requirements are detailed in the description of relevant commands. Except for specifically detailed parameters, the text following response codes is server-dependent.
特定のステータス応答は、このような数値や文字列などのパラメータが含まれています。各応答コードが応答の解釈を簡素化するため、このようなパラメータの数およびタイプは固定されています。他のステータス応答は、特定のテキスト識別子を必要としません。パラメータの要件は、関連するコマンドの説明に詳述されています。特に詳細なパラメータを除いて、応答コード以下のテキストは、サーバーに依存しています。
Parameters are separated from the numeric response code and from each other by a single space. All numeric parameters are decimal, and may have leading zeros. All string parameters MUST conform to the "atom" or "dqstring" grammar productions.
パラメータは、単一のスペースで数値応答コードからおよび互いから分離されています。すべての数値パラメータは小数であり、先行ゼロを有することができます。すべての文字列パラメータは、「アトム」や「dqstring」文法プロダクションに従わなければなりません。
If no parameters are present, and the server implementation provides no implementation-specific text, then there MAY or MAY NOT be a space after the response code.
。パラメータが存在しない、とサーバーの実装は何も実装固有のテキストを提供しない場合、または応答コードの後にスペースがあってもなくてもよいです。
Response codes not specified in this standard may be used for any installation-specific additional commands also not specified.
この規格に規定されていないレスポンスコードも指定されていないインストール固有の追加のコマンドのために使用することができます。
These should be chosen to fit the pattern of x8z specified above. The use of unspecified response codes for standard commands is prohibited.
これらは、上記で指定x8zのパターンに合わせて選択する必要があります。標準コマンドのため、不特定の応答コードの使用は禁止されています。
In response to every command, the following general status responses are possible:
すべてのコマンドに応答して、次の一般的な状態応答が可能です。
500 Syntax error, command not recognized
501 Syntax error, illegal parameters
502 Command not implemented
503 Command parameter not implemented
420 Server temporarily unavailable
421 Server shutting down at operator request
Before text is sent a numeric status response line, using a 1yz code, will be sent indicating text will follow. Text is sent as a series of successive lines of textual matter, each terminated with a CRLF. A single line containing only a period (decimal code 46, ".") is sent to indicate the end of the text (i.e., the server will send a CRLF at the end of the last line of text, a period, and another CRLF).
テキストは1yzコードを使用して、数値ステータス応答ラインを送信される前に、後に続くテキストを示す送信されます。テキストは、それぞれがCRLFで終了、テキストの問題の連続した一連のラインとして送信されます。唯一の期間含む単一の行（10進数46は、「」）テキストの終わりを示すために送信される（すなわち、サーバは、テキスト、期間の最後の行の末尾にCRLFを送信し、別のCRLFます）。
If a line of original text contained a period as the first character of the line, that first period is doubled by the DICT server. Therefore, the client must examine the first character of each line received. Those that begin with two periods must have those two periods collapsed into one period. Those that contain only a single period followed by a CRLF indicate the end of the text response.
元のテキストの行は、行の最初の文字としてピリオドが含まれている場合は、その最初の期間は、DICTサーバによって倍増されます。そのため、クライアントは、受信した各ラインの最初の文字を調べる必要があります。 2つのピリオドで始まるものは、これらの二つの期間は一の周期に崩壊している必要があります。 CRLFに続いて、単一のピリオドが含まれているものは、テキスト応答の終わりを示します。
If the OPTION MIME command has been given, all textual responses will be prefaced by a MIME header [RFC2045] followed by a single blank line (CRLF). See section 3.10.1 for more details on OPTION MIME.
OPTIONのMIMEコマンドが与えられた場合、すべてのテキスト応答は、単一の空白行（CRLF）、続いMIMEヘッダ[RFC2045]で始まるであろう。 OPTIONのMIMEの詳細については、セクション3.10.1を参照してください。
Following a text response, a 2yz response code will be sent.
テキスト応答の後、2yz応答コードが送信されます。
Text lines MUST NOT exceed 1024 characters in length, counting all characters including spaces, separators, punctuation, the extra initial period (if needed), and the trailing CRLF. Since UTF-8 may encode a character using up to 6 octets, the text line input buffer MUST be able to accept up to 6144 octets.
テキスト行は、スペース、セパレータ、句読点、（必要な場合）、余分な初期期間、および末尾のCRLFを含むすべての文字を数え、長さが1024文字を超えてはなりません。 UTF-8は、6つのオクテットまで使用して文字を符号化することができるので、テキストライン入力バッファは6144オクテットまで受け入れることができなければなりません。
By default, the text of the definitions MUST be composed of characters from the UCS character set [ISO10644] using the UTF-8 [RFC2044] encoding. The UTF-8 encoding has the advantage of preserving the full range of 7-bit US ASCII [USASCII] values. Clients and servers MUST support UTF-8, even if only in some minimal fashion.
デフォルトでは、定義のテキストはUTF-8 [RFC2044]エンコードを使用してUCSの文字セット[ISO10644]の文字から構成されなければなりません。 UTF-8エンコーディングは、7ビットUS ASCII [USASCII]値の全範囲を維持するという利点を有します。クライアントとサーバーだけでもいくつかの最低限のやり方であれば、UTF-8をサポートしなければなりません。
Below, each DICT command and appropriate responses are detailed. Each command is shown in upper case for clarity, but the DICT server is case-insensitive.
以下に、各DICTコマンドと適切な対応が詳述されています。各コマンドは、明確にするために大文字で示されているが、DICTサーバは大文字と小文字を区別しないです。
Except for the AUTH and SASLAUTH commands, every command described in this section MUST be implemented by all DICT servers.
AUTHとSASLAUTHコマンドを除いて、このセクションで説明するすべてのコマンドは、すべてのDICTサーバによって実装されなければなりません。
When a client initially connects to a DICT server, a code 220 is sent if the client's IP is allowed to connect:
クライアントが最初にDICTサーバに接続すると、クライアントのIPが接続を許可されている場合は、コード220が送信されます。
220 text capabilities msg-id
220のテキスト機能のMSG-ID
The code 220 is a banner, usually containing host name and DICT server version information.
コード220は、通常、ホスト名とDICTサーバのバージョン情報を含む、バナーです。
The second-to-last sequence of characters in the banner is the optional capabilities string, which will allow servers to declare support for extensions to the DICT protocol. The capabilities string is defined below:
バナーの文字の最後から2番目のシーケンスは、サーバーがDICTプロトコルの拡張機能のサポートを宣言することができますオプション機能文字列です。機能文字列を以下のように定義されています。
capabilities = ["<" msg-atom *("." msg-atom) ">"]
msg-atom = 1*<any CHAR except SPACE, CTLs,
"<", ">", ".", and "\">
Individual capabilities are described by a single msg-atom. For example, the string <html.gzip> might be used to describe a server that supports extensions which allow HTML or compressed output. Capability names beginning with "x" or "X" are reserved for experimental extensions, and SHOULD NOT be defined in any future DICT protocol specification. Some of these capabilities may inform the client that certain functionality is available or can be requested. The following capabilities are currently defined:
個々の機能は、単一のMSG-原子によって記述されています。例えば、文字列が<html.gzip> HTMLまたは圧縮された出力を許可する拡張機能をサポートするサーバーを記述するために使用される可能性があります。 「X」または「X」で始まる能力名は、実験的な拡張のために予約されており、将来のDICTプロトコル仕様で定義されるべきではありません。これらの機能のいくつかは、特定の機能が利用可能であるか、要求することができることをクライアントに通知することができます。次の機能は、現在定義されています。
mime The OPTION MIME command is supported
auth The AUTH command is supported
kerberos_v4 The SASL Kerberos version 4 mechanism is supported
gssapi The SASL GSSAPI [RFC2078] mechanism is supported
skey The SASL S/Key [RFC1760] mechanism is supported
external The SASL external mechanism is supported
The last sequence of characters in the banner is a msg-id, similar to the format specified in [RFC822]. The simplified description is given below:
バナー内の文字の最後のシーケンスは、[RFC822]で指定された形式に類似MSG-IDです。簡略な説明を以下に示します：
msg-id = "<" spec ">" ; Unique message id
spec = local-part "@" domain
local-part = msg-atom *("." msg-atom)
domain = msg-atom *("." msg-atom)
Note that, in contrast to [RFC822], spaces and quoted pairs are not allowed in the msg-id. This restriction makes the msg-id much easier for the client to locate and parse but does not significantly decrease any security benefits, since the msg-id may be arbitrarily long (as bounded by the response length limits set forth elsewhere in this document).
[RFC822]とは対照的に、なお、スペースおよび引用対はMSG-IDに許可されていません。この制限は、クライアントが見つけて解析するためにMSG-IDがはるかに容易になりますが、MSG-idは任意に長くなる可能性があるため大幅に（このドキュメントの他の場所で記載応答の長さ制限に囲まれたように）、任意のセキュリティ上の利点を減少させません。
Note also that the open and close brackets are part of the msg-id and should be included in the string that is used to compute the MD5 checksum.
開閉ブラケットはMSG-IDの一部であり、MD5チェックサムを計算するために使用される文字列に含まれるべきであることにも留意されたいです。
This message id will be used by the client when formulating the authentication string used in the AUTH command.
AUTHコマンドで使用される認証文字列を処方する場合、このメッセージIDは、クライアントによって使用されます。
If the client's IP is not allowed to connect, then a code 530 is sent instead:
クライアントのIPが接続を許可されていない場合は、コード530が代わりに送信されます。
530 Access denied
530回のアクセスが拒否されました
Transient failure responses are also possible:
一時的な障害の応答も可能です。
420 Server temporarily unavailable
421 Server shutting down at operator request
For example, response code 420 should be used if the server cannot currently fork a server process (or cannot currently obtain other resources required to proceed with a usable connection), but expects to be able to fork or obtain these resources in the near future.
例えば、応答コード420は、サーバが現在のサーバプロセスをフォークすることができない場合に使用されるべきである（または現在使用可能な接続を続行するために必要なその他のリソースを取得できない）が、近い将来にこれらのリソースをフォークまたは得ることができると予想しています。
Response code 421 should be used when the server has been shut down at operator request, or when conditions indicate that the ability to service more requests in the near future will be impossible. This may be used to allow a graceful operator-mediated temporary shutdown of a server, or to indicate that a well known server has been permanently removed from service (in which case, the text message might provide more information).
サーバはオペレータ要求でシャットダウンされたときのレスポンスコード421を使用する必要があり、または条件が近い将来に多くの要求を処理する能力が不可能になることを示しているとき。これは、サーバーの優雅なオペレータ媒介一時的なシャットダウンを可能にするために、または（その場合には、テキスト・メッセージは、より多くの情報を提供するかもしれない）がよく知られているサーバが恒久的にサービスから削除されたことを示すために使用することができます。
DEFINE database word
データベースの単語を定義します
This command will look up the specified word in the specified database. All DICT servers MUST implement this command.
このコマンドは、指定されたデータベースで、指定した単語を検索します。すべてのDICTサーバは、このコマンドを実行しなければなりません。
If the database name is specified with an exclamation point (decimal code 33, "!"), then all of the databases will be searched until a match is found, and all matches in that database will be displayed. If the database name is specified with a star (decimal code 42, "*"), then all of the matches in all available databases will be displayed. In both of these special cases, the databases will be searched in the same order as that printed by the "SHOW DB" command.
データベース名は感嘆符（10進数33、「！」）で指定されている場合は、データベースのすべてが一致するものが見つかるまで検索され、そのデータベース内のすべての一致が表示されます。データベース名は星（10進数42、「*」）で指定されている場合は、すべての利用可能なすべてのデータベースでの一致が表示されます。これらの特別な例の両方で、データベースが「SHOW DB」コマンドで印刷されたものと同じ順序で検索されます。
If the word was not found, then status code 552 is sent.
言葉が見つからなかった場合は、ステータスコード552が送信されます。
If the word was found, then status code 150 is sent, indicating that one or more definitions follow.
単語が見つかった場合には、ステータスコード150は、一つ以上の定義が続くことを示す、送信されます。
For each definition, status code 151 is sent, followed by the textual body of the definition. The first three space-delimited parameters following status code 151 give the word retrieved, the name of the database (which is the same as the first column of the SHOW DB command), and a short description for the database (which is the same as the second column of the SHOW DB command). The short name is suitable for printing as:
各定義は、ステータスコード151の定義のテキスト本体、続いて送信されます。ステータスコード151に続く最初の三つのスペース区切りのパラメータが同じである単語検索、（SHOW DBコマンドの最初の列と同じである）データベースの名前、およびデータベースの簡単な説明を（与えますSHOW DBコマンドの第2列）。短い名前は、などの印刷に適しています：
From name:
before the definition is printed. This provides source information for the user.
定義が印刷される前に。これは、ユーザーのためのソース情報を提供します。
The textual body of each definition is terminated with a CRLF period CRLF sequence.
各定義のテキスト本体はCRLF期間CRLFシーケンスで終了します。
After all of the definitions have been sent, status code 250 is sent. This command can provide optional timing information (which is server dependent and is not intended to be parsable by the client). This additional information is useful when debugging and tuning the server.
定義のすべてが送信された後、ステータスコード250が送信されます。このコマンドは、（依存するサーバであり、クライアントによって解析可能であることを意図していない）任意のタイミング情報を提供することができます。サーバーをデバッグし、チューニングするときに、この追加情報は有用です。
550 Invalid database, use "SHOW DB" for list of databases
552 No match
150 n definitions retrieved - definitions follow
151 word database name - text follows
250 ok (optional timing information here)
Response codes 150 and 151 require special parameters as part of their text. The client can use these parameters to display information on the user's terminal.
レスポンスコード150および151は、そのテキストの一部として特別なパラメータを必要としています。クライアントは、ユーザーの端末に情報を表示するには、これらのパラメータを使用することができます。
For code 150, parameters 1 indicates the number of definitions retrieved.
コード150のために、パラメータ1は、取得した定義の数を示します。
For code 151, parameter 1 is the word retrieved, parameter 2 is the database name (the first name as shown by "SHOW DB") from which the definition has been retrieved, and parameter 3 is the the short database description (the second column of the "SHOW DB" command).
コード151のために、パラメータ1は、ワード検索され、パラメータ2は、定義が検索されたデータベース名（「SHOW DB」によって示すように、第1名）であり、パラメータ3は、短いデータベース記述（第2カラムであります"SHOW DB" コマンドの）。
MATCH database strategy word
MATCHデータベース戦略ワード
This command searches an index for the dictionary, and reports words which were found using a particular strategy. Not all strategies are useful for all dictionaries, and some dictionaries may support additional search strategies (e.g., reverse lookup). All DICT servers MUST implement the MATCH command, and MUST support the "exact" and "prefix" strategies. These are easy to implement and are generally the most useful. Other strategies are server dependent.
このコマンドは、辞書のインデックスを検索し、特定の戦略を使用して発見された単語を報告します。いないすべての戦略はすべての辞書のために有用であり、いくつかの辞書には（例えば、逆引き参照）追加の検索戦略をサポートすることができます。すべてのDICTサーバは、MATCHコマンドを実行しなければなりませんし、「正確な」と「接頭辞」の戦略をサポートしなければなりません。これらは、実装が容易であり、一般に最も有用です。他の戦略は、サーバーに依存しています。
The "exact" strategy matches a word exactly, although different servers may treat non-alphanumeric data differently. We have found that a case-insensitive comparison which ignores non-alphanumeric characters and which folds whitespace is useful for English-language dictionaries. Other comparisons may be more appropriate for other languages or when using extended character sets.
異なるサーバーを異なる英数字以外のデータを扱うかもしれないが、「正確な」戦略は、まさに言葉と一致します。私たちは、英数字以外の文字を無視し、空白を折るれ、大文字と小文字を区別しない比較は英語の辞書に有用であることを発見しました。その他の比較は、拡張文字セットを使用して他の言語またはときのために、より適切かもしれません。
The "prefix" strategy is similar to "exact", except that it only compares the first part of the word.
「接頭辞」戦略は、それが唯一の単語の最初の部分を比較することを除いて、「正確」に似ています。
Different servers may implement these algorithms differently. The requirement is that strategies with the names "exact" and "prefix" exist so that a simple client can use them.
異なるサーバーは異なり、これらのアルゴリズムを実装することができます。要件は、単純なクライアントがそれらを使用できるように、「正確な」の名前と「接頭辞」との戦略が存在することです。
Other strategies that might be considered by a server implementor are matches based on substring, suffix, regular expressions, soundex [KNUTH73], and Levenshtein [PZ85] algorithms. These last two are especially useful for correcting spelling errors. Other useful strategies perform some sort of "reverse" lookup (i.e., by searching definitions to find the word that the query suggests).
サーバーの実装者によって考慮されるかもしれない他の戦略は、サブストリング、接尾辞、正規表現、同音[KNUTH73]、およびレーベンシュタイン[PZ85]アルゴリズムに基づいて一致しています。最後の2つは、スペルの誤りを訂正するために特に有用です。他の有用な戦略は（つまり、クエリが示唆という言葉を見つけるために、定義を検索して）「逆」引きのいくつかの並べ替えを行います。
If the database name is specified with an exclamation point (decimal code 33, "!"), then all of the databases will be searched until a match is found, and all matches in that database will be displayed. If the database name is specified with a star (decimal code 42, "*"), then all of the matches in all available databases will be displayed. In both of these special cases, the databases will be searched in the same order as that printed by the "SHOW DB" command.
データベース名は感嘆符（10進数33、「！」）で指定されている場合は、データベースのすべてが一致するものが見つかるまで検索され、そのデータベース内のすべての一致が表示されます。データベース名は星（10進数42、「*」）で指定されている場合は、すべての利用可能なすべてのデータベースでの一致が表示されます。これらの特別な例の両方で、データベースが「SHOW DB」コマンドで印刷されたものと同じ順序で検索されます。
If the strategy is specified using a period (decimal code 46, "."), then the word will be matched using a server-dependent default strategy, which should be the best strategy available for interactive spell checking. This is usually a derivative of the Levenshtein algorithm [PZ85].
戦略は（、10進46「」）期間を使用して指定されている場合は、その単語は、インタラクティブなスペルチェックのために利用可能な最善の戦略である必要があり、サーバーに依存するデフォルトの戦略を、使用して照合されます。これは通常、レーベンシュタインアルゴリズム[PZ85]の誘導体です。
If no matches are found in any of the searched databases, then status code 552 will be returned.
一致が検索データベースのいずれにも見つからない場合は、ステータスコード552が返されます。
Otherwise, status code 152 will be returned followed by a list of matched words, one per line, in the form:
そうでない場合は、ステータスコード152の形式で、マッチした単語のリストが続く1行に1つずつ返されます。
database word
データベース・ワード
This makes the responses directly useful in a DEFINE command.
これは、DEFINEコマンドで応答が直接役立ちます。
The textual body of the match list is terminated with a CRLF period CRLF sequence.
一致リストのテキスト本体はCRLF期間CRLFシーケンスで終了します。
Following the list, status code 250 is sent, which may include server-specific timing and statistical information, as discussed in the section on the DEFINE command.
リストは、ステータスコード250以下のDEFINEコマンドのセクションで説明したように、サーバ固有のタイミング及び統計情報を含むことができる、送信されます。
550 Invalid database, use "SHOW DB" for list of databases
551 Invalid strategy, use "SHOW STRAT" for a list of strategies
552 No match
152 n matches found - text follows
250 ok (optional timing information here)
Response code 152 requires a special parameter as part of its text. Parameter 1 must be the number of matches retrieved.
レスポンスコード152は、そのテキストの一部として特別なパラメータを必要とします。パラメータ1は、検索された一致の数でなければなりません。
The ability to search all of the provided databases using a single command is given using the special "*" and "!" databases.
単一のコマンドを使用して提供されるデータベースのすべてを検索する機能は、「！」特別な「*」を使用して与えられ、データベース。
However, sometimes, a client may want to search over some but not all of the databases that a particular server provides. One alternative is for the client to use the SHOW DB command to obtain a list of databases and descriptions, and then (perhaps with the help of a human), select a subset of these databases for an interactive search. Once this selection has been done once, the results can be saved, for example, in a client configuration file.
しかし、時には、クライアントがいくつかではなく、特定のサーバーが提供するすべてのデータベースを検索することもできます。一つの選択肢は、データベースと説明のリストを取得するには、SHOW DBコマンドを使用して、（おそらく人間の助けを借りて）、インタラクティブな検索のためにこれらのデータベースのサブセットを選択するためのクライアントのためです。この選択は一度行われていたら、結果はクライアントの設定ファイルに、例えば、保存することができます。
Another alternative is for the server to provide "virtual" databases which merge several of the regular databases into one. For example, a virtual database may be provided which includes all of the translating dictionaries, but which does not include regular dictionaries or thesauri. The special "*" and "!" databases can be considered as names of virtual databases which provide access to all of the databases. If a server implements virtual databases, then the special "*" and "!" databases should probably exclude other virtual databases (since they merely provide information duplicated in other databases). If virtual databases are supported, they should be listed as a regular database with the SHOW DB command (although, since "*" and "!" are required, they need not be listed).
別の方法としては、一つに、通常のデータベースのいくつかをマージする「仮想」データベースを提供するサーバーです。例えば、仮想データベースは、翻訳辞書の全てを含むが提供されてもよいが、規則的な辞書やシソーラスを含みません。特別な「*」と「！」データベースは、すべてのデータベースへのアクセスを提供する仮想データベースの名前とみなすことができます。サーバは仮想のデータベースを実装する場合、特別な「*」と「！」 （彼らは単に他のデータベースに重複した情報を提供するので）データベースは、おそらく他の仮想データベースを除外する必要があります。仮想データベースがサポートされている場合は、SHOW DBコマンドを使用して、定期的なデータベースとして表示されます（「*」および「！」が要求されるため、けれども、彼らが表示されない必要があります）。
Virtual databases are an implementation-specific detail which has absolutely no impact on the DICT protocol. The DICT protocol views virtual and non-virtual databases the same way.
仮想データベースは、DICTプロトコルに全く影響を与えない実装固有の詳細です。 DICTプロトコルは、仮想および非仮想データベースを同じように見ています。
We mention virtual databases here, however, because they solve a problem of database selection which could also have been solved by changes in the protocol. For example, each dictionary could be assigned attributes, and the protocol could be extended to specify searches over databases with certain attributes. However, this needlessly complicates the parsing and analysis that must be performed by the implementation. Further, unless the classification system is extremely general, there is a risk that it would restrict the types of databases that can be used with the DICT protocol (although the protocol has been designed with human-language databases in mind, it is applicable to any read-only database application, especially those with a single semi-unique alphanumeric key and textual data).
彼らはまた、プロトコルの変更によって解決されている可能性がデータベース選択の問題を解決するため、我々は、しかし、ここでは仮想のデータベースに言及します。例えば、各辞書は、属性を割り当てることができ、プロトコルは、特定の属性を持つデータベース上の検索を指定するために拡張することができます。しかし、これは不実装によって行われなければならない構文解析と分析を複雑にします。分類システムは、プロトコルは心の中で人間の言語のデータベースを使用して設計されているが、それは（DICTプロトコルで使用できるデータベースの種類を制限することをおそれがあり、非常に一般的でない限り、また、それはいずれにも適用されます読み取り専用データベースアプリケーション、単一半固有の英数字キーとテキストデータと特に）。
SHOW DBSHOW DATABASES
Displays the list of currently accessible databases, one per line, in the form:
形で、現在アクセス可能なデータベース、1行につき1つのリストを表示します。
database description
データベースの説明
The textual body of the database list is terminated with a CRLF period CRLF sequence. All DICT servers MUST implement this command.
データベースリストのテキスト本体はCRLF期間CRLFシーケンスで終了します。すべてのDICTサーバは、このコマンドを実行しなければなりません。
Note that some databases may be restricted due to client domain or lack of user authentication (see the AUTH and SASLAUTH commands in sections 3.11 and 3.12). Information about these databases is not available until authentication is performed. Until that time, the client will interact with the server as if the additional databases did not exist.
一部のデータベースは（AUTHとSASLAUTHは、セクション3.11と3.12にコマンドを参照）により、クライアントのドメインやユーザー認証の欠如に制限することができることに注意してください。認証が実行されるまで、これらのデータベースについての情報が利用可能ではありません。追加のデータベースが存在していなかったかのようにその時までは、クライアントがサーバーと対話します。
110 n databases present - text follows
554 No databases present
Response code 110 requires a special parameter. Parameter 1 must be the number of databases available to the user.
レスポンスコード110は、特別なパラメータが必要です。パラメータ1は、ユーザが利用可能なデータベースの数でなければなりません。
SHOW STRATSHOW STRATEGIES
Displays the list of currently supported search strategies, one per line, in the form:
形で、現在サポートされている検索方法、1行につき1つのリストを表示します。
strategy description
戦略の説明
The textual body of the strategy list is terminated with a CRLF period CRLF sequence. All DICT servers MUST implement this command.
戦略リストのテキスト本体はCRLF期間CRLFシーケンスで終了します。すべてのDICTサーバは、このコマンドを実行しなければなりません。
111 n strategies available - text follows
555 No strategies available
Response code 111 requires a special parameter. Parameter 1 must be the number of strategies available.
レスポンスコード111は、特別なパラメータが必要です。パラメータ1は、利用可能な多くの戦略でなければなりません。
SHOW INFO database
Displays the source, copyright, and licensing information about the specified database. The information is free-form text and is suitable for display to the user in the same manner as a definition. The textual body of the information is terminated with a CRLF period CRLF sequence. All DICT servers MUST implement this command.
指定されたデータベースに関するソース、著作権、およびライセンス情報を表示します。情報は、自由形式のテキストであると定義と同様に、ユーザへの表示に適しています。情報のテキスト本体はCRLF期間CRLFシーケンスで終了します。すべてのDICTサーバは、このコマンドを実行しなければなりません。
550 Invalid database, use "SHOW DB" for list of databases
112 database information follows
These response codes require no special parameters.
これらの応答コードは、特別なパラメータを必要としません。
SHOW SERVER
Displays local server information written by the local administrator. This could include information about local databases or strategies, or administrative information such as who to contact for access to databases requiring authentication. All DICT servers MUST implement this command.
ローカル管理者によって書かれたローカルサーバ情報を表示します。これは、このような認証を必要とするデータベースへのアクセスのために連絡する人など、ローカルデータベースや戦略、または管理情報についての情報を含めることができます。すべてのDICTサーバは、このコマンドを実行しなければなりません。
114 server information follows
This response code requires no special parameters.
この応答コードは、特別なパラメータを必要としません。
CLIENT text
This command allows the client to provide information about itself for possible logging and statistical purposes. All clients SHOULD send this command after connecting to the server. All DICT servers MUST implement this command (note, though, that the server doesn't have to do anything with the information provided by the client).
このコマンドは、クライアントが可能ロギングと統計目的のために自分自身についての情報を提供することができます。すべてのクライアントがサーバーに接続した後、このコマンドを送るべきです。すべてのDICTサーバは、（サーバがクライアントによって提供された情報で何もする必要はありませんので、しかし、注意してください）このコマンドを実行しなければなりません。
250 ok (optional timing information here)
250 OK（ここでは任意のタイミング情報）
This response code requires no special parameters.
この応答コードは、特別なパラメータを必要としません。
STATUS
Display some server-specific timing or debugging information. This information may be useful in debugging or tuning a DICT server. All DICT servers MUST implement this command (note, though, that the text part of the response is not specified and may be omitted).
いくつかのサーバ固有のタイミングやデバッグ情報を表示します。この情報は、デバッグに有用であることやDICTサーバをチューニングすることがあります。すべてのDICTサーバは、（応答のテキスト部分が指定されていないと、省略することができること、しかし、注意してください）このコマンドを実行しなければなりません。
210 (optional timing and statistical information here)
210（ここで任意のタイミング及び統計情報）
This response code requires no special parameters.
この応答コードは、特別なパラメータを必要としません。
HELP
Provides a short summary of commands that are understood by this implementation of the DICT server. The help text will be presented as a textual response, terminated by a single period on a line by itself. All DICT servers MUST implement this command.
DICTサーバのこの実装によって理解されているコマンドの簡単な要約を表示します。ヘルプテキストは、単独行上の単一のピリオドで終わるテキスト応答として提供されます。すべてのDICTサーバは、このコマンドを実行しなければなりません。
113 help text follows
113ヘルプテキストは、以下の
This response code requires no special parameters.
この応答コードは、特別なパラメータを必要としません。
QUIT
This command is used by the client to cleanly exit the server. All DICT servers MUST implement this command.
このコマンドはきれいにサーバーを終了するには、クライアントによって使用されます。すべてのDICTサーバは、このコマンドを実行しなければなりません。
221 Closing Connection
221閉会の接続
This response code requires no special parameters.
この応答コードは、特別なパラメータを必要としません。
OPTION MIME
Requests that all text responses be prefaced by a MIME header [RFC2045] followed by a single blank line (CRLF).
すべてのテキスト応答がMIMEヘッダ[RFC2045]によって前置きされる要求は、1つの空白行（CRLF）が続きます。
If a client requests this option, then the client MUST be able to parse Content-Type and Content-transfer-encoding headers, and MUST be able to ignore textual responses which have an unsupported content or encoding. A client MUST support the UTF-8 encoding [RFC2044], which minimally means that the client MUST recognize UTF-8 multi-octet encodings and convert these into some symbol that can be printed by the client.
クライアントの要求このオプション場合、クライアントは、Content-TypeとContent-転送エンコードヘッダーを解析できなければならないし、サポートされていないコンテンツやエンコーディングを持つテキストの応答を無視することができなければなりません。クライアントは、最小限、クライアントがUTF-8のマルチオクテットエンコーディングを認識し、クライアントから印刷することができるいくつかのシンボルにこれらを変換しなければならないことを意味するUTF-8エンコーディング[RFC2044]をサポートしなければなりません。
If a client requests this option, then the server will provide a MIME header. If the header is empty, the text response will start with a single blank line (CRLF), in which case a client MUST interpret this as a default header. The default header for SASL authentication is:
クライアントがこのオプションを要求した場合、サーバはMIMEヘッダーを提供します。ヘッダが空の場合は、テキスト応答は、クライアントがデフォルトのヘッダーとしてこれを解釈しなければならない場合には、1つの空白行（CRLF）で始まります。 SASL認証のためのデフォルトのヘッダーは次のとおりです。
Content-type: application/octet-stream
Content-transfer-encoding: base64
The default header for all other textual responses is:
他のすべてのテキスト応答のための標準ヘッダーは次のとおりです。
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
If OPTION MIME is not specified by the client, then the server may restrict the information content provided to the client. For example, a definition may be accompanied by an image and an audio clip, but the server cannot transmit this information unless the client is able to parse MIME format headers.
OPTIONのMIMEがクライアントによって指定されていない場合、サーバはクライアントに提供される情報の内容を制限することができます。例えば、定義は、画像や音声クリップを添付することができるが、クライアントがMIMEフォーマットヘッダを解析することができない限り、サーバは、この情報を送信することができません。
Note that, because of the line length restrictions and end-of-response semantics, the "binary" content-transfer-encoding MUST NOT be used. In the future, extensions to the protocol may be provided which allow a client to request binary encodings, but the default SHOULD always be that the client can look for a "CRLF . CRLF" sequence to locate the end of the current text response. This allows clients to easily skip over text responses which have unsupported types or encodings.
なぜなら行の長さ制限と終了の応答セマンティクスの、なお、「バイナリ」コンテンツ転送エンコードを使用してはいけません。将来的には、プロトコルの拡張は、クライアントがバイナリエンコードを要求することを可能にするが提供することができるが、デフォルトでは常に、クライアントが現在のテキスト応答の終わりを検索する「CRLF。CRLF」シーケンスを探すことができることであるべきです。これは、クライアントが簡単にサポートされていないタイプやエンコーディングを持つテキスト応答をスキップすることができます。
In the future, after significant experience with large databases in various languages has been gained, and after evaluating the need for specifying character sets and other encodings (e.g., compressed or BASE64 encoding), standard extensions to this protocol should be proposed which allow the client to request certain content types or encodings. Care should be taken that these extensions do not require a handshake which defeats pipelining. In the mean time, private extensions should be used to explore the parameter space to determine how best to implement these extensions.
将来的には、さまざまな言語で大規模なデータベースでの豊富な経験の後に得られていると、クライアント可能にするこのプロトコルに文字セットと他のエンコーディング（例えば、圧縮またはBASE64エンコード）、標準の拡張子を指定するための必要性を評価した後に提案する必要があります特定のコンテンツタイプやエンコーディングを要求します。ケアは、これらの拡張機能は、パイプラインを破るハンドシェイクを必要としないように注意しなければなりません。平均時間では、民間の拡張機能は、これらの拡張機能を実装する最善の方法を決定するパラメータ空間を探索するために使用されるべきです。
OPTION MIME is a REQUIRED server capability, all DICT servers MUST implement this command.
OPTION MIMEは、必要なサーバー機能は、すべてのDICTサーバは、このコマンドを実装しなければならないです。
250 ok (optional timing information here)
250 OK（ここでは任意のタイミング情報）
Note that some older server implementations, completed before this document was finalized, will return a status code 500 if this command is not implemented. Clients SHOULD be able to accept this behavior, making default assumptions. Clients may also examine the capabilities string in the status code 220 header to determine if a server supports this capability.
このコマンドは実装されていない場合は、この文書が確定される前に完了し、一部の古いサーバの実装は、ステータスコード500を返すことに注意してください。クライアントは、デフォルトの仮定を作り、この動作を受け入れることができべきです。また、クライアントは、サーバがこの機能をサポートしているかどうかを判断するために、ステータスコード220のヘッダ内の機能文字列を調べることができます。
AUTH username authentication-string
AUTHのユーザ名認証文字列
The client can authenticate itself to the server using a username and password. The authentication-string will be computed as in the APOP protocol discussed in [RFC1939]. Briefly, the authentication-string is the MD5 checksum of the concatenation of the msg-id (obtained from the initial banner) and the "shared secret" that is stored in the server and client configuration files. Since the user does not have to type this shared secret when accessing the server, the shared secret can be an arbitrarily long passphrase. Because of the computational ease of computing the MD5 checksum, the shared secret should be significantly longer than a usual password.
クライアントは、ユーザー名とパスワードを使用してサーバに自身を認証することができます。認証文字列は、[RFC1939]で議論APOPプロトコルのように計算されます。簡単に言えば、認証文字列は、サーバーとクライアントの設定ファイルに保存されている（初期のバナーから入手した）MSG-IDと「共有秘密」の連結のMD5チェックサムです。ユーザーがサーバーにアクセスするとき、この共有シークレットを入力する必要はありませんので、共有秘密は、任意の長パスフレーズすることができます。なぜならMD5チェックサムを計算する計算容易であることから、共有秘密は、通常のパスワードよりも大幅に長くする必要があります。
Authentication may make more dictionary databases available for the current session. For example, there may be some publicly distributable databases available to all users, and other private databases available only to authenticated users. Or, a server may require authentication from all users to minimize resource utilization on the server machine.
認証は、現在のセッションのためのより多くの辞書データベースが利用可能にすることができます。例えば、認証されたユーザーのみが利用可能ないくつかのすべてのユーザーが利用できる公に配布データベース、およびその他のプライベートデータベースがあるかもしれません。または、サーバーは、サーバー・マシン上のリソース使用率を最小限に抑えるために、すべてのユーザからの認証が必要な場合があります。
Authentication is an optional server capability. The AUTH command MAY be implemented by a DICT server.
認証は、オプションのサーバ機能です。 AUTHコマンドは、DICTサーバによって実現することができます。
230 Authentication successful
531 Access denied, use "SHOW INFO" for server information
These response codes require no special parameters.
これらの応答コードは、特別なパラメータを必要としません。
SASLAUTH mechanism initial-response SASLRESP response
SASLAUTHメカニズム初期応答SASLRESP応答
The Simple Authentication and Security Layer (SASL) is currently being developed [RFC2222]. The DICT protocol reserves the SASLAUTH and SASLRESP commands for this method of authentication. The results of successful authentication with SALSAUTH will be the same as the results of successful AUTH authentication: more dictionary databases may become available for the current session.
簡易認証セキュリティー層（SASL）は、現在、[RFC2222]を開発されています。 DICTプロトコルはSASLAUTHとSASLRESPは、この認証方法のためにコマンドを留保します。 SALSAUTHで成功した認証の結果が成功したAUTH認証の結果と同じになります。より多くの辞書データベースは、現在のセッションのために利用可能になることがあります。
The initial-response is an optional parameter for the SASLAUTH command, encoded using BASE64 encoding [RFC2045]. Some SASL mechanisms may allow the use of this parameter. If SASL authentication is supported by a DICT server, then this parameter MUST also be supported.
初期の応答は、base64エンコーディング[RFC2045]を使用してエンコードSASLAUTHコマンドのためのオプションのパラメータです。いくつかのSASLメカニズムは、このパラメータの使用を可能にすることができます。 SASL認証がDICTサーバによってサポートされている場合、このパラメータもサポートしなければなりません。
A typical SASL authentication will be initiated by the client using the SASLAUTH command. The server will reply with status code 130, followed by a challenge. The challenge will be followed by status code 330, indicating that the client must now send a response to the server.
典型的なSASL認証がSASLAUTHコマンドを使用して、クライアントによって開始されます。サーバーは、チャレンジに続いて、ステータスコード130、と返信します。課題は、クライアントが現在サーバーに応答を送信しなければならないことを示す、ステータスコード330が続きます。
Depending on the details of the SASL mechanism currently in use, the server will either continue the exchange using status code 130, a challenge, and status code 330; or the server will use status code 230 or 531 to indicate authentication was successful or has failed.
現在使用されているSASLメカニズムの詳細に応じて、サーバはステータスコード130、挑戦、およびステータスコード330を使用して交流を継続しますか。またはサーバは、認証が成功したか失敗したことを示すために、ステータスコード230または531を使用します。
The challenges sent by the server are defined by the mechanisms as binary tokens of arbitrary length, and should be sent using a standard DICT textual response, as described in section 2.4.3. If OPTION MIME is not set, then BASE64 encoding MUST be used. If
サーバによって送信された課題は、任意の長さのバイナリトークンなどの機構によって定義され、セクション2.4.3に記載したように、標準的なDICTのテキスト応答を使用して送信されるべきです。 OPTIONのMIMEが設定されていない場合は、BASE64エンコーディングを使用しなければなりません。もし
OPTION MIME is set, then BASE64 is the default encoding, as specified in section 3.10.1.
OPTIONのMIMEが設定され、その後、BASE64はセクション3.10.1に指定され、デフォルトのエンコーディングです。
The client will send all responses using the SASLRESP command and a BASE64-encoded parameter. The responses sent by the client are defined by the mechanisms as binary tokens of arbitrary length. Remember that DICT command lines may only be 1024 characters in length, so the response provided by a DICT client is limited.
クライアントはSASLRESPコマンドとBASE64でエンコードされたパラメータを使用して、すべての応答を送信します。クライアントによって送信された応答は、任意の長さのバイナリトークンとしてメカニズムによって定義されます。 DICTクライアントによって提供される応答が限られているので、DICTコマンドラインのみ、長さは1024の文字であってもよいことに注意してください。
If the mechanism specified in the SASLAUTH command is not supported, then status code 532 will be returned.
SASLAUTHコマンドで指定されたメカニズムがサポートされていない場合は、ステータスコード532が返されます。
Authentication is an optional server capability. The SASLAUTH command MAY be implemented by a DICT server.
認証は、オプションのサーバ機能です。 SASLAUTHコマンドは、DICTサーバによって実現することができます。
130 challenge follows
330 send response
230 Authentication successful
531 Access denied, use "SHOW INFO" for server information
532 Access denied, unknown mechanism
These response codes require no special parameters.
これらの応答コードは、特別なパラメータを必要としません。
All DICT servers MUST be able to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improved DICT performance significantly, especially in the face of high latency network links.
すべてのDICTサーバは、単一のTCP送信操作で複数のコマンドを受け入れることができなければなりません。複数のコマンドのための単一のTCP送信操作を使用して、特に高遅延ネットワークリンクに直面して、大幅にDICTのパフォーマンスを改善することができます。
The possible implementation problems for a DICT server which would prevent command pipelining are similar to the problems that prevent pipelining in an SMTP server. These problems are discussed in detail in [RFC1854], which should be consulted by all DICT server implementors.
コマンドパイプラインを妨げるDICTサーバのための可能な実装上の問題は、SMTPサーバにパイプライン化を防ぐの問題に似ています。これらの問題は、すべてのDICTサーバの実装によって相談すべきである[RFC1854]に詳細に記載されています。
The main implication is that a DICT server implementation MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
主な含意はDICTサーバの実装はフラッシュまたはその他のいかなる状況下でTCP入力バッファの内容を失ってはならないということです。
A DICT client may pipeline several commands and must check the responses to each command individually. If the server has shut down, it is possible that all of the commands will not be processed. For example, a simple DICT client may pipeline a CLIENT, DEFINE, and QUIT command sequence as it is connecting to the server. If the server is shut down, the initial response code sent by the server may be 420 (temporarily unavailable) instead of 220 (banner). In this case, the definition cannot be retrieved, and the client should report and error or retry the command. If the server is working, it may be able to send back the banner, definition, and termination message in a single TCP send operation.
DICTクライアントパイプラインのいくつかのコマンドがあり、個別に各コマンドに対する応答を確認する必要があります。サーバーがシャットダウンしている場合、すべてのコマンドが処理されない可能性があります。例えば、簡単なDICTクライアントは、パイプラインCLIENTを定義し、それがサーバーに接続しているように、コマンドシーケンスを終了することがあります。サーバがシャットダウンされている場合は、サーバによって送信された初期応答コードが代わりに220の420（一時的に利用できない）（バナー）であってもよいです。この場合、定義が取得できない、とクライアントが報告し、エラーまたはコマンドを再試行する必要があります。サーバが動作している場合、単一のTCP送信操作にバナー、定義、および終了メッセージを送り返すことができるかもしれません。
The DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:
DICT URLスキームは、定義やDICTプロトコルを使用して、使用可能な単語リストを参照するために使用されます。
dict://<user>;<auth>@<host>:<port>/d:<word>:<database>:<n>
dict://<user>;<auth>@<host>:<port>/m:<word>:<database>:<strat>:<n>
The "/d" syntax specifies the DEFINE command (section 3.2), whereas the "/m" specifies the MATCH command (section 3.3).
"/ m" はMATCHコマンド（セクション3.3）を指定し、一方、 "/ D" 構文は、DEFINEコマンド（セクション3.2）を指定します。
Some or all of "<user>;<auth>@", ":<port>", "<database>", "<strat>", and "<n>" may be omitted.
一部またはすべての "<ユーザー>; <AUTH> @"、 "：<ポート>"、 "<データベース>"、 "<ストラト>" および "<N>" を省略してもよいです。
"<n>" will usually be omitted, but when included, it specifies the nth definition or match of a word. A method for extracting exactly this information from the server is not available using the DICT protocol. However, a client using the URL specification could obtain all of the definitions or matches, and then select the one that is specified.
「<n>は」通常省略されますが、含まれている場合、それは言葉のn番目の定義やマッチを指定します。正確サーバからこの情報を抽出する方法は、DICTプロトコルを使用して利用できません。ただし、URLの仕様を使用して、クライアントは定義や試合の全てを取得し、指定されたものを選択することができます。
If "<user>;<auth>@" is omitted, no authentication is done. If ":<port>" is omitted, the default port (2628) SHOULD be used. If "<database>" is omitted, "!" SHOULD be used (see section 3.2). If "<strat>" is omitted, "." SHOULD be used (see section 3.3).
場合は、「<ユーザー>、<認証>を@」は省略され、認証は行われません。場合は、「：<ポート>」が省略され、デフォルトポート（2628）が使用されるべきです。場合は、「<データベース>」、省略されています「！」 （セクション3.2を参照）が使用されるべきです。 「<ストラト>」は省略され、「」の場合使用されるべきである（3.3節を参照）。
"<user>;<auth>@" specifies the username and the type of authentication performed. For "<auth>", the string "AUTH" indicates that APOP authentication using the AUTH command will be performed, whereas the string "SASLAUTH=<auth_type>" indicates that the SASLAUTH and SASLRESP commands will be used, with "<auth_type>" indicating the type of SASL authentication which will be used. If "<auth_type>" is a star (decimal code 42, "*"), then the client will select some type of authentication.
「<ユーザー>、<認証> @」のユーザー名と行われる認証のタイプを指定します。 「<AUTH>」のために、文字列「AUTHは、」string「はSASLAUTH = <AUTH_TYPE>」SASLAUTHとSASLRESPコマンドことを示しているが、<AUTH_TYPE>」で、使用されるのに対し、AUTHコマンドを使用して、APOP認証が実行されることを示し「使用されるSASL認証の種類を示します。 「<AUTH_TYPE>」（10進数42、「*」）スターの場合、クライアントは、認証のいくつかのタイプを選択します。
Whenever authentication is required, the client SHOULD request additional information (e.g., a passphrase) from the user. In contrast to [RFC1738], clear text passwords are not permitted in the URL.
認証が必要なときはいつでも、クライアントは、ユーザから追加の情報（例えば、パスフレーズ）を要求すべきです。 [RFC1738]とは対照的に、クリアテキストのパスワードは、URLで許可されていません。
Trailing colons may be omitted. For example, the following URLs might specify definitions or matches:
後続のコロンを省略することができます。たとえば、次のURLを定義またはマッチを指定できます：
dict://dict.org/d:shortcake:
dict://dict.org/d:shortcake:*
dict://dict.org/d:shortcake:wordnet:
dict://dict.org/d:shortcake:wordnet:1
dict://dict.org/d:abcdefgh
dict://dict.org/d:sun
dict://dict.org/d:sun::1
dict://dict.org/m:sundict://dict.org/m:sun::soundexdict://dict.org/m:sun:wordnet::1dict://dict.org/m:sun::soundex:1dict://dict.org/m:sun:::
This protocol was designed so that flat text databases can be used with a server after a minimum of analysis and formatting. Our experience is that merely constructing an index for a database may be sufficient to make it useful with a DICT server. The ability to serve preformatted text is especially important since freely-available databases are often distributed as flat text files without any semantic mark-up information (and often contain "ASCII art" which precludes the automation of even simple formatting).
フラットなテキストデータベースを分析し、フォーマットの最小後、サーバーで使用できるように、このプロトコルを設計しました。私たちの経験は、単にデータベースのインデックスを構築することはDICTサーバと、それは有用なものにするのに十分であり得るということです。自由に利用可能なデータベースは、多くの場合、任意のセマンティックマークアップ情報なしでフラットなテキストファイルとして配布（そして多くの場合でも、簡単な書式設定の自動化を妨げる「ASCIIアート」を含む）されているので、整形済みテキストを処理する機能は特に重要です。
However, given a database with sufficient mark-up information, it may be possible to generate output in a variety of different formats (e.g., simple HTML or more sophisticated SGML). The specification of formatting is beyond the scope of this document. The requirements for negotiation of format (including character set and other encodings) is complex and should be examined over time as more experience is gained. We suggest that the use of different formats, as well as other server features, be explored as extensions to the protocol.
しかし、十分なマークアップ情報を持つデータベースが与えられると、異なるフォーマット（例えば、単純なHTMLまたはより洗練されたSGML）のさまざまな出力を生成することが可能であってもよいです。フォーマットの仕様は、このドキュメントの範囲を超えています。 （文字セットと他のエンコーディングを含む）形式の交渉のための要件は複雑であり、より多くの経験が得られるよう時間をかけて検討する必要があります。私たちは、異なるフォーマットを使用するだけでなく、他のサーバ機能は、プロトコルの拡張として検討されることを示唆しています。
Single-letter commands are reserved for debugging and testing, SHOULD NOT be defined in any future DICT protocol specification, and MUST NOT be used by any client software.
単一文字のコマンドは、デバッグおよびテスト用に予約されている任意の将来DICTプロトコル仕様で定義されるべきではない、と任意のクライアントソフトウェアで使用してはいけません。
Commands beginning with the letter "X" are reserved for experimental extensions, and SHOULD NOT be defined in any future DICT protocol specification. Authors of client software should understand that these commands are not part of the DICT protocol and may not be available on all DICT servers.
文字「X」で始まるコマンドは、実験的な拡張のために予約されており、将来のDICTプロトコル仕様で定義されるべきではありません。クライアントソフトウェアの作成者は、これらのコマンドは、DICTプロトコルの一部ではなく、すべてのDICTサーバで利用できない可能性があることを理解すべきです。
Experimental commands should be designed so that a client can pipeline the experimental commands without knowing if a server supports the commands (e.g., instead of using feature negotiation). If the server does not support the commands, then a response code in the 5yz series (usually 500) will be given, notifying the client that the extension is not supported. Of course, depending on the complexity of the extensions added, feature negotiation may be necessary. To help minimize negotiation time, server-supported features may be announced in the banner (code 220) using the optional capabilities parameter.
実験のコマンドを設計する必要があり、クライアントはパイプラインを知らずに実験的なコマンドをサーバが（例えば、代わりに機能ネゴシエーションを使用しての）コマンドをサポートしている場合にできるように。サーバーがコマンドをサポートしていない場合は、5yzシリーズ（通常は500）での応答コードは、拡張子がサポートされていないことをクライアントに通知し、与えられます。もちろん、追加の拡張機能の複雑さに応じて、機能の交渉が必要になることがあります。交渉時間を最小限に抑えるために、サーバーがサポートする機能は、オプション機能パラメータを使用してバナー（コード220）に発表することができます。
Below is a summary of response codes. A star (*) in the first column indicates the response has defined arguments that must be provided.
以下は、応答コードの要約です。最初の列にアスタリスク（*）は、応答が提供されなければならない引数を定義したことを示します。
* 110 n databases present - text follows
* 111 n strategies available - text follows
112 database information follows
113 help text follows
114 server information follows
130 challenge follows
* 150 n definitions retrieved - definitions follow
* 151 word database name - text follows
* 152 n matches found - text follows
210 (optional timing and statistical information here)
* 220 text msg-id
221 Closing Connection
230 Authentication successful
250 ok (optional timing information here)
330 send response
420 Server temporarily unavailable
421 Server shutting down at operator request
500 Syntax error, command not recognized
501 Syntax error, illegal parameters
502 Command not implemented
503 Command parameter not implemented
530 Access denied
531 Access denied, use "SHOW INFO" for server information
532 Access denied, unknown mechanism
550 Invalid database, use "SHOW DB" for list of databases
551 Invalid strategy, use "SHOW STRAT" for a list of strategies
552 No match
554 No databases present
555 No strategies available
Theses are samples of the conversations that might be expected with a typical DICT server. The notation "C:" indicates commands set by the client, and "S:" indicates responses sent by the server. Blank lines are included for clarity and do not indicate actual newlines in the transaction.
論文は、典型的なDICTサーバと予想されるかもしれない会話のサンプルです。表記「C：」は、クライアントによって設定されたコマンドを示し、「S：」サーバーから送信された応答を示します。空白行は、明確にするために含まれており、取引の実際の改行を示すものではありません。
C: [ client initiates connection ]
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
C: HELP
S: 113 Help text follows
S: DEFINE database word look up word in database
S: MATCH database strategy word match word in database using strategy
S: [ more server-dependent help text ]
S: .
S: 250 Command complete
C: DEFINE ! penguin
S: 150 1 definitions found: list follows
S: 151 "penguin" wn "WordNet 1.5" : definition text follows
S: penguin
S: 1. n: short-legged flightless birds of cold southern esp. Antarctic
S: regions having webbed feet and wings modified as flippers
S: .
S: 250 Command complete
C: DEFINE * shortcake
S: 150 2 definitions found: list follows
S: 151 "shortcake" wn "WordNet 1.5" : text follows
S: shortcake
S: 1. n: very short biscuit spread with sweetened fruit and usu.
S: whipped cream
S: .
S: 151 "Shortcake" web1913 "Webster's Dictionary (1913)" : text follows
S: Shortcake
S: \Short"cake`\, n.
S: An unsweetened breakfast cake shortened with butter or lard,
S: rolled thin, and baked.
S: .
S: 250 Command complete
C: DEFINE abcdefgh
S: 552 No match
C: quit
S: 221 Closing connection
C: SHOW DB
S: 110 3 databases present: list follows
S: wn "WordNet 1.5"
S: foldoc "Free On-Line Dictionary of Computing"
S: jargon "Hacker Jargon File"
S: .
S: 250 Command complete
C: SHOW STRAT
S: 111 5 strategies present: list follows
S: exact "Match words exactly"
S: prefix "Match word prefixes"
S: substring "Match substrings anywhere in word"
S: regex "Match using regular expressions"
S: reverse "Match words given definition keywords"
S: .
S: 250 Command complete
C: MATCH foldoc regex "s.si"
S: 152 7 matches found: list follows
S: foldoc Fast SCSI
S: foldoc SCSI
S: foldoc SCSI-1
S: foldoc SCSI-2
S: foldoc SCSI-3
S: foldoc Ultra-SCSI
S: foldoc Wide SCSI
S: .
S: 250 Command complete
C: MATCH wn substring "abcdefgh"
S: 552 No match
C: [ client initiates connection ]
S: 420 Server temporarily unavailable
C: [ client initiates connection ]
S: 421 Server shutting down at operator request
C: [ client initiates connection ]
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
C: SHOW DB
S: 110 1 database present: list follows
S: free "Free database"
S: .
S: 250 Command complete
C: AUTH joesmith authentication-string
S: 230 Authentication successful
C: SHOW DB
S: 110 2 databases present: list follows
S: free "Free database"
S: licensed "Local licensed database"
S: .
S: 250 Command complete
This RFC raises no security issues.
このRFCには、セキュリティ上の問題を提起していません。
[ASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[ASCII] US-ASCII。コード化文字セット - 情報交換のための7ビットの米国標準コード。標準ANSI X3.4-1986、ANSI、1986。
[FOLDOC] Howe, Denis, ed. The Free On-Line Dictionary of Computing, <URL:http://wombat.doc.ic.ac.uk/>
[FOLDOC]ハウ、デニス、エド。コンピューティングの無料のオンライン辞書、<URL：のhttp：//wombat.doc.ic.ac.uk/>
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. UTF-8 is described in Annex R, adopted but not yet published. UTF-16 is described in Annex Q, adopted but not yet published.
[ISO10646] ISO / IEC 10646-1：1993。国際規格 - 情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS） - 第1部：アーキテクチャと基本多言語面。 UTF-8は、附属書Rに記述採用したがまだ公開されていません。 UTF-16は、附属書Qで説明した採用が、まだ公表されていません。
[JARGON] The on-line hacker Jargon File, version 4.0.0, 25 JUL 1996, <URL:http://www.ccil.org/jargon/>
[専門用語]のオンラインハッカージャーゴンファイル、バージョン4.0.0、1996年7月25日、<URL：のhttp：//www.ccil.org/jargon/>
[KNUTH73] Knuth, Donald E. "The Art of Computer Programming", Volume 3: Sorting and Searching (Addison-Wesley Publishing Co., 1973, pages 391 and 392). Knuth notes that the soundex method was originally described by Margaret K. Odell and Robert C. Russell [US Patents 1261167 (1918) and 1435663 (1922)].
[KNUTH73]クヌース、ドナルドE.「コンピュータプログラミングの芸術」、第3巻：ソートと検索（アディソン・ウェズリー出版社、1973年、ページ391および392）。クヌースはSOUNDEX方法は、もともとマーガレットK.オデルとロバート・C・ラッセル[米国特許1261167（1918）および1435663（1922）〕により記載されていることを指摘しています。
[PZ85] Pollock, Joseph J. and Zamora, Antonio, "Automatic spelling correction in scientific and scholarly text," CACM, 27(4): Apr. 1985, 358-368.
【PZ85]ポロック、ジョセフJ.及びサモラ、アントニオ、 "科学学術テキストに自動スペル訂正、" CACM、27（4）：1985年4月、358から368。
[RFC640] Postel, J., "Revised FTP Reply Codes", RFC 640, June, 1975.
[RFC640]ポステル、J.、 "改訂FTPの応答コード"、RFC 640、1975年6月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[RFC977] Kantor, B., and P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, February 1986.
[RFC977]カンター、B.、およびP.ラプスリー、「ネットワークニュース転送プロトコル：ニュースのストリームベースの伝送のためのProposed Standard」、RFC 977、1986年2月。
[RFC2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]フリード、N.、およびN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[RFC1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[RFC1760]ハラー、N.、 "S / KEYワンタイムパスワードシステム"、RFC 1760、1995年2月。
[RFC1985] Freed, N., and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
[RFC1985]フリード、N.、およびA.カーギル、 "コマンドパイプラインのためのSMTPサービス拡張"、RFC 1854、1995年10月。
[RFC1939] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]マイヤーズ、J.、およびM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[RFC2044] Yergeau、F.、 "UTF-8、UnicodeとISO 10646の変換フォーマット"、RFC 2044、1996年10月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2"、RFC 2078、1997年1月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[WEB1913] Webster's Revised Unabridged Dictionary (G & C. Merriam Co., 1913, edited by Noah Porter). Online version prepared by MICRA, Inc., Plainfield, N.J. and edited by Patrick Cassidy <cassidy@micra.com>. For further information, see <URL:ftp://uiarchive.cso.uiuc.edu/pub/etext/gutenberg/etext96/pgw*>, and <URL:http://humanities.uchicago.edu/forms_unrest/webster.form.html>
【WEB1913】ウェブスター大辞典改訂辞書（ノア・ポーターによって編集されたG＆C.メリアム社、1913）。オンラインバージョンMICRA社、プレインフィールド、ニュージャージ州によって調製し、パトリック・キャシディ<cassidy@micra.com>で編集。詳しい情報については、<URL：ftpの：//uiarchive.cso.uiuc.edu/pub/etext/gutenberg/etext96/pgw*>、および<URL：のhttp：//humanities.uchicago.edu/forms_unrest/webster。 form.html>
[WORDNET] Miller, G.A. (1990), ed. WordNet: An On-Line Lexical Database. International Journal of Lexicography. Volume 3, Number 4. <URL:http://www.cogsci.princeton.edu/~wn/>
【WORDNET】ミラー、G.A. （1990）、エド。 WordNetの：オンライン語彙データベース。辞書編集の国際ジャーナル。第3巻、4番<URL：のhttp：//www.cogsci.princeton.edu/~wn/>
Thanks to Arnt Gulbrandsen and Nicolai Langfeldt for many helpful discussions. Thanks to Bennet Yee, Doug Hoffman, Kevin Martin, and Jay Kominek for extensive testing and feedback on the initial implementations of the DICT server. Thanks to Zhong Shao for advice and support.
多くの有用な議論のためのARNT GulbrandsenのとニコライLangfeldtに感謝します。 DICTサーバの初期の実装に関する広範なテストとフィードバックのためのベネット・イー、ダグ・ホフマン、ケビン・マーティン、そしてジェイKominekに感謝します。助言や支援のための忠シャオに感謝します。
Thanks to Brian Kanto, Phil Lapsley, and Jon Postel for writing exemplary RFCs which were consulted during the preparation of this document.
本文書の作成時に相談された模範的なRFCを書くためのブライアン・関東、フィル・ラプスリー、そしてジョン・ポステルに感謝します。
Thanks to Harald T. Alvestrand, whose comments helped improve this document.
コメントこのドキュメントを改善する助けハラルドT. Alvestrandのおかげ。
Rickard E. Faith EMail: faith@cs.unc.edu (or faith@acm.org)
リカードE.フェイス電子メール：faith@cs.unc.edu（又はfaith@acm.org）
Bret Martin EMail: bamartin@miranda.org
ブレット・マーティンEメール：bamartin@miranda.org
The majority of this work was completed while Bret Martin was a student at Yale University.
ブレット・マーティンは、エール大学の学生だったときにこの作品の大部分は完成しました。
Copyright (C) The Internet Society (1997). All Rights Reserved.
著作権（C）インターネット協会（1997）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピー、公表andand配布することができることを説明したり、そのimplmentationを支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。