[要約] RFC 2229は、辞書サーバープロトコルに関する規格であり、辞書データの取得や検索を可能にする。目的は、異なる辞書サーバー間の相互運用性を確保し、クライアントが一貫した方法で辞書データにアクセスできるようにすること。
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.
Copyright（c）The Internet Society（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.
長年にわたり、インターネットコミュニティは、自然言語の定義にアクセスするための「Webster」プロトコルに依存してきました。Websterプロトコルは、単一の辞書へのアクセスをサポートし、（オプションでは）単一のシソーラスへのアクセスをサポートしています。近年、インターネット上の公開されているWebsterサーバーの数が劇的に減少しています。
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).
幸いなことに、いくつかの自由に分散できる辞書とレキシコンが最近インターネットで利用可能になりました。ただし、これらの自由に分散できるデータベースは、均一なインターフェイスからアクセスできず、単一のサイトからアクセスできません。多くの場合、個別に小さく不完全ですが、英語の単語の興味深い有用なデータベースをまとめて提供します。例には、Jargonファイル[Jargon]、WordNetデータベース[WordNet]、1913年のWebsterの修正された辞書[Web1913]のMicraのバージョン、およびコンピューティングの無料オンライン辞書[Foldoc]が含まれます。翻訳および非英語の辞書も利用可能になっています（たとえば、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.
Websterプロトコルは、多数の個別の辞書データベースへのアクセスを提供するのに適しておらず、現在のWebsterプロトコルへの拡張は、辞書データベースの問題に対するクリーンソリューションであるとは感じられませんでした。
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.
このドキュメントでは、このドキュメントで指定された各特定の要件の重要性を定義するために、大文字の単語を使用する必要がある、必要に応じて、推奨される、推奨される可能性があり、可能性がある場合、必要に応じて、[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.
簡単に言えば、「必須」（または「必須」）は、アイテムが仕様の絶対的な要件であることを意味します。「すべき」（または「推奨」）は、このアイテムを無視する正当な理由が存在する可能性があることを意味しますが、そうする前に完全な意味を理解する必要があります。「5月」（または「オプション」）は、彼のアイテムがオプションであり、慎重に検討せずに省略される可能性があることを意味します。
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.
コマンドは、コマンドワードに続いてゼロ以上のパラメーターで構成されています。パラメーターを使用したコマンドは、1つ以上のスペースまたはタブ文字によってパラメーターを互いに、およびコマンドから分離する必要があります。コマンドラインは、必要なすべてのパラメーターを完了する必要があり、複数のコマンドを含めることはできません。
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.
コマンドラインは長さ1024文字を超えてはならず、スペース、セパレーター、句読点、および後続のCRLFを含むすべての文字をカウントしてください。コマンドラインの継続に関する規定はありません。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
1yz-正の予備返信2yz-正の完了返信3yz-ポジティブ中間回答4yz-一時的な負の完了返信5yz-永続的なネガティブ完了返信
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
X0Z -Syntax X1Z -Information（例えば、ヘルプ）X2Z -Connections X3Z-認証X4Z-まだ不特定X5Z -DICTシステム（これらの応答は、要求された転送またはその他。）x8z-非標準（プライベート実装）拡張機能
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.
パラメーターは、数値応答コードから、単一のスペースによって互いに分離されます。すべての数値パラメーターは10進数であり、主要なゼロがある場合があります。すべての文字列パラメーターは、「原子」または「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
500構文エラー、コマンド認識されていない501構文エラー、違法パラメーター502コマンドが実装されていない503コマンドパラメーターが実装されていない420サーバーが一時的に利用できない421サーバーオペレーターリクエストでシャットダウンする
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倍になります。したがって、クライアントは、受信した各ラインの最初の文字を調べる必要があります。2つの期間から始まるものは、これらの2つの期間を1つの期間に崩壊させる必要があります。CRLFが続く1つの期間のみを含むものは、テキスト応答の終了を示します。
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.
オプションMIMEコマンドが与えられている場合、すべてのテキスト応答には、MIMEヘッダー[RFC2045]が続いて1つの空白行（CRLF）が追加されます。オプション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.
テキスト行は長さ1024文字を超えてはならず、スペース、セパレーター、句読点、追加の初期期間（必要に応じて）、および後続のCRLFを含むすべての文字をカウントしてください。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ビットの米国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
MIMEオプションMIMEコマンドはサポートされていますauth authコマンドはサポートされていますkerberos_v4 sasl kerberosバージョン4メカニズムはサポートされていますgssapi sasl gssapi [rfc2078]メカニズムはサポートされています。サポート
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がはるかに容易になりますが、MSG-IDがarbitrarily意的に長くなる可能性があるため（このドキュメントの他の場所に記載されている応答長い制限に制限されているため）、セキュリティ利益は大幅に減少しません。
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.
このメッセージ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
420サーバーは一時的に利用できません421サーバーオペレーターのリクエストでシャットダウンする
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が送信され、1つ以上の定義が続くことを示します。
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に続く最初の3つのスペース削除パラメーターは、取得した単語、データベースの名前（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)
550無効なデータベース、データベースのリストに「show db」を使用してください
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」で示されている最初の名前）、パラメーター3は短いデータベースの説明（2番目の列です。「db show db」コマンドの）。
MATCH database strategy word
データベース戦略ワードを一致させます
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).
サーバーの実装者が考慮する可能性のあるその他の戦略は、サブストリング、接尾辞、正規表現、SoundEx [Knuth73]、およびLevenshtein [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].
戦略が期間（小数コード46、 "。"）を使用して指定されている場合、単語はサーバー依存のデフォルト戦略を使用して一致します。これは、インタラクティブなスペルチェックに利用できる最良の戦略です。これは通常、levenshteinアルゴリズム[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行ごとに一致した単語のリストがフォームにあります。
database word
データベースワード
This makes the responses directly useful in a DEFINE command.
これにより、応答は定義コマンドで直接役立ちます。
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が送信されます。これには、サーバー固有のタイミングと統計情報が含まれる場合があります。
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)
550無効なデータベース、データベースのリストに「show db」を使用してください。
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.
ただし、特定のサーバーが提供するすべてのデータベースではなく、クライアントが一部を検索したい場合があります。1つの選択肢は、クライアントがDBコマンドを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).
もう1つの選択肢は、サーバーが通常のデータベースのいくつかを1つに統合する「仮想」データベースを提供することです。たとえば、すべての翻訳辞書を含むが、通常の辞書やシソーリは含まれない仮想データベースが提供される場合があります。特別な「*」と「！」データベースは、すべてのデータベースへのアクセスを提供する仮想データベースの名前と見なすことができます。サーバーが仮想データベースを実装する場合、特別な「*」と「！」データベースは、おそらく他の仮想データベースを除外する必要があります（他のデータベースで複製された情報を提供するだけではありません）。仮想データベースがサポートされている場合、それらは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 DB SHOW DATABASES
DBショーデータベースを表示します
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.
クライアントドメインまたはユーザー認証の欠如により、一部のデータベースが制限される場合があることに注意してください（セクション3.11および3.12のAUTHおよびSASLAUTHコマンドを参照）。これらのデータベースに関する情報は、認証が実行されるまで使用できません。それまで、クライアントは、追加のデータベースが存在しないかのようにサーバーと対話します。
110 n databases present - text follows 554 No databases present
110 nデータベースが表示されます - テキストは554フォローしますデータベースはありません
Response code 110 requires a special parameter. Parameter 1 must be the number of databases available to the user.
応答コード110には、特別なパラメーターが必要です。パラメーター1は、ユーザーが利用できるデータベースの数でなければなりません。
SHOW STRAT SHOW STRATEGIES
Strat Show Strategiesを表示します
Displays the list of currently supported search strategies, one per line, in the form:
現在サポートされている検索戦略のリスト、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
111 n戦略が利用可能 - テキストは555フォローしています戦略は利用できません
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
550無効なデータベース、データベースのリストに「DBを表示する」を使用します112データベース情報がフォローします
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
114サーバー情報が続きます
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サーバーのこの実装によって理解されるコマンドの短い要約を提供します。ヘルプテキストは、テキストの応答として提示され、単独で1回の期間で終了します。すべての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.
クライアントがこのオプションを要求する場合、クライアントはコンテンツタイプとコンテンツ転送エンコードヘッダーを解析できる必要があり、サポートされていないコンテンツまたはエンコードを持つテキスト応答を無視できる必要があります。クライアントは、[RFC2044]をエンコードするUTF-8をサポートする必要があります。これは、クライアントがUTF-8マルチオクテットエンコーディングを認識し、クライアントが印刷できるシンボルに変換する必要があることを最小限にします。
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ヘッダーを提供します。ヘッダーが空の場合、テキスト応答は単一の空白行（CRLF）で開始されます。この場合、クライアントはこれをデフォルトのヘッダーとして解釈する必要があります。SASL認証のデフォルトヘッダーは次のとおりです。
Content-type: application/octet-stream Content-transfer-encoding: base64
コンテンツタイプ：アプリケーション/オクテットストリームコンテンツ - 転送エンコード：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.
オプション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.
オプション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,
このドキュメントが確定する前に完了したいくつかの古いサーバーの実装は、このコマンドが実装されていない場合、ステータスコード500を返すことに注意してください。クライアントはこの動作を受け入れることができるはずです、
making default assumptions. Clients may also examine the capabilities string in the status code 220 header to determine if a server supports this capability.
デフォルトの仮定を作成します。クライアントは、ステータスコード220ヘッダーの機能文字列を調べて、サーバーがこの機能をサポートしているかどうかを判断することもできます。
AUTH username authentication-string
AUTH USERNAME AUTIONDICATION-STRING
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.
認証はオプションのサーバー機能です。認証コマンドは、DICTサーバーによって実装される場合があります。
230 Authentication successful 531 Access denied, use "SHOW INFO" for server information
230認証成功531アクセスが拒否され、サーバー情報に「情報を表示」を使用します
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
現在、単純な認証とセキュリティ層（SASL）が開発中です[RFC2222]。DICTプロトコルは、この認証方法のSASLAUTHおよびSASLRESPコマンドを留保します。結果
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.
Salsauthで成功した認証の結果は、成功した認証の結果と同じです。現在のセッションでは、より多くの辞書データベースが利用可能になる場合があります。
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.
初期応答は、Saslauthコマンドのオプションパラメーターであり、base64エンコード[RFC2045]を使用してエンコードされています。一部の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.
Saslauthコマンドを使用して、クライアントによって典型的なSASL認証が開始されます。サーバーは、ステータスコード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テキスト応答を使用して送信する必要があります。オプションMIMEが設定されていない場合は、Base64エンコードを使用する必要があります。もしも
OPTION MIME is set, then BASE64 is the default encoding, as specified in section 3.10.1.
オプションMIMEが設定され、セクション3.10.1で指定されているように、Base64がデフォルトのエンコードです。
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コマンドラインの長さは1024文字のみである可能性があるため、DICTクライアントが提供する応答は限られていることに注意してください。
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
130チャレンジフォロー330応答を送信230認証成功してください
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サーバーでのパイプラインを防ぐ問題に似ています。これらの問題は[RFC1854]で詳細に説明されており、すべてのDICTサーバー実装者が相談する必要があります。
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クライアントは、クライアントをパイプラインし、サーバーに接続しているときにコマンドシーケンスを定義し、終了する場合があります。サーバーがシャットダウンされている場合、サーバーから送信された初期応答コードは、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).
「/d」構文は、定義コマンド（セクション3.2）を指定し、「/m」は一致コマンド（セクション3.3）を指定します。
Some or all of "<user>;<auth>@", ":<port>", "<database>", "<strat>", and "<n>" may be omitted.
「<user>; <auth>@"、"：<port> "、" <database> "、" <strat> "、および" <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).
"<user>; <auth>@"が省略されている場合、認証は行われません。「：<port>」が省略されている場合、デフォルトのポート（2628）を使用する必要があります。「<database>」が省略されている場合、「！」使用する必要があります（セクション3.2を参照）。「<Strat>」が省略されている場合、」。使用する必要があります（セクション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.
"<user>; <auth>@"は、実行されるユーザー名と認証のタイプを指定します。「<auth>」の場合、文字列「認証」は、authコマンドを使用したAPOP認証が実行されることを示しますが、文字列「saslauth = <auth_type>」は、saslauthおよびsaslRespコマンドが使用され、 "<auth_type>で使用されることを示します。「使用されるSASL認証のタイプを示します。「<auth_type>」が星（小数コード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:sun dict://dict.org/m:sun::soundex dict://dict.org/m:sun:wordnet::1 dict://dict.org/m:sun::soundex:1 dict://dict.org/m:sun:::
dict：//dict.org/m：sun dict：//dict.org/m：sun :: soundex dict：//dict.org/m：sun：wordnet :: 1 dict：//dict.org/m：sun :: soundex：1 dict：//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
* 110 nデータベースの存在 - テキストは続きます * 111 n戦略が利用可能 - テキストは112データベース情報に従う113ヘルプに従う113テキストは114サーバー情報に従います130課題に従う * 150 n定義を取得 - 定義は * 151ワードデータベース名 - テキストに従う * 152 n一致見つかった - テキストは210（オプションのタイミングと統計情報はこちら）に続きます * 220テキストMSG -ID 221クロージング接続230認証成功250 OK（ここでオプションのタイミング情報） 、コマンド認識されていない501構文エラー、違法パラメーター502コマンドが実装されていない503コマンドパラメーターが実装されていない530アクセスが拒否されない531アクセス拒否、サーバー情報に「show info」を使用532アクセス拒否、未知のメカニズム550無効なデータベース、「show db」の使用データベースのリスト551無効な戦略、戦略のリストに「Show Strat」を使用する552 No Match 554 No Databases Presen T 555戦略なし
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 ]
C：[クライアントが接続を開始する]
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
C: HELP
C：ヘルプ
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
C：定義！ペンギン
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
C：定義 *ショートケーキ
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
C：ABCDEFGHを定義します
S: 552 No match
S：552一致なし
C: quit
C：終了
S: 221 Closing connection
S：221クロージング接続
C: SHOW DB
C：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
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"
C：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"
C：WNサブストリング「Abcdefgh」を一致させる
S: 552 No match
S：552一致なし
C: [ client initiates connection ]
C：[クライアントが接続を開始する]
S: 420 Server temporarily unavailable
S：420サーバーは一時的に利用できません
C: [ client initiates connection ]
C：[クライアントが接続を開始する]
S: 421 Server shutting down at operator request
S：421サーバーオペレーターのリクエストでシャットダウンします
C: [ client initiates connection ]
C：[クライアントが接続を開始する]
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
C: SHOW DB
C：DBを表示します
S: 110 1 database present: list follows
S: free "Free database"
S: .
S: 250 Command complete
C: AUTH joesmith authentication-string
C：Auth Joesmith Authentication-String
S: 230 Authentication successful
S：230認証が成功しました
C: SHOW DB
C：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/>
[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/>
[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] Knuth、Donald E.Knuthは、SoundexメソッドはもともとMargaret K. OdellとRobert C. Russell [米国特許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] Pollock、Joseph J. and Zamora、Antonio、「科学的および学術的テキストにおける自動スペリング補正」、CACM、27（4）：1985年4月、358-368。
[RFC640] Postel, J., "Revised FTP Reply Codes", RFC 640, June, 1975.
[RFC640] Postel、J。、「改訂されたFTP応答コード」、RFC 640、1975年6月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821] Postel、J。、「Simple Mail Transfer Protocol」、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] Crocker、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] Kantor、B。、およびP. Lapsley、「ネットワークニュース転送プロトコル：ニュースのストリームベースの送信のための提案された基準」、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] Freed、N。、およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[RFC1760]ハラー、N。、「S/キーのワンタイムパスワードシステム」、RFC 1760、1995年2月。
[RFC1985] Freed, N., and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
[RFC1985] Freed、N。、およびA. Cargille、「Command PipeliningのSMTPサービス拡張」、RFC 1854、1995年10月。
[RFC1939] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。、およびM. Rose、「郵便局プロトコル - バージョン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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2068、1997年1月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078] Linn、J。、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス、バージョン2」、RFC 2078、1997年1月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222] Myers、J。、「Simple Authentication and Security Layer（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>
[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/>
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とNicolai Langfeldtに感謝します。Bennet Yee、Doug Hoffman、Kevin Martin、およびJay Kominekに感謝します。アドバイスとサポートをしてくれたZhong Shaoに感謝します。
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.
Harald T. Alvestrandのおかげで、そのコメントはこの文書の改善に役立ちました。
Rickard E. Faith EMail: faith@cs.unc.edu (or faith@acm.org)
Rickard E. Faith Email：faith@cs.unc.edu（またはwhite@acm.org）
Bret Martin EMail: bamartin@miranda.org
Bret Martin Email：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.
Copyright（c）The Internet Society（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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。