RFC1914 日本語訳
1914 How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz,C. Weider. February 1996. (Format: TXT=17842 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Faltstrom
Request for Comments: 1914 Bunyip Information Systems, Inc.
Category: Standards Track R. Schoultz
KTHNOC
C. Weider
Bunyip Information Systems, Inc.
February 1996
Faltstromがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1914年の詐欺師情報システムInc.カテゴリ: 標準化過程R.Schoultz KTHNOC C.ワイダー詐欺師情報システムInc.1996年2月
How to Interact with a Whois++ Mesh
Whois++メッシュと対話する方法
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
1. Overview
1. 概要
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). The protocol is simple. The client opens a connection to a server, sends a query, receives a reply, closes the connection, and after parsing the response the client decides which server to contact next, if necessary.
Whois+ + アーキテクチャ[Deutsch94]、[Weider94]では、メッシュ縦断がクライアントによって行われます、各サーバが次の適切なサーバをクライアントを'参照する'ので。 プロトコルは簡単です。 クライアントは、サーバに接続を開いて、質問を送って、回答を受け取って、閉鎖は接続です、そして、必要なら、応答を分析した後に、クライアントは次にどのサーバに連絡したらよいかを決めます。
So, the client needs to have an algorithm to follow when it interacts with the Whois++ mesh so that referral loops can be detected, cost is minimised, and appropriate servers are rapidly and effectively contacted.
それで、クライアントがWhois++メッシュと対話するとき、続くようにアルゴリズムを必要とするので、紹介輪を検出できて、費用は最小となって、急速に事実上、適切なサーバは連絡されます。
Faltstrom, et al Standards Track [Page 1] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[1ページ]
2. Basic functionality
2. 基本機能
Each Whois++ client should be configured to automatically send queries to a specific Whois++ server. The deault Whois++ server can vary depending on which template is desired, and the location of the client with respect to the WHOIS++ index mesh, but as a rule the server should be as local as possible.
+ + クライアントが自動的に構成されるべきである各WhoisはWHOIS++インデックスメッシュに関して+ + サーバどのテンプレートが望まれているかによる+ + サーバが変えることができる特定のWhois deault Whoisへの質問、およびクライアントの位置を送りますが、原則として、サーバはできるだけローカルであるべきです。
A
/ \
B C
/ \ \
Z -----> D E F
/ \
G H
/\B C/\\Z----->D E F/\G H
Fig 1: The client Z is configured to first query server D
図1: クライアントZは、最初にサーバDについて質問するために構成されます。
After getting responses from a server, the client can act in several ways. If the number of hits is greater than zero, the response is just presented to the user. If the client gets one or many servers- to-ask answers, the client should be able to automatically resolve these pointers, i.e. query these servers in turn.
サーバから応答を得た後に、クライアントはいくつかの方法で行動できます。 命中した数がゼロ以上であるなら、応答はただユーザに提示されます。 クライアントが1か多くのサーバを得る、-尋ねてください、答え、クライアントは自動的にこれらの指針を決議できるべきであって、すなわち、順番にこれらのサーバについて質問してください。
A
/ \
B C
/ \ \
Z <----- D E F
\ / \
--> G H
/\B C/\\Z<。----- D E F\/\-->G H
Fig 2: The client Z gets a "servers-to-ask G" response from D and
therefore may automatically queries server G.
図2: ZがDから「尋ねるサーバG」応答を得て、したがって自動的にそうするかもしれないクライアントはサーバGについて質問します。
3. How to navigate in the mesh
3. メッシュでナビゲートする方法
A client can use several different strategies when traversing or navigating around in the mesh. The automatic way of doing this is to just "expand the search" (described in 3.1) and a second method is to use the "Directory of Servers" (described in 3.2).
コネの周りでメッシュに横断するか、またはナビゲートするとき、クライアントはいくつかの異なった戦略を使用できます。 2番目のメソッドは「これをする自動方法がまさしく検索を広げる」(3.1では、説明されます)ことであり、「サーバのディレクトリ」(3.2では、説明される)を使用することです。
3.1. Expansion of searches
3.1. 検索の拡張
If the number of hits is zero, or if the user in some way wants to expand the search, it is recommended for the client to issue a 'polled-by' and 'polled-for' query to the server. The client can then repeat the original query to the new servers indicated.
命中した数がゼロである、または何らかの方法でユーザが検索を広げたいなら、発行するクライアントのために、aが'投票し'て、質問にサーバに'投票したこと'が勧められます。次に、クライアントは示された新しいサーバにオリジナルの質問を繰り返すことができます。
Faltstrom, et al Standards Track [Page 2] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[2ページ]
A
/ \
/-----> B C
/ / \ \
Z <----- D E F
/ \
G H
/\/----->B C//\\Z<。----- D E F/\G H
Fig 3: The client Z gets a "polled-by B" response from D and therefore
queries server B.
図3: クライアントZは、Dからaが「Bに投票した」という応答を得て、したがって、サーバBについて質問します。
The client must always keep track of which servers it has queried because it must itself detect loops in the mesh by not querying the same server more than once.
質問されなければならないのでそれで質問するサーバ自体が一度よりメッシュに同じサーバについてさらに質問しないことによって輪を検出するクライアントはいつも動向をおさえなければなりません。
A
/ \
/- B C
/ / \ \
Z <---/ D E F
/ \
G H
/\/B C//\\Z<。---/D E F/\G H
Fig 4: The client Z gets a "servers-to-ask D" response from B but Z
does not query D because the server D has already been queried.
図4: クライアントZはBから「尋ねるサーバD」応答を得ますが、サーバDが既に質問されたので、ZはDについて質問しません。
So, the default expansion of a query by a client causes increasingly more comprenhensive index servers to be queried; the forward knowledge contained in the index server mesh allows rapid pruning of these larger trees.
それで、クライアントによる質問のデフォルト拡張で、ますますより多くのcomprenhensiveインデックスサーバについて質問します。 インデックスサーバメッシュに含まれた前進の知識はこれらのより大きい木の急速な刈り込みを許容します。
All loop detection and elimination is done in the client, rather than in the server mesh. This decision was made because loop detection and elimination are quite difficult to build into the mesh if we are to continue to allow each server to participate in multiple hierarchies within the mesh.
すべての輪の検出とサーバメッシュでというよりむしろクライアントで除去します。 私たちが各サーバをメッシュの中の複数の階層構造にずっと参加させるつもりであるなら輪の検出と除去はメッシュに建てるのがかなり難しいので、この決定をしました。
3.1.1. Optimising the mesh
3.1.1. メッシュを最適化します。
If organization A tends to use organization B's WHOIS++ server frequently, for example if A is cooperating in a project with B, A may wish to make B's server locally available by creating a local index server which retrieves the centroid for both organizations. When A's client then expands a query which is looking for someone at B, the client can much more rapidly resolve the query, as it does not have to find the top level servers for the tree to which A and B both belong.
組織Aが、頻繁に組織ビーズWHOIS++サーバを使用する傾向があるなら、Aは、例えば、AがBと共にプロジェクトに協力しているなら、両方の組織のために図心を検索するローカルのインデックスサーバを作成することによって、ビーズサーバを局所的に利用可能にしたがっているかもしれません。 次に、AのクライアントがBでだれかを探している質問を広げるとき、クライアントははるかに急速に質問を決議できます、AとBがともに属する木のためにトップ平らなサーバを見つける必要はないとき。
Faltstrom, et al Standards Track [Page 3] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[3ページ]
A
/ \
B C
/ \ \
Z D --> F
/ \
G H
A/\B C/\\、Z D-->F/\G H
Fig 5: The server B gets a centroid from server F
図5: サーバBはサーバFから図心を得ます。
A
/ \
B C
/ \ \
Z <----> D --- F
/ \
G H
/\B C/\\Z<。---->D--- F/\G H
Fig 6: The client queries server D, gets zero hits back, expands the
search and gets a "polled-by B" response back.
図6: クライアントは、サーバDについて質問して、ヒットを全く取り戻さないで、検索を広げて、aが「Bに投票した」という応答を到着して戻させます。
A
/ \
/--> B C
/ / \ \
Z <-/ D --- F
/ \
G H
/\/-->B C//\\Z</D--- F/\G H
Fig 7: The client Z queries server B and gets "servers-to-ask F"
response back.
図7: クライアントZは、サーバBについて質問して、「尋ねるサーバF」応答を到着して戻させます。
A
/ \
B C
/ \ \
D --- F <-----> Z
/ \
G H
/\B C/\\D--- F<。----->Z/\G H
Fig 8: The client Z queries server F and gets the answer.
図8: クライアントZは、サーバFについて質問して、答えを得ます。
The example given in Fig 5-8 shows that the algorithm works even though the Whois++ mesh is not a tree. There are many reasons why a given index server mesh might be 'short-circuited'. For example, in the case of a multinational company, the Swedish branch of Acme Inc., is polled both by the national server in Sweden and the headquarters server in the USA. By querying the Swedish server, one finds all
図5-8で出された例は、Whois++メッシュが木ではありませんが、アルゴリズムが働くのを示します。 与えられたインデックスサーバメッシュが'短絡するかもしれない'多くの理由があります。 例えば、多国籍企業に関するケース、Acme Inc.のスウェーデンのブランチでは、ともにスウェーデンと本部の国家のサーバで、米国のサーバに投票しています。 スウェーデンのサーバについて質問することによって、人はすべてを見つけます。
Faltstrom, et al Standards Track [Page 4] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[4ページ]
persons working at the Swedish branch of Acme Inc., but by querying the Acme Inc. server in the USA, you will find all employees in the company, including those in Sweden.
人々がAcme Inc.のスウェーデンの支店で働いていますが、米国でAcme株式会社サーバについて質問することによって働いていると、あなたは会社で全社員を見つけるでしょう、スウェーデンにそれらを含んでいて。
Note that the location of a server does not implicitly narrow the search, i.e. you have to specify all information when sending a query to a server. In the example above, one can see that by just querying a server for companies in the USA, you will not implicitly only get hits from records in the states, because the Acme Inc. server in the states has polled a server in Sweden. So, in this case you have to explicitly include "country=USA" in the query if you are only interested in those records.
サーバの位置がそれとなく検索を狭くしないというメモ、質問をサーバに送るとき、すなわち、あなたはすべての情報を指定しなければなりません。上では、例では、人が、会社のために米国でただサーバについて質問することによって、あなたが州で記録からヒットをそれとなく得るだけではないのを見ることができます、州のAcme株式会社サーバがスウェーデンのサーバに投票したので。 それで、この場合、それらの記録に関心があるだけであるなら、あなたは質問で明らかに「国=の米国」を入れなければなりません。
Although the WHOIS++ index service has been designed to make searches at any location in the index mesh quite effective and efficient, blindly expanding the query can incur an exponentially growing cost in resources, and, as charging for responses is implemented in parts of the WHOIS++ index service mesh, growing cost, automatic expansion is not recommended. More sophisticated clients should also be configurable to "cut off" some servers from a search, i.e. a blacklist of servers. This might be needed when searching for records and one server might have a very high cost (in dollars) so one might want to explicitly forbid the client to send queries to that server.
WHOISですが、+ + インデックスサービスはインデックスメッシュのどんな位置での検索もかなり効果的で効率的にするように設計されています、そして、盲目的に質問を広げると、リソースの指数関数的に増加している費用を被ることができます、そして、応答に課金するのがWHOISの部分で+ + インデックスサービスメッシュで、増加していた状態で実装されるとき、費用、自動拡張は推薦されません。 また、より洗練されたクライアントもすなわち、検索、サーバに関するブラックリストからいくつかのサーバを「中断すること」において構成可能であるべきです。 記録を検索して、1つのサーバに非常に高い費用があるかもしれないなら(ドルで)これが必要であるかもしれないので、人は、クライアントがそのサーバに質問を送るのを明らかに禁じたがっているかもしれません。
3.1.2. The algorithm used by the client
3.1.2. クライアントによって使用されたアルゴリズム
By following this algorithm a client finds all records in a mesh which the first Whois++ server queried belongs to.
クライアントが見つけるこのアルゴリズムに従うことで、すべてが、+ + サーバが質問した最初のWhoisがどれに属するかをメッシュに記録します。
The algorithm for the client follows:
クライアントのためのアルゴリズムは従います:
Query := data to search for;
QueriedServers := {};
AnswerList := {};
OriginalServers := { known servers to this client };
while OriginalServers is not empty do:
ServerList = OriginalServers;
while ServerList is not empty do:
Server := ServerList[1];
if Server is not in QueriedServers then do:
send Query to Server;
Answer := answer from Server;
append ServersToAsk to ServerList;
remove Server from ServerList;
append Answers to AnswerList;
end;
done;
if query should be expanded then do:
検索する:=データについて質問してください。 QueriedServers:=、。 AnswerList:=、。 OriginalServers:=、このクライアントへの知られているサーバ。 OriginalServersが空でない間、以下をしてください。 ServerListはOriginalServersと等しいです。 ServerListが空でない間、以下をしてください。 サーバ:=ServerList[1]。 ServerがQueriedServersにないなら、以下をしてください。 QueryをServerに送ってください。 Serverから:=答えに答えてください。 ServersToAskをServerListに追加してください。 ServerListからServerを取り外してください。 AnswersをAnswerListに追加してください。 終わってください。 します。 質問が広げられるなら、以下をしてください。
Faltstrom, et al Standards Track [Page 5] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[5ページ]
ServerList := OriginalServers;
OriginalServers := {};
while ServerList is not empty do:
Server := ServerList[1];
send Polled-For-Query to Server;
Answer := answer from Server;
append Answer to OriginalServers;
remove Server from ServerList;
end;
done;
done;
display AnswerList to user;
ServerList:=OriginalServers。 OriginalServers:=、。 ServerListが空でない間、以下をしてください。 サーバ:=ServerList[1]。 質問のためのPolledをServerに送ってください。 Serverから:=答えに答えてください。 AnswerをOriginalServersに追加してください。 ServerListからServerを取り外してください。 終わってください。 します。 します。 ユーザにAnswerListを表示してください。
3.2. The Directory of Servers
3.2. サーバのディレクトリ
A second way of finding the correct server to query is to use a separate service we call the Directory of Servers. The Directory of Servers is a special Whois++ server which polls every Whois++ server for information about common information among the records on that perticular server.
質問する正しいサーバを見つける2番目の方法は私たちがServersのディレクトリを呼ぶ別々のサービスを利用することです。 Serversのディレクトリは一般的な情報の情報のためにそのperticularサーバに関する記録の中であらゆるWhois++サーバに投票する特別なWhois++サーバです。
3.2.1. How should a client use the Directory of Servers?
3.2.1. クライアントはどのようにServersのディレクトリを使用するべきですか?
A client that want to very quickly find what servers serves USER templates in Sweden, should do it this way:
スウェーデンで非常にすぐにどんなサーバサーブにUSERテンプレートを見つけたいか、そして、このようにそれをするべきであるクライアント:
1) The hostname and portnumber of the directory of Servers have
to be preconfigured in the current version of the protocol.
1) Serversのディレクトリのホスト名とportnumberはプロトコルの最新版であらかじめ設定されなければなりません。
2) Query the Directory of Servers for serverhandle records for
country sweden. This gives information of all these servers.
By presenting this information to the user the user should be
able to start the search at some closer server.
2) 国のswedenのためのserverhandle記録のためにServersのディレクトリについて質問してください。 これはこれらのすべてのサーバの情報を教えます。 この情報をユーザに提示することによって、ユーザは何らかのより近いサーバで検索を始めることができるべきです。
Note that we at this moment doesn't think this should be an autmatic process in the client. The Directory of Servers should be used for giving the user information about what Whois++ servers that exists.
私たちが、この瞬間これがクライアントのautmaticプロセスであるべきであると思わないことに注意してください。 Serversのディレクトリは、それがどんなWhois++サーバに関して存在しているかというユーザー情報を与えるのに使用されるべきです。
In the future a technique might have developed that makes it possible for a client to do this selection automatically depending on the query the user issues.
将来、ユーザが発行する質問によって、クライアントが自動的にこの選択をするのを可能にする技術は見いだされたかもしれません。
Faltstrom, et al Standards Track [Page 6] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[6ページ]
3.2.2. What does the serverhandle record look like?
3.2.2. serverhandle記録は何に似ていますか?
The attributes that must be in all serverhandle records are:
すべてのserverhandle記録にあるに違いない属性は以下の通りです。
Server-Handle: The handle for this server. Host-Name: The (current) hostname of this server. Host-Port: The (current) portnumber for this server.
サーバハンドル: これには、サーバホスト名を扱ってください: このサーバの(現在)のホスト名、ホストポート: このサーバのための(現在)のportnumber。
Part from that information, the record can include other attributes like:
その情報と別れてください、そして、記録は以下のような他の属性を含むことができます。
Admin-Name: Patrik Faltstrom Admin-Email: paf@bunyip.com Admin-Phone: +1-514-875-8611 Organization-Name: Bunyip Information Systems Inc. Description: USER information Menu-Item: World (Bunyip Information Systems inc) City: Montreal State: Quebec Country: Canada : : (Other attributes that can identify all records on this server, for example domainname)
アドミン名: パトリクFaltstromアドミンメール: paf@bunyip.com アドミン電話: +1-514-875-8611 組織名: 詐欺師情報システム株式会社記述: USER情報のMenu-品目: 世界(詐欺師情報Systems inc)市: モントリオール州: ケベック国: カナダ: : (このサーバ、例えば、ドメイン名に関するすべての記録を特定できる他の属性)
The information in the Navigation record is intended to be presented to a user.
Navigation記録の情報によってユーザに提示されることを意図します。
3.2.3. Example
3.2.3. 例
An example of how an interaction with the Directory of Servers is
done follows. The characters '<' and '>' displays if it is the client
('<') or responding server ('>') which is responsible for the output:
Serversのディレクトリとの相互作用がどう完了しているかに関する例は従います。 キャラクタの'<'と'>'はそれが出力に原因となるクライアント('<')か応じるサーバ('>')であるなら表示します:
> % 220-This is services.bunyip.com running Bunyip-Whois++: DIGGER 1.0.5 > % 220 Ready to go! < template=serverhandle and bunyip > % 200 Search is executing > # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01 > SERVER-HANDLE: BUNYIPCOM01 > HOST-NAME: services.bunyip.com > HOST-PORT: 63 > ADMIN-NAME: Patrik Faltstrom > ADMIN-EMAIL: paf@bunyip.com > ORGANIZATION-NAME: Bunyip Information Systems Inc. > DESCRIPTION: USER information > DESCRIPTION: Directory of Servers > DESCRIPTION: Toplevel Index server in the world
>%、220、-、これ、services.bunyip.com走りBunyip-Whois++です: 行くDIGGER1.0.5>%220Ready! <テンプレート=serverhandleと詐欺師>%200検索は>#FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01>SERVER-HANDLEを実行しています: BUNYIPCOM01>ホスト名: services.bunyip.com>HOST-PORT: 63>アドミン名: パトリクFaltstrom>アドミンメール: paf@bunyip.com 、gt;、組織名: 詐欺師情報システム株式会社>記述: USER情報>記述: サーバ>記述のディレクトリ: 世界のToplevel Indexサーバ
Faltstrom, et al Standards Track [Page 7] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[7ページ]
> MENU-ITEM: World (Bunyip Information Systems inc) > CITY: Montreal > COUNTRY: Canada > # END > > # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM02 > SERVER-HANDLE: BUNYIPCOM02 > HOST-NAME: services.bunyip.com > HOST-PORT: 7778 > ADMIN-NAME: Patrik Faltstrom > ADMIN-EMAIL: paf@bunyip.com > ORGANIZATION-NAME: Bunyip Information Systems Inc. > DESCRIPTION: USER information > MENU-ITEM: Bunyip Information Systems > CITY: Montreal > COUNTRY: Canada > # END > > % 226 Transaction complete > % 203 Bye, bye
>メニュー品目: 世界(詐欺師情報Systems inc)>市: モントリオール>国: カナダ>#は>の#完全なSERVERHANDLE BUNYIPCOM01 BUNYIPCOM02>サーバ>ハンドルを終わらせます: BUNYIPCOM02>ホスト名: services.bunyip.com>HOST-PORT: 7778年の>アドミン名: パトリクFaltstrom>アドミンメール: paf@bunyip.com 、gt;、組織名: 詐欺師情報システム株式会社>記述: USER情報>MENU-ITEM: 詐欺師情報システム>都市: モントリオール>国: カナダ>#END>>%226Transactionが>%203Byeを完成する、さようなら
4. Caching
4. キャッシュ
A client can cache all information it gets from a server for some time. For example records, IP-addresses of Whois++ servers, the Directory of Services server etc.
クライアントはそれがしばらくサーバから得るすべての情報をキャッシュできます。 例えば、+ + サーバ、ServicesのWhoisディレクトリのIP-アドレスサーバ記録など
A client can itself choose for how long it should cache the information.
クライアント缶自体はそれがどれくらい長い間情報をキャッシュするべきであるかに選ばれます。
The IP-address of the Directory of Services server might not change for a day or two, and neither might any other information.
ServicesサーバのディレクトリのIP-アドレスは1日か2日間、変化しないかもしれません、そして、いかなる他の情報もそうしないかもしれません。
4.1. Caching a Whois++ servers hostname
4.1. Whois++サーバホスト名をキャッシュします。
An example of cached information that might change is the chached hostname, IP-address and portnumber which a client gets back in a servers-to-ask response. That information is cached in the server since the last poll, which might occurred several weeks ago. Therefore, when such a connection fails, the client should fall back to use the serverhandle insted, which means that it contacts the Directory of Services server and queries for a server with that serverhandle. By doing this, the client should always get the last known hostname.
変化するかもしれないキャッシュされた情報に関する例は、chachedホスト名と、IP-アドレスとクライアントが尋ねるサーバ応答で取り戻すportnumberです。 最後の投票以来情報がサーバでキャッシュされるのは数週間前に起こりました。(投票はそうするかもしれません)。 したがって、そのような接続が失敗すると、クライアントは、serverhandle instedを使用するために後ろへ下がるべきです。(serverhandle instedはそのserverhandleでサーバのためのServicesサーバと質問のディレクトリに連絡することを意味します)。 そうすれば、クライアントはいつも最後に知られているホスト名を得るべきです。
Faltstrom, et al Standards Track [Page 8] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[8ページ]
An algorithm for this might be:
これのためのアルゴリズムは以下の通りです。
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server
接続やり損ないがエラーメッセージと共に出るなら接続やり損ないがホストのためのサーバIP-アドレス:=がDNSで接続するのがresponse.hostnameのためのip-アドレスがわかるServicesのディレクトリからポートresponse.portnumberのip-アドレスまでのserverhandle response.serverhandle応答:=応答によるServicesサーバ質問のディレクトリに接続するなら、A IP-アドレス:=が、ポートresponse.portnumberでipに扱うために中のresponse.hostnameのためのipアドレスのDNSが接続するのがわかるサーバからの応答:=尋ねるサーバ応答はこの新しいサーバについて質問します。
5. Security Considerations
5. セキュリティ問題
Security considerations when using the Whois++ protocol is described in [Deutsch94].
Whoisを使用して、+ + プロトコルが[Deutsch94]で説明されるセキュリティ問題。
A client should be able to have a "blacklist" of servers it should not query, because it might happen that fake Whois++ servers is put up on the net. When such a fake Whois++ servers is found, a user should be able to configure it's client to never query this server.
クライアントは+ + サーバがネットに置かれるWhoisを見せかけるそれが起こるかもしれないので質問するべきでないサーバの「ブラックリスト」を持つことができるべきです。 そのようなにせのWhoisであるときに、+ + サーバは見つけられて、ユーザは、このサーバについて決して質問しないようにそれがクライアントであることを構成できるべきです。
Note that a client should be careful when expanding a query by either using normal expansion or using the directory of servers. A query might take a long time, so a user should be able to quit in the middle of such a transaction. This is though more a question of user interaction than a plain security issue.
通常の拡張を使用するか、またはサーバのディレクトリを使用することによって質問を広げるとき、クライアントが慎重であるはずであることに注意してください。 質問が長くかかるかもしれないので、ユーザはそのようなトランザクションの中央でやめることができるべきです。 明瞭な安全保障問題よりユーザ相互作用の問題ですが、これはそうです。
6. References
6. 参照
[Deutsch94] Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
"Architecture of the Whois++ service", RFC 1835,
August 1995.
[Deutsch94] ドイツ語P.、Schoultz R.、Faltstrom P.、およびC.ワイダー、「Whois++サービスのアーキテクチャ」、RFC1835、1995年8月。
[Weider94] Weider C., Fullton J., and S. Spero, "Architecture of
the WHOIS++ Index Service", RFC 1913, February 1996.
[Weider94] ワイダーC.、Fullton J.、およびS.スペロウ、「WHOIS++インデックスサービスのアーキテクチャ」、RFC1913、1996年2月。
Faltstrom, et al Standards Track [Page 9] RFC 1914 How to Interact with a Whois++ Mesh February 1996
Faltstrom、Whois++があるInteractへのRFC1914Howが1996年2月に網の目にかける他のStandards Track[9ページ]
7. Authors' Addresses
7. 作者のアドレス
Patrik Faltstrom BUNYIP INFORMATION SYSTEMS, inc 310 St Catherine St West, Suite 300 Montreal, Quebec CANADA H2X 2A1
パトリクFaltstrom BUNYIP情報SYSTEMS、inc310通りキャサリンSt西洋、Suite300モントリオール、ケベックCANADA H2X 2A1
EMail: paf@bunyip.com
メール: paf@bunyip.com
Rickard Schoultz KTHNOC, SUNET/NORDUnet/Ebone Operations Centre S-100 44 STOCKHOLM SWEDEN
リカードSchoultz KTHNOC、SUNET/NORDUnet/Ebone操作はS-100 44ストックホルムスウェーデンを集中させます。
EMail: schoultz@sunet.se
メール: schoultz@sunet.se
Chris Weider BUNYIP INFORMATION SYSTEMS, inc 310 St Catherine St West, Suite 300 Montreal, Quebec CANADA H2X 2A1
クリスワイダーBUNYIP INFORMATION SYSTEMS、inc310通りキャサリンSt西洋、Suite300モントリオール、ケベックCANADA H2X 2A1
EMail: clw@bunyip.com
メール: clw@bunyip.com
Faltstrom, et al Standards Track [Page 10]
Faltstrom、他のStandards Track[10ページ]
一覧
スポンサーリンク
