RFC1714 日本語訳
1714 Referral Whois Protocol (RWhois). S. Williamson, M. Kosters. November 1994. (Format: TXT=85395, PS=204207, PDF=85556 bytes) (Obsoleted by RFC2167) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Williamson
Request for Comments: 1714 M. Kosters
Category: Informational Network Solutions Inc.
InterNIC
November 1994
コメントを求めるワーキンググループS.ウィリアムソン要求をネットワークでつないでください: 1714年のM.Kostersカテゴリ: 情報のネットワークソリューション株式会社InterNIC1994年11月
Referral Whois Protocol (RWhois)
紹介Whoisプロトコル(RWhois)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information.
このメモはRWhoisのクライアント/サーバ相互作用のバージョン1.0について説明します。 RWhoisは階層的な情報のディスプレイに分散システムを提供します。 このシステムは故意に階層的です、質問の減少を考慮してユーザの紹介は情報の維持装置により厳密です。
Table of Contents
目次
1. Introduction................................... 3
2. RWhois Client Model............................ 5
2.1 Directives: Client to Server Interaction ... 6
2.2 Required Directives ......................... 6
2.2.1 <query>.................................. 6
2.2.2 RWhois................................... 7
2.3 Optional Directives ......................... 7
2.3.1 load..................................... 7
2.3.2 limit.................................... 7
2.3.3 schema................................... 8
2.3.4 xfer..................................... 8
2.3.5 quit..................................... 9
2.3.6 status................................... 9
2.3.7 cache.................................... 9
2.3.8 holdconnect..............................10
2.3.9 forward..................................10
2.3.10 soa.....................................11
2.3.11 notify..................................11
2.3.12 register................................13
2.3.13 object..................................14
2.3.14 define..................................15
2.3.15 private.................................15
2.3.16 X-......................................16
1. 序論… 3 2. RWhoisクライアントモデル… 5 2.1の指示: サーバ相互作用への…クライアント 6 2.2 指示を必要とします… 6 2.2 .1 <質問>… 6 2.2 .2RWhois… 7 2.3の任意の指示… 7 2.3 .1 ロードしてください… 7 2.3 .2 制限します。 7 2.3 .3図式… 8 2.3 .4xfer… 8 2.3 .5 やめてください… 9 2.3 .6状態… 9 2.3 .7 キャッシュします。 9 2.3 .8holdconnect…10 2.3 .9 進めます。10 2.3 .10soa…11 2.3 .11 通知してください…11 2.3 .12 登録してください…13 2.3 .13 反対してください…14 2.3 .14 定義します。15 2.3 .15 個人的…15 2.3 .16X…16
Williamson & Kosters [Page 1] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[1ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
2.3.17 directive...............................17
2.3.18 display.................................17
2.3.19 language................................18
2.4 RWhois Client Model .........................18
3. RWhois Server Model............................20
3.1 Output Display and Restriction Keywords .....20
3.2 Responses: Server to Client Interaction ....21
3.3 Required Responses ..........................22
3.3.1 RWhois...................................22
3.3.2 referral.................................22
3.3.3 ok.......................................24
3.3.4 error....................................24
3.4 Optional Responses ..........................25
3.4.1 see-also.................................25
3.4.2 load.....................................26
3.4.3 soa......................................26
3.4.4 status...................................28
3.4.5 xfer.....................................29
3.4.6 schema...................................30
3.4.7 define...................................32
3.4.8 object...................................32
3.4.9 directive................................33
3.4.10 info....................................34
3.4.11 display.................................34
3.4.12 X-......................................35
3.4.13 language................................35
3.5 Query Reduction .............................36
3.6 Determining Authority .......................36
3.7 Secondary Server Interaction ................37
3.8 Registration Process ........................38
3.9 Out-of-Service ..............................38
4. Interaction: Client Directives and Acceptable
Server Responses...............................39
4.1 General ......................................39
4.2 On Connection ................................39
4.3 <QUERY> ......................................39
4.4 -RWhois ......................................40
4.5 -load ........................................40
4.6 -limit<SP>< value > ..........................40
4.7 -schema<SP>[object] ..........................40
4.8 -xfer<SP>[object] ............................40
4.9 -quit ........................................40
4.10 -cache<SP><on/off> ..........................40
4.11 -status .....................................40
4.12 -forward ....................................40
4.13 -soa ........................................40
4.14 -notify .....................................41
4.15 -register ...................................41
2.3.17 指示…17 2.3 .18 表示してください…17 2.3 .19言語…18 2.4RWhoisクライアントモデル…18 3. RWhoisサーバモデル…20 3.1 ディスプレイと制限キーワードを出力してください…20 3.2の応答: クライアントとの対話へのサーバ…21 3.3 応答を必要とします…22 3.3 .1RWhois…22 3.3 .2紹介…22 3.3 .3 OK…24 3.3 .4誤り…24 3.4 任意の応答…25 3.4 .1 -また、見てください…25 3.4 .2 ロードしてください…26 3.4 .3soa…26 3.4 .4状態…28 3.4 .5xfer…29 3.4 .6図式…30 3.4 .7 定義します。32 3.4 .8 反対してください…32 3.4 .9指示…33 3.4 .10インフォメーション…34 3.4 .11 表示してください…34 3.4 .12X…35 3.4 .13言語…35 3.5 減少について質問してください…36 3.6 権威を決定します…36 3.7セカンダリサーバ相互作用…37 3.8登録手続…38 3.9 使われなくなっている…38 4. 相互作用: クライアント指示と許容できるサーバ応答…39 4.1一般…39 4.2 接続に関して…39 4.3 <質問>…39 4.4-RWhois…40 4.5 -ロードしてください…40 4.6 -<SP><値の>を制限してください…40 4.7図式の<SP>[オブジェクト]…40 4.8 -xfer<SP>[オブジェクト]…40 4.9 -やめてください…40 4.10 ->で/で<SP><をキャッシュしてください…40 4.11状態…40 4.12 進めます。40 4.13-soa…40 4.14 -通知してください…41 4.15 -登録してください…41
Williamson & Kosters [Page 2] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[2ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
4.16 -holdconnect ................................41
4.17 -object .....................................41
4.18 -define .....................................41
4.19 -X- .........................................41
4.20 -display ....................................41
4.21 -language ...................................41
5. Error Codes....................................42
5.1 Error Code List .............................42
6. Attribute Format...............................43
6.1 Format Specification Macros .................44
7. Quick Query (RWhois using UDP).................45
8. References.....................................46
9. Security Considerations....................... 46
10. Authors' Addresses.............................46
4.16-holdconnect…41 4.17 -反対してください…41 4.18 …を定義してください…41 4.19X、-、…41 4.20 -表示してください…41 4.21言語…41 5. 誤りコード…42 5.1エラーコードリスト…42 6. 形式を結果と考えてください…43 6.1 書式仕様マクロ…44 7. 迅速な質問(UDPを使用するRWhois)…45 8. 参照…46 9. セキュリティ問題… 46 10. 作者のアドレス…46
1. Introduction
1. 序論
Early in ARPANET development, the SRI-NIC established a centralized whois database that provided host and network information about the systems connected to the network and the E-mail addresses of the users on those systems. The ARPANET experiment has evolved into a global network with countless people and hundreds of thousands of end systems. Given the sheer size and effort needed to maintain a centralized database, an alternate, decentralized approach to store and display this information is desired.
アルパネット開発で早くて、SRI-NICはそれらのシステムの上でホストを提供した集結されたwhoisデータベース、ネットワークに接続されたシステムに関するネットワーク情報、およびユーザのEメールアドレスを確立しました。アルパネット実験は無数の人々との世界的なネットワークと何十万台ものエンドシステムに発展しました。集中データベース(補欠)が保存するアプローチとディスプレイを分散したと主張するのに必要である全くのサイズと取り組みを考えて、この情報は望まれています。
The Internet portions of the DDN NIC have been transitioned to what is now known as InterNIC Registration Services (RS). The charter for InterNIC RS has been reduced to maintain information only for IP networks, top-level domains, Autonomous System Numbers, and the points of contact for each of these particular entities. In addition, the InterNIC, in its role as an Internet Registry (IR), has delegated IP block assignment authority to Regional Registries such as the RIPE NCC for Europe and the APNIC for the Asian Pacific region, while retaining authority for North America and all non- delegated regions. This has led to a fragmentation of whois service to the Internet user.
DDN NICのインターネット一部に移行しました。InterNIC Registration Servicesとして知られていて、現在であること(RS)。 InterNIC RSのための特許は、それぞれのこれらの特定の実体のためにIPのためだけの情報がネットワークと、最上位のドメインと、Autonomous System民数記と、連絡先であることを支持するために抑えられました。 北アメリカとすべての非代表として派遣された領域への権威を保有している間、さらに、インターネットRegistry(IR)としての役割では、InterNICはアジアの太平洋の領域のためにIPブロック課題権威をヨーロッパへのRIPE NCCやAPNICなどのRegional Registriesへ代表として派遣しています。 これはインターネットユーザに対するwhoisサービスの断片化に通じました。
Several different solutions have been proposed and developed by the various regional IR's. Two solutions have been worked on extensively: the Shared Whois Project (SWIP) and X.500.
いくつかの異なった解決策が、様々なIRの地方のもので提案されて、見いだされました。 2つのソリューションが手広く扱われました: 共有されたWhoisは(SWIP)とX.500を映し出します。
The SWIP project has a common exchange format that can be parsed by the various IR's for input and output. Thus, one can synchronize their databases with information obtained from the other IR's. This project is showing promise and is now operational. However, this approach still requires a centralized database for store and display.
SWIPプロジェクトには、入出力のための様々なIRのもので分析できる一般的な交換形式があります。 したがって、1つはIRの他のものから得る情報とそれらのデータベースを同期させることができます。 このプロジェクトは、見込みを示していて、現在、操作上です。 しかしながら、このアプローチはまだ店とディスプレイのための集中データベースを必要としています。
Williamson & Kosters [Page 3] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[3ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
The InterNIC has also been involved in the use of X.500 for display of registration information. Among other things, this included defining schemas and Directory information tree structures for the purpose of distributing information amongst the various IR X.500 Directory Service Agents (DSA). Unfortunately, X.500's complexity, resource utilization, and lack of Internet support has made a search for an alternative solution necessary.
また、InterNICはX.500のレジスト情報のディスプレイの使用にかかわりました。 特に、これは、情報伝達の目的のために様々なIR X.500ディレクトリサービスエージェント(DSA)の中でschemasとディレクトリ情報木構造を定義するのを含んでいました。 残念ながら、X.500のインターネットサポートの複雑さ、リソース利用、および不足で、代替のソリューションの検索は必要になりました。
The information that the various IR's maintain is inherently hierarchical in nature. (Examples: hammer.nic.ddn.mil is under the nic.ddn.mil domain which is under the ddn.mil domain which is under the .mil domain. 198.41.0.21 is part of network 198.41.0.0/24 which is part of the block 198.41.0.0/16 which is part of the block 198.0.0.0/8) The InterNIC may not have the information, but will at least be able to reduce the query and point or refer the users closer to their goal. This has led to the development of a referral whois, and the corresponding RWhois protocol.
様々なIRのものが保守する情報は本来現実に階層的です。 (例: hammer.nic.ddn.milが.milドメインの下にあるddn.milドメインの下にあるnic.ddn.milドメインの下にあります。 198.41.0.21 ネットワーク198.41.0の一部が.0/24である、どれ、ブロック198.41.0のものの一部がブロック198.0.0.0/の一部である.0/16であるか、8) InterNICは情報を持っていないかもしれませんが、質問とポイントを抑えるか、または彼らの目標の、より近くでユーザを少なくとも参照できるでしょう。 これはwhois、および対応するRWhoisプロトコルを紹介の開発に導きました。
The underlying premise for this project has been to retain the basic functionality of the whois server and client, making all of the extensions optional. The server must respond to the original whois client, currently included with many operating systems. The RWhois client must also interact with RFC 954 [RFC-954] whois servers.
このプロジェクトのための基本的な前提はwhoisサーバとクライアントの基本機能を保有しに行ったことがあります、拡大のすべてを任意にして。 サーバは現在多くのオペレーティングシステムで含まれているオリジナルのwhoisクライアントに反応しなければなりません。また、RWhoisクライアントはRFC954[RFC-954]whoisサーバと対話しなければなりません。
RWhois has been designed as an extensible protocol to ensure that many uses can be accommodated. Public extensions to the protocol should be documented as RFCs. Private extensions can be used with agreement left up to the client and server.
RWhoisは、多くの用途に対応できるのを保証するように広げることができるプロトコルとして設計されています。 プロトコルへの公共の拡大はRFCsとして記録されるべきです。 クライアントとサーバまで残っている協定と共に個人的な拡張子を使用できます。
If extensions are not implemented at the server in question, an appropriate error message must be sent. The use of extended error message is outlined in Section 5 - Error Codes.
問題のサーバで拡大を実装しないなら、適切なエラーメッセージを送らなければなりません。 拡張エラーメッセージの使用はセクション5に概説されています--誤りCodes。
Throughout this document the following notations will be used to describe the RWhois server/client interaction:
このドキュメント中では、以下の記法はRWhoisサーバ/クライアントとの対話について説明するのに使用されるでしょう:
<SP> space
[arg] optional argument
<arg> required argument
(<arg>) conditional required argument
([arg]) conditional optional argument
{format} format of item
\ continued on next line
<SP>宇宙[arg]の任意の議論<arg>は\が次の系列で続けていた項目の主張(<arg>)の条件付きの必要な議論([arg])条件付きの任意の議論形式形式を必要としました。
The words should and must are significant in this document. If should is used, the implementor has the option to follow the advice of this document. If must is used then it is a required part of the protocol. Implementations without this functionality may not
単語は重要であるべきです、そして、必須は本書では重要です。 作成者には、使用されていて、このドキュメントのアドバイスに従うオプションがあるべきです。 必須が使用されているなら、それはプロトコルの必要な部分です。 この機能性のない実装はそうしないかもしれません。
Williamson & Kosters [Page 4] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[4ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
interact correctly with other RWhois servers.
正しく他のRWhoisサーバと対話してください。
The format descriptions throughout this document use macro definitions described in Section 6.1. Refer to that section for clarification.
このドキュメント中の書式の記述はセクション6.1で説明されたマクロ定義を使用します。 明確化についてそのセクションを参照してください。
The RWhois protocol specified in this document can be extended to accommodate such applications as NetHelp and ZoneGen (DNS zone generator).
NetHelpとZoneGen(DNSゾーンジェネレータ)のようなアプリケーションを収容するために本書では指定されたRWhoisプロトコルは広げることができます。
2. RWhois Client Model
2. RWhoisクライアントモデル
The RWhois design requires compatibility with the current Whois and Whois++ servers. Therefore, the RWhois client must wait or have knowledge of server type to determine if the server contacted is an RWhois server. The user should have control over the time the client waits, since this will vary based on network congestion and capacity. If after the wait the server does not respond with the %RWhois response, the client must not send any RWhois extended directives.
RWhoisデザインは現在のWhoisとWhois++サーバとの互換性を必要とします。 したがって、RWhoisクライアントには、決定するサーバタイプに関する知識は、連絡されたサーバがRWhoisサーバであるなら待たなければならないか、またはなければなりません。クライアントが待つとき、ユーザはコントロールを家に迎えるべきです、これがネットワークの混雑と容量に基づいて異なるので。 サーバが待ちの後にRWhois応答、クライアントがそうしてはいけない%で反応しないなら、拡張指示をあらゆるRWhoisに送ってください。
In this case, the client should only send the query. We realize that the server identification feature may mean that the identity of an RWhois server may be missed. However, it will allow the RWhois system to utilize the current Whois and Whois++ infrastructure. Referrals from RWhois can be directed toward a Whois or Whois++ server. These non-RWhois servers must be placed as a leaf on the hierarchical tree. These servers represent a mesh structure from the RWhois perspective. This restriction should not discourage the use of these servers in building the RWhois structure.
この場合、クライアントは質問を送るだけであるべきです。 私たちは、サーバ識別機能が、RWhoisサーバのアイデンティティが逃されるかもしれないことを意味するかもしれないとわかります。 しかしながら、それで、RWhoisシステムは現在のWhoisとWhois++インフラストラクチャを利用できるでしょう。 RWhoisからの紹介はWhoisかWhoisに向けられて、+ + サーバこれらの非RWhoisサーバが階層木に関して葉として課されなければならないということであるかもしれません。 これらのサーバはRWhois見解からメッシュ構造を表します。 この制限はRWhois構造を建設することにおけるこれらのサーバの使用に水をさしているべきではありません。
The RWhois server must remain connected until a query is received. If the client wishes to make multiple queries it must send the -holdconnect directive. In this mode, once the client has sent the last query and received either an answer or the error code indicating that no records were found, it must issue the -quit directive. If the client only wishes to issue directives, then upon completion the -quit directive must be sent. If it is not sent, the server will wait until it receives non-directive input from the client.
質問が受け取られているまで、RWhoisサーバは接続されていたままで残らなければなりません。 クライアントが複数の質問をしたいと思うなら、それは-holdconnect指示を送らなければなりません。 このモードで、クライアントがいったん最後の質問を送って、記録が全く見つけられなかったのを示す答えかエラーコードのどちらかを受け取ると、それは辞任に指示を発行しなければなりません。 クライアントがそして、完成の指示に辞任を発行するだけでありたいなら、指示を送らなければなりません。 それが送られないなら、クライアントから非指示入力を受け取るまで、サーバは待っています。
Considering the requirement for compatibility with the original whois, the RWhois client in default mode must operate exactly like the current Whois client. However, in the enhanced mode, the RWhois client can do much more based on information received from the RWhois server.
オリジナルのwhoisとの互換性のための要件を考える場合、デフォルトモードによるRWhoisクライアントはちょうど現在のWhoisクライアントのように働かなければなりません。 しかしながら、高められたモードで、RWhoisクライアントはRWhoisサーバから受け取られた情報に基づいてはるかに多くができます。
Williamson & Kosters [Page 5] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[5ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
2.1 Directives: Client to Server Interaction
2.1の指示: サーバ相互作用へのクライアント
The RWhois client sends directives to the RWhois server. These directives are prefaced with the `-' character always at the start of a new line. However, for compatibility with older Whois clients, the query is not prefaced with the `-' character. Only after the client is certain that the server is an RWhois server should these directives be sent. Compatibility with RFC 954 [RFC-954] whois servers is required. All directives must be terminated by <LF><CR>.
RWhoisクライアントはRWhoisサーバに指示を送ります。これらの指示はいつも復帰改行の始めの'--'キャラクタと共に前書きされます。 しかしながら、より年取ったWhoisクライアントとの互換性において、質問は'--'キャラクタと共に前書きされません。 クライアントがサーバがRWhoisサーバであることを確信していた後にだけこれらの指示を送るべきです。 RFC954[RFC-954]whoisサーバとの互換性が必要です。 <LF><CR>はすべての指示を終えなければなりません。
2.2 Required Directives
2.2 必要な指示
The following are required RWhois client directives.
↓これは必要なRWhoisクライアント指示です。
2.2.1 <query>
2.2.1 <質問>。
The query is generally the final directive sent to the server. It is the only directive that does not start with a `-'. The query is the question that the client wants the server to answer. The qualifiers that may proceed the query are addressed in Section 3.1 - Output Display and Restriction Keywords.
一般に、質問はサーバに送られた最終的な指示です。それは'--'から始まらない唯一の指示です。 質問はクライアントが、サーバに答えて欲しいという問題です。 質問を続かせるかもしれない資格を与える人はセクション3.1で宛てられます--出力DisplayとRestriction Keywords。
Format for use:
使用のための形式:
[display format]<SP>[query restriction]<SP><query>
[システム出力表示形式] <SP>[質問制限]<SP><質問>。
[Display format]{%s} This optional pre-query directive allows
the requester to select the format of
the returned data. Details of the
allowable values can be found in Section
3.1.
この任意のプレ質問指示で返されたデータの形式をリクエスタを選択する[システム出力表示形式]%s。 セクション3.1で許容量の詳細を見つけることができます。
[Query restriction]{%s} This optional pre-query directive allows
the requester to limit the area in which
the servers search for a specific
object.
[質問制限] この任意のプレ質問指示で、リクエスタをサーバが特定のオブジェクトを捜し求める領域を制限する%s。
Example of use:
使用に関する例:
dump domain netsol.com
ドメインnetsol.comをどさっと落としてください。
Williamson & Kosters [Page 6] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[6ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
2.2.2 RWhois
2.2.2 RWhois
The -RWhois directive identifies the client as an RWhois client allowing the server to operate using the RWhois protocol exclusively.
-RWhois指示は、クライアントがサーバを排他的にRWhoisプロトコルを使用することで作動させるRWhoisクライアントであると認識します。
Format for use:
使用のための形式:
-RWhois<SP>V-<spec version #><SP>[imp identifier]
-RWhois<SP>V、-、<仕様バージョン#><SP>。[悪童識別子]
<Spec version #>{%2d.%2d} This required argument identifies
the specification version that the
client is built to conform with.
Clients that are built in
accordance with this document are
V-1.0. This argument will be used
by the server to determine if
features introduced in subsequent
releases of the protocol document
may be used.
<仕様バージョン# この必要な議論の%2d.%2dがクライアントが従うために建てられる仕様バージョンを同一視する>。 このドキュメントによると、建てられるクライアントはV-1.0です。 この議論はサーバによって使用されて、プロトコルドキュメントのその後のリリースで導入された特徴が使用されるかもしれないかどうか決定するでしょう。
[Imp identifier]{%s} This optional argument identifies client
implementation information. It is
recommended that the implementor maintain a
version number separate from the
specification version.
この任意の議論が特定する[悪童識別子]%s、クライアント実装情報。 作成者が仕様バージョンから別々にバージョン番号を維持するのは、お勧めです。
Example of use:
使用に関する例:
-RWhois V-1.0 [InterNIC B.0.9.7]
-RWhois V-1.0[InterNIC B.0.9.7]
2.3 Optional Directives
2.3 任意の指示
The following are OPTIONAL RWhois server directives.
↓これはOPTIONAL RWhoisサーバ指示です。
2.3.1 load
2.3.1 負荷
The -load directive allows the client to make a quick decision about presenting the query to the current server. If the client determines that another server can better serve the query, then control may be transferred to the server with the lower load and better connection. This directive has no arguments.
クライアントは負荷指示で現在のサーバに質問を提示することに関する素早い決定をすることができます。クライアントが、別のサーバが質問に役立つことができるほうがよいと決心しているなら、下側の負荷と、より良い接続と共にコントロールをサーバに移すかもしれません。 この指示には、議論が全くありません。
2.3.2 limit
2.3.2 限界
The -limit directive will allow the client to request the server allocate enough space to collect more responses than would currently be collected by the server.
限界指示で、クライアントは、サーバが現在サーバによって集められるだろうより多くの応答を集めることができるくらいのスペースを割り当てるよう要求できるでしょう。
Williamson & Kosters [Page 7] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[7ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
-limit<SP><value>
-限界<SP><値の>。
<Value>{%d} This required argument is the new limit requested by
the client. If the limit exceeds the limit set by
the server administrator, the client must receive an
error message. It is recommended that if the client
receives an error for exceeding the servers upper
limit, it should cut the request in half and resend
the request until an acceptable level has been
negotiated.
<はこれが必要とした>%dを評価します。クライアントによって要求されていて、議論は新しい限界です。 限界がサーバアドミニストレータで極限集合を超えているなら、クライアントはエラーメッセージを受け取らなければなりません。 クライアントがサーバ上限を超えるための誤りを受けるなら、半分に要求を切って、合格水準が交渉されるまでの要求を再送するのは、お勧めです。
Example of use:
使用に関する例:
-limit 2000
-2000を制限してください。
2.3.3 schema
2.3.3 図式
One of the shortcomings of X.500 was the requirement to know the schema of an object before making a query. RWhois allows the client to request the schema for an object without knowledge of the object by using the -schema directive.
X.500の短所の1つは質問をする前にオブジェクトの図式を知るという要件でした。 RWhoisは、クライアントにオブジェクトのためにオブジェクトに関する知識なしで図式指示を使用することによって、図式を要求させます。
Format for use:
使用のための形式:
-schema<SP>[object]
-図式<SP>。[オブジェクト]
[object]{%s} This optional argument identifies the objects for
which the schema is being requested. If this
argument is not sent, the schemas for all objects
contained in the server will be sent.
この任意の議論がオブジェクトを特定する図式がそうである要求されている[反対します]%s。 この議論を送らないと、サーバに含まれたすべてのオブジェクトのためのschemasを送るでしょう。
Example of use:
使用に関する例:
-schema domain
-図式ドメイン
2.3.4 xfer
2.3.4 xfer
The -xfer directive is used to transfer all data from a server. This method of transfer has no limit on the number of records that can be transferred to the client application. This directive is primarily used to transfer data contained in an authority area for caching at a secondary server.
-xfer指示は、サーバからすべてのデータを移すのに使用されます。転送のこのメソッドはクライアントアプリケーションに移すことができる記録の数に限界を全く持っていません。 この指示は、セカンダリサーバにおけるキャッシュのために権威領域に保管されていたデータを移すのに主として使用されます。
Format for use:
使用のための形式:
-xfer<SP>[object]<SP>[authority area]<SP>[SOA]
-xfer<SP>[オブジェクト]<SP>[権威領域]<SP>。[SOA]
Williamson & Kosters [Page 8] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[8ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
[Object]{All|%s} This required argument identifies the
object to transfer. If the keyword all
is sent, all objects contained in the
server will be transferred. Otherwise,
only the object specified will be sent.
[反対します] すべて| この必要な議論が移すためにオブジェクトを特定する%s。 キーワードであるなら、すべてを送って、サーバに含まれたすべてのオブジェクトを移すでしょう。 指定されたオブジェクトだけを送るでしょう。
[Authority area]{%s} This optional argument contains the
authority area of the object to send
further limiting the data transfer.
[権威領域] この任意の議論がさらに送るためにオブジェクトの権威領域を含むデータ転送を制限する%s。
[SOA]{%d} This optional argument notifies the server
to send everything that has been updated
since this SOA number.
このSOA番号以来この任意の議論がそれをすべてに送るようにサーバに通知する[SOA]%dをアップデートしています。
Example of use:
使用に関する例:
-xfer domain netsol.com -xfer domain netsol.com 19940818141259
-xferドメインnetsol.com -xferドメインnetsol.com19940818141259
2.3.5 quit
2.3.5 やめてください。
The -quit directive will inform the server that the client is finished. The server and client should close the connection. This directive has no arguments.
終わっていて、指示がクライアントがそうであるサーバを知らせる辞任。 サーバとクライアントは接続を終えるべきです。 この指示には、議論が全くありません。
2.3.6 status
2.3.6 状態
The -status directive is used to poll the server for its status. There are seven required responses to this directive. Additional attributes may be sent in the response. The client should ignore all unknown attributes. This directive has no arguments.
状態指示は、サーバに状態に投票するのに使用されます。 この指示への7つの必要な応答があります。 応答で追加属性を送るかもしれません。 クライアントはすべての未知の属性を無視するべきです。 この指示には、議論が全くありません。
2.3.7 cache
2.3.7 キャッシュ
The RWhois server can hold data that it has no authority over. If the server sends this data to a requester, it is considered a non- authoritative response. The holding of this data is called caching. The physical data for these objects is not contained on the system hosting the server. The -cache directive allows the client to instruct the server whether or not to send cached data. The RWhois client should start with the cache turned off. The server must start with the cache turned on in order to function like the RFC 954 [RFC- 954] whois server. Because of the server's default, the client should send the -cache off directive during initial session setup if cached data should not be sent. Details on expiration of cache data can be found in section 3.4.3, %soa response.
RWhoisサーバはそれが権威を全く持っていないデータを保持できます。サーバがこのデータをリクエスタに送るなら、それは非正式の応答であると考えられます。 このデータの把持はキャッシュと呼ばれます。 これらのオブジェクトのための物理的なデータは、サーバをホスティングしながら、システムの上に含まれていません。キャッシュ指示は、クライアントが、発信するのがデータをキャッシュしたようサーバに命令するのを許容します。 RWhoisクライアントはオフにされたキャッシュから始まるべきです。 サーバはRFC954[RFC954]whoisサーバのように機能するようにつけられたキャッシュから始まらなければなりません。サーバのデフォルトのために、キャッシュされたデータを送らないなら、クライアントは初期のセッションセットアップの間、指示からキャッシュを送るべきです。 セクション3.4.3でキャッシュデータの満了に関する詳細を見つけることができて、%はsoa応答です。
Williamson & Kosters [Page 9] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[9ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
-cache<SP><mode>
-キャッシュ<SP><モード>。
<mode>{on|off}
on: Turns caching on.
off: Turns caching off.
以下の|オフな<モード>。 キャッシュをつける、: キャッシュをオフにします。
Example of use: -cache on
使用に関する例: -キャッシュ、オン
2.3.8 holdconnect
2.3.8 holdconnect
The RWhois server must close the connection after the response to a query has been received. The query is the final exchange between the client and server. However, this characteristic can be modified with the -holdconnect directive. If this directive is issued to the RWhois sever, it will remain connected until the -quit directive is received. Once the -quit directive is received, both the server and the client must close their connection.
質問への応答を受けた後にRWhoisサーバは接続を終えなければなりません。 質問はクライアントとサーバの間の最終的な交換です。しかしながら、-holdconnect指示でこの特性は変更できます。 この指示がRWhoisに発行されるなら、切れてください、そして、それは辞任まで接続されるのを残るでしょう。受けられた指示。 一度、やめられて、指示が受け取られている、サーバとクライアントの両方が彼らの接続を終えなければなりません。
Format for use:
使用のための形式:
-holdconnect<SP><mode>
-holdconnect<SP><モード>。
<mode>{on|off}
On: Turns holdconnect on.
Off: Turns holdconnect off.
以下の|オフな<モード>。 holdconnectをつけます。 オフ: holdconnectをオフにします。
Example of use:
使用に関する例:
-holdconnect on
-holdconnectにオンです。
2.3.9 forward
2.3.9 前方
During normal sever operation the server will send %referral or see-also responses to the client, expecting the client to redirect the query to the server identified in the response. If the client is located behind a firewall or is poorly connected, having a server make the query may improve query performance or allow a query to be satisfied. The -forward directive will instruct the server to operate as a forwarding server. Whether or not this directive should be allowed should be a configuration parameter of the server.
標準の間、サーバが%紹介を送る操作を断ち切るか、または-また、クライアントへの応答を見てください、クライアントが応答で特定されたサーバに質問を向け直すと予想して。 クライアントがファイアウォールの後ろに位置しているか、または不十分に接されるなら、サーバに質問をさせるのが、質問性能を向上させるか、または質問が満たされるのを許容するかもしれません。 前進の指示は、推進サーバとして作動するようサーバに命令するでしょう。この指示が許容されるべきであるかどうかが、サーバに関する設定パラメータであるべきです。
Williamson & Kosters [Page 10] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[10ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
-forward<SP><mode>
-前進の<SP><モード>。
<mode>{on|off}
On: Turns forwarding on.
Off: Turns forwarding off.
以下の|オフな<モード>。 推進をつけます。 オフ: 推進をオフにします。
Example of use:
使用に関する例:
-forward on
-転送
2.3.10 soa
2.3.10 soa
The identification of authority area is an important part of the RWhois design. The -soa directive is used to question the server's authority for a specific area. A positive response will include the administrative parameters for the authority area as detailed in section 3.4.3. If the server does not contain an SOA for the authority area requested, it must send an error message to the client.
権威領域の識別はRWhoisデザインの重要な部分です。 -soa指示は、特定の領域にサーバの権威に質問するのに使用されます。 積極的な応答はセクション3.4.3で詳しく述べられるように権威領域のための管理パラメタを含むでしょう。 サーバが領域が要求した権威のためのSOAを含んでいないなら、それはエラーメッセージをクライアントに送らなければなりません。
Format for use:
使用のための形式:
-soa<SP>[authority area]
-soa<SP>。[権威領域]
[Authority area]{%s} This optional argument identifies the
authority area being requested. If this
argument is not sent, information about
all authority areas contained in the
server must be sent.
この任意の議論が特定する[権威領域]%s、要求されている権威領域。 この議論を送らないなら、サーバに含まれたすべての権威領域の情報を送らなければなりません。
Example of use:
使用に関する例:
-soa netsol.com
-soa netsol.com
2.3.11 notify
2.3.11 通知してください。
The -notify directive is used to notify a server of a bad or recursive referral or a change in a primary server's data.
使用される指示がa悪いか再帰的な紹介のサーバかプライマリサーバのデータにおける変化に通知するように通知してください。
Format for use:
使用のための形式:
-notify<SP><action><SP><information>
-<SP><動作><SP><情報>に通知してください。
<action>{badref|recurref|update|inssec|delsec}
<動作>。badref|recurref|アップデート|inssec|delsec
Williamson & Kosters [Page 11] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[11ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
badref When a client receives a %referral response that does
not work, it must report the bad referral to the server
that issued the referral. The referral is bad only if
the referred server does not contain the SOA record for
the authority area in question. It is not considered a
bad referral if the server does not have an answer to
the query, but responds positively to the -soa area
directive. This merely means that there is not an
answer to the query. When a -badref is sent to the
referring server; it should log the bad referral so the
administrator of that server can remove the reference
if it is no longer correct. This action should only be
taken after receiving a negative response to the query
and the SOA request.
badref When aクライアントは働いていない紹介応答を何%も受けて、それは紹介を発行したサーバに悪い紹介を報告しなければなりません。 参照されたサーバが問題の権威領域のためのSOA記録を含んでいない場合にだけ、紹介は悪いです。 それは、サーバに質問の答えがないなら悪い紹介であることは考えられませんが、-soa領域指示に積極的に対応しています。 これは、質問の答えがないことを単に意味します。 参照サーバに-badrefを送るとき。 それがもう正しくないならそのサーバの管理者が参照を取り除くことができるように、それは悪い紹介を登録するべきです。 この動作は、質問とSOA要求に否定応答を受けながら、似られているだけであるべきです。
recurref When a client receives a referral that results in a
recursive action, the referring server must be
informed. The -recurref directive must be sent
identifying the recursive loop. This directive should
only be sent to the server one level back, even if
multiple server were involved in the referral.
recurref When aクライアントは再帰的な動作をもたらす紹介を受けて、参照サーバは知識があるに違いありません。 -recurref指示に再帰的な輪を特定させなければなりません。 サーバ1レベルにこの指示を送り返すだけであるべきです、複数のサーバが紹介にかかわったとしても。
update An RWhois primary server must be aware of its
secondary servers. If the data in the primary server
changes, the primary server may choose to notify the
secondary servers. This allows the secondary servers
to quickly reflect changes in the primary server's data.
アップデートAn RWhoisプライマリのサーバはセカンダリサーバを意識しているに違いありません。 プライマリサーバのデータが変化するなら、プライマリサーバは、セカンダリサーバに通知するのを選ぶかもしれません。 これで、セカンダリサーバはすぐにプライマリサーバのデータにおける変化を反映できます。
inssec This action will inform the authority server that the
server indicated in the argument will be a secondary
for its authority area. The server receiving this
directive must determine if the secondary is
acceptable. If it is, the server should be added to
the update list so that it will be informed if data in
the authority area changes.
inssec This動作は、議論で示されたサーバが権威領域への2番目になることを権威サーバに知らせるでしょう。 この指示を受けるサーバは、セカンダリが許容できるかどうか決定しなければなりません。 それがそうなら、サーバは、権威領域のデータが変化するなら知識があるようになるように、アップデートリストに追加されるべきです。
delsec This action will inform the server that the server
indicated in the subsequent arguments will no longer be
a secondary. The server receiving this action must
determine if the server is a secondary and if so,
remove it from the update list.
delsec This動作は、その後の議論で示されたサーバがもう2番目にならないことをサーバに知らせるでしょう。 この動作を受けるサーバは、サーバが2番目であるかどうか決定しなければなりません、そして、そうだとすれば、アップデートリストからそれを取り除いてください。
<information>{action=badref|recurref <<server>:<query>>
action=inssec|delsec|update
<<server>:<object>:<authority>>}
<情報>。動作はbadrefと等しいです| recurref<<サーバ>: <質問>>動作はinssec|delsec|アップデート<<サーバ>: <オブジェクト>: <権威>>と等しいです。
Williamson & Kosters [Page 12] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[12ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
<server>{%Mserver} This required argument identifies the server
that contained the recursive or bad referral,
or has data that changed.
この必要な議論の<サーバ>%Mserverは再帰的であるか悪い紹介を含んでいるか、または変化したデータを持っているサーバを特定します。
<query>{%s} This required argument identifies the query
that was sent to the server that gave a
recursive or bad referral.
<はこれが必要とした>%sについて質問します。議論は再帰的であるか悪い紹介を与えたサーバに送られた質問を特定します。
<object>{%s} This required argument identifies the object
that changed.
この必要な議論が特定する<オブジェクト>%s、変化したオブジェクト。
<authority>{%s} This required argument identifies the
authority area where the object that changed
currently resides.
<権威>%s、この必要な議論は現在変化したオブジェクトが住んでいる権威領域を特定します。
Example of use:
使用に関する例:
-notify recurref netman1.netsol.com:4343:scottw@netsol.com -notify badref nic.ddn.mil:43:abc.af.mil -notify update netman1.netsol.com:4343:domain:netsol.com -notify inssec dmeister.internic.net:4343:domain:netsol.com -notify delsec dmeister.internic.net:4343:domain:netsol.com
-recurref netman1.netsol.comに通知してください: : scottw@netsol.com が通知するようにbadref nic.ddn.mil:43:abc.af.milに通知する4343はnetman1.netsol.com: : ドメイン: netsol.comがdelsec dmeister.internic.net: 4343:ドメイン:netsol.comに通知するようにinssec dmeister.internic.net: 4343:ドメイン:netsol.comに通知する4343をアップデートします。
2.3.12 register
2.3.12 レジスタ
This directive allows the client to add, modify, or delete information that exists or should exist in the server's database. During the exchange, all attributes of an object must be sent. The client must wait to send the registration data until the %ok response is received from the server.
この指示で、クライアントは、存在するべきであるか、またはサーバのデータベースに存在するべきである情報を、加えるか、変更するか、または削除します。 交換の間、オブジェクトのすべての属性を送らなければなりません。 クライアントは、間違いない応答が受けられる%までの登録データにサーバを送るのを待たなければなりません。
Format for use:
使用のための形式:
-register<SP><mode><SP>(on:<action><SP><e-mail contact>
<SP><authority info>)
-<SP><モード><SP>を登録してください。(: <動作><SP><メール連絡><SP><権威インフォメーション>の)
<mode>{on|off}
on: This required argument starts the
registration process.
以下の|オフな<モード>。 この必要な議論は登録手続を始めます。
off: This required argument ends the registration
process.
オフ: この必要な議論は登録手続を終わらせます。
The following arguments are only required if the mode argument is sent with the value on:
値と共に以下でモード議論を送る場合にだけ、以下の議論を必要とします。
(<action>){add|mod|del}
(<動作>){モッズ風で|加えてください| del}
Williamson & Kosters [Page 13] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[13ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
add: This conditionally required argument
indicates that the object being sent should
be added to the server's database.
加えます: この条件付きに必要な議論は、送られるオブジェクトがサーバのデータベースに追加されるべきであるのを示します。
mod: This conditionally required argument
indicates that the object being sent should
be modified and should already exist in the
server's database.
モッズ: この条件付きに必要な議論は送られるオブジェクトが変更されるべきであり、サーバのデータベースに既に存在するはずであるのを示します。
del: This conditionally required argument
indicates that the object being sent should
be deleted from the server's database.
del: この条件付きに必要な議論は、送られるオブジェクトがサーバのデータベースから削除されるべきであるのを示します。
(<e-mail contact>){%Memail} This conditionally required
argument identifies the sender of
the registration information.
(<メール接触>) この条件付きに必要な議論の%Memailはレジスト情報の送付者を特定します。
(<authority info>){%s} This required argument contains
information used to authenticate
the person sending the registration
information. The method used must
be identified using the -private
directive. Work must be done to
identify usable authentication
methods for unsupervised
delegation. This is beyond the
scope of this document. However,
the authors have made an effort to
allow flexibility in the
implementation of an authentication
system.
(<権威インフォメーション>) この必要な議論が使用される情報を含む%sはレジスト情報を送る人を認証します。 個人的な指示を使用することで使用されるメソッドを特定しなければなりません。 監督を受けない委譲のために使用可能な認証方法を特定するために仕事をしなければなりません。 これはこのドキュメントの範囲を超えています。 しかしながら、作者は、認証システムの実装における柔軟性を許容するために取り組みを作りました。
Example of use:
使用に関する例:
-register on add scottw@netsol.com Object-type:referral Referral:netman1.netsol.com:4343 Domain-Name:netsol.com IP-Network:192.153.247.0 IP-Network:198.41.0.0 -register off
-レジスタ、 scottw@netsol.com Object-タイプは加えます: netman1.netsol.com: 紹介Referral:4343は: netsol.com IP-ネットワーク: 192.153に.247.0IP-ネットワーク: 198.41を.0が下に登録する.0とDomain命名します。
2.3.13 object
2.3.13 オブジェクト
RWhois data is a collection of objects with defined attributes. The attributes for an object can be acquired by issuing the -schema directive. Each object must at a minimum define the attribute object-type. This attribute identifies the name of the object that
RWhoisデータは定義された属性があるオブジェクトの収集です。 図式指示を発行することによって、オブジェクトのための属性を取得できます。 各オブジェクトは最小限で属性オブジェクト・タイプを定義しなければなりません。 この属性がオブジェクトの名前を特定する、それ
Williamson & Kosters [Page 14] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[14ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
will be displayed in response to the -object directive. This directive can be used by a client to verify that a server contains the desired object. Another possible use may be to gather all of the objects contained on a server and display them to the user in the form of a menu for selection.
オブジェクト指示に対応して、表示するでしょう。 クライアントは、サーバが必要なオブジェクトを含むことを確かめるのにこの指示を使用できます。 別の活用可能性はオブジェクトのすべてが選択のためのメニューの形にサーバとディスプレイにユーザにそれらを含んだと推測することであるかもしれません。
Format for use:
使用のための形式:
-object<SP>[object]
-オブジェクト<SP>。[オブジェクト]
[object]{%s} This optional argument identifies the object
requested. If no argument is sent, all objects
contained in the server will be returned.
この任意の議論が特定する[オブジェクト]%s、要求されたオブジェクト。 議論を全く送らないと、サーバに含まれたすべてのオブジェクトを返すでしょう。
Example of use:
使用に関する例:
-object domain
-オブジェクトドメイン
2.3.14 define
2.3.14、定義
Format strings describing the format of an object's attribute may include format macros. More information about definitions of format macros can be found in Section 6. The -define directive allows the client to request the definition of a format macro.
オブジェクトの属性の形式について説明する書式の記号列は形式マクロを含むかもしれません。 セクション6で形式マクロの定義に関する詳しい情報を見つけることができます。 指示を定義してください。クライアントが形式マクロの定義を要求するのを許容します。
Format for use:
使用のための形式:
-define<SP>[macro name]
-<SP>を定義してください。[マクロ名]
[macro name]{%s} This optional argument identifies the name of
the macro to display. If no arguments are
sent, the server must return the definition
of all macros contained in the server.
この任意の議論が表示するためにマクロの名前を特定する[マクロ名]%s。 議論を全く送らないなら、サーバはサーバに含まれたすべてのマクロの定義を返さなければなりません。
Example of use:
使用に関する例:
-define server
-サーバを定義してください。
2.3.15 private
2.3.15 個人的です。
The -private directive allows the client to identify the authentication method to be used. More research needs to be done with respect to client authentication. This directive will allow more experimentation.
個人的な指示で、クライアントは使用されるべき認証方法を特定できます。 より多くの研究が、クライアント認証に関してする必要があります。 この指示は、より多くの実験を許すでしょう。
Williamson & Kosters [Page 15] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[15ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
-private<SP><action><SP><method><SP>[data]
-個人的な<の><SP><SP><動作メソッド><SP>。[データ]
<action>{auth|encr} This required argument identifies the action
the directive is taking. Currently the value
for this argument can be auth for
authentication or encr for encryption.
<動作>はencrに|authして、この必要な議論は指示が取っている行動を特定します。 この議論のための現在の、値は、認証のためのauthか暗号化のためのencrであるかもしれません。
<method>{%s} This required argument contains the name of
the method to be used. The value must be
recognized by the server or an error will be
sent. It is beyond the scope of this
document to identify the possible method to
be used.
使用されて、この必要な議論がメソッドの名前を含む<メソッド>%s。 サーバで値を認識しなければならない、さもなければ、誤りを送るでしょう。 それは、使用されるべき可能なメソッドを特定するためにこのドキュメントの範囲を超えています。
[data]{%s} This optional argument must be supplied if
required by the method identified in the
previous argument.
必要なら前の議論で特定されたメソッドでこの任意の議論を供給しなければならない[データ]%s。
Example of use:
使用に関する例:
-private auth pass1 xxjdk998uu
-個人的なauth pass1 xxjdk998uu
The above example is a simple password exchange. It is beyond the scope of this document to determine the authentication technique that would best suit this protocol. Development is underway to determine the authentication needs and to experiment with potential solutions.
上記の例は簡単なパスワード交換です。 それは、このプロトコルに最もよく合う認証のテクニックを決定するためにこのドキュメントの範囲を超えています。 開発は、認証の必要性を決定して、潜在的ソリューションを実験するために進行中です。
2.3.16 X-
2.3.16 X
This directive is the preface to extended directives, mutually agreed to between the client and server. The client and server must have knowledge of the extended directives to use. Extension can accommodate other uses such as NetHelp, white pages, and many others. If the extensions are public, they should be documented in an RFC and available through the -directive directive.
この指示は拡張指示への序文です、クライアントとサーバの間に相談ずくです。クライアントとサーバには、使用する拡張指示に関する知識がなければなりません。 拡大はNetHelpや、ホワイトページや、多くの他のものなどの他の用途に対応できます。 拡大が公共であるなら、それらは、指示指示でRFCに記録されていて利用可能であるべきです。
Williamson & Kosters [Page 16] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[16ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
-X-<directive name><SP>[directive arguments]
-X-<指示、<SP>と>を命名してください。[指示の議論]
<directive name>{%s} This required argument identifies the
name of the directive being issued.
<指示はこの必要な議論が名前を特定する>%sを発行される指示と命名します。
[directive arguments]{?} This optional argument is dependent upon
the required or optional arguments of
the extended directive. There may be
multiple directive arguments.
[指示の議論] この任意の議論は拡張指示の必要であるか任意の議論に依存しています。 複数の指示の議論があるかもしれません。
Example of use:
使用に関する例:
-X-date
-X-日付
2.3.17 directive
2.3.17 指示
Directives allowed by a server may vary. The client can issue the -directive directive to determine if the server allows a specific directive or to obtain a list of all acceptable directives for that server.
サーバによって許容された指示は異なるかもしれません。 クライアントは、サーバが特定の指示を許容するかどうか決定するか、またはそのサーバのためのすべての許容できる指示のリストを得るために指示指示を発行できます。
Format for use:
使用のための形式:
-directive<SP>[directive]
-指示の<SP>。[指示]
[directive][%s] This optional argument identifies the directive
being requested. If no arguments are sent, all
of the directives accepted by the server must
be sent.
[指示の] [%s] この任意の議論は要求されている指示を特定します。 議論を全く送らないなら、サーバによって受け入れられた指示のすべてを送らなければなりません。
Example of use:
使用に関する例:
-directive X-date
-指示のX-期日
2.3.18 display
2.3.18 ディスプレイ
The -display directive is used to set the display mode of the server or to identify display modes the client is capable of. If this directive is sent without arguments, the server will return all available display methods.
ディスプレイ指示は、サーバの表示モードを設定するか、またはクライアントができる表示モードを特定するのに使用されます。 議論なしでこの指示を送ると、サーバはすべての利用可能なディスプレイメソッドを返すでしょう。
Williamson & Kosters [Page 17] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[17ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
-display<SP>[action]<SP>[method]
-ディスプレイ<SP>[動作]<SP>。[メソッド]
[action]{activate|capable}
The `activate' setting enables a certain
display mode, while a `capable' setting sends
the display mode the client is capable of.
[動作]、動かします|、できる、'動かし'設定はaある表示モードを可能にします、'できる'設定がクライアントができる表示モードを送りますが。
[method]{%s} This optional argument indicates the display
method desired by the client.
この任意の議論が、ディスプレイメソッドがクライアントで望んでいたのを示す[メソッド]%s。
Example of use:
使用に関する例:
-display swip -display mime
-ディスプレイswipディスプレイパントマイム
2.3.19 language
2.3.19 言語
The -language directive is used to set the language mode of the server or to identify language modes the client is capable of. If this directive is sent without arguments, the server will return all available languages.
言語指示は、サーバの言語モードを設定するか、またはクライアントができる言語モードを特定するのに使用されます。 議論なしでこの指示を送ると、サーバはすべての利用可能な言語を返すでしょう。
Format for use:
使用のための形式:
-language<SP>[language]
-言語<SP>。[言語]
[language]{%s} This optional argument indicates the language
desired by the client.
この任意の議論が、言語がクライアントで望んでいたのを示す[言語]%s。
Example of use:
使用に関する例:
-language german
-言語ドイツ語
2.4 RWhois Client Model
2.4 RWhoisクライアントモデル
Server <-------> Client
サーバ<。------->クライアント
START:
<------ Connection (record time to connect)
If no server type...Wait up to specified
time for------> "%RWhois" response
(recommend wait of at least 5 seconds)
以下を始めてください。 <、-、-、-、-、-- 接続(接続する記録的な時間)はサーバでないならタイプします…指定された時間まで待っています。------">"%RWhois、」 応答(少なくとも5秒の待ちを推薦します)
if "%RWhois" is not received from server, assume that it is
not an RWhois server
goto QUERY:
「」 %RWhoisです」、サーバから受け取られていないで、それがRWhoisサーバgoto QUERYでないと仮定してください:
Williamson & Kosters [Page 18] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[18ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
else if "%RWhois" is received from server
<------- send "-RWhois -VX.X"
--------> receive "%ok"
DIRECTIVE: if directive for server
<------- send directive
-------> receive server response
if "%ok" received
goto DIRECTIVE:
if "%error" received
process error then goto DIRECTIVE:
else if no more commands for server
goto QUERY:
QUERY:
<-------- send query
--------> Receive and display response
PROCESS: if "%referral" received
if first referral
restart server list
else
add to server list
if "%see-also" received
insert server into server list
if in holdconnection mode
goto DIRECTIVE:
if no directive (%)
goto END:
goto PROCESS:
END:
server will disconnect
if more servers on Queue and multi or referral mode active
goto START:
「ほか、」 %RWhoisである、」、サーバ<から、受け取ります。------- "-RWhois -VX.X"を送ってください。--------」 「>は受信する」%OK DIRECTIVE: サーバ<における指示------- 指示を送ってください。-------「>は」 %であるならOKにサーバ応答を受けること」の容認されたgoto DIRECTIVE: 次に、「」 %誤りであるなら」容認されたプロセス誤りgoto DIRECTIVE: ほかに、いいえなら、以上はサーバgoto QUERYのために命令します: 以下について質問してください。 <、-、-、-、-、-、-、-- 質問を送ってください。-------->は応答PROCESSを受けて、表示します: holdconnectionモードgoto DIRECTIVEで「」 %紹介です」なら、最初の紹介再開サーバがほかに記載するなら受け取って、-また、」 %が」 容認された差し込みサーバをサーバリストの中に見るなら、サーバリストに加えてください: 指示の(%)がないgoto ENDであるなら: goto PROCESS: 以下を終わらせてください。 サーバはQueueとマルチ、に関する、より多くのサーバか紹介モードのアクティブなgoto STARTであるなら切断するでしょう:
Every time the RWhois client receives a %referral or %see-also response from the RWhois server it must compare the host:port:query with those already executed. If the client discovers that it is being directed to repeat the same query to a server that it has already visited, it must not repeat that query. As an example, the prototype RWhois client maintains a server trail and compares each new directive with the entire list. If a recursive act is about to occur, the client will notify the user and exit. The original Whois client opens a TCP connection, sends the query, and displays the response. The RWhois client must be more robust in order to handle multiple server queries, servers that do not exist, and recursive referrals. The client must also remain connected while sending directives and receiving responses. All of these features have been incorporated into the experimental RWhois client.
RWhoisクライアントが%紹介を受けるか、または-また、%がRWhoisサーバから応答を見るときはいつも、ホストを比較しなければなりません: ポート: それらが既に実行されている質問。 クライアントが、それが既に訪問したサーバに同じ質問を繰り返すのが指示されていると発見するなら、それはその質問を繰り返してはいけません。 例として、プロトタイプRWhoisクライアントは、サーバ道を維持して、それぞれの新しい指示を全体のリストと比べます。 再帰的な行為が起ころうとしていると、クライアントはユーザと出口に通知するでしょう。 オリジナルのWhoisクライアントは、TCP接続を開いて、質問を送って、応答を表示します。 RWhoisクライアントは、複数のサーバ質問、存在しないサーバ、および再帰的な紹介を扱うために、より強健でなければなりません。 また、クライアントは指示を送って、応答を受けている間、接続されていたままで残らなければなりません。 これらの特徴のすべてを実験的なRWhoisクライアントに組み入れてあります。
Williamson & Kosters [Page 19] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[19ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
3. RWhois Server Model
3. RWhoisサーバモデル
This section describes the functionality of the RWhois server.
このセクションはRWhoisサーバの機能性について説明します。
3.1 Output Display and Restriction Keywords
3.1 出力ディスプレイと制限キーワード
The RWhois server will behave similarly to the original whois server in terms of display formats and restrictions. The following are required in the RWhois server.
RWhoisサーバはシステム出力表示形式と制限で同様にオリジナルのwhoisサーバに振る舞うでしょう。 以下がRWhoisサーバで必要です。
Display Format Keywords
システム出力表示形式キーワード
EXPand (*) Expand
広げる、広がります(*)。
~ no sub displays
~潜水艦は全く表示しません。
SUBdisplay (%) sub displays
SUBdisplay(%)潜水艦ディスプレイ
SUMmary ($) Give a short summary for the query on one to
many hits (defaults on multiple hits).
SUMmary($)は多くのヒット(複数のヒットを怠る)に1における質問のための要約をします。
Full (=) Give the full record output on one to many
hits (defaults on one hit only).
完全な(=)は1で多くのヒット(1つのヒットだけを怠る)に出力された完全な記録を与えます。
The following was added to whois post RFC 954 [RFC-954] and is part of the RWhois requirements:
↓これは、whoisポストRFC954[RFC-954]に加えられて、RWhois要件の一部です:
dump (#) Display the record in a parsable format.
ダンプ(#)は「パー-可能」形式で記録を表示します。
In addition to the above, the RWhois server must accept additional pre-query directives such as Boolean queries and attribute=value query combinations. The capability to perform partial matches are requested by post fixing a `*' or `.' at the end of the search item for unknown characters. This capability is required for an RWhois server.
上記に加えて、RWhoisサーバはブール質問や属性=値質問組み合わせなどの追加プレ質問指示を受け入れなければなりません。 '部分的なマッチを実行する能力は'*を修理する郵便によって要求されます。''.'未知のキャラクタのための検索項目の端で。 この能力がRWhoisサーバに必要です。
Example: last-name=williamson and first-name=scott
例: 姓はwilliamsonと名=scottと等しいです。
Data Restriction Format Keywords
データ制限形式キーワード
Williamson & Kosters [Page 20] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[20ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
The following restriction keywords are found in the RFC 954
[RFC-954] whois server:
以下の制限キーワードはRFC954[RFC-954]whoisサーバで見つけられます:
!(handle) Query on Handle only mailbox Query on all records for person person Query on User records only host Query on Host records only domain Query on Domain records only network Query on Network Records only asn Query on Autonomous System Numbers only
すべてのメールボックスだけQueryが人の人のQueryのためにHostの上のホストQueryだけがドメインだけQueryをDomainに記録するというUser記録に記録するHandleにおける(ハンドル)質問がネットワークQueryだけをNetwork Recordsだけに記録する、Autonomous System民数記だけのasn Query
The RWhois server must allow restriction of search to any object contained on that server. With the exception of the `!' restriction format keyword, the above listed restriction keywords represent defined objects. In the prototype software, each of these objects are defined in configuration files, not hard-coded into the server. New objects, and therefore restriction keywords, should be easily designed with no code change necessary to the server.
RWhoisサーバはそのサーバに含まれたどんなオブジェクトにも検索の制限を許さなければなりません。'!'制限形式キーワードを除いて、上記の記載された制限キーワードは定義されたオブジェクトを表します。 プロトタイプソフトウェアでは、それぞれのこれらのオブジェクトは一生懸命サーバにコード化されるのではなく、構成ファイルで定義されています。新しいオブジェクト、およびしたがって、制限キーワードはサーバに必要なコード変遷なしで容易に設計されるべきです。
3.2 Responses: Server to Client Interaction
3.2の応答: クライアントとの対話へのサーバ
Responses are sets of data that servers send in response to a client directive. Responses from an RWhois server must be prefaced with the `%' character at the start of a line. Responses are divided into two groups: those that are required to provide minimal RWhois interaction and those that are used to achieve the desired characteristics of a fully functional distributed system. A server must respond with an error message indicating that a directive is not available on the server and therefore does not have the required responses.
応答はサーバがクライアント指示に対応して送るデータのセットです。 系列の始めの'%'キャラクタと共にRWhoisサーバからの応答について前書きしなければなりません。 応答は2つのグループに分割されます: そうするそれらが最小量のRWhois相互作用と完全に機能的な分散システムの必要な特性を獲得するのに使用されるものを供給するのが必要です。 したがって、エラーメッセージが、指示がサーバで利用可能でなく、また必要な応答を持っていないのを示していて、サーバは反応しなければなりません。
Williamson & Kosters [Page 21] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[21ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
3.3 Required Responses
3.3 必要な応答
The following sections describe the required RWhois server responses.
以下のセクションは必要なRWhoisサーバ応答について説明します。
3.3.1 RWhois
3.3.1 RWhois
The %RWhois response is used to identify a server as an RWhois server. Clients that treat RWhois servers differently will need this response to enable the RWhois capabilities.
RWhois応答が使用されている%は、サーバがRWhoisサーバであると認識します。RWhoisサーバを異なって扱うクライアントは、RWhois能力を可能にするためにこの応答を必要とするでしょう。
Format for use:
使用のための形式:
RWhois<SP>V-<Spec version #><SP><server name><SP>[imp name and version #]
Specバージョン#><SP><サーバが><SP>と命名するRWhois<SP>V-<。[悪童名とバージョン#]
<Spec version #>[V-%2.2f] This required response indicates
the version number of the RWhois
protocol specification that the
software is capable of handling.
The version described in this
document is V-1.0.
<仕様バージョン# この必要な応答が、バージョンが付番するのを示すソフトウェアが扱うことができるRWhoisプロトコル仕様の>[V-%2.2f]。 本書では説明されたバージョンはV-1.0です。
<server name>[%s] This required response is the host
name of the computer hosting the
RWhois server.
<サーバはこれが必要とした[%s]と>を命名します。RWhoisサーバをホスティングしながら、応答はコンピュータのホスト名です。
[imp name and version #][%s] This optional argument contains
information about the server
implementation. It is recommended
that the version number of the
software be indicated. This
version may differ from the
specification version number.
[悪童名とバージョン#] [%s] この任意の議論はサーバ実装の情報を含んでいます。 ソフトウェアのバージョン番号が示されるのは、お勧めです。 このバージョンは仕様バージョン番号と異なるかもしれません。
Example of use:
使用に関する例:
%RWhois V-1.0 rs.internic.net (Network Solutions V-1.6)
%RWhois V-1.0 rs.internic.net(ネットワークソリューションV-1.6)
3.3.2 referral
3.3.2 紹介
The %referral response instructs the client to query another server (which could be a whois, RWhois, or whois++ server). Referrals are cumulative. The first referral received during a session must replace the default server list. Any subsequent referrals received must be appended to the end of the server list.
%紹介、応答、別のサーバ(+ + whois、RWhois、またはwhoisがサーバであるならそうすることができる)について質問するようクライアントに命令します。 紹介は累積しています。 セッションの間に受けられた最初の紹介は標準サーバーリストに取って代わらなければなりません。 サーバリストの終わりまでその後の紹介が受けたいずれも追加しなければなりません。
Williamson & Kosters [Page 22] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[22ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
In the non-Uniform Resource Location (URL) response format below, the authority area equals the reduced query. There are three types of referral. The type can be determined by the client evaluating the authority area which is part of the %referral response.
以下の非のユニフォームResource Location(URL)応答形式では、権威領域は減少している質問と等しいです。 紹介の3つのタイプがあります。 そうする権威領域を評価するのが離れているクライアントがタイプを決心できる、%紹介、応答
If the authority area received from a referral response is equal to the original query, then it is a link type referral. If the authority area is not equal to the query, then it is a reduction type referral. If no authority area is sent, then it is a punt type referral. (Punt means the server is not a root and cannot answer the query and therefore is referring the client to a level up the tree or to a server that can better answer the query.) [NOTE: the punt type referral may be used to direct a client into the whois++ mesh type.]
紹介応答から受け取られた権威領域がオリジナルの質問と等しいなら、それはリンク型紹介です。 権威領域が質問と等しくないなら、それは減少タイプ紹介です。 権威領域を全く送らないなら、それはパントタイプ紹介です。 (パントは、サーバが根でないことを意味して、質問に答えることができないで、したがって、木へのレベル、または、質問に答えることができるほうがよいサーバにクライアントを差し向けています。) [注意: パントタイプ紹介はwhois++メッシュタイプにクライアントを向けるのに使用されるかもしれません。]
The client may receive multiple referrals from a single query. If the SOA for each of these referrals is the same, then the first referral is the primary server and all subsequent servers are secondary. Each of the servers will report the SOA for the authority area in question.
クライアントはただ一つの質問から複数の紹介を受けるかもしれません。 それぞれのこれらの紹介のためのSOAが同じであるなら、最初の紹介はプライマリサーバです、そして、すべてのその後のサーバがセカンダリです。 それぞれのサーバは問題の権威領域にSOAを報告するでしょう。
Format for use:
使用のための形式:
%referral<SP><server>[:type]<SP>[authority area] %referral<SP>url:<url>
%紹介<SP><サーバ>[: タイプ]<SP>[権威領域]%紹介<SP>url: <url>。
<server>{%Mserver} This required argument identifies the
server that the client should re-connect
with.
この必要な議論の<サーバ>%Mserverはクライアントが再接続するべきであるサーバを特定します。
[type]{%Mstype} This optional argument identifies the
server type. This could save wait time for
the client trying to identify a server
which is non-RWhois.
[タイプします] この任意の議論の%Mstypeはサーバタイプを特定します。 これは非RWhoisであるサーバを特定しようとするクライアントのための待ち時間を保存するかもしれません。
<authority area>{%s} This optional argument identifies the
authority area that caused the referral for
the query in question. Using this value as
the argument for the -soa directive to
the referral server should result in a
positive response. If this is not the
case, the referral is considered bad.
この任意の議論が紹介を引き起こした権威領域を特定する<権威領域>%s、問題の質問。 -soa指示に議論として紹介サーバにこの値を使用すると、積極的な応答はもたらされるべきです。 これがそうでないなら、紹介は悪いと考えられます。
<url>{%Murl} This required argument defines the Uniform
Resource Location (URL) string that points
to the resource containing the information
desired.
この必要な議論の<url>%Murlは情報が望んでいたリソース含有を示すUniform Resource Location(URL)ストリングを定義します。
Williamson & Kosters [Page 23] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[23ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Example of use:
使用に関する例:
%referral nic.ddn.mil:43 .mil %referral url:http://www.netsol.com/
%紹介nic.ddn.mil: 43 紹介url: .mil% http://www.netsol.com/
3.3.3 ok
3.3.3 OK
The %ok response must be sent by the RWhois server at the completion of every task or to positively acknowledge a directive.
または、あらゆるタスクの完成のときにRWhoisサーバで間違いない応答を送らなければならない%、明確に指示を承諾するために。
Format for use:
使用のための形式:
%ok
%OK
3.3.4 error
3.3.4 誤り
The %error response is used to indicate an error condition to the client. Refer to Section 5 for details on the error reporting scheme. It is important to note that only the error number will be used to determine the client's action. The text message will only be used to make the error readable by humans connected using telnet or an old whois client. The only exception to this rule is the error message used to indicate problems with registration transactions. The format for these message can be found in Section 5.
誤り応答が使用されている%はエラー条件をクライアントに示します。 誤り報告体系に関する詳細についてセクション5を参照してください。 エラー番号だけがクライアントの動作を決定するのに使用されることに注意するのは重要です。 テキストメッセージは、telnetを使用することで接された人間か年取ったwhoisクライアントで誤りを読み込み可能にするのに使用されるだけでしょう。 この規則への唯一の例外が登録トランザクションに関する問題を示すのに使用されるエラーメッセージです。 セクション5でこれらのメッセージのための形式を見つけることができます。
Format for use:
使用のための形式:
%error<SP><error number><SP>[error text]
%誤り<SP><エラー番号><SP>。[誤りテキスト]
<error number>{%d} This required argument is the error number
identified in Section 5. The client can use
this number to categorize errors.
<誤りはこれが必要とした>%dに付番します。セクション5で特定されて、議論はエラー番号です。 クライアントは、誤りを分類するのにこの数を使用できます。
[error text]{%s} This optional argument is the text that
describes the error message. This message
must be consistent for each error. Variables
should not be added to this message. This
message is only to make the error message
human readable. Message sent following an
error code associated with the registration
process will contain the line number of the
attribute that is incorrect.
[誤りテキスト]%s、この任意の議論はエラーメッセージについて説明するテキストです。 各誤りにおいて、このメッセージは一貫しているに違いありません。 このメッセージに変数を追加するべきではありません。 このメッセージは単にエラーメッセージ人間を読み込み可能にすることです。 登録手続に関連しているエラーコードに従わされたメッセージが不正確な属性の行番号を含むでしょう。
Williamson & Kosters [Page 24] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[24ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Example of use:
使用に関する例:
%error<SP>400<SP>Invalid Server Directive
%誤り<SP>400の<のSPの>の無効のサーバ指示
3.4 Optional Responses
3.4 任意の応答
The following are optional RWhois server responses.
↓これは任意のRWhoisサーバ応答です。
3.4.1 see-also
3.4.1 参照
The %see-also response instructs the client to contact another server for additional information about the current query. See-also servers should be inserted into the server list just after the current server. If multiple see-alsos are received from a single query, each subsequent see-also should be inserted after any other see-alsos previously received. See-alsos should be additional information related to the current query.
-また、%は応答を見ます。現在の質問に関する追加情報のために別のサーバに連絡するようクライアントに命令します。 以前に、いかなる他の後にもalsosを見て挿入されるべきです。-また、サーバが現在のサーバのすぐ後にサーバリストの中に挿入されるべきであるのを確実にしてください、複数、alsosを見る、-また、見た状態でただ一つの質問によって受け取られていて、それぞれその後、受信しました。 alsosを見るのは、現在の質問に関連する追加情報であるべきです。
One example use for the see-also response is to display autonomous system information relating to an IP network number or router interface information relating to an IP host number.
-また、見ている応答の1つの例の使用はIPネットワーク・ナンバーに関連する自律システム情報かIPホスト番号に関連するルータインターフェース情報を表示することです。
Format for use:
使用のための形式:
%see-also<SP><server>[:type]:<query> %see-also<SP>url:<url>
-また、%は<SP><サーバ>[: タイプ]を見ます: -また、<質問>%は<SP>url: <url>を見ます。
<server>{%Mserver} This required argument identifies the server
the client should reconnect with.
この必要な議論の%Mserverがクライアントが再接続するべきであるサーバを同一視する<サーバ>。
[type]{%Mstype] This optional argument identifies the server
type. This could save wait time for the
client trying to identify a server which is
non-RWhois.
この任意の議論はサーバタイプを特定します。[タイプ]、%Mstype] これは非RWhoisであるサーバを特定しようとするクライアントのための待ち時間を保存するかもしれません。
<query>{%s} This required argument sets the query that
must be sent to the referred server. The
query may be different from the original
query sent to the referring server.
<はこれが必要とした>%sについて質問します。議論は参照されたサーバに送らなければならない質問を設定します。質問は参照サーバに送られたオリジナルの質問と異なっているかもしれません。
<url>{%Murl} This required argument defines the Uniform
Resource Location (URL) string that points to
the resource containing the information
desired.
この必要な議論の<url>%Murlは情報が望んでいたリソース含有を示すUniform Resource Location(URL)ストリングを定義します。
Williamson & Kosters [Page 25] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[25ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Example of use:
使用に関する例:
%see-also prmd.merit.edu:43:handle=xxx %see-also url:http://www.netsol.com/
-また、%は参照、url: prmd.merit.edu:43:ハンドル=xxx% http://www.netsol.com/ を見ます。
3.4.2 load
3.4.2 負荷
The %load response returns the current and average load of the computer hosting the RWhois server. We realize that the measurement may be different depending on the implication of the system's load mechanism. This directive/response was implemented to allow experiments with sorting preferred servers to deliver better results to the user.
%は電流と平均がロードするRWhoisサーバをホスティングするコンピュータの応答復帰をロードします。私たちは、システムの負荷メカニズムの含意によって、測定が異なるかもしれないとわかります。 この指示/応答は、常用サーバーを分類する実験が、より良い結果をユーザに提供するのを許容するために実装されました。
Format for use:
使用のための形式:
%load <SP><current><SP><average>
%は現在の<の<SP><平均したSP><>>を積み込みます。
<current>{%2.2f} This required argument delivers the current
load on the system hosting the RWhois server.
この必要な議論の<の現在の>%2.2fは、RWhoisサーバをホスティングしながら、システムの上で現在の負荷を提供します。
<average>{%2.2f} This required argument delivers the average
load on the system hosting the RWhois server.
この必要な議論の<の平均した>%2.2fは、RWhoisサーバをホスティングしながら、システムの上で平均荷重を提供します。
Example of use:
使用に関する例:
%load 5.68 1.32
%は5.68 1.32をロードします。
3.4.3 soa
3.4.3 soa
The %soa response delivers information about the authority area in question. If the server does not contain the authority for the area in question, it must respond with the appropriate error message. The SOA data must never be cached. SOA records must originate on the server giving the answer. The increment and refresh attributes are used to provide for incremental updates of the secondary server. Deleted data will remain in the secondary server's cache until the refresh time has been reached. This will reduce the amount of data transferred and not require the primary server to retain deleted data. The following are the minimum attributes required for the soa object:
soa応答が問題の権威領域の情報を提供する%。 サーバが問題の領域への権威を含んでいないなら、それは適切なエラーメッセージで応じなければなりません。 SOAデータを決してキャッシュしてはいけません。 SOA記録は、答えを与えながら、サーバで起因しなければなりません。 時間をリフレッシュしてください。増分. 削除されたデータがセカンダリサーバのキャッシュに残っているセカンダリサーバのアップデート増加に備えるために使用される属性をリフレッシュする、達しました。 これは、移されたデータ量を減少させて、削除されたデータを保有するためにプライマリサーバを必要としないでしょう。 ↓これはsoaオブジェクトに必要である最小の属性です:
object-type
authority
ttl
serial
refresh
increment
オブジェクト・タイプ権威ttlシリーズは増分をリフレッシュします。
Williamson & Kosters [Page 26] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[26ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
retry
tech-contact
admin-contact
hostmaster
primary
再試行科学技術の連絡アドミン連絡hostmaster予備選挙
Format for use:
使用のための形式:
%soa<SP>authority:<SP><authority area> %soa<SP>ttl:<SP><ttl> %soa<SP>serial:<SP><serial> %soa<SP>refresh:<SP><refresh> %soa<SP>increment:<SP><incremental> %soa<SP>retry:<SP><retry> %soa<SP>tech-contact:<SP><tech-contact> %soa<SP>admin-contact:<SP><admin-contact> %soa<SP>hostmaster:<SP><hostmaster> %soa<SP>primary:<SP><primary>
soa<SP>シリーズ: 連続の>%soa<SP>がリフレッシュする<SP><: %soa<SP>権威: <SP><権威領域>%soa<SP>ttl: <SP><ttl>%<SP><は%soa<SP>が増加する>をリフレッシュします: <SP><増加の>%soa<SP @は再試行されます?br />権威が命名するSOAの<権威領域>%s。 (例: internic.netか198.41、.0、.0/24)
<authority area>{%s} The authority name of the SOA. (Example:
internic.net or 198.41.0.0/24)
別のサーバがデータのためにこの権威地域の中にそれを生きるためにキャッシュされるとき、<は>%dをttlします。 データをキャッシュするサーバはこの属性によって特定された秒数のためのストレージの後に吐き出されたデータを考えるべきです。
<ttl>{%d} The time to live for data within this
authority area that another server may cache.
The server caching the data should consider
the data expired after storage for the number
of seconds identified by this attribute.
<の連続の>、データの通し番号が権威領域に保管していた%Mserial。 権威領域のデータが変化したときはいつも、通し番号を増加しなければなりません。 それは数値であるに違いありません。
<serial>{%Mserial} Serial number of the data contained in the
authority area. The serial number must be
incremented every time data in the authority
area has changed. It must be numeric.
<は完全に取り外すのがデータをキャッシュしたとき>%dをリフレッシュして、プライマリサーバからすべてのデータを移します。
<refresh>{%d} The time to completely remove cached data and
transfer all data from the primary server.
アップデート増加がないかどうかプライマリサーバからチェックする前の待ちへの時間の<増分の>%d。
<increment>{%d} The time to wait before checking for
incremental updates from a primary server.
使われなくなっているように見えるサーバに接続を再試行する前の待ちへの時間の<再試行>%d。
<retry>{%d} The time to wait before retrying connection
to a server that appears to be out-of-service.
<はサーバの操作に責任があった状態で人か役割のEメールアドレスが説明する>%Memailに技術者と同じくらい連絡します。
<tech-contact>{%Memail} E-mail address of the person or role
account responsible for the operation of
the server.
Williamson & Kosters [Page 27] RFC 1714 Referral Whois Protocol (RWhois) November 1994
<admin-contact>{%Memail} E-mail address of the person or role
account responsible for the data
contained on the server.
<hostmaster>%Memail、サーバのデータのどの変化にEメールアドレスを送るべきであるか。 データ編集ツールは、メールでサーバに関するデータをアップデートするために自動的に変化を送ることができます。
<hostmaster>{%Memail} E-mail address to which changes of the
server's data should be sent. A data
edit tool can automatically send changes
to update the data on the server via e-mail.
権威領域への<のプライマリ>%Mpermプライマリのサーバ。
<primary>{%Mperm} Primary server for authority area.
使用に関する例:
Example of use:
%は権威をsoaします: netsol.com%soa ttl: 7200%のsoaシリーズ: 19940606203030 %soaはリフレッシュします: 7200%のsoa増分: 60%のsoa再試行: 1200%のsoaの科学技術の接触: markk@netsol.com %soaは以下にアドミンで連絡します。 stanb@netsol.com %soa hostmaster: hostmaster@netsol.com %は予備選挙をsoaします: netman1.netsol.com: 4343%のOK
%soa authority: netsol.com %soa ttl: 7200 %soa serial: 19940606203030 %soa refresh: 7200 %soa increment: 60 %soa retry: 1200 %soa tech-contact: markk@netsol.com %soa admin-contact: stanb@netsol.com %soa hostmaster: hostmaster@netsol.com %soa primary: netman1.netsol.com:4343 %ok
3.4.4 状態
3.4.4 status
状態応答が数個の重要な旗か値の状態を返す%。 応答は以下の要素を含まなければなりません。
The %status response returns the status of several important flags or values. The response must contain the following elements.
以下を制限してください。 現在の限界はサーバにセットしました。限界指示を使用することでこの値を変えるかもしれません。 これはサーバの最大の限界ではありません。この値はクライアントが自動的に可能な最も高い限界を設定するのを防ぐために明らかにされません、サーバの性能における退行を引き起こして。
Limit: Current limit set on the server. This value may
be changed using the -limit directive. This is
not the maximum limit of the server. This value
is not disclosed to prevent clients from
automatically setting the highest limit possible,
causing degradation in performance of the server.
以下をロードしてください。 これはホストシステムの現在の負荷です。
Load: This is the current load of the host system.
以下をキャッシュしてください。 キャッシュ旗の現在の状態。 (オンかオフに)
Cache: Current status of the cache flag. (on or off)
Holdconnect: holdconnect旗の現在の状態。 (オンかオフに)
Holdconnect: Current status of the holdconnect flag. (on or
off)
以下を進めてください。 前進の旗の現在の状態。 (オンかオフに)
Forward: Current status of the forward flag. (on or off)
権威記録: サーバのデータベースの権威記録の数。
Authority records: Number of authority records in server's
database.
Williamson & Kosters [Page 28] RFC 1714 Referral Whois Protocol (RWhois) November 1994
Cached records: Number of records in the server's cache
database.
ディスプレイ: サーバが使用している表示モードのタイプを示します。
Display: Indicates the types of display modes the
server is using.
使用のための形式:
Format for use:
状態<SP>限界: <><現在の限界>SP%状態<SP>がロードする%: 現在の負荷>%状態<SP>がキャッシュする<SP><: <SP><キャッシュ>%状態<SP>holdconnect: <SP><holdconnect>%状態<SP>は以下を進めます; <SP><前進の>%状態<SP>Authority: 状態<SP>Cached: <SP><SOA数の>%<SP><は状態<SP>Display<SP><モード>: 数の>%<SP><タイプ>をキャッシュしました。
%status<SP>limit:<SP><current limit> %status<SP>load:<SP><current load> %status<SP>cache:<SP><cache> %status<SP>holdconnect:<SP><holdconnect> %status<SP>forward:<SP><forward> %status<SP>Authority:<SP><SOA number> %status<SP>Cached:<SP><cached number> %status<SP>Display<SP><mode>:<SP><type>
これらの値の記述に関して上を見てください。
See above for the description of these values.
<がキャッシュする<現在の限界>%dの<の現在の負荷>%2.2f、|オフな>、|オフな<holdconnect>、|オフな<前進の>、<がキャッシュした<SOA数の>%dがシングル| マルチ<がタイプする>%d<モード>に付番する、>。%s
<current limit>{%d}
<current load>{%2.2f}
<cache>{on|off}
<holdconnect>{on|off}
<forward>{on|off}
<SOA number>{%d}
<cached number>{%d}
<mode>{single|multi}
<type>{%s}
使用に関する例: %状態は以下を制限します。 1500%の状態負荷: 1.23%の状態キャッシュ: %状態holdconnectで: %状態では、以下を進めてください。 オフ%状態Authority: 25%の状態Cached: 200%の状態ディスプレイマルチ: 概要
Example of use: %status limit: 1500 %status load: 1.23 %status cache: off %status holdconnect: on %status forward: off %status Authority:25 %status Cached:200 %status display multi: summary
3.4.5 xfer
3.4.5 xfer
xfer応答がオブジェクトのすべてのインスタンスを送る%。 これは-xfer指示に対応しています。 転送は議論で指示に制限されるかもしれません。 議論が全くなければ、サーバはデータベースでオブジェクトのすべてを送らなければなりません。 キャッシュされたデータは移して、キャッシュしない場合このメソッドを使用するのがつけられているということであるはずがありません。
The %xfer response will send all instances of an object. This is in response to the -xfer directive. The transfer may be limited by the arguments to the directive. If there are no arguments, the server must send all of the objects in the database. Cached data must not be transferred using this method unless caching is turned on.
Williamson & Kosters [Page 29] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[29ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Each object instance is sent with a blank %xfer response between instances.
間のxfer応答が例証する空白の%と共にそれぞれのオブジェクトインスタンスを送ります。
Format for use:
使用のための形式:
%xfer<SP>[<object>:<attribute>:<value>]
%xfer<SP>。[<オブジェクト>: <属性>: <値の>]
These arguments are not required if the current response is an object instance separator.
これらの議論は現在の応答がオブジェクトインスタンス分離符であるなら必要ではありません。
<object>{%s} This required argument represents the name of
the object being transferred.
この必要な議論が名前を表す<オブジェクト>%s、移されるオブジェクト。
<attribute>{%s} This required argument identifies the attribute
being sent.
<はこれが必要とした>%sを結果と考えます。議論は送られる属性を特定します。
<value>{%s} This required argument contains the value of the
attribute. If blank, the attribute value is
blank.
<はこれが必要とした>%sを評価します。議論は属性の値を含んでいます。 空白であるなら、属性値は空白です。
Example of use:
使用に関する例:
%xfer user:last-name:Kosters %xfer user:first-name:Mark %xfer user:organization-phone:703-555-1212 %xfer %xfer user:last-name:Williamson %xfer user:first-name:Scott %xfer user:organization-phone:703-555-1212 %xfer
xferユーザ: 組織電話: %のxferユーザ:姓:Kosters%のxferユーザ:名:マーク%のxferユーザ: 組織電話: 703-555-1212%のxfer%のxferユーザ:姓:ウィリアムソン%のxferユーザ:名:スコット%の703-555-1212%のxfer
3.4.6 schema
3.4.6 図式
The %schema response is used to describe the attributes of an object. This is in response to the -schema directive.
図式応答が使用されている%はオブジェクトの属性について説明します。 これは図式指示に対応しています。
Each attribute is sent with a blank %schema as a separator.
空白の%図式と共に分離符として各属性を送ります。
Format for use:
使用のための形式:
%schema<SP><object>:attribute:<attribute name> %schema<SP><object>:format:<format string> %schema<SP><object>:description:<descriptive string> %schema<SP><object>:indexed:<indexed> %schema<SP><object>:required:<required> %schema<SP><object>:multi-line:<multi-line> %schema<SP><object>:type:<type> %schema<SP><object>:primary:<primary>
%図式<SP><オブジェクト>:属性:<は名前>%図式<SP><オブジェクト>:形式:<書式の記号列>%図式<SP><オブジェクト>:記述:<描写的であるストリング>%図式<SP><オブジェクト>を結果と考えます: 索引をつけられます:; <は>%図式<SP><オブジェクト>に索引をつけました: : <必要な>%の図式<SP><オブジェクトの>:予備選挙:<のプライマリ図式<SP><オブジェクト>: マルチ系列: <マルチ系列の>%図式<SP><オブジェクト>:タイプ:<タイプ>%>を必要とします。
Williamson & Kosters [Page 30] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[30ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
%schema
%図式
These arguments are not required if the current response is an attribute separator.
これらの議論は現在の応答が属性分離符であるなら必要ではありません。
<attribute name>{%s} This required argument identifies the
name of the attribute being described.
<属性はこの必要な議論が名前を特定する>%sを説明される属性と命名します。
<format string>{%s} This required argument describes the
allowed format for the attribute.
この必要な議論が許容形式について説明する<書式の記号列>%s、属性。
<descriptive string>{%s} This required argument describes the
attribute's use.
これが必要とした>%sを結んでください。<描写的である、議論は属性の使用について説明します。
<indexed>{on|off} This required argument identifies
attributes that are indexed.
<は|オフな>に索引をつけました。この必要な議論は索引をつけられる属性を特定します。
<required>{on|off} This required argument identifies
attributes that are required.
<は|オフな>を必要としました。この必要な議論は必要である属性を特定します。
<multi-line>{on|off} This required argument indicates whether
the attribute can span multiple lines.
|オフな>を裏打ちしてください。<、マルチ、この必要な議論は、属性は長さ倍数線をそうすることができるかどうかを示します。
<type>{text|MIME|see-also|PostScript}
This required argument identifies the
type of the attribute.
<は>をタイプします。{テキスト| MIME| -また、見てください| ポストスクリプト}というこれほど必要な議論は属性のタイプを特定します。
<unique-key>{on|off} This required argument indicates whether
the attribute is a unique key.
|オフなこれほど必要な<ユニークキー>、議論は、属性がユニークキーであるかどうかを示します。
Example of use:
使用に関する例:
%schema user:attribute:Object-Type %schema user:description:Name of the object %schema %schema user:attribute:Email %schema user:format:[%Memail] %schema user:description:RFC-822 compliant Email address %schema %schema user:attribute:Organization-Phone %schema user:format:[%3d[0-999]-%3d[0-999]-%4d[0-9999]] %schema user:description:Work phone number %schema
%、図式ユーザ、: 以下を結果と考えてください、オブジェクトタイプ%図式、ユーザ、: 記述: 名前、オブジェクト%図式、%、図式ユーザ、図式ユーザ: 形式: : 属性: メール%[%Memail]、%、図式ユーザ、: 記述: RFC-822対応することのメールが、%が図式%図式であると扱う、ユーザ: 以下を結果と考えてください、組織電話%図式、ユーザ、: 形式:、[%3d[0-999]-%3d[0-999]-%4d[0-9999]]、%、図式ユーザ:記述:仕事電話番号%図式
Williamson & Kosters [Page 31] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[31ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
3.4.7 define
3.4.7、定義
The %define response describes format macros to the client. All format macros used in the schema format definition string must be available to the client through the -define directive. Format macros may be nested. It is the client's responsibility to request all format strings that are unrecognized from a server. If the format strings change on a server, the serial number of the schemas that use the format must change.
%は応答を定義します。形式マクロについてクライアントに説明します。 図式形式定義ストリングで使用されるすべての形式マクロがクライアントにとって突き抜けた状態で利用可能であるに違いない、指示を定義してください。 形式マクロは入れ子にされるかもしれません。 サーバから認識されていないのは、すべての書式の記号列を要求するクライアントの責任です。書式の記号列がサーバで変化するなら、形式を使用するschemasの通し番号は変化しなければなりません。
Format for use:
使用のための形式:
%define<SP><macro name>:<[format string]>
%は<SP><マクロ名>: <を定義します。[書式の記号列] >。
[NOTE: The brackets around the format string are required to ensure that spaces contained in the format string are interpreted correctly by the client.]
[注意: 書式の記号列の周りの括弧が書式の記号列に含まれた空間がクライアントによって正しく解釈されるのを保証するのに必要です。]
Example of use:
使用に関する例:
%format server:[%s:%16Bd] %format email:[%s@%s]
%はサーバをフォーマットします: [%s: %16Bd]%はメールをフォーマットします:[ %s@%s ]
3.4.8 object
3.4.8 オブジェクト
All visible objects on an RWhois server must be identified in response to a -object directive. The %object response either confirms the existence of an object or returns a complete list of all objects available to the currently connected user.
オブジェクト指示に対応してRWhoisサーバのすべての目に見える物体を特定しなければなりません。 オブジェクト応答がオブジェクトの存在を確認するか、または全リストを返す%は現在接続されたユーザにとって利用可能な状態ですべて反対します。
A blank %object line serves as an object separator.
空白の%、見える線はオブジェクト分離符として機能します。
Format for use:
使用のための形式:
%object %object<SP><object name>:description:<object description> %object<SP><object name>:restrict:<restriction words>
%オブジェクト%オブジェクト<SP><オブジェクト名>:記述:<オブジェクト記述>%オブジェクト<SP><オブジェクト名>: 以下を制限してください、そして、<制限は>を言い表します。
<object name>{%s} This required argument is the name of
the object.
オブジェクトがこの必要な議論に>%sと命名する<はオブジェクトの名前です。
<object description>{%s} This required argument is a description
of the object identified.
<オブジェクト記述>%s、この必要な議論は特定されたオブジェクトの記述です。
<restriction words>{%s} This required argument is a list of
words used to restrict a search to this
object.
<制限はこれが必要とした>%sを言い表します。議論は検索をこのオブジェクトに制限するのに使用される単語のリストです。
Williamson & Kosters [Page 32] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[32ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Example of use:
使用に関する例:
%object user:description:user records for entity POC %object user:restrict:user %object user:restrict:person %object user:restrict:mailbox
以下を制限してください、そして、ユーザ%オブジェクト・ユーザ: 以下を制限してください、そして、オブジェクト・ユーザ:記述:ユーザが実体POC%オブジェクト・ユーザのために記録する%: 人の%オブジェクト・ユーザ: : メールボックスを制限してください。
3.4.9 directive
3.4.9 指示
The %directive response is used to display directives allowed on the connected server. The directive name, description and syntax attributes must be sent for each directive. If information about a single directive is requested then only information about that directive must be returned.
接続サーバに許容された指示を表示するのに%指示の応答を使用します。各指示のために指示の名前、記述、および構文属性を送らなければなりません。 ただ一つの指示の情報を要求するなら、その指示の情報だけを返さなければなりません。
A %directive response with no arguments must be sent between directives.
1%議論のない指示の応答を指示の間に送らなければなりません。
Format for use:
使用のための形式:
%directive<SP>directive:<directive> %directive<SP>description:<description> %directive<SP>syntax:<format> %directive
指示の<SP>構文: %指示の<SP>指示: <指示の>%指示の<SP>記述: <記述>%<は>%指示をフォーマットします。
The arguments below are required except when separating directives.
指示を切り離す時を除いて、以下での議論が必要です。
<directive>{%s} This required argument indicates the name of
the directive.
この必要な議論が名前を示す<指示の>%s、指示。
<description>{%s} This required argument describes the
directive.
この必要な議論が説明する<記述>%s、指示。
<format>{%s} This required argument defines the format of
the directive.
<はこれが必要とした>%sをフォーマットします。議論は指示をフォーマットを定義します。
Example of use:
使用に関する例:
%directive directive:schema %directive description:displays schema attributes %directive syntax:schema<SP>[%s] %directive %directive directive:xfer %directive description:transfer all object[authority area] %directive syntax:xfer<SP>[%s]<SP>[%s]
すべてのオブジェクト[権威領域]%指示構文: %指示の指示: 図式%指示の記述: ディスプレイ図式属性%指示の構文: 図式<SP>[%s]%指示の%指示の指示: xfer%指示の記述: 転送xfer<SP>[%s]<SP>。[%s]
Williamson & Kosters [Page 33] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[33ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
3.4.10 info
3.4.10 インフォメーション
The %info response is used to give the user of the client a message. This response is not initiated by any directive. The information between the %info on and the %info off should be presented to the user of the client. An ideal use of this response is to present a Message of The Day (MOTD) to the user.
インフォメーション応答が使用されている%はクライアントのユーザにメッセージを与えます。 この応答はどんな指示でも開始されません。 下に、あるべきです。%インフォメーションの間でオンな情報と%インフォメーション、クライアントのユーザに提示されます。 この応答の理想的な使用はデー(MOTD)のMessageをユーザに寄贈することです。
Format for use:
使用のための形式:
%info<SP><mode>
%インフォメーション<SP><モード>。
<mode>{on|off}
<モード>。オフでは、|オフです。
on: Turns the passthru mode on.
off: Turns the passthru mode off.
オン: passthruモードを有効にする、: passthruモードを無効にします。
Example of use:
使用に関する例:
%info on As of 3/24/1994 at 9:00 EST this server will no longer be in service. If you have this server in your configuration file we recommend that you change it to rs.internic.net:4343. You will automatically be redirected there following this message. %info off
3/24/1994の東部標準時9時0分のこのサーバのAsに関する%インフォメーションはもう使用中にならないでしょう。 あなたの構成ファイルのこのサーバがありましたら、私たちは、あなたがそれをrs.internic.netに変えることを勧めます: 4343。 このメッセージに従って、あなたはそこで自動的に向け直されるでしょう。 %インフォメーション、オフ
3.4.11 display
3.4.11 ディスプレイ
The %display response is used to inform the client that the data following this response is using the indicated method. The method selected will continue to be active until a %display response is sent without any arguments. The server must send an error message to clients that have been identified as non-RWhois clients. This response allows the use of display methods such as MIME [RFC 1521] or other special character sets such as those used in the Japanese language.
%は、この応答に続くデータが示されたメソッドを使用していることをクライアントに知らせるために使用される応答を表示します。 選択されたメソッドは応答が少しも議論なしで送られる%ディスプレイまでずっとアクティブでしょう。 サーバは非RWhoisクライアントとして特定されたクライアントにエラーメッセージを送らなければなりません。 この応答はMIME[RFC1521]などのディスプレイメソッドか日本語で使用されるものなどの他の特殊文字セットの使用を許します。
Format for use:
使用のための形式:
%display<SP>extended:<extended>
%ディスプレイ<SP>は広がりました: <は>を広げました。
%display<SP>name:<name> %display<SP>length:<length> %display<SP>description:<description> %display<SP>command-line-option:<mode>
%は<SP>名を表示します: <名前>%は<SP>の長さを表示します: <長さの>%は<SP>記述を表示します: <記述>%は<SP>コマンドラインのオプション: <モード>を表示します。
<extended> This optional argument identifies if the display
method is extended, i.e., RWhois specific.
ディスプレイメソッドが拡張されていて、すなわち、RWhois特有であるなら、<は任意の議論が特定する>Thisを広げました。
Williamson & Kosters [Page 34] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[34ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Example of use:
使用に関する例:
%display extended:mime MIME-Version:1.0 Content-type: image/gif Content-Transfer-Encoding: base64 ...data... %display
ディスプレイが広げた%: パントマイムMIMEバージョン: 1.0文書内容: gif Content転送イメージ/コード化: base64…データ… %は表示します。
3.4.12 X-
3.4.12 X
The %X- response represents extended responses. The client must have prior knowledge of this response.
X-応答が表す%は応答を広げました。 クライアントには、この応答に関する先の知識がなければなりません。
Format for use:
使用のための形式:
%X-<response><SP>[arguments]
%X、-、<応答><SP>。[議論]
<response>{%s} This required argument contains the response name.
この必要な議論が含む<応答>%s、応答名。
Example of use:
使用に関する例:
%X-extstatus numusers:500 %X-extstatus avalslots:200
X-extstatus numusers: %の500%のX-extstatus avalslots: 200
[NOTE: The above examples are not implemented in the current RWhois prototype software. They are only examples of the %X- response to a -X- directive. X6X error codes are used when problems are encountered in relation to the -X- directives contained on the server. Details can be found in Section 5.]
[以下に注意してください。 上記の例は現在のRWhoisプロトタイプソフトウェアで実装されません。 それらはa-X指示への%X応答に関する例にすぎません。 と関連して問題が行きあたられるとき、X6Xエラーコードが使用されている、-X-指示は備え付けることのコネがセクション5であったかもしれないならサーバに. 詳細を含みました。]
3.4.13 language
3.4.13 言語
The %language response is used to inform the client that the data following this response will be sent in the indicated language. The language selected will continue to be active until a %language response is sent without any arguments, at which time the server will revert back to English, the default. The server must send an error message to clients that have been identified as non-RWhois clients.
%言語、応答、この応答に続くデータが示された言語で送られることをクライアントに知らせるために、使用されます。 選択された言語がずっとアクティブである、%言語、応答、サーバがどの時に英語(デフォルト)に戻って戻るかとき、少しも議論なしで送ります。 サーバは非RWhoisクライアントとして特定されたクライアントにエラーメッセージを送らなければなりません。
Williamson & Kosters [Page 35] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[35ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
Format for use:
使用のための形式:
%language:<SP><language>
%言語: <SP><言語>。
Example of use:
使用に関する例:
%language: german RWhois Deutsche Version: 1.0 %language
%言語: ドイツ語RWhois Deutscheバージョン: 1.0%言語
3.5 Query Reduction
3.5 質問減少
The critical component of the RWhois server is the ability to reduce the query to find a server that is closer to the data. The search algorithm of the server is the following:
RWhoisサーバの重要な要素はデータの、より近くにあるサーバを見つけるために質問を抑える能力です。 サーバの検索アルゴリズムは以下です:
1) accept a query 2) find any local matches - display them 3) find any referrals - display them 4) if no local or referral hits, reduce the query and goto step 3
1) 2が)どんな地方のマッチも見つける質問を受け入れてください--それらを表示してください。3によって、)いずれが紹介であることがわかります--、それらを表示してください、4は、)ローカルでない紹介でないなら当たって、質問を抑えて、ステップ3をgotoします。
Here is an example of the query ietf.cnri.reston.va.us:
ここに、質問ietf.cnri.reston.va.usに関する例があります:
1) query whois for ietf.cnri.reston.va.us
2) search rs.internic.net for information (no hits).
3) search referrals for ietf.cnri.reston.va.us (no hits).
4) search referrals for cnri.reston.va.us (no hits).
5) search referrals for reston.va.us (no hits).
6) search referrals for va.us (no hits).
7) search referrals for us (referral found) - referral to
isi.edu.
1) ietf.cnri.reston.va.us2のための質問whois) 情報(ヒットがない)のためにrs.internic.netを捜してください。 3) ietf.cnri.reston.va.us(ヒットがない)のために紹介を捜してください。 4) cnri.reston.va.us(ヒットがない)のために紹介を捜してください。 5) reston.va.us(ヒットがない)のために紹介を捜してください。 6) va.us(ヒットがない)のために紹介を捜してください。 7) 私たち(見つけられた紹介)のための検索紹介 - isi.eduへの紹介。
[currently on rs.internic.net:4343 for proof of concept].
[rs.internic.net: 現在、概念の証拠のための4343の。]
3.6 Determining Authority
3.6 権威を決定すること。
Authority areas are a major part of the RWhois protocol. If an authoritative response is required, turning the cache off is the first step. The client can also determine if the server connected has authority over the name/number space of interest by sending the -soa <authority area> directive. If the server has authority for the area requested, it must return important information about the authority area. The exchange below is a client determining if the server is an authority for abc.net or no.net.
権威領域はRWhoisプロトコルの大半です。 正式の応答が必要であるなら、キャッシュをオフにするのは、第一歩です。 また、クライアントは、接続されたサーバが興味がある名前/数のスペースの上で-soa<権威領域>指示を送ることによって権限があるかどうかと決心できます。 サーバから領域への権威を要求するなら、それは権威領域に関する重要情報を返さなければなりません。 以下での交換はabc.netかNo.ネットのためにサーバが権威であるかどうかと決心しているクライアントです。
S wait for connection C connect to rs.internic.net port 4343 S %RWhois V-1.0 rs.internic.net (Network Solutions, Inc. V-1.0)
接続CのためのS待ちはrs.internic.netのポートの4343秒間の%RWhois V-1.0 rs.internic.netに接続します。(ネットワークソリューションズ社V-1.0)
Williamson & Kosters [Page 36] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[36ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
C -RWhois V-1.0 (Network Solutions, Inc. V-1.0) S %ok C -cache off S %ok C -soa abc.net S %error<SP>333<SP>Not SOA for requested authority area S %ok C -soa no.net S %soa authority: no.net S %soa ttl: 7500 S %soa serial: 45 S %soa refresh: 3600 S %soa retry: 3600 S %soa tech-contact: markk@no.net S %soa admin-contact: stanb@no.net S %soa hostmaster: hostmaster@no.net S %ok
C-RWhois V-1.0(ネットワークソリューションズ社V-1.0)S%OK CはS%OK C-soa abc.net S%誤り<でOKにSP>333<SP>Not SOAを要求された権威領域S%キャッシュします。C-soa No.ネットのS%は権威をsoaします: No.ネットのS%soa ttl: 7500秒間の%はシリーズをsoaします: 45秒間の%soaはリフレッシュします: 3600秒間の%soaは再試行されます: 3600秒間の%soaは以下に技術者と同じくらい連絡します。 markk@no.net S%soaは以下にアドミンで連絡します。 stanb@no.net S%soa hostmaster: hostmaster@no.net S%OK
3.7 Secondary Server Interaction
3.7 セカンダリサーバ相互作用
A server that operates as a secondary will report an authoritative SOA for the authority area of the data it contains. Below is the interaction between the primary and secondary server. In reality the secondary operation would be performed using a client specifically designed for this purpose.
2番目として作動するサーバはそれが含むデータの権威領域に正式のSOAを報告するでしょう。 以下に、プライマリの、そして、セカンダリのサーバの間には、相互作用があります。ほんとうは、二次手術は、明確にこのために設計されたクライアントを使用することで実行されるでしょう。
S wait for connection C connect to slam.internic.net port 4343 S %RWhois V-1.0 slam.internic.net (Network Solutions Inc. V-1.0) C -RWhois V-1.0 (Network Solutions Inc. V-1.0) S %ok C -soa internic.net S %soa authority: internic.net S %soa ttl: 7500 S %soa serial: 45 S %soa refresh: 3600 S %soa retry: 3600 S %soa tech-contact: markk@internic.net S %soa admin-contact: stanb@internic.net S %soa hostmaster: hostmaster@rs.internic.net S %ok C -xfer domain internic.net S ... all data for domain object in the internic.net authority area transferred S%ok C -notify inssec netman1.netsol.com:4343:domain:internic.net S %ok C -quit
接続CのためのS待ちはslam.internic.netのポートの4343秒間の%RWhois V-1.0 slam.internic.net(ネットワークソリューション株式会社V-1.0)C-RWhois V-1.0(ネットワークソリューション株式会社V-1.0)S%OK C-soa internic.net S%soaに権威を接続します: internic.net S%soa ttl: 7500秒間の%はシリーズをsoaします: 45秒間の%soaはリフレッシュします: 3600秒間の%soaは再試行されます: 3600秒間の%soaは以下に技術者と同じくらい連絡します。 markk@internic.net S%soaは以下にアドミンで連絡します。 stanb@internic.net S%soa hostmaster: ドメインのためのすべてのデータがOK Cがinssec netman1.netsol.comに通知するinternic.net権威領域わたっているS%で反対させる hostmaster@rs.internic.net S%OK C-xferドメインinternic.net S…: OK Cがやめた4343:ドメイン:internic.net S%
Williamson & Kosters [Page 37] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[37ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
S close connection C close connection
S浅からぬ関係C浅からぬ関係
3.8 Registration Process
3.8 登録手続
The following is the interaction that occurs when a server accepts a registration from a client.
↓これはサーバがクライアントから登録を受け入れるとき起こる相互作用です。
S wait for connection C connect to slam.internic.net port 4343 S %RWhois V-1.0 slam.internic.net (Network Solutions Inc. V-1.0) C -RWhois V-1.0 (Network Solutions Inc. V-1.0) S %ok C -soa internic.net S %soa authority: internic.net S %soa ttl: 7500 S %soa serial: 45 S %soa refresh: 3600 S %soa retry: 3600 S %soa tech-contact: markk@internic.net S %soa admin-contact: stanb@internic.net S %soa hostmaster: hostmaster@rs.internic.net S %ok C -private auth password 98uuuts S %ok C -register on add scottw@netsol.com 98uuuts S %ok C ... send all attributes for object to register S %error 120 Registration not processed... will process hours:24 C %quit
接続CのためのS待ちはslam.internic.netのポートの4343秒間の%RWhois V-1.0 slam.internic.net(ネットワークソリューション株式会社V-1.0)C-RWhois V-1.0(ネットワークソリューション株式会社V-1.0)S%OK C-soa internic.net S%soaに権威を接続します: internic.net S%soa ttl: 7500秒間の%はシリーズをsoaします: 45秒間の%soaはリフレッシュします: 3600秒間の%soaは再試行されます: 3600秒間の%soaは以下に技術者と同じくらい連絡します。 markk@internic.net S%soaは以下にアドミンで連絡します。 stanb@internic.net S%soa hostmaster: 間違いないC兵卒がOK Cが登録するパスワード98uuuts S%をauthする hostmaster@rs.internic.net S%は、オブジェクトが誤り120Registrationが処理しなかったS%を登録するようにOK Cがすべての属性を送る… scottw@netsol.com 98uuuts S%がプロセス時間を望んでいると言い足します…: 24C%はやめます。
3.9 Out-of-Service
3.9、使われなくなっている。
Servers that are being taken out of service should automatically refer the client back into the tree. Of course, this is not possible if the system which hosts the server is out of service. In this case, the client's robustness must be relied upon to return to the referrer and notify that server that the referral was bad. If the system will still be available on the Internet, the following exchange is recommended:
使われなくなっていた状態で取られているサーバは自動的に木へクライアントを差し戻すべきです。 もちろん、サーバをホスティングするシステムが使われなくなっているなら、これは可能ではありません。 この場合、リファラーに戻って、紹介が悪かったことをそのサーバに通知するためにクライアントの丈夫さを当てにしなければなりません。 システムがインターネットでまだ利用可能になっているなら、以下の交換はお勧めです:
S wait for connection C connect to slam.internic.net port 3636 S %RWhois V-1.0 slam.internic.net (Network Solutions Inc. V-1.0) C -RWhois V-1.0 (Network Solutions Inc. V-1.0) S %info on S This server will no longer be in service. You should S change your configuration file to reflect the new root
接続CがS Thisサーバで3636秒間のslam.internic.netポート%RWhois V-1.0 slam.internic.net(ネットワークソリューション株式会社V-1.0)C-RWhois V-1.0(ネットワークソリューション株式会社V-1.0)S%インフォメーションに接続するので、S待ちはもう使用中にならないでしょう。 あなた、Sは、新しい根を反映するためにあなたの構成ファイルを変えるべきです。
Williamson & Kosters [Page 38] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[38ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
S server at rs.internic.net:4343. You will automatically be S referred to the new root. S %error 200 Service not available referral to follow S %referral rs.internic.net:4343 S close connection C close connection
rs.internic.netのSサーバ: 4343。 あなたは自動的に新しい根が参照されたSになるでしょう。 利用可能な紹介ではなく、S%紹介rs.internic.netに続く誤り200Service: 4343秒間のS%は接続C浅からぬ関係を終えます。
4. Interaction: Client Directives and Acceptable Server Responses
4. 相互作用: クライアント指示と許容できるサーバ応答
This section describes the responses to the various client directives.
このセクションは様々なクライアント指示に応答を説明します。
4.1 General
4.1 一般
The responses below are general responses that can occur as a result of any directive. Therefore, they will not be repeated under each directive.
以下での応答はどんな指示の結果、起こることができる一般反応です。 したがって、それらは各指示で繰り返されないでしょう。
%ok
%error<SP>400<SP>Invalid Server Directive
%error<SP>100<SP>Get Peer Name query failed
%error<SP>500<SP>Memory Allocation Problem
%error<SP>401<SP>Not authorized for directive
%error<SP>402<SP>Unidentified error... continue
%error<SP>502<SP>Unrecoverable error... goodbye
%error<SP>503<SP>Idle time exceeded... goodbye
400<SP>Invalid Server Directive%誤り<SP>100<SP>Get Peer Nameが質問する%間違いない%誤り<SP>は500<SP>Memory Allocation Problem%誤り<SP>401<SP>Notが指示の%誤り<SP>402<SP>Unidentified誤りによって認可した%誤り<SP>に失敗しました; . . 超えられていて、502<SP>Unrecoverable誤り…さようならの%誤り<SP>503<SP>Idleが調節する%誤り<SP>は続けています…、さようなら。
4.2 On Connection
4.2 接続に関して
These responses will only occur following successful connection to the server's host and start-up of the application:
サーバのアプリケーションのホストと始動にうまくいっている接続に続いて、これらの応答は起こるだけでしょう:
%RWhois
%error<SP>501<SP>Service not available
%referral
%error<SP>503<SP>Idle time exceeded... goodbye
>503<SP>Idle時間が超えていた利用可能な%紹介%誤り<SPではなく、%RWhois%誤り<SP>501<SP>Service… さようなら
4.3 <QUERY>
4.3 <質問>。
These responses may occur following a query:
質問に続いて、これらの応答は起こるかもしれません:
<answer>
%referral
%see-also
%error<SP>334<SP>Pre-query directive not implemented
%error<SP>230<SP>No Records Found
%error<SP>130<SP>Not authority for answer... TTL good
%error<SP>231<SP>Not authority for answer... TTL expired
答えのための<答え>%紹介%-また、見ている%誤り<SP>334<SP>Pre質問指示の実装していない%誤り<SP>230<SP>いいえRecords Found%誤り<SP>130<SP>Not権威… 答えのためのTTL良い%誤り<SP>231<SP>Not権威… TTLは期限が切れました。
Williamson & Kosters [Page 39] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[39ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
4.4 -RWhois
4.4 -RWhois
%error<SP>300<SP>Not compatible with that version number
そのバージョン番号とのコンパチブル%誤り<SP>300<SP>Not
4.5 -load
4.5負荷
%load
%error<SP>335<SP>System's load not available
%は%誤り<SP>335<SP>Systemの利用可能でない負荷をロードします。
4.6 -limit<SP>< value >
4.6限界の<SP><値の>。
%limit
%error<SP>330<SP>Exceeded Max Records Limit
%error<SP>331<SP>Invalid Max Records Size
%限界%誤り<SP>330<SP>はSP>331の<のSPの>の無効のマックスがサイズを記録することにおけるマックスRecords限界%誤り<を超えていました。
4.7 -schema<SP>[object]
4.7図式の<SP>。[オブジェクト]
%schema
%error<SP>337<SP>Object's schema not found
337<SP>Objectの図式が見つけなかった%図式%誤り<SP>。
4.8 -xfer<SP>[object]
4.8 -xfer<SP>。[オブジェクト]
%xfer
%error<SP>332<SP>Nothing to transfer
%error<SP>337<SP>Object's schema not found
転送%誤り<SP>337<SP>Objectの図式への332<SP>Nothingが見つけなかった%xfer%誤り<SP>。
4.9 -quit
4.9はやめます。
%ok
%OK
4.10 -cache<SP><on/off>
>の/の4.10キャッシュの<SP><。
%error<SP>232<SP>Cache disabled
232<SP>Cacheが無効にした%誤り<SP>。
4.11 -status
4.11 状態
%status
%状態
4.12 -forward
4.12 -前方
%error<SP>431<SP>Not authorized to forward
%error<SP>433<SP>Bad reference on forward
431<SP>Notが前方の進行中の<の433<SP>Bad SP>参照を%誤りに転送するのを認可した%誤り<SP>。
4.13 -soa
4.13 -soa
%soa
%error<SP>333<SP>Not SOA for requested authority area
要求された権威領域への%soa%誤り<SP>333<SP>Not SOA
Williamson & Kosters [Page 40] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[40ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
4.14 -notify
4.14に通知します。
%error<SP>434<SP>Referral does not exist on this server
%error<SP>530<SP>Not authorized as secondary
434<SP>Referralがする%誤り<SP>は530<SP>Notがセカンダリとして認可したこのサーバ%誤り<SP>で存在していません。
4.15 -register
4.15は登録されます。
%error<SP>120<SP>Registration not processed... will process
hours:<hours>
%error<SP>320<SP>Invalid attribute line:<line number>
%error<SP>321<SP>Invalid format line:<line number>
%error<SP>322<SP>Required attribute missing name:<attribute
name>
%error<SP>323<SP>Required related object missing name:<object
name>
%error<SP>324<SP>Primary key not unique
%error<SP>420<SP>Registration not authorized
%error<SP>421<SP>Not authorized to change object:<object
name><SP>key:<key>
120<SP>Registrationが処理しなかった%誤り<SP>…; 名前: <属性名前>%誤り<SP>323のSPの>のRequiredの関連するオブジェクトの<取り逃がすことを逃す>322<SP>Requiredが結果と考えるプロセス時間(<時間)>%誤り<SP>320<SP>Invalid属性系列: <行番号>%誤り<SP>321<SP>Invalid形式系列: <行番号>%誤り<SPが以下を命名するでしょうか?; 421<SP>Notがオブジェクトを変えるのを認可した認可された%誤り<SP>ではなく、<SP>420<SP>Registration: どんな324<SP>Primaryキーユニークな%誤り<もSP>キーと><を命名するのを反対させない<オブジェクト名>%誤り<SP>: <の主要な>。
4.16 -holdconnect
4.16 -holdconnect
4.17 -object
4.17オブジェクト
%object
%error<SP>336<SP>Object not defined
336<SP>Objectが定義しなかった%オブジェクト%誤り<SP>。
4.18 -define
4.18は定義します。
%define
%error<SP>435<SP>Macro not defined
%は435<SP>Macroが定義しなかった%誤り<SP>を定義します。
4.19 -X-
4.19X、-
%X-
%error<SP>460<SP>Extended directive not recognized
%error<SP>461<SP>Extended directive not authorized
>461<SP>Extended指示が認可しなかった%X%誤り<SP>460<SP>Extended指示認識された%誤り<SPでない
4.20 -display
4.20 ディスプレイ
%display
%display<SP>436<SP>Display mode not allowed
436<SP>Displayモードが許容しなかった%ディスプレイ%ディスプレイ<SP>。
4.21 -language
4.21 言語
%language<SP>437<SP>Language not supported
437<SP>Languageがサポートしなかった%言語<SP>。
Williamson & Kosters [Page 41] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[41ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
5. Error Codes
5. エラーコード
The error code immediately follows the %error response from the RWhois server. The definitions of the error codes are below. The error codes are descriptive so that the client can group the error messages in order to determine group action that must be taken before taking error specific action. Error codes should remain consistent without variable extensions except for messages associated with the registration process. If a client receives a `6' in the second position of the error code and the client does not support the extended code received, the client must act on the first position code. (Example: If a client received %error 561 and the client did not support the extended error codes for the server currently connected, the client would exit based on the `5' in the first position of the error code.)
エラーコードはすぐに、%誤りに続きます。サーバエラーコードの定義があるRWhoisからの応答。 エラーコードは、クライアントが誤りの特定の行動を取るのに承認させなければならない集団行動を決定するためにエラーメッセージを分類できるくらい描写的です。 エラーコードは登録手続に関連しているメッセージ以外の可変拡大なしで一貫していたままで残るべきです。 クライアントが第2代エラーコードの位置で'6'を受けて、クライアントが受け取られた拡張コードをサポートしないなら、クライアントは第1ポジションコードに影響しなければなりません。 (例: クライアントが受信したなら、誤り561とクライアントがした%は、現在接続されるサーバのために拡張誤りがコードであるとサポートしないで、クライアントはエラーコードの第1ポジションの'5'に基づいて出るでしょう。)
X00
X00
1 - information only, no action required
2 - information, action required
3 - Specific command error, retry that command or try
another directive
4 - Serious for current directive, may correct with another
directive
5 - Fatal, must disconnect
情報(現在の指示に、重大な必要な行動3(特定のコマンド誤り、別の指示の4を命令するか、または試みる再試行))が別の指示の5で修正するかもしれない1(どんな動作も2を必要としただけではないという情報)--致命的な必須分離
0X0
0×0
0(1) - System wide, no specific directive
2 - Registration error
3(4,5) - Specific directive
6 - Extended message (version specific)
0(1)--システム広くて、いいえ特有の指示の2--登録誤り3(4、5)(特定の指示の6)はメッセージを広げました。(バージョン特有)です。
00X
00X
Sequential order
連続したオーダー
5.1 Error Code List
5.1 エラーコードリスト
Below is an ordered list of RWhois error codes. These codes may be extended with implementation specific codes. These extended codes will have a `6' in the second position of the code.
以下に、RWhoisエラーコードの規則正しいリストがあります。 これらのコードは実装の特定のコードで広げられるかもしれません。 これらの拡張コードには、第2代コードの位置の'6'があるでしょう。
100 Get Peer Name query failed 120 Registration not processed... will process hours:<hours> 130 Not authority for answer... TTL good 200 Service not available... Referral to follow 230 No Records Found
100 失敗した120Registrationが処理しなかったPeer Name質問を得てください… 時間、処理するでしょう: 答えのための<時間>130Not権威 利用可能でないTTL良い200Service… 230ノーRecords Foundに続く紹介
Williamson & Kosters [Page 42] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[42ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
231 Not authority for answer... TTL expired 232 Cache disabled
231 答えのための…権威でない TTLはCacheが無効にした232を吐き出しました。
300 Not compatible with that version number 320 Invalid attribute line:<line number> 321 Invalid format line:<line number> 322 Required attribute missing name:<attribute name> 323 Required related object missing name:<object name> 324 Primary key not unique 330 Exceeded Max Records Limit 331 Invalid Max Records Size 332 Nothing to transfer 333 Not SOA for requested authority area 334 Pre-query directive not implemented 335 System's load not available 336 Object not defined 337 Object's schema not found
そのバージョンNo.320Invalid属性系列があるコンパチブルでない300: <行番号>321Invalid形式系列: 名前を逃す>322Requiredが結果と考える<行番号: <属性名前>323Requiredは名前を逃すオブジェクトを関係づけました:; 要求された権威領域334Pre-質問指示が、335Systemの負荷が利用可能な336Objectでないと実装しなかったので、ユニークな330ExceededマックスRecords Limit331InvalidマックスRecords Size332Nothingではなく、333Not SOAを移す<オブジェクト名前>324PrimaryキーがObjectの図式が見つけなかった337を定義しませんでした。
400 Invalid Server Directive 401 Not authorized for directive 402 Unidentified error... continue 420 Registration not authorized 421 Not authorized to change object:<object name><SP>key:<key> 431 Not authorized to forward 432 Not authorized to transfer 433 Bad reference on forward 434 Referral does not exist on this server 435 Macro not defined 436 Display mode not allowed 437 Language not supported 460 Extended directive not recognized 461 Extended directive not authorized
400 無効のServer Directive401Notは指示のために402Unidentified誤りを認可しました…; 認可された421Notではなく、オブジェクトを変えるのが認可された420Registrationを続けてください: <オブジェクト名><SP>キー: 431Notが前進の434Referralに関する433Bad参照を移すのが認可された432Notを進めるのを認可した<の主要な>は定義された認識された461Extended指示ではなく、460Extended指示であることはサポートされなかった437Languageが許容されなかった436Displayモードではなく、435Macroが認可しなかったこのサーバに存在していません。
500 Memory Allocation Problem 501 Service not available 502 Unrecoverable error... goodbye 503 Idle time exceeded... goodbye 530 Not authorized as secondary
503Idle時間が超えていた利用可能な502Unrecoverable誤り…さよならではなく、500メモリAllocation Problem501Service… セカンダリとして認可されたさようなら530のNot
6. Attribute Format
6. 属性形式
The format for all attributes for objects in the RWhois server must be specified using a format specifier. This definition will allow the client software to interpret the received data correctly. The RWhois format specifier closely follows the `C' language scanf syntax with macro extensions.
形式特許説明書の作成書を使用することでRWhoisサーバのオブジェクトのためのすべての属性のための形式を指定しなければなりません。 この定義で、クライアントソフトウェアは正しく受信データを解釈できるでしょう。 RWhois形式特許説明書の作成書はマクロ拡大で密接に'C'言語scanf構文に従います。
Format specifiers must follow this pattern:
形式特許説明書の作成書はこのパターンに従わなければなりません:
Williamson & Kosters [Page 43] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[43ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
%[alignment][length restriction]<type>[range restriction]
%[整列][長さの制限]<は>をタイプします。[範囲制限]
[alignment] '-' = left justified
'.' = right justified
'[整列]'--'= 左は正当な状態で'.'=権利を正当化しました。
[length restriction] <value> = number of bytes allowed
<value>B = number of bits allowed
ビットの<値の>Bが許容された<値の>=バイト数=数が許容した[長さの制限]
<type> This is the only required part of the format specifier.
Below are the allowed format type values. The length
of these values are not specified. These restrictions
will be on the left of the [length restriction].
<タイプ>Thisは形式特許説明書の作成書の唯一の必要な部分です。 以下に、許容形式タイプ値があります。 これらの値の長さは指定されていません。 これらの制限が左にある、[長さの制限。]
%c Character %s String %d Integer %x Hex Integer %o Octal Integer %f Float %e Scientific %M defined macro
%Mが定義した%cキャラクター%s String%d Integer%x Hex Integer%o Octal Integer%f Float%e Scientific、マクロ
[range restriction] The range restriction will limit the allowed
values. This may specify a number,
character, or string range.
[範囲制限] 範囲制限は許容値を制限するでしょう。 これは数、キャラクタ、またはストリング範囲を指定するかもしれません。
Examples: %-3s["ON","OFF"] = Defines a string with 3 characters
left aligned and limited to the
strings ON or OFF.
%16Bd[0-50] = 16 bit integer between 0 and 50
例: %-3s[“ON"、"OFF"]=はオンかオフにストリングに並べられて、制限されるように残っている3つのキャラクタと共にストリングを定義します。 %16Bd[0-50]は16ビットの0〜50の整数と等しいです。
%4.2f[0-2500.50] = Defines a floating point number
limited to 4 digits before and 2
after the decimal with a value
between 0 and 2500.50.
%4.2f[0-2500.50]=は値に従った小数の後に0〜2500.50に以前4ケタに制限された浮動小数点と2を定義します。
6.1 Format Specification Macros
6.1 書式仕様マクロ
Format specifications may be presented as macros. Format specification macros may be defined using the following format.
書式仕様はマクロとして提示されるかもしれません。 書式仕様マクロは、以下の形式を使用することで定義されるかもしれません。
%M<macro name>=<format string or earlier macro>
%M<マクロ名>は<書式の記号列か以前のマクロ>と等しいです。
The following macros are pre-defined in this RWhois specification:
以下のマクロはこのRWhois仕様に事前に定義されます:
Month/Day/Year formats: %MM=[%-2d[0-12]] %MD=[%-2d[0-31]]
月/日/年形式: %mmが等しい、[%2d[0-12]]%MDは等しいです。[%2d[0-31]]
Williamson & Kosters [Page 44] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[44ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
%MY2=[%-2d[0-99]] %MY4=[%-4d[0-9999]] %MMs=[%-3s\ ["JAN","FEB","MAR","APR","MAY","JUN","JUL","AUG","SEP",\ "OCT","NOV","DEC"]]
%MY2が等しい、[%2d[0-99]]%MY4が等しい、[%4d[0-9999]]%MMsは等しいです。[%3円[「1月」、「2月」、「3月」「4月」、「5月」「6月」、「7月」「8月」、「9月」\「10月」、「11月」「DEC社」]]
Date formats: %Mdate1=[%MM/%MD/%MY2] %Mdate2=[%MM/%MD/%MY4] %Mdate3=[%MD-%MMs-%MY2] %Mdate4=[%MD-%MMs-%MY4] %Mdate5=[%MY4%MM%MD]
形式の日付を入れてください: %Mdate1=[%mm/%MD/%MY2]%Mdate2=[%mm/%MD/%MY4]%Mdate3=[%MD-%MMs-%MY2]%Mdate4=[%MD-%MMs-%MY4]%Mdate5=[%MY4%mm%MD]
Hour/Minute/Second formats: %MTH=[%-2d[0-24]] %MTM=[%-2d[0-59]] %MTS=[%-2d[0-59]]
時間/分/秒形式: %MTHが等しい、[%2d[0-24]]%MTMが等しい、[%2d[0-59]]%MTSは等しいです。[%2d[0-59]]
Time formats: %Mtime1=[%MTH:%MTM:%MTS] %Mtime2=[%MTH%MTM%MTS]
時間形式: %Mtime1=[%MTH: %MTM: %MTS]%Mtime2=[%MTH%MTM%MTS]
Miscellaneous formats: %Mserver=[%s:%16Bd] %Mipnumber=[%8Bd.%8Bd.%8Bd.%8Bd] %Memail=[%s@%s]
その他は以下をフォーマットします。 %Mserver=[%s: %16Bd]%Mipnumber=[%8Bd.%8Bd.%8Bd.%8Bd]%Memail=[ %s@%s ]
%Mserial=[%Mdate5%Mtime2] %Mstype=[RWHOIS/WHOIS/WHOIS++/OTHER] %Murl=[%s://%s]
[RWHOIS/WHOIS/WHOIS++/他]の%Mserial=[%Mdate5%Mtime2]%Mstype=%Murl=[%、s://%s]
Macro definitions may be obtained by sending the -define directive to the server. For client efficiency, definitions can be remembered. If the definition of a macro changes, the serial number of all schemas using that macro must change, allowing the client to reacquire the schema and format specifier macros.
指示をサーバと定義してください。発信することによってマクロ定義を得るかもしれない、クライアント効率において、定義は思い出すことができます。 マクロの定義が変化するなら、そのマクロを使用するすべてのschemasの通し番号は変化しなければなりません、reacquireへのクライアントに図式を許容して、特許説明書の作成書マクロを形式に許容して。
7. Quick Query (RWhois using UDP)
7. 迅速な質問(UDPを使用するRWhois)
The overhead incurred by establishing a TCP connection and interacting with an RWhois server may be unnecessary if the client only wishes to ask one question. A separate document will describe the UDP facility for RWhois. Adjustments to the query must be made to make this a practical option. The only function allowed while utilizing UDP is a single query.
クライアントが1質問したくないならしか、TCP接続を確立して、RWhoisサーバと対話することによって被られたオーバーヘッドは不要であるかもしれません。 別々のドキュメントはRWhoisのためにUDP施設について説明するでしょう。 これを実用的なオプションにするのを質問への調整をしなければなりません。 UDPを利用している間に許容された唯一の機能はただ一つの質問です。
Williamson & Kosters [Page 45] RFC 1714 Referral Whois Protocol (RWhois) November 1994
ウィリアムソンとKosters[45ページ]RFC1714紹介Whoisプロトコル(RWhois)1994年11月
8. References
8. 参照
[RFC-954] Harrenstien, K., Stahl, M., and E Feinler, "NICNAME/
WHOIS", RFC 954, SRI, October 1985.
[RFC-954]HarrenstienとK.とスタール、M.とE Feinler、「NICNAME/ WHOIS」RFC954、様、1985年10月。
[RFC-1521] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies", RFC 1521, Bellcore, Innosoft,
September 1993.
解放された[RFC-1521]Borenstein、N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
10. Authors' Addresses
10. 作者のアドレス
Scott Williamson 505 Huntmar Park Dr. Herndon, VA 22070
ハーンドン、スコット・ウイリアムソン505Huntmar Parkヴァージニア博士 22070
Phone: (703) 742-4820 EMail: scottw@internic.net
以下に電話をしてください。 (703) 742-4820 メールしてください: scottw@internic.net
Mark Kosters 505 Huntmar Park Dr. Herndon, VA 22070
ハーンドン、マークKosters505Huntmar Parkヴァージニア博士 22070
Phone: (703) 742-4795 EMail: markk@internic.net
以下に電話をしてください。 (703) 742-4795 メールしてください: markk@internic.net
Williamson & Kosters [Page 46]
ウィリアムソンとKosters[46ページ]
一覧
スポンサーリンク
