RFC1913 日本語訳
1913 Architecture of the Whois++ Index Service. C. Weider, J. Fullton,S. Spero. February 1996. (Format: TXT=33743 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Weider
Request for Comments: 1913 Bunyip
Category: Standards Track J. Fullton
CNIDR
S. Spero
EIT
February 1996
コメントを求めるワーキンググループC.ワイダーの要求をネットワークでつないでください: 1913年の詐欺師カテゴリ: 標準化過程J.Fullton CNIDR S.スペロウEIT1996年2月
Architecture of the Whois++ Index Service
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol.
作者は、分散データベースで索引をつけるためにアーキテクチャについて説明して、WHOIS++プロトコルにこれを適用します。
1. Purpose:
1. 目的:
The WHOIS++ directory service [Deutsch, et al, 1995] is intended to provide a simple, extensible directory service predicated on a template-based information model and a flexible query language. This document describes a general architecture designed for indexing distributed databases, and then applys that architecture to link together many of these WHOIS++ servers into a distributed, searchable wide area directory service.
テンプレートベースの情報モデルとフレキシブルな照会言語で叙述された簡単で、広げることができるディレクトリサービスを供給する+ + ディレクトリサービス[ドイツ語、他、1995]が意図するWHOIS。 このドキュメントは分散データベースに索引をつけるように設計された一般的なアーキテクチャについて説明します、そして、次に、applysはこれらのWHOIS++サーバの多くを分配されて、探せる広い領域ディレクトリサービスに結びつけるそのアーキテクチャについて説明します。
2. Scope:
2. 範囲:
This document details a distributed, easily maintained architecture for providing a unified index to a large number of distributed WHOIS++ servers. This architecture can be used with systems other than WHOIS++ to provide a distributed directory service which is also searchable.
このドキュメントは、多くの分配されたWHOIS++サーバに統一されたインデックスを提供するために分配されて、容易に維持されたアーキテクチャを詳しく述べます。 また、探せる分配されたディレクトリサービスを提供するのにWHOIS++を除いたシステムと共にこのアーキテクチャを使用できます。
3. Motivation and Introduction:
3. 動機と序論:
It seems clear that with the vast amount of directory information potentially available on the Internet, it is simply not feasible to build a centralized directory to serve all this information. If we are to distribute the directory service, the easiest (although not
このすべての情報に役立つのはインターネットで潜在的に利用可能なディレクトリ情報の広大な量で、集結されたディレクトリを造るのが絶対に可能でないことが明確に思えます。 私たちがディレクトリサービス、最も簡単であるのを分配するつもりである、(
Weider, et al Standards Track [Page 1] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[1ページ]RFC
necessarily the best) way of building the directory service is to build a hierarchy of directory information collection agents. In this architecture, a directory query is delivered to a certain agent in the tree, and then handed up or down, as appropriate, so that the query is delivered to the agent which holds the information which fills the query. This approach has been tried before, most notably in some implementations of the X.500 standard. However, there are number of major flaws with the approach as it has been taken. This new Index Service is designed to fix these flaws.
必ずベスト) ディレクトリサービスを建てる方法はディレクトリ情報収集エージェントの階層構造を築き上げることです。 このアーキテクチャでは、ディレクトリ質問は、木の確信しているエージェントに提供されて、次に、手渡されて、下がっています、適宜、質問がエージェントに提供されるように(質問をいっぱいにする情報を保持します)。 このアプローチを以前、X.500規格のいくつかの実装で最も著しく試みてあります。 しかしながら、それを取ったとき、アプローチがある主要な欠点の数があります。 この新しいIndex Serviceは、これらの欠点を修理するように設計されています。
3.1. The search problem
3.1. 検索問題
One of the primary assumptions made by recent implementations of distributed directory services is that every entry resides in some location in a hierarchical name space. While this arrangement is ideal for reading the entry once one knows its location, it is not as good when one is searching for the location in the namespace of those entries which meet some set of criteria. If the only criteria we know about a desired entry are items which do not appear in the namespace, we are forced to do a global query. Whenever we issue a global query (at the root of the namespace), or a query at the top of a given subtree in the namespace, that query is replicated to "all" subtrees of the starting point. The replication of the query to all subtrees is not necessarily a problem; queries are cheap. However, every server to which the query has been replicated must process that query, even if it has no entries which match the specified criteria. This part of the global query processing is quite expensive. A poorly designed namespace or a thin namespace can cause the vast majority of queries to be replicated globally, but a very broad namespace can cause its own navigation problems. Because of these problems, search has been turned off at high levels of the X.500 namespace.
分配されたディレクトリサービスの最近の実装によってされたプライマリ仮定の1つはあらゆるエントリーが階層的な名前スペースのいくらかの位置に住んでいるということです。 人がいったん位置を知っているとエントリーを読むのに、このアレンジメントは理想的ですが、1つが何らかのセットの評価基準を満たすそれらのエントリーの名前空間における位置を捜し求めているとき、それは良くはありません。 私たちが必要なエントリーに関して知っている唯一の評価基準が名前空間に現れない商品であるなら、私たちはやむを得ずグローバルな質問をします。 私たちが名前空間における与えられた下位木の先端でグローバルな質問(名前空間の根の)、または質問を発行するときはいつも、その質問は出発点の「all」の下位木に模写されます。 すべての下位木への質問の模写は必ず問題であるというわけではありません。 質問は安いです。 しかしながら、質問を模写してあるあらゆるサーバがその質問を処理しなければなりません、それに指定された評価基準に合っているエントリーが全くなくても。 グローバルな問い合わせ処理のこの部分はかなり高価です。 不十分に設計された名前空間か薄い名前空間でかなりの大多数の質問をグローバルに模写できますが、非常に広い名前空間はそれ自身のナビゲーション問題を引き起こす場合があります。これらの問題のために、検索はX.500名前空間の高いレベルでオフにされました。
3.2. The location problem
3.2. 位置問題
With global search turned off, one must know in advance how the name space is laid out so that one can guide a query to a proper location. Also, the layout of the namespace then becomes critical to a user's ability to find the desired information. Thus there are endless battles about how to lay out the name space to best serve a given set of users, and enormous headaches whenever it becomes apparent that the current namespace is unsuited to the current usages and must be changed (as recently happened in X.500). Also, assuming one does impose multiple hierarchies on the entries through use of the namespace, the mechanisms to maintain these multiple hierarchies in X.500 do not exist yet, and it is possible to move entries out from under their pointers. Also, there is as yet no agreement on how the X.500 namespace should look even for the White Pages types of information that is currently installed in the X.500 pilot project.
グローバル検索がオフにされている状態で、あらかじめ、1つが適切な位置に質問を誘導できるように名前スペースがどのように広げられるかを知らなければなりません。 また、そして、名前空間のレイアウトは必要な情報を見つけるユーザの能力に重要になります。 したがって、現在の名前空間を現在の用法に不適当であり、変えなければならないのが(同じくらい最近、X.500で起こります)明らかになるときはいつも、与えられたセットのユーザ、および莫大な頭痛に最もよく役立つように、どうスペースという名前を広げるかに関して無限の戦いがあります。 人がエントリーのときに終えた複数の階層構造を課すとまた仮定すること名前空間、X.500のこれらの複数の階層構造がまだ存在していないと主張するメカニズム、およびそれの使用がそれらの指針の下でエントリーを外へ出すのにおいて可能である。 また、まだ、X.500名前空間がどう現在X.500試験計画にインストールされる情報のホワイトページタイプさえ探すべきであるかに関する協定が全くありません。
Weider, et al Standards Track [Page 2] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[2ページ]RFC
3.3. The Yellow Pages problem
3.3. イエローページ問題
Current implementations of this hierarchical architecture have also been unsuited to solving the Yellow Pages problem; that is, the problem of easily and flexibly building special-purpose directories (say of molecular biologists) and of automatically maintaining these directories once they have been built. In particular, the attributes appropriate to the new directory must be built into the namespace because that is the only way to segregate related entries into a place where they can be found without a global search. Also, there is a classification problem; how does one adequately specify the proper categories so that people other than the creator of the directory can find the correct subtree? Additionally, there is the problem of actually finding the data to put into the subtree; if one must traverse the hierarchy to find the data, we have to look globally for the proper entries.
また、この階層的なアーキテクチャの現在の実装もイエローページ問題を解決するのに不適当です。 すなわち、簡単に柔軟に、専用ディレクトリ(分子生物学者について言う)を造って、それらがいったん建てられると自動的にこれらのディレクトリを維持するという問題。 それがグローバル検索なしでそれらを見つけることができる場所に関連するエントリーを隔離する唯一の方法であるので、特に、名前空間を新しいディレクトリに適切な属性に組み込まなければなりません。 また、分類問題があります。 1つは、ディレクトリのクリエイター以外の人々が正しい下位木を見つけることができるように、どのように適切に適切なカテゴリを指定しますか? さらに、実際に下位木に置くデータを見つけるという問題があります。 データを見つけるために階層構造を横断しなければならないなら、私たちは適切なエントリーをグローバルに探さなければなりません。
3.4. Solutions
3.4. ソリューション
The problems examined in this section can be addressed by a combination of two new techniques: directory meshes and forward knowledge.
2つの新しいやり方の組み合わせでこのセクションで調べられた問題は扱うことができます: ディレクトリメッシュと前進の知識。
4. Directory meshes and forward knowledge
4. ディレクトリメッシュと前進の知識
We'll hold off for a moment on describing the actual architecture used in our solution to these problems and concentrate on a high level description of what solutions are provided by our conceptual approach. To begin with, although every entry in WHOIS++ does indeed have a unique identifier (resides in a specific location in the namespace) the navigational algorithms to reach a specific entry do not necessarily depend on the identifier the entry has been assigned. The Index Service gets around the namespace and hierarchy problems by creating a directory mesh on top of the entries. Each layer of the mesh has a set of 'forward knowledge' which indicates the contents of the various servers at the next lower layer of the mesh. Thus when a query is received by a server in a given layer of the mesh, it can prune the search tree and hand the query off to only those lower level servers which have indicated that they might be able to answer it. Thus search becomes feasible at all levels of the mesh. In the current version of this architecture, we have chosen a certain set of information to hand up the mesh as forward knowledge. This may or may not be exactly the set of information required to construct a truly searchable directory, but the protocol itself doesn't restrict the types of information which can be handed around.
私たちは、私たちのソリューションにこれらの問題に使用される実際のアーキテクチャについて説明するときちょっと距離を保って、私たちの概念的アプローチでどんな解決法を提供するかに関する高い平らな記述に集中するつもりです。 初めに、WHOIS++のあらゆるエントリーには、ユニークな識別子(名前空間における特定の位置では、住んでいる)が本当にありますが、特定のエントリーに達するナビゲーション上のアルゴリズムは必ずエントリーを割り当ててある識別子によるというわけではありません。 Index Serviceは、エントリーの上でディレクトリメッシュを作成することによって、名前空間と階層構造問題を逃れます。 メッシュの各層には、メッシュの次の下層で様々なサーバのコンテンツを示す1セットの'前進の知識'があります。 したがって、メッシュの与えられた層の中でサーバで質問を受けるとき、それは、彼らがそれに答えることができるかもしれないのを示したそれらの下のレベルサーバだけに、検索木を剪定して、質問を渡すことができます。 したがって、検索はメッシュのすべてのレベルで可能になります。 このアーキテクチャの最新版では、私たちは、前進の知識としてメッシュを手渡すためにある情報を選びました。 これはまさに本当に探せるディレクトリを構成するのに必要である情報のセットであるかもしれませんが、プロトコル自体は回すことができる情報のタイプを制限しません。
In addition, the protocols designed to maintain the forward knowledge will also work perfectly well to provide replication of servers for
追加、サーバの模写を提供するまた、前進の知識が完全にうまくいくと主張するように設計されたプロトコルで
Weider, et al Standards Track [Page 3] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[3ページ]RFC
redundancy and robustness. In this case, the forward knowledge handed around by the protocols is the entire database of entries held by the replicated server.
冗長と丈夫さ。 この場合、プロトコルによって回された前進の知識は模写されたサーバによって保持されたエントリーの全体のデータベースです。
Another benefit provided by the mesh of index servers is that since the entry identification scheme has been decoupled from the navigation service, multiple hierarchies can be built and easily maintained on top of the existing data. Also, the user does not need to know in advance where in the mesh the entry is contained.
インデックスサーバのメッシュによって提供された別の利益はエントリー識別体系がナビゲーションサービスから衝撃を吸収されたので、複数の階層構造を築き上げて、既存のデータの上で容易に維持できるということです。 また、ユーザは、あらかじめ、メッシュでは、エントリーがどこに含まれているかを知る必要はありません。
Also, the Yellow Pages problem now becomes tractable, as the index servers can pick and choose between information proffered by a given server; because we have an architecture that allows for automatic polling of data, special purpose directories become easy to construct and to maintain.
また、現在イエローページ問題は御しやすくなります、インデックスサーバが与えられたサーバによって提供された情報を選んで、選ぶことができるとき。 私たちにはデータの自動ポーリングを考慮するアーキテクチャがあるので、専用ディレクトリは組み立てて、維持するのが簡単になります。
5. Components of the Index Service:
5. インデックスサービスのコンポーネント:
5.1. WHOIS++ servers
5.1. WHOIS++サーバ
The whois++ service is described in [Deutsch, et al, 1995]. As that service specifies only the query language, the information model, and the server responses, whois++ services can be provided by a wide variety of databases and directory services. However, to participate in the Index Service, that underlying database must also be able to generate a 'centroid', or some other type of forward knowledge, for the data it serves.
+ + サービスが説明されるwhois[ドイツ語、他、1995]。 そのサービスが照会言語、情報モデル、およびサーバ応答だけを指定するので、whoisですさまざまなデータベースとディレクトリサービスで+ + サービスを提供できる。 しかしながら、Index Serviceに参加するために、また、その基本的なデータベースは'図心'、またはある他のタイプの前進の知識を生成することができなければなりません、それが役立つデータのために。
5.2. Centroids as forward knowledge
5.2. 前進の知識としての図心
The centroid of a server is comprised of a list of the templates and attributes used by that server, and a word list for each attribute. The word list for a given attribute contains one occurrence of every word which appears at least once in that attribute in some record in that server's data, and nothing else.
サーバの図心はそのサーバによって使用されるテンプレートと属性のリスト、および各属性のための単語リストから成ります。 与えられた属性のための単語リストはそのサーバのデータ、および他に何もでの何らかの記録のその属性に少なくとも一度現れるあらゆる単語の1回の発生を含んでいます。
A word is any token delimited by blank spaces, newlines, or the '@' character, in the value of an attribute.
単語は属性の値で空白の空間、ニューライン、または'@'キャラクタによって区切られたあらゆるトークンです。
For example, if a whois++ server contains exactly three records, as follows:
例えば、whoisであるなら、+ + サーバは以下の通りまさに3つの記録を含んでいます:
Record 1 Record 2 Template: User Template: User First Name: John First Name: Joe Last Name: Smith Last Name: Smith Favourite Drink: Labatt Beer Favourite Drink: Molson Beer
記録1は2テンプレートを記録します: ユーザテンプレート: ユーザ、名: ジョン、名: ジョー姓: スミス姓: スミスFavouriteの飲み物: Labattビールお気に入りの飲み物: モルソンビール
Weider, et al Standards Track [Page 4] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[4ページ]RFC
Record 3 Template: Domain Domain Name: foo.edu Contact Name: Mike Foobar
3テンプレートを記録してください: ドメインドメイン名: foo.edu Contact Name: マイクFoobar
the centroid for this server would be
このサーバのための図心はそうでしょう。
Template: User
First Name: Joe
John
Last Name: Smith
Favourite Drink: Beer
Labatt
Molson
テンプレート: ユーザ、名: ジョージョン姓: スミスFavouriteの飲み物: ビールLabattモルソン
Template: Domain
Domain Name: foo.edu
Contact Name: Mike
Foobar
テンプレート: ドメインドメイン名: foo.edu Contact Name: マイクFoobar
It is this information which is handed up the tree to provide forward knowledge. As we mention above, this may not turn out to be the ideal solution for forward knowledge, and we suspect that there may be a number of different sets of forward knowledge used in the Index Service. However, the directory architecture is in a very real sense independent of what types of forward knowledge are handed around, and it is entirely possible to build a unified directory which uses many types of forward knowledge.
それは前進の知識を提供するために木に手渡されるこの情報です。 私たちが上に言及するように、これは前進の知識の理想的な解決であると判明しないかもしれません、そして、私たちはIndex Serviceで使用される多くの異なった前進の知識があるかもしれないと疑います。 しかしながら、どんなタイプの前進の知識が回されるかからディレクトリアーキテクチャは本質的には独立しています、そして、多くのタイプの前進の知識を使用する統一されたディレクトリを造るのは完全に可能です。
5.3. Index servers and Index server Architecture
5.3. インデックスサーバとIndexサーバArchitecture
A whois++ index server collects and collates the centroids (or other forward knowledge) of either a number of whois++ servers or of a number of other index servers. An index server must be able to generate a centroid for the information it contains. In addition, an index server can index any other server it wishes, which allows one base level server (or index server) to participate in many hierarchies in the directory mesh.
whois++インデックスサーバは、+ + サーバか他の多くのインデックスサーバの多くのwhoisの図心(または、他の前進の知識)を集めて、照合します。 インデックスサーバはそれが含む情報のために図心を生成することができなければなりません。 さらに、インデックスサーバはそれが願っているいかなる他のサーバにも索引をつけることができます(1つの基準面サーバ(または、インデックスサーバ)がディレクトリメッシュの多くの階層構造に参加できます)。
5.3.1. Queries to index servers
5.3.1. サーバに索引をつける質問
An index server will take a query in standard whois++ format, search its collections of centroids and other forward information, determine which servers hold records which may fill that query, and then notifies the user's client of the next servers to contact to submit the query (referral in the X.500 model). An index server can also contain primary data of its own; and thus act a both an index server and a base level server. In this case, the index server's response to
インデックスサーバは++形式、図心で他の収集が情報を転送する検索が決定する標準のwhoisでのサーバ保持が、質問(X.500モデルにおける紹介)を提出するために連絡するためにどれがその質問をいっぱいにするかもしれなくて、次に、次のサーバについてユーザのクライアントに通知するかを記録する質問を取るでしょう。 また、インデックスサーバはそれ自身のプライマリデータを含むことができます。 そして、その結果、aを活動させてください、インデックスサーバとa基準面サーバこの場合インデックスサーバの応答の両方
Weider, et al Standards Track [Page 5] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[5ページ]RFC
a query may be a mix of records and referral pointers.
質問は記録と紹介指針のミックスであるかもしれません。
5.3.2. Index server distribution model and centroid propogation
5.3.2. インデックスサーバ分配モデルと図心propogation
The diagram on the next page illustrates how a mesh of index servers might be created for a set of whois++ servers. Although it looks like a hierarchy, the protocols allow (for example) server A to be indexed by both server D and by server H.
次のページのダイヤグラムはインデックスサーバのメッシュが1セットのwhois++サーバのためにどう作成されるかもしれないかを例証します。 階層構造に似ていますが、プロトコルで、(例えば)サーバAはサーバDとサーバHによる両方で索引をつけます。
whois++ index index
servers servers servers
for for
whois++ lower-level
servers index servers
_______
| |
| A |__
|_______| \ _______
\----------| |
_______ | D |__ ______
| | /----------|_______| \ | |
| B |__/ \----------| |
|_______| | F |
/----------|______|
/
_______ _______ /
| | | |-
| C |--------------| E |
|_______| |_______|-
\
\
_______ \ ______
| | \----------| |
| G |--------------------------------------| H |
|_______| |______|
+ + 低レベルサーバがwhoisに関してサーバに索引をつけるので、whois++はインデックスサーバサーバサーバに索引をつけます。_______ | | | A|__ |_______| \ _______ \----------| | _______ | D|__ ______ | | /----------|_______| \ | | | B|__/ \----------| | |_______| | F| /----------|______| / _______ _______ / | | | |- | C|--------------| E| |_______| |_______|- \ \ _______ \ ______ | | \----------| | | G|--------------------------------------| H| |_______| |______|
Figure 1: Sample layout of the Index Service mesh
図1: Index Serviceメッシュのサンプルレイアウト
In the portion of the index tree shown above, whois++ servers A and B hand their centroids up to index server D, whois++ server C hands its centroid up to index server E, and index servers D and E hand their centroids up to index server F. Servers E and G also hand their centroids up to H.
上で見せられたインデックス木の一部では、whois++サーバAとBはそれらの図心をインデックスサーバDまで手渡します、また、+ + サーバCが図心をインデックスサーバEまで手渡して、インデックスサーバDとEがそれらの図心をインデックスサーバF.Servers EとGまで手渡すwhoisは彼らの図心をHまで手渡します。
The number of levels of index servers, and the number of index servers at each level, will depend on the number of whois++ servers deployed, and the response time of individual layers of the server tree. These numbers will have to be determined in the field.
インデックスサーバのレベルの数、および各レベルにおけるインデックスサーバの数は+ + サーバが配布したwhoisの数、およびサーバ木の個々の層の応答時間に依存するでしょう。 これらの数はその分野で決定しなければならないでしょう。
Weider, et al Standards Track [Page 6] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[6ページ]RFC
5.3.3. Centroid propogation and changes to centroids
5.3.3. 図心propogationと図心への変化
Centroid propogation is initiated by an authenticated POLL command (sec. 5.2). The format of the POLL command allows the poller to request the centroid of any or all templates and attributes held by the polled server. After the polled server has authenticated the poller, it determines which of the requested centroids the poller is allowed to request, and then issues a CENTROID-CHANGES report (sec. 5.3) to transmit the data. When the poller receives the CENTROID- CHANGES report, it can authenticate the pollee to determine whether to add the centroid changes to its data. Additionally, if a given pollee knows what pollers hold centroids from the pollee, it can signal to those pollers the fact that its centroid has changed by issuing a DATA-CHANGED command. The poller can then determine if and when to issue a new POLL request to get the updated information. The DATA-CHANGED command is included in this protocol to allow 'interactive' updating of critical information.
図心propogationは認証されたPOLLコマンドで開始されます。(秒 5.2). pollerは、POLLコマンドの形式からいずれかすべてのテンプレートと属性の図心が投票されたサーバを固守したよう要求できます。投票されたサーバがpollerを認証した後に、それは、pollerが要求された図心のどれに要求できるかを決定して、次に、CENTROID-CHANGESレポートを発行します。(秒 5.3) データを送るために。 pollerがCENTROID- CHANGESレポートを受け取るとき、それは、図心変化をデータに追加するかどうか決定するために世論調査の対象者を認証できます。 さらに、与えられた世論調査の対象者が、pollersが図心を何から隠すかを知っているなら、世論調査の対象者であり、それは図心がDATA-CHANGEDコマンドを発行することによって変化したという事実にそれらのpollersに合図できます。 そして、pollerは、問題に新しいPOLLが、アップデートされた情報を得るよう要求することを決定できます。 DATA-CHANGEDコマンドは、重要情報の'対話的な'アップデートを許すためにこのプロトコルに含まれています。
5.3.4. Centroid propogation and mesh traversal
5.3.4. 図心propogationとメッシュ縦断
When an index server issues a POLL request, it may indicate to the polled server what relationship it has to the polled. This information can be used to help traverse the directory mesh. Two fields are specified in the current proposal to transmit the relationship information, although it is expected that richer relationship information will be shared in future revisions of this protocol.
インデックスサーバがPOLL要求を出すとき、それは、どんな関係を投票に持っているかを投票されたサーバに示すかもしれません。 ディレクトリメッシュを横断するのを助けるのにこの情報を使用できます。 2つの分野が関係情報を伝えるという現在の提案で指定されます、より豊かな関係情報がこのプロトコルの今後の改正で共有されると予想されますが。
One field used for this information is the Hierarchy field, and can take on three values. The first is 'topology', which indicates that the indexing server is at a higher level in the network topology (e.g. indexes the whole regional ISP). The second is 'geographical', which indicates that the polling server covers a geographical area subsuming the pollee. The third is 'administrative', which indicates that the indexing server covers an administrative domain subsuming the pollee.
この情報に、中古の1つの分野が、Hierarchy分野であり、3つの値を呈することができます。 1番目はインデックスサーバがネットワーク形態(例えば、全体の地方のISPに索引をつける)により高いレベルにあるのを示す'トポロジー'です。 2番目は'地理的である'(世論調査サーバが世論調査の対象者を包括する地理的な領域をカバーするのを示します)。 第3は'管理である'(インデックスサーバが世論調査の対象者を包括する管理ドメインをカバーするのを示します)。
The second field used for this information is the Description field, which contains the DESCRIBE record of the polling server. This allows users to obtain richer metainformation for the directory mesh, enabling them to expand queries more effectively.
ユーザはこれで、より豊かなmetainformationをディレクトリメッシュに入手できます、彼らが質問で、より効果的に広がるのを可能にして。この情報に使用される2番目の分野は記述分野です。(それは、世論調査サーバに関するDESCRIBE記録を含みます)。
5.3.5. Query handling and passing algorithms
5.3.5. 質問取り扱いとアルゴリズムを通過すること。
When an index server receives a query, it searches its collection of centroids and determines which servers hold records which may fill that query. As whois++ becomes widely deployed, it is expected that some index servers may specialize in indexing certain whois++
インデックスサーバが質問を受けるとき、それは、図心の収集を捜して、どのサーバがその質問をいっぱいにするかもしれない記録を保持するかを決定します。 whoisとして、+ +は広く配布されるようになって、いくつかのインデックスサーバがインデックスのあるwhois++を専門に扱うかもしれないと予想されます。
Weider, et al Standards Track [Page 7] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[7ページ]RFC
templates or perhaps even certain fields within those templates. If an index server obtains a match with the query "for those template fields and attributes the server indexes", it is to be considered a match for the purpose of forwarding the query.
それらのテンプレートの中のテンプレートか恐らくある一定の分野さえ。 インデックスサーバが「サーバが索引をつけるそれらのテンプレート分野と属性」のための質問とのマッチを入手するなら、それは質問を進める目的のためのマッチであると考えられることになっています。
5.3.5.1. Query referral
5.3.5.1. 質問紹介
Query referral is the process of informing a client which servers to contact next to resolve a query. The syntax for notifying a client is outlined in section 5.5.
質問紹介は次に質問を決議するためにどのサーバに連絡するかをクライアントに知らせるプロセスです。 クライアントに通知するための構文はセクション5.5で概説されています。
5.3.6 Loop control
5.3.6 ループ制御
Since there are no a priori restrictions on which servers may poll which other servers, and since a given server may participate in many sub-meshes, mechanisms must be installed to allow the detection of cycles in the polling relationships. This is accomplished in the current protocol by including a hop-count on polling relationships. Each time a polled server generates forward information, it informs the polling server about its current hopcount, which is the maximum of the hopcounts of all the servers it polls, plus 1. A base level server (one which polls no other servers) will have a hopcount of 0. When a server decides to poll a new server, if its hopcount goes up, then it must information all the other servers which poll it about its new hopcount. A maximum hopcount (8 in the current version) will help the servers detect polling loops.
サーバがどの他のサーバに投票するかもしれない先験的な制限が全くなくて、与えられたサーバが多くのサブメッシュに参加するかもしれないので、世論調査関係における、サイクルの検出を許すためにメカニズムをインストールしなければなりません。 これは、世論調査関係で現在のプロトコルでホップカウントを含んでいることによって、達成されます。 投票されたサーバが前方に情報を生成する各回、それは現在のhopcountに関する世論調査サーバを知らせます。(hopcountはそれが投票するすべてのサーバ、および1のhopcountsの最大です)。 基準面サーバ(他のサーバに全く投票しないもの)には、0のhopcountがあるでしょう。 hopcountが上がるなら、サーバは、新しいサーバに投票すると決めて、次に、それは必須情報です。いつ、新しいhopcountの周りでそれに投票するもう片方のすべてのサーバ。 最大のhopcount(最新版における8)は、サーバが世論調査輪を検出するのを助けるでしょう。
A second approach to loop detection is to do all the work in the client; which would determine which new referrals have already appeared in the referral list, and then simply iterate the referral process until there are no new servers to ask. An algorithm to accomplish this in WHOIS++ is detailed in [Faltstrom 95].
検出を輪にする2番目のアプローチはクライアントですべての仕事をすることです。 尋ねるためにどんな新しいサーバもないまで、どの新しい紹介が紹介リストに既に現れたかを決定して、次に、単に紹介プロセスを繰り返します。 + +が詳細であるWHOIS[Faltstrom95]でこれを達成するアルゴリズム。
6. Syntax for operations of the Index Service:
6. Index Serviceの操作のための構文:
The syntax for each protocol componenet is listed below. In addition, each section contains a listing of which of these attributes is required and optional for each of the componenet. All timestamps must be in the format YYYYMMDDHHMM and in GMT.
それぞれのプロトコルcomponenetのための構文は以下に記載されています。 さらに、各セクションはそれぞれのcomponenetに、これらの属性のどれが必要であって、任意であるかに関するリストを含みます。 形式YYYYMMDDHHMMとグリニッジ標準時に、すべてのタイムスタンプがあるに違いありません。
6.1. Data changed syntax
6.1. データは構文を変えました。
The data changed template look like this:
データはこのようにテンプレート外観を変えました:
# DATA-CHANGED
Version-number: // version number of index service software, used to
// insure compatibility. Current value is 1.0
Time-of-latest-centroid-change: // time stamp of latest centroid
# データで変えられたバージョン番号: インデックスの//バージョン番号は、互換性をソフトウェアを調整して、/に使用されるか、または保障します。 現行価値は最新の図心変化の1.0Timeです: 最新の図心の//タイムスタンプ
Weider, et al Standards Track [Page 8] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[8ページ]RFC
// change, GMT
Time-of-message-generation: // time when this message was generated,
// GMT
Server-handle: // IANA unique identifier for this server
Host-Name: // Host name of this server (current name)
Host-Port: // Port number of this server (current port)
Best-time-to-poll: // For heavily used servers, this will identify
// when the server is likely to be lightly
// loaded so that response to the poll will be
//speedy, GMT
Authentication-type: // Type of authentication used by server, or NONE
Authentication-data: // data for authentication
# END // This line must be used to terminate the data changed
// message
//変化、グリニッジ標準時のメッセージ世代のTime: このメッセージが発生し、//グリニッジ標準時であった//時は以下をServer扱います。 このサーバHost-名のための//IANAのユニークな識別子: このサーバ(現在の名前)ホストポートの//ホスト名: このサーバ(現在のポート)の最も良い時間から投票の//ポートナンバー: 大いに使用されたサーバのための//、サーバが軽く、//が投票への応答が//迅速であるようにロードされたということである傾向があるときに、これは//を特定するでしょう、グリニッジ標準時のAuthentication-タイプ: サーバによって使用される認証の//タイプ、またはNONE Authentication-データ: データの変えられた//メッセージを終えるのにこれが裏打ちする認証#END//のための//データを使用しなければなりません。
Required/optional table
必要であるか任意のテーブル
Version-Number REQUIRED Time-of-latest-centroid-change REQUIRED Time-of-message-generation REQUIRED Server-handle REQUIRED Host-Name REQUIRED Host-Port REQUIRED Best-time-to-poll OPTIONAL Authentication-type OPTIONAL Authentication-data OPTIONAL
メッセージ世代の必要な時間が必要とした最新の図心変化の時間サーバハンドルが必要としたバージョン注文数のホスト名の必要なホストポートは任意の状態で最も良い時間から投票への認証タイプ任意の任意の認証データを必要としました。
6.2. Polling syntax
6.2. 世論調査構文
# POLL:
Version-number: // version number of poller's index software, used to
// insure compatibility
Type-of-poll: // type of forward data requested. CENTROID or QUERY
// are the only one currently defined
Poll-scope: // Selects bounds within which data will be returned.
// See note.
Start-time: // give me all the centroid changes starting at this
// time, GMT
End-time: // ending at this time, GMT
Template: // a standard whois++ template name, or the keyword ALL,
// for a full update.
Field: // used to limit centroid update information to specific
// fields, is either a specific field name, a list of field
// names, or the keyword ALL
Server-handle: // IANA unique identifier for the polling server.
// this handle may optionally be cached by the polled
// server to announce future changes
Host-Name: // Host name of the polling server.
# 以下に投票してください。 バージョン番号: //バージョンは、投票の互換性Typeを/に使用されるpollerのインデックスソフトウェアに付番するか、または保障します: 要求された前進のデータの//タイプ。 CENTROIDかQUERY//による唯一無二が現在Poll-範囲を定義したということです: //はデータが返される領域を選択します。 //は注意を見ます。 開始時刻: //はこの//時に始まるグリニッジ標準時のEnd-時に、すべての図心変化を私に与えます: このとき、グリニッジ標準時のTemplateを終わらせる//: //a規格は+ + テンプレート名、またはキーワードをwhoisします。すべて、完全なアップデートのための//。 以下をさばいてください。 図心アップデート情報を特定の//分野に制限するのにおいて//使用されていて、特定のフィールド名、分野//名のリスト、またはキーワードがすべてのServer-ハンドルです: //IANAのユニークな識別子、世論調査サーバにおいて. これが扱う//は投票された//サーバによって任意にキャッシュされて、未来がHost-名前を変えると発表するかもしれません: 世論調査サーバの//ホスト名。
Weider, et al Standards Track [Page 9] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[9ページ]RFC
Host-Port: // Port number of the polling server.
Hierarchy: // This field indicates the relationship which the poller
// bears to the pollee. Typical values might include
// 'Topology', 'Geographical", or "Administrative"
Description: // This field contains the DESCRIBE record of the
// polling server
Authentication-type: // Type of authentication used by poller, or NONE
Authentication-data: // Data for authentication
# END // This line must by used to terminate the poll message
ホストポート: 世論調査サーバの//ポートナンバー、階層構造: これがさばく//はpoller//が世論調査の対象者に堪える関係を示します。 「典型的な値は//'トポロジー'、'地理的である」か、または「管理」の記述を含むかもしれません' これがさばく//は//世論調査サーバAuthentication-タイプに関するDESCRIBE記録を含んでいます: pollerによって使用された認証の//タイプ、またはNONE Authentication-データ: この系列必須が投票メッセージを終えるのに使用した認証#END//のための//データ
Note: For poll type CENTROID, the allowable values for Poll Scope are FULL and RELATIVE. Support of the FULL value is required, this provides a complete listing of the centroid or other forward information. RELATIVE indicates that these are the relative changes in the centroid since the last report to the polling server.
以下に注意してください。 投票タイプCENTROIDに関しては、Poll Scopeのための許容量は、FULLとRELATIVEです。 FULL価値のサポートが必要であり、これは図心か他の前進の情報の完全なリストを提供します。 RELATIVEは、これらが世論調査サーバへの最後のレポート以来の図心の相対的な変化であることを示します。
For poll type QUERY, the allowable values for Poll Scope are a blank line, which indicates that all records are to be returned, or a valid WHOIS++ query, which indicates that just those records which satisfy the query are to be returned. N.B. Security considerations may require additional authentication for successful response to the Blank Line Poll Scope. This value has been included for server replication.
(それは、すべての記録が返すことであることを示します)。+ + 投票タイプQUERYに関しては、Poll Scopeのための許容量は空白行であるか有効なWHOISが質問です。(それは、まさしく質問を満たすそれらの記録が返すことであることを示します)。 N.B.セキュリティ問題はBlank線Poll Scopeへのうまくいっている応答のための追加認証を必要とするかもしれません。 この値はサーバ模写のために含まれています。
A polling server may wish to index different types of information than the polled server has collected. The POLLED-FOR command will indicate which servers the polled server has contacted.
世論調査サーバは投票されたサーバが集めたより異なったタイプの情報に索引をつけたがっているかもしれません。 POLLED-FORコマンドは、投票されたサーバがどのサーバに連絡したかを示すでしょう。
Required/Optional Table
必要であるか任意のテーブル
Version-Number REQUIRED, value is 1.0
Type-Of-Poll REQUIRED, values CENTROID and QUERY are required
Poll-scope REQUIRED If Type-of-poll is CENTROID, FULL is required,
RELATIVE is optional
If Type-of-poll is QUERY, Blank line is
required, and WHOIS++-type queries are
required
Start-time OPTIONAL
End-Time OPTIONAL
Template REQUIRED
Field REQUIRED
Server-handle REQUIRED
Host-Name REQUIRED
Host-Port REQUIRED
Hierarchy OPTIONAL
Description OPTIONAL
Authentication-Type: OPTIONAL
Authentication-data: OPTIONAL
バージョン番号REQUIRED、RELATIVEによる投票の任意のIf TypeがQUERYであるということであり、値のCENTROIDとQUERYは投票の必要なPoll-範囲REQUIRED If TypeがCENTROIDであるということであり、値は1.0投票のType REQUIREDであり、FULLが必要であり、Blank系列が必要であり、+ +タイプが質問するWHOISは必要なStart-時間のOPTIONAL Template REQUIRED Field REQUIRED Server-ハンドルREQUIRED Host-名前REQUIRED Host-ポートREQUIRED Hierarchy OPTIONAL記述OPTIONAL End-時間OPTIONAL Authentication-タイプです: 任意の認証データ: 任意
Weider, et al Standards Track [Page 10] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[10ページ]RFC
Example of a POLL command: # POLL: Version-number: 1.0 Type-of-poll: CENTROID Poll-scope: FULL Start-time: 199501281030+0100 Template: ALL Field: ALL Server-handle: BUNYIP01 Host-Name: services.bunyip.com Host-Port: 7070 Hierarchy: Geographical # END
POLLコマンドに関する例: # 以下に投票してください。 バージョン番号: 1.0 投票のタイプ: 図心投票範囲: 完全な開始時刻: 199501281030 +0100 テンプレート: すべての分野: すべてのサーバハンドル: BUNYIP01ホスト名: services.bunyip.com Host-ポート: 7070年の階層構造: 地理的な#終わり
6.3. Centroid change report
6.3. 図心変更報告書
As the centroid change report contains nested multiply-occuring
blocks, each multiply occurring block is surrounded *in this paper*
by curly braces '{', '}'. These curly braces are NOT part of the
syntax, they are for identification purposes only.
図心変更報告書が入れ子にされた存在を掛けているブロックを含むときそれぞれが発生ブロックを掛ける、囲まれた*コネが巻き毛の支柱によるこの紙*である、'、'、'}'。 これらの巻き毛の支柱が構文の一部でない、それらは識別目的だけのためのものです。
The syntax of a Data: item is either a list of words, one word per line, or the keyword:
Dataの構文: 項目は、単語のリスト、1系列あたり1つの単語かキーワードのどちらかです:
ANY
少しも
The keyword ANY as the only item of a Data: list means that any value for this field should be treated as a hit by the indexing server.
キーワード、Dataの唯一の項目としてのいずれも: リストは、この分野へのどんな値もインデックスサーバによってヒットとして扱われるべきであることを意味します。
The field Any-field: needs more explanation than can be given in the body of the syntax description below. It can take two values, True or False. If the value is True, the pollee is indicating that there are fields in this template which are not being exported to the polling server, but wishes to treat as a hit. Thus, when the polling server gets a query which has a term requesting a field not in this list for this template, the polling server will treat that term as a 'hit'. If the value is False, the pollee is indicating that there are no other fields for this template which should be treated as a hit. This field is required because the basic model for the WHOIS++ query syntax requires that the results of each search term be 'and'ed together. This field allows polled servers to export data only for non-sensitive fields, yet still get referrals of queries which contain sensitive terms.
分野Any-分野: 構文記述のボディーで以下に与えることができるより多くの説明を必要とします。 それは2つの値、TrueまたはFalseを取ることができます。 値がTrueであるなら、世論調査の対象者は、このテンプレートの世論調査サーバにエクスポートされていない分野があるのを示していますが、ヒットとして扱いたがっています。 用語を持っている質問が世論調査サーバからこのテンプレートのためのこのリストでないところの分野を要求するとき、したがって、世論調査サーバは'ヒット'としてその用語を扱うでしょう。 値がFalseであるなら、世論調査の対象者は、ヒットとして扱われるべきであるこのテンプレートのための他の分野が全くないのを示しています。 WHOIS++質問構文のための基本型が、それぞれの検索用語の結果が一緒に'and'教育であることを必要とするので、この分野が必要です。 この分野で、投票されたサーバは、非敏感な分野のためだけのデータをエクスポートしますが、まだ機密の用語を含む質問の紹介を得ています。
IMPORTANT: The data listed in the centroid must be in the ISO-8859-1 character set in this version of the indexing protocol. Use of any other character set is a violation of the protocol. Note that the base-level server is also specified to use ISO-8859-1 [Deutsch, et
重要: インデックスプロトコルのこのバージョンのISO-8859-1文字集合には図心にリストアップされたデータがあるに違いありません。 いかなる他の文字集合の使用もプロトコルの違反です。 また、基準面サーバがISO-8859-1を使用するために指定されることに注意してください、[ドイツ語、et
Weider, et al Standards Track [Page 11] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[11ページ]RFC
al, 1995].
アル、1995]。
# CENTROID-CHANGES
Version-number: // version number of pollee's index software, used to
// insure compatibility
Start-time: // change list starting time, GMT
End-time: // change list ending time, GMT
Server-handle: // IANA unique identifier of the responding server
Case-sensitive: // states whether data is case sensitive or case
// insensitive. values are TRUE or FALSE
Authentication-type: // Type of authentication used by pollee, or NONE
Authentication-data: // Data for authentication
Compression-type: // Type of compression used on the data, or NONE
Size-of-compressed-data: // size of compressed data if compression
// is used
Operation: // One of 3 keywords: ADD, DELETE, FULL
// ADD - add these entries to the centroid for this server
// DELETE - delete these entries from the centroid of this
// server
// FULL - the full centroid as of end-time follows
{ // The multiply occurring template block starts here
# BEGIN TEMPLATE
Template: // a standard whois++ template name
Any-field: // TRUE or FALSE. See beginning of 6.3 for explanation.
{ // the template contains multiple field blocks
# BEGIN FIELD
Field: // a field name within that template
Data: // Either the keyword *ANY*, or
// the word list itself, one per line, cr/lf terminated,
// each line starting with a dash character ('-').
# END FIELD
} // the field ends with END FIELD
# END TEMPLATE
} // the template block ends with END TEMPLATE
# END CENTROID-CHANGES // This line must be used to terminate the
// centroid change report
# 図心変化バージョン番号: //バージョンは、互換性Start-時間を/に使用される世論調査の対象者のインデックスソフトウェアに付番するか、または保障します: //変化リスト始動時、グリニッジ標準時のEnd-時間: //変化リスト終了時刻、グリニッジ標準時のServerハンドル: 応じるサーバの//IANAのユニークな識別子、Case敏感: //は、データが大文字と小文字を区別しているか、またはケース//神経が鈍いかを述べます。値は、TRUEかFALSE Authentication-タイプです: 世論調査の対象者によって使用された認証の//タイプ、またはNONE Authentication-データ: 認証のための//データは以下をCompressionタイプします。 データで使用される圧縮の//タイプ、または圧縮されたデータのNONE Size: 圧縮//であるなら、圧縮されたデータの//サイズは中古のOperationです: 3つのキーワードの//1つ: ADD、DELETE、FULL // ADD--このサーバ//DELETEのためにこれらのエントリーを図心に加えてください--この//サーバ//FULLの図心からこれらのエントリーを削除してください--終わり-時間現在の間の完全な図心は続きます。{ 起こるのを増えさせてください。//、テンプレートブロックはここから#BEGIN TEMPLATE Templateを始動します: 標準のwhois++テンプレートがAny-分野と命名する//: //本当であるか、または誤っています。 説明に関して6.3の始まりを見てください。 テンプレートが複数の周囲浸潤麻酔法#BEGIN FIELD Field含む//: そのテンプレートDataの中の//aフィールド名: //、キーワード*、どんな*、または//、も単語リスト自体、1系列あたり1つ、aダッシュキャラクタ('--')から始めて、終えられたcr/lf、それぞれ//は立ち並んでいます。 # END FIELD、分野がEND FIELD#END TEMPLATEと共に終わらせる//} //図心変更報告書を終えるのに、テンプレートブロックがこれが裏打ちするEND TEMPLATE#END CENTROID-CHANGES//で終わらせる//を使用しなければなりません。
For each template, all fields must be listed, or queries will not be referred correctly.
各テンプレートに関しては、すべての分野を記載しなければならない、さもなければ、質問は正しく参照されないでしょう。
Required/Optional table
必要であるか任意のテーブル
Version-number REQUIRED, value is 1.0 Start-time REQUIRED (even if the centroid type is FULL) End-time REQUIRED (even if the centroid type is FULL) Server-handle REQUIRED Case-Sensitive OPTIONAL Authentication-Type OPTIONAL
バージョン番号REQUIRED、値は1.0Start-時間REQUIRED(図心タイプがFULLであっても)終わり-時間REQUIRED(図心タイプがFULLであっても)のサーバハンドルのREQUIRED Case敏感なOPTIONAL Authentication-タイプOPTIONALです。
Weider, et al Standards Track [Page 12] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[12ページ]RFC
Authentication-Data OPTIONAL Compression-type OPTIONAL Size-of-compressed-data OPTIONAL (even if compression is used) Operation OPTIONAL, if used, upport for all three values is required Tokenization-type OPTIONAL #BEGIN TEMPLATE REQUIRED Template REQUIRED Any-field REQUIRED #BEGIN FIELD REQUIRED Field REQUIRED Data REQUIRED #END FIELD REQUIRED #END TEMPLATE REQUIRED #END CENTROID-CHANGES REQUIRED
認証データOPTIONAL Compression-タイプ圧縮されたデータのOPTIONAL Size OPTIONAL(圧縮が使用されていても)操作OPTIONAL、使用されるなら、すべての3つの値のためのupportは必要なTokenization-タイプOPTIONAL#BEGIN TEMPLATE REQUIRED Template REQUIRED Any-分野REQUIRED#BEGIN FIELD REQUIRED Field REQUIRED Data REQUIRED#END FIELD REQUIRED#END TEMPLATE REQUIRED#END CENTROID-CHANGES REQUIREDです。
Example:
例:
# CENTROID-CHANGES Version-number: 1.0 Start-time: 197001010000 End-time: 199503012336 Server-handle: BUNYIP01 # BEGIN TEMPLATE Template: USER Any-field: TRUE # BEGIN FIELD Field: Name Data: Patrik -Faltstrom -Malin -Linnerborg #END FIELD #BEGIN FIELD Field: Email Data: paf@bunyip.com -malin.linnerborg@paf.se # END FIELD # END TEMPLATE # END CENTROID-CHANGES
# 図心変化バージョン番号: 1.0 開始時刻: 197001010000終わり-時間: 199503012336サーバハンドル: BUNYIP01#はテンプレートテンプレートを始めます: ユーザ、いくらか、-、分野、: 本当の#、は分野分野を始めます: データを命名してください: パトリク・-Faltstromマリン-Linnerborg#端の分野#は分野分野を始めます: データをメールしてください: paf@bunyip.com -malin.linnerborg@paf.se#終わりの分野#終わりのテンプレート#終わりの図心変化
6.4 QUERY and POLLEES responses
6.4 QUERYとPOLLEES応答
The response to a QUERY command is done in WHOIS++ format.
WHOIS++形式でQUERYコマンドへの応答をします。
Weider, et al Standards Track [Page 13] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[13ページ]RFC
6.5. Query referral
6.5. 質問紹介
When referrals are included in the body of a response to a query, each referral is listed in a separate SERVER-TO-ASK block as shown below.
紹介が質問への応答のボディーに含まれているとき、各紹介は別々のSERVER-TO-ASKブロックに以下に示すように記載されます。
# SERVER-TO-ASK
Version-number: // version number of index software, used to insure
// compatibility
Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address of the referred server
Port-Number: // Port number to which to connect, if different from the
// WHOIS++ port number
# 尋ねるサーババージョン番号: 質問の//互換性Bodyを保障するのに使用されるインデックスソフトウェアの//バージョン番号: オリジナルが質問する//は以下をServer扱いにここに行きます。 参照されたサーバHost-名の//WHOIS++ハンドル: 参照されたサーバPort-番号の//DNS名かIPアドレス: //WHOIS++ポートナンバーと異なる接続する//ポートナンバー
# END
# 終わり
Required/Optional table
必要であるか任意のテーブル
Version-number REQUIRED, value should be 1.0 Body-of-query OPTIONAL Server-Handle REQUIRED Host-Name REQUIRED Port-Number OPTIONAL, must be used if different from port 63
バージョン番号REQUIRED、値は、1.0質問のBody OPTIONAL Server-ハンドルREQUIRED Host-名前REQUIRED Port-数のOPTIONALであるべきであり、中古ですが、ポート63と異なっているに違いありません。
Example:
例:
# SERVER-TO-ASK Version-Number: 1.0 Server-Handle: SUNETSE01 Host-Name: sunic.sunet.se Port-Number: 63 # END
# 尋ねるサーババージョン番号: 1.0サーバハンドル: SUNETSE01ホスト名: sunic.sunet.se Port-数: 63#終わり
7: Reply Codes
7: 回答コード
In addition to the reply codes listed in [Deutsch 95] for the basic WHOIS++ client/server interaction, the following reply codes are used in version 1.0 of this protocol.
基本的なWHOIS++クライアント/サーバ相互作用のために[ドイツ語95]で記載された回答コードに加えて、以下の回答コードはこのプロトコルのバージョン1.0で使用されます。
113 Requested method not available Unable to provide a requested
compression method. Contacted
server will send requested
data in different format.
113は、要求された圧縮方法を提供するようどんなメソッドの利用可能なUnableにも要求しませんでした。 連絡されたサーバは異なった形式で要求されたデータを送るでしょう。
227 Update request acknowledged A DATA-CHANGED transmission
has been accepted and logged
for further action.
227 さらなる動作のために更新要求の承認されたA DATA-CHANGED送信を、受け入れられて、登録してあります。
Weider, et al Standards Track [Page 14] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[14ページ]RFC
503 Required attribute missing A REQUIRED attribute is
missing in an interaction.
なくなったA REQUIREDが結果と考える503の必要な属性は相互作用でなくなっています。
504 Desired server unreachable The desired server is
unreachable.
504の必要なサーバ手の届かない、必要なサーバは手が届きません。
505 Desired server unavailable The desired server fails to
respond to requests, but host
is still reachable.
505は入手できないサーバを望んでいました。必要なサーバは要求に応じませんが、ホストはまだ届いています。
8. References
8. 参照
[Deutsch 95] Deutsch, et al., "Architecture of the WHOIS++ service",
RFC 1835, August 1995.
[ドイツ語95]ドイツ語、他、「WHOIS++サービスのアーキテクチャ」、RFC1835、1995年8月。
[Faltstrom 95] Faltstrom, P., et al., "How to Interact with a WHOIS++
Mesh, RFC 1914, February 1996.
[Faltstrom95] Faltstrom、P.、他、「1996年2月にWHOISと共に+ + メッシュ、RFC1914にどう相互作用します」。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Weider, et al Standards Track [Page 15] RFC 1913 Architecture of the Whois++ Index Service February 1996
ワイダー、Whois++の1913ArchitectureがService1996年2月に索引をつける他のStandards Track[15ページ]RFC
10. Authors' Addresses
10. 作者のアドレス
Chris Weider Bunyip Information Systems, Inc. 310 St. Catherine St. West Montreal, PQ H2X 2A1 CANADA
クリスワイダー詐欺師情報システムInc.310の西PQ H2X 2A1セント・キャサリン聖モントリオール(カナダ)
Phone: +1-514-875-8611 Fax: +1-514-875-6134 EMail: clw@bunyip.com
以下に電話をしてください。 +1-514-875-8611 Fax: +1-514-875-6134 メールしてください: clw@bunyip.com
Jim Fullton MCNC Center for Communications Post Office Box 12889 3021 Cornwallis Road Research Triangle Park North Carolina 27709-2889
ジムFullton MCNCはコミュニケーションのためにPost Office Box12889 3021コーンウォリス道路リサーチトライアングルParkノースカロライナ27709-2889を中心に置きます。
Phone: 410-795-5422 Fax: 410-795-5422 EMail: fullton@cnidr.org
以下に電話をしてください。 410-795-5422 Fax: 410-795-5422 メールしてください: fullton@cnidr.org
Simon Spero EMail: ses@eit.com
サイモンスペロウメール: ses@eit.com
Weider, et al Standards Track [Page 16]
ワイダー、他のStandards Track[16ページ]
一覧
スポンサーリンク
