RFC1588 日本語訳
1588 White Pages Meeting Report. J. Postel, C. Anderson. February 1994. (Format: TXT=77945 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 1588 C. Anderson
Category: Informational ISI
February 1994
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 1588年のC.アンダーソンカテゴリ: 情報のISI1994年2月
WHITE PAGES MEETING REPORT
ホワイトページミーティングレポート
STATUS OF THIS 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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
INTRODUCTION
序論
This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet.
このレポートは、1993年11月2日にホワイトページディレクトリサービスへの未来とアプローチについてインターネットと議論するためにヒューストン(テキサス)で11月のIETFで行われる会合(インターネット・エンジニアリング・タスク・フォース)の結果について説明します。
As proposed to the National Science Foundation (NSF), USC/Information Sciences Institute (ISI) conducted the meeting to discuss the viability of the X.500 directory as a practical approach to providing white pages service for the Internet in the near future and to identify and discuss any alternatives.
国立科学財団(NSF)に提案されるように、USC/情報Sciences Institute(ISI)はどんな選択肢も近い将来インターネットのためのホワイトページサービスを提供することへの実践的なアプローチとしてX.500ディレクトリの生存力について議論して、特定して、議論するミーティングを行いました。
An electronic mail mailing list was organized and discussions were held via email for two weeks prior to the meeting.
電子メールメーリングリストは組織化されました、そして、議論がミーティングの2週間前の間のメールで行われました。
1. EXECUTIVE SUMMARY
1. 要約
This report is organized around four questions:
このレポートは4つの質問の周りにまとめられます:
1) What functions should a white pages directory perform?
1) ホワイトページディレクトリはどんな機能を実行するはずですか?
There are two functions the white pages service must provide:
searching and retrieving.
ホワイトページサービスが提供しなければならない2つの機能があります: 捜して、検索します。
Searching is the ability to find people given some fuzzy
information about them. Such as "Find the Postel in southern
California". Searches may often return a list of matches.
彼らに関する何らかのファジー情報を考えて、探すのは人々を見つける能力です。 「南カリフォルニアでポステルを見つけます。」 検索はしばしば取組表を返すかもしれません。
While the idea of indexing has been around for some time, such as
the IN-ADDR tree in the Domain Name System (DNS), a new
acknowledgment of its importance has emerged from these
索引をつけるという考えはしばらく周囲でドメインネームシステムにおけるIN-ADDR木などに似ていますが(DNS)、新しい重要な承認はこれらから現れました。
Postel & Anderson [Page 1] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[1ページ]RFC1588ホワイトページは1994年2月に報告します。
discussions. Users want fast searching across the distributed
database on attributes different from the database structure.
Pre-computed indices satisfy this desire, though only for
specified searches.
議論。 ユーザは、速く属性の分散データベースの向こう側に探すのにデータベース構造と異なっていて欲しいです。 指定された検索のためだけに満たしますが、あらかじめ計算されたインデックスリストはこの願望を満たします。
Retrieval is obtaining additional information associated with a
person, such as an address, telephone number, email mailbox, or
security certificate.
電話番号、メールメールボックス、またはセキュリティが、検索がアドレスなどの人に関連している追加情報を得ていると証明します。
Security certificates (a type of information associated with an
individual) are essential for the use of end-to-end
authentication, integrity, and privacy in Internet applications.
The development of secure applications in the Internet is
dependent on a directory system for retrieving the security
certificate associated with an individual. For example, the
privacy enhanced electronic mail (PEM) system has been developed
and is ready to go into service, and is now hindered by the lack
of an easily used directory of security certificates. An open
question is whether or not such a directory needs to be internally
secure.
インターネットアプリケーションにおける終わりから終わりへの認証、保全、およびプライバシーの使用に、セキュリティ証明書(個人に関連している情報の種類)は不可欠です。 インターネットでの安全なアプリケーションの開発は個人に関連しているセキュリティ証明書を検索するディレクトリシステムに依存しています。 例えば、プライバシーの高められた電子メール(PEM)システムは、開発されて、サービスに入る準備ができていて、現在、セキュリティ証明書の容易に使用されたディレクトリの不足によって妨げられます。 未決問題はそのようなディレクトリが、内部的に安全である必要があるかどうかということです。
2) What approaches will provide us with a white pages directory?
2) どんなアプローチがホワイトページディレクトリを私たちに提供するでしょうか?
It is evident that there are and will be several technologies in
use. In order to provide a white pages directory service that
accommodates multiple technologies, we should promote
interoperation and work toward a specification of the simplest
common communication form that is powerful enough to provide the
necessary functionality. This "common ground" approach aims to
provide the ubiquitous WPS (White Pages Service) with a high
functionality and a low entry cost.
使用中のいくつかの技術はあって、あるのは、明白です。 複合的な技術に対応するホワイトページディレクトリサービスを提供するために、私たちは、必要な機能性を提供するほど強力な最も簡単な一般的なコミュニケーションフォームの仕様に向かってinteroperationを促進して、取り組むべきです。 この「共通基盤」アプローチは、遍在しているWPS(白いページService)を高い機能性と低い参入費用に提供することを目指します。
3) What are the problems to be overcome?
3) 問題は打ち勝つべき、何ですか?
It must be much easier to be part of the Internet white pages than
to bring up a X.500 DSA (Directory Service Agent), yet we must
make good use of the already deployed X.500 DSAs. Simpler white
pages services (such as Whois++) must be defined to promote
multiple implementations. To promote reliable operation, there
must be some central management of the X.500 system. A common
naming scheme must be identified and documented. A set of index-
servers, and indexing techniques, must be developed. The storage
and retrieval of security certificates must be provided.
インターネットホワイトページの部分であることはX.500 DSA(ディレクトリサービスエージェント)を持って来るよりはるかに簡単です、しかし、私たちが有効に既に配布しているX.500 DSAsを利用しなければならないということであるに違いありません。 複数の実装を促進するために、より簡単なホワイトページサービス(Whois++などの)を定義しなければなりません。 信頼できる操作を促進するために、X.500システムの何らかの主要な管理があるに違いありません。 一般的な命名体系を特定されて、記録しなければなりません。 1セットのインデックスサーバ、およびインデックス技術を見いださなければなりません。 セキュリティ証明書のストレージと検索を提供しなければなりません。
Postel & Anderson [Page 2] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[2ページ]RFC1588ホワイトページは1994年2月に報告します。
4) What should the deployment strategy be?
4) 展開戦略は何であるべきですか?
Some central management must be provided, and easy to use user
interfaces (such as the Gopher "gateway"), must be widely
deployed. The selection of a naming scheme must be documented.
We should capitalize on the existing infrastructure of already
deployed X.500 DSAs. The "common ground" model should be adopted.
A specification of the simplest common communication form must be
developed. Information about how to set up a new server (of
whatever kind) in "cookbook" form should be made available.
何らかの主要な管理を提供しなければなりません、そして、配布されて、インタフェース(ゴーファー「ゲートウェイ」などの)は、広くたやすく、提供しなければなりませんユーザを使用するために。 命名体系の選択を記録しなければなりません。 私たちはX.500 DSAsであると配布された既にの既存のインフラストラクチャを利用するべきです。 「共通基盤」モデルは採用されるべきです。 最も簡単な一般的なコミュニケーションフォームの仕様を開発しなければなりません。 「料理の本」フォームでどう新しいサーバをセットアップするかに関する(いかなる種類についても)情報を利用可能にするべきです。
RECOMMENDATIONS
推薦
1. Adopt the common ground approach. Encourage multiple client and
server types, and the standardization of an interoperation
protocol between them. The clients may be simple clients,
front-ends, "gateways", or embedded in other information access
clients, such as Gopher or WWW (World Wide Web) client programs.
The interoperation protocol will define message types, message
sequences, and data fields. An element of this protocol should
be the use of Universal Record Locators (URLs).
1. 共通基盤アプローチを取ってください。 複数のクライアントとサーバタイプ、および彼らの間のinteroperationプロトコルの標準化を奨励してください。 クライアントは、純真なクライアント、フロントエンド、「ゲートウェイ」、またはゴーファーかWWWなどの他の情報アクセスクライアントに埋め込まれた(WWW)クライアントプログラムであるかもしれません。interoperationプロトコルはメッセージタイプ、メッセージ系列、およびデータ・フィールドを定義するでしょう。 このプロトコルの原理はUniversal Record Locators(URL)の使用であるべきです。
2. Promote the development of index-servers. The index-servers
should use several different methods both for gathering data for
their indices, and for searching their indices.
2. インデックスサーバの開発を促進してください。 インデックスサーバは、それらのインデックスリストのための集会データと、それらのインデックスリストを捜すのにいくつかの異なったメソッドを使用するべきです。
3. Support a central management for the X.500 system. To get the
best advantage of the effort already invested in the X.500
directory system it is essential to provide the relatively small
amount of central management necessary to keep the system
functioning.
3. X.500システムのための主要な管理をサポートしてください。 取り組みの既にX.500ディレクトリシステムに投資された中で最も良い利点を得るために、システムを機能させ続けるのに必要な主要な管理の比較的少な量を供給するのは不可欠です。
4. Support the development of security certificate storage and
retrieval from the white pages service. One practical approach
is initially to focus on getting support from the existing X.500
directory infrastructure. This effort should also include
design and development of the storage and retrieval of security
certificates for other white pages services, such as Whois++.
4. ホワイトページサービスからセキュリティ証明書ストレージと検索の開発をサポートしてください。 初めは、既存のX.500ディレクトリインフラストラクチャからサポートを得るところの焦点には1つの実践的なアプローチがあります。 また、この取り組みはストレージのデザインと開発と他のホワイトページサービスのためのセキュリティ証明書の検索を含むべきです、Whois++などのように。
Postel & Anderson [Page 3] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[3ページ]RFC1588ホワイトページは1994年2月に報告します。
2. HISTORY
2. 歴史
In February 1989, a meeting on Internet white pages service was initiated by the FRICC (Federal Research Internet Coordinating Committee) and the ensuing discussions resulted in RFC 1107 [1] that offered some technical conclusions. Widespread deployment was to have taken place by mid-1992.
1989年2月に、インターネットホワイトページサービスのミーティングはFRICC(連邦政府のResearchインターネットCoordinating Committee)によって開始されました、そして、続く議論はいくつかの技術的結論を提供したRFC1107[1]をもたらしました。 広範囲の展開は1992年中頃までに行われることになっていました。
RFC 1107: K. Sollins, "Plan for Internet Directory Services",
[1].
RFC1107: K。 Sollins、「インターネットディレクトリサービスのためのプラン」、[1]。
Several other RFCs have been written suggesting deployment strategies and plans for an X.500 Directory Service.
他の数個のRFCsが展開戦略を示すのに書かれていて、X.500ディレクトリサービスの計画を立てます。
They are:
それらは以下の通りです。
RFC 1275: S. Hardcastle-Kille, "Replication Requirements to
provide an Internet Directory using X.500", [2].
RFC1275: S。 Hardcastle-Kille、「インターネットディレクトリを提供するX.500を使用する模写Requirements」、[2]。
RFC 1308: C. Weider, J. Reynolds, "Executive Introduction to
Directory Services Using the X.500 Protocol", [3].
RFC1308: C。 ワイダー、J.レイノルズ、「ディレクトリサービスへのX.500プロトコルを使用する幹部社員序論」、[3]。
RFC 1309: C. Weider, J. Reynolds, S. Heker, "Technical Overview
of Directory Services Using the X.500 Protocol", [4].
RFC1309: C。 ワイダー、J.レイノルズ、S.Heker、「X.500プロトコルを使用するディレクトリサービスの技術的な概要」、[4]。
RFC 1430: S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby &
S. Kent, "A Strategic Plan for Deploying an Internet X.500
Directory Service", [5].
RFC1430: S。 Hardcastle-Kille、E.Huizer、V.サーフ、R.趣味、およびS.ケント、「インターネットX.500ディレクトリサービスを配布するための長期計画」[5]。
Also, a current working draft submitted by A. Jurg of SURFnet entitled, "Introduction to White pages services based on X.500", describes why we need a global white pages service and why X.500 is the answer [6].
また、「サービスがX.500に基礎づけたホワイトページへの序論」というSURFnetのジュルグが権利を与えたA.によって提出された現在の概要版は私たちがなぜグローバルなホワイトページサービスを必要とするか、そして、X.500がなぜ答え[6]であるかを説明します。
The North America Directory Forum (NADF) also has done some useful work setting conventions for commercial providers of X.500 directory service. Their series of memos is relevant to this discussion. (See RFC 1417 for an overview of this note series [7].) In particular, NADF standing document 5 (SD-5) "An X.500 Naming Scheme for National DIT Subtrees and its Application for c=CA and c=US" is of interest for its model of naming based on civil naming authorities [8].
北アメリカディレクトリForum(NADF)もX.500ディレクトリサービスの商業プロバイダーのためにいくつかの実質的な仕事設定コンベンションをしました。 それらのメモのシリーズはこの議論に関連しています。 (この注意シリーズ[7]の概要に関してRFC1417を見てください。) 特に、命名のモデルに関するドキュメント5「National DIT SubtreesのためのX.500 Naming SchemeとcのためのそのApplicationはカリフォルニアと等しいです、そして、cは米国と等しいこと」がある(サウスダコタ-5)関心に耐えるNADFが当局[8]を民間命名に基礎づけました。
Deployment of a X.500 directory service including that under the PSI (Performance Systems International) White Pages Pilot Project and the PARADISE Project is significant, and continues to grow, albeit at a slower rate than the Internet.
PSI(国際パフォーマンスSystems)の白いページPilot ProjectとPARADISE Projectの下にそれを含むX.500ディレクトリサービスの展開は、重要であり、それにしても、インターネットより遅い速度で成長し続けています。
Postel & Anderson [Page 4] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[4ページ]RFC1588ホワイトページは1994年2月に報告します。
3. QUESTIONS
3. 問題
Four questions were posed to the discussion list:
4つの質問が議論リストに提出されました:
1) What functions should a white pages directory perform?
1) ホワイトページディレクトリはどんな機能を実行するはずですか?
2) What approaches will provide us with a white pages directory?
2) どんなアプローチがホワイトページディレクトリを私たちに提供するでしょうか?
3) What are the problems to be overcome?
3) 問題は打ち勝つべき、何ですか?
4) What should the deployment strategy be?
4) 展開戦略は何であるべきですか?
3.A. WHAT FUNCTIONS SHOULD A WHITE PAGES DIRECTORY PERFORM?
3.A. ホワイトページディレクトリはどんな機能を実行するはずですか?
The basic function of a white pages service is to find people and information about people.
ホワイトページサービスの基本機能は人々の人々と情報を見つけることです。
In finding people, the service should work fast when searching for people by name, even if the information regarding location or organization is vague. In finding information about people, the service should retrieve information associated with people, such as a phone number, a postal or email address, or even a certificate for security applications (authentication, integrity, and privacy). Sometimes additional information associated with people is provided by a directory service, such as a list of publications, a description of current projects, or a current travel itinerary.
名前の人々を捜し求めるとき、人々を見つける際に、サービスは速く働くべきです、位置か組織の情報があいまいであっても。 人々の情報を見つける際に、サービスは電話番号、aなどの人々に郵便で関連づけられた情報、Eメールアドレス、またはセキュリティアプリケーションのための証明書(認証、保全、およびプライバシー)さえ検索するべきです。 時々、ディレクトリサービスで人々に関連している追加情報を提供します、刊行物のリスト、現在のプロジェクトの記述、または現在の旅程表などのように。
Back in 1989, RFC 1107 detailed 8 requirements of a white pages service: (1) functionality, (2) correctness of information, (3) size, (4) usage and query rate, (5) response time, (6) partitioned authority, (7) access control, (8) multiple transport protocol support; and 4 additional features that would make it more useful: (1) descriptive naming that could support a yellow pages service, (2) accountability, (3) multiple interfaces, and (4) multiple clients.
1989年に、RFC1107はホワイトページサービスの8つの要件を詳しく述べました: (1) (2) (3) (5) 機能性、情報の正当性、サイズ、用法と質問が評定する(4)、応答時間、(6)は権威を仕切りました、(7)アクセスコントロール、(8)倍数トランスポート・プロトコルサポート。 それをより役に立つようにする4つの付加的な機能: (1) 職業別広告欄サービス、(2)責任、(3)倍数インタフェース、および(4)が複数のクライアントであるとサポートすることができた描写的である命名。
Since the writing of RFC 1107, many additional functions have been identified. A White Pages Functionality List is attached as Appendix 1. The problem is harder now, the Internet is much bigger, and there are many more options available (Whois++, Netfind, LDAP (Lightweight Direct Access Protocol), different versions of X.500 implementations, etc.)
RFC1107の書くこと以来、多くの追加機能が特定されています。 ホワイトページFunctionality ListはAppendix1として取り付けられます。 問題は現在より困難です、そして、インターネットははるかに大きいです、そして、利用可能なずっと多くのオプションがあります。(Whois++、Netfind、LDAP(軽量のDirect Accessプロトコル)、X.500実装の異なった見解など)
A white pages directory should be flexible, should have low resource requirements, and should fit into other systems that may be currently in use; it should not cost a lot, so that future transitions are not too costly; there should be the ability to migrate to something else, if a better solution becomes available; there should be a way to share local directory information with the Internet in a seamless
ホワイトページディレクトリは、フレキシブルであるべきであり、少ないリソース要件を持つべきであり、他の現在使用中であるかもしれないシステムに収まるはずです。 それがいろいろな事費用がかかるべきでないので、将来の変遷はそれほど高価ではありません。 より良いソリューションが利用可能になるなら、他の何かにわたる能力があるべきです。 シームレスにはローカルディレクトリ情報をインターネットと共有する方法があるべきです。
Postel & Anderson [Page 5] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[5ページ]RFC1588ホワイトページは1994年2月に報告します。
fashion and with little extra effort; the query responses should be reliable enough and consistent enough that automated tools could be used.
ファッションと付加的な取り組みでほとんどそうしません。 質問応答は、自動化されたツールを使用できたくらい十分信頼できて一貫しているべきです。
3.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY?
3.B. どんなアプローチがホワイトページディレクトリを米国に提供するでしょうか?
People have different needs, tastes, etc. Consequently, a large part of the ultimate solution will include bridging among these various solutions. Already we see a Gopher to X.500 gateway, a Whois++ to X.500 gateway, and the beginnings of a WWW to X.500 gateway. Gopher can talk to CSO (a phonebook service developed by University of Illinois), WAIS (Wide Area Information Server), etc. WWW can talk to everything. Netfind knows about several other protocols.
人々には、異なった必要性、味などがあります。 その結果、根本的な解決のかなりの部分は、これらの様々なソリューションの中でブリッジするのを含むでしょう。 + 既に、私たちがX.500ゲートウェイにゴーファーを見て、WhoisがX.500ゲートウェイへの+であり、X.500へのWWWの始まりはゲートウェイです。 ゴーファーはCSO(phonebookサービスはイリノイ大学で展開した)、WAIS(広いArea情報Server)などと話すことができます。 WWWはすべてと話すことができます。 Netfindは他のいくつかのプロトコルに関して知っています。
Gopher and WAIS "achieved orbit" simply by providing means for people to export and to access useful information; neither system had to provide ubiquitous service. For white pages, if the service doesn't provide answers to specific user queries some reasonable proportion of the time, users view it as as failure. One way to achieve a high hit rate in an exponentially growing Internet is to use a proactive data gathering architecture (e.g., as realized by archie and Netfind). Important as they are, replication, authentication, etc., are irrelevant if no one uses the service.
ゴーファーとWAISは単に人々がエクスポートして、役に立つ情報にアクセスする手段を提供することによって、「軌道を達成しました」。 どちらのシステムも遍在しているサービスを提供する必要はありませんでした。 ホワイトページに関しては、サービスが現代のいくつかの妥当な割合を特定のユーザー・クエリーの答えに提供しないなら、ユーザは失敗のようにそれを見ます。 指数関数的に増加しているインターネットで高いヒット率を達成する1つの方法は先を見越すデータ集会アーキテクチャを使用する(例えば、archieとNetfindが実感されるように)ことです。 それらは重要ですが、だれもサービスを利用しないなら、模写、認証などは無関係です。
There are pluses and minuses to a proactive data gathering method. On the plus side, one can build a large database quickly. On the minus side, one can get garbage in the database. One possibility is to use a proactive approach to (a) acquire data for administrative review before being added to the database, and/or (b) to check the data for consistency with the real world. Additionally, there is some question about the legality of proactive methods in some countries.
先を見越すデータ集会メソッドへのプラスとマイナスがあります。 プラス側では、人がすぐに大容量データベースを築き上げることができます。 マイナスの面では、1つがデータベースでゴミを手に入れることができます。 1つの可能性は一貫性がないかどうか本当の世界にデータについて問い合わせるためにデータベース、そして/または、(b)に加えられる前に(a)への先を見越すアプローチを使用するのが不服審査のためのデータを取得するということです。 さらに、いくつかの国の先を見越すメソッドの合法に関する何らかの質問があります。
One solution is to combine existing technology and infrastructure to provide a good white pages service, based on a X.500 core plus a set of additional index/references servers. DNS can be used to "refer" to the appropriate zone in the X.500 name space, using WAIS or Whois++, to build up indexes to the X.500 server which will be able to process a given request. These can be index-servers or centroids or something new.
1つのソリューションは良いホワイトページサービスを提供するために既存の技術とインフラストラクチャを結合することです、追加インデックス/参照サーバのX.500コアとセットに基づいて。 DNSは、+ スペースというX.500名の適切なゾーンが「参照されること」において中古の使用WAISかWhoisが+であったなら与えられた要求を処理できるX.500サーバにインデックスを確立するためにそうすることができます。 これらは、インデックスサーバ、図心または何か新しいものであるかもしれません。
Some X.500 purists might feel this approach muddles the connecting fabric among X.500 servers, since the site index, DNS records, and customization gateways are all outside of X.500. On the other hand, making X.500 reachable from a common front-end would provide added incentive for sites to install X.500 servers. Plus, it provides an immediate (if interim) solution to the need for a global site index in X.500. Since the goal is to have a good white pages service,
何人かのX.500純粋主義者が、このアプローチがX.500サーバの中で接続骨組みを混乱させるのを感じるかもしれません、サイトインデックス、DNS記録、および改造ゲートウェイがX.500のすべて外にあるので。 他方では、X.500を一般的なフロントエンドから届くようにすると、サイトがX.500サーバをインストールするご褒美は提供されるでしょう。 そのうえ、それは即座の、そして、(当座)の解決法をX.500のグローバルなサイトインデックスの必要性に提供します。 以来、目標は良いホワイトページサービスを持つことです。
Postel & Anderson [Page 6] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[6ページ]RFC1588ホワイトページは1994年2月に報告します。
X.500 purity is not essential.
X.500の純粋さは不可欠ではありません。
It may be that there are parts of the white pages problem that cannot be addressed without "complex technology". A solution that allows the user to progress up the ladder of complexity, according to taste, perceived need, and available resources may be a much healthier approach. However, experience to date with simpler solutions (Whois++, Netfind, archie) indicates that a good percentage of the problem of finding information can be addressed with simpler approaches. Users know this and will resist attempts to make them pay the full price for the full solution when it is not needed. Whereas managers and funders may be concerned with the complexity of the technology, users are generally more concerned with the quality and ease of use of the service. A danger in supporting a mix of technologies is that the service may become so variable that the loose constraints of weak service in some places lead users to see the whole system as too loose and weak.
「複雑な技術」なしで扱うことができないホワイトページ問題の部分が多分あります。 味に従ってユーザが複雑さのはしごで進歩をすることができるソリューション、必要性と、利用可能資源であると知覚されているのは、はるかに健康なアプローチであるかもしれません。 しかしながら、より簡単なソリューション(Whois++、Netfind、archie)によるこれまでの経験は、より簡単なアプローチで情報を見つけるという問題の良い割合を扱うことができるのを示します。 ユーザは、これを知って、それは必要でないときに完全なソリューションの正価を支払わせる試みに抵抗するでしょう。 マネージャとfundersは技術の複雑さに関係があるかもしれませんが、一般に、ユーザはサービスの品質と使いやすさにさらに関係があります。 技術のミックスをサポートすることにおける危険はサービスがとても可変になるかもしれないのでゆるい弱くサービスの規制が、ユーザが、全体のシステムがゆる過ぎて、弱いとみなすように所々導くということです。
Some organizations will not operate services that they cannot get for free or they cannot try cheaply before investing time and money. Some people prefer a bare-bones, no support solution that only gives them 85 percent of what they want. Paying for the service would not be a problem for many sites, once the value of the service has been proven. Although there is no requirement to provide free software for everybody, we do need viable funding and support mechanisms. A solution can not be simply dictated with any expectation that it will stick.
いくつかの組織はただで、それらが得ることができないサービスを運用しないことができないでしょうか、時間とお金を費やす前に、彼らは安く試みることができません。 人々の中には骨子、彼らが欲しいものに関する85パーセントしかそれらに与えないサポート対策を全く好まない人もいます。 サービスの代価を払うのは、多くのサイトへの問題でないでしょう、サービスの価値がいったん立証されると。 フリーソフトウェアをみんなに提供するという要件が全くありませんが、私たちは、実行可能な基金を必要として、メカニズムをサポートします。それが張り付けるどんな期待でもソリューションは絶対に書き取ることができません。
Finally, are there viable alternative technologies to X.500 now or do we need to design something new? What kind of time frame are we talking about for development and deployment? And will the new technology be extensible enough to provide for the as yet unimagined uses that will be required of directory services 5 years from now? And will this directory service ultimately provide more capabilities than just white pages?
現在、最終的に、X.500への実行可能な代案技術がありますか、私たちは、何か新しいものを設計する必要がありますか? どういう時間枠に関して、私たちは開発と展開のために話していますか? そして、新技術はディレクトリサービスが現在から5年間要求されるまだ非想像される用途に備えるほど広げることができるようになるでしょうか? そして、このディレクトリサービスは結局、まさしくホワイトページより多くの能力を提供するでしょうか?
3.C. WHAT ARE THE PROBLEMS TO BE OVERCOME?
3.C. 問題は打ち勝つべき、何ですか?
There are two classes of problems to be examined; technology issues and infrastructure.
調べられるために、2つのクラスの問題があります。 技術問題とインフラストラクチャ。
TECHNOLOGY:
技術:
How do we populate the database and make software easily available?
私たちは、どのようにデータベースに居住して、ソフトウェアを容易に利用可能にしますか?
Many people suggest that a public domain version of X.500 is necessary before a wide spread X.500 service is operational. The current public domain version is said to be difficult to install and
多くの人々が、広い普及のX.500サービスが操作上になる前にX.500の公共の場バージョンが必要であると示唆します。 そして現在の公共の場バージョンがインストールするのが難しいと言われている。
Postel & Anderson [Page 7] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[7ページ]RFC1588ホワイトページは1994年2月に報告します。
to bring into operation, but many organizations have successfully installed it and have had their systems up and running for some time. Note that the current public domain program, quipu, is not quite standard X.500, and is more suited to research than production service. Many people who tried earlier versions of quipu abandoned X.500 due to its costly start up time, and inherent complexity.
操作にもかかわらず、多くに組織を持って来てください。首尾よくそれをインストールして、しばらくそれらのシステムを活動するようにしています。 現在の公共の場プログラム(結び縄文字)がかなり標準のX.500でなく、生産サービスより研究に合っていることに注意してください。 結び縄文字の以前のバージョンを試みた多くの人々がその高価な始動時間、および固有の複雑さのためX.500を捨てました。
The ISODE (ISO Development Environment) Consortium is currently developing newer features and is addressing most of the major problems. However, there is the perception that the companies in the consortium have yet to turn these improvements into actual products, though the consortium says the companies have commercial off-the- shelf (COTS) products available now. The improved products are certainly needed now, since if they are too late in being deployed, other solutions will be implemented in lieu of X.500.
ISODE(ISO Development Environment)共同体は、現在、より新しい特徴を発生していて、大した問題の大部分を扱っています。しかしながら、共同体における会社がまだこれらの改良を実際の製品に変えていないように持っている知覚があります、共同体が、会社が商業に持っていると言いますが-、現在利用可能な棚(COTS)の製品。 確かに、改良品が現在必要です、それらが配布されるのに遅過ぎるなら、他のソリューションがX.500の代わりに実現されるので。
The remaining problem with an X.500 White Pages is having a high quality public domain DSA. The ISODE Consortium will make its version available for no charge to Universities (or any non-profit or government organization whose primary purpose is research) but if that leaves a sizeable group using the old quipu implementation, then there is a significant problem. In such a case, an answer may be for some funding to upgrade the public version of quipu.
X.500ホワイトPagesがある残った問題には、高品質の公共の場DSAがあります。 ISODE Consortiumは充電でないのに利用可能なバージョンを大学(または、プライマリ目的が研究であるどんな非営利団体や政府機関も)にするでしょうが、それが古い結び縄文字実装を使用することでかなり大きいグループを出るなら、重大な問題があります。 このような場合には、答えは結び縄文字の公共のバージョンをアップグレードさせるいくつかの基金のためのものであるかもしれません。
In addition, the quipu DSA should be simplified so that it is easy to use. Tim Howes' new disk-based quipu DSA solves many of the memory problems in DSA resource utilization. If one fixes the DSA resource utilization problem, makes it fairly easy to install, makes it freely available, and publishes a popular press book about it, X.500 may have a better chance of success.
さらに、結び縄文字DSAが簡素化されるべきであるので、それは使用しやすいです。 ティム・ハウズの新しいディスクベースの結び縄文字DSAはDSAリソース利用における記憶障害の多くを解決します。 人がDSAリソース利用問題を修正して、インストールするのをかなり簡単にして、それを自由に利用可能にして、それに関するポピュラーなプレスの本を発行するなら、X.500には、より良い勝算があるかもしれません。
The client side of X.500 needs more work. Many people would rather not expend the extra effort to get X.500 up. X.500 takes a sharp learning curve. There is a perception that the client side also needs a complex Directory User Interface (DUI) built on ISODE. Yet there are alternative DUIs, such as those based on LDAP. Another aspect of the client side is that access to the directory should be built into other applications like gopher and email (especially, accessing PEM X.509 certificates).
X.500のクライアント側面は、より多くの仕事を必要とします。 多くの人々は、X.500を起こすために付加的な取り組みを費やさない方がましです。 X.500は鋭いラーニングカーブを取ります。 クライアントは面がある知覚がありました、また、必要性のa複雑なディレクトリUser Interface(DUI)はISODEに建てました。 しかし、LDAPに基づくものなどの代替のDUIsがあります。 クライアント側のもう一つの側面はリスとメール(特にPEM X.509証明書にアクセスする)のような他のアプリケーションがディレクトリへのアクセスに組み込まれるべきであるということです。
We also need data conversion tools to make the transition between different systems possible. For example, NASA had more than one system to convert.
また、私たちは、異系統の間の変遷を可能にするようにデータ変換ツールを必要とします。 例えば、NASAには、変換する1台以上のシステムがありました。
Searching abilities for X.500 need to be improved. LDAP is great help, but the following capabilities are still needed:
X.500のための探索能力は、改良される必要があります。 LDAPは大助かりですが、以下の能力がまだ必要です:
Postel & Anderson [Page 8] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[8ページ]RFC1588ホワイトページは1994年2月に報告します。
-- commercial grade easily maintainable servers with back-end
database support.
-- バックエンドデータベースがある容易に維持できるサーバがサポートする商用銘柄。
-- clients that can do exhaustive search and/or cache useful
information and use heuristics to narrow the search space in case
of ill-formed queries.
-- 不適格な質問の場合に検索スペースを狭くするのに徹底的な検索をする、役に立つ情報をキャッシュして、そして/または、発見的教授法を使用できるクライアント。
-- index servers that store index information on a "few" key
attributes that DUIs can consult in narrowing the search space.
How about index attributes at various levels in the tree that
capture the information in the corresponding subtree?
-- DUIsが検索スペースを狭くする際に相談できる「わずか」主要な属性のインデックス情報を保存するサーバに索引をつけてください。 木の対応する下位木における情報を得る様々なレベルにおけるインデックス属性はどうですか?
Work still needs to be done with Whois++ to see if it will scale to the level of X.500.
まだWhois++で行われる必要性を扱っていて、それがX.500のレベルに比例するかどうか確認してください。
An extended Netfind is attractive because it would work without any additional infrastructure changes (naming, common schema, etc.), or even the addition of any new protocols.
どんな追加インフラストラクチャ変化(命名、一般的な図式など)も、またはどんな新しいプロトコルの追加もなしでも働いているでしょう、したがって、拡張Netfindは魅力的です。
INFRASTRUCTURE:
インフラストラクチャ:
The key issues are central management and naming rules.
主要な問題は、主要な管理と規則を命名することです。
X.500 is not run as a service in the U.S., and therefore those using X.500 in the U.S. are not assured of the reliability of root servers. X.500 cannot be taken seriously until there is some central management and coordinated administration support in place. Someone has to be responsible for maintaining the root; this effort is comparable to maintaining the root of the DNS. PSI provided this service until the end of the FOX project [9]; should they receive funding to continue this? Should this be a commercial enterprise? Or should this function be added to the duties of the InterNIC?
X.500はサービスとして米国で実行されません、そして、したがって、米国でX.500を使用するものがルートサーバーの信頼性を保証されません。 何らかの主要な管理と連携管理サポートが適所にあるまで、真剣にX.500を受け止めることができません。 だれかが根を維持するのに責任がなければなりません。 この取り組みはDNSの根を維持するのに匹敵しています。 PSIはFOXプロジェクト[9]の終わりまでこのサービスを提供しました。 彼らは、これを続けるために基金を受けるべきですか? これは営利事業であるべきですか? または、この機能はInterNICの義務に加えられるべきですか?
New sites need assistance in getting their servers up and linked to a central server.
新しいサイトはセントラルサーバーにそれらのサーバを得て、リンクする際に支援を必要とします。
There are two dimensions along which to consider the infrastructure: 1) general purpose vs. specific, and 2) tight vs. loose information framework.
インフラストラクチャを考える二次元があります: 1) 特定、そして、2の)ゆるい情報に対してきついフレームワークに対して汎用です。
General purpose leads to more complex protocols - the generality is an overhead, but gives the potential to provide a framework for a wide variety of services. Special purpose protocols are simpler, but may lead to duplication or restricted scope.
汎用は、より複雑なプロトコルにつながります--一般性は、オーバーヘッドですが、さまざまなサービスにフレームワークを提供する可能性を与えます。 専用プロトコルは、より簡単ですが、複製か制限された範囲につながるかもしれません。
Tight information framework costs effort to coerce existing data and to build structures. Once in place, it gives better managability and more uniform access. The tight information framework can be
フレームワークが既存のデータと体格構造に強制するのに取り組みかかるきつい情報。 適所に、より良いmanagabilityと、より一定のアクセサリーを与えるとき きつい情報フレームワークはそうであることができます。
Postel & Anderson [Page 9] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[9ページ]RFC1588ホワイトページは1994年2月に報告します。
subdivided further into: 1) the naming approach, and 2) the object and attribute extensibility.
以下により遠くに、細分されます。 1) 命名アプローチ、および2) オブジェクトと属性伸展性。
Examples of systems placed in this space are: a) X.500 is a general purpose and tight information framework, b) DNS is a specific and tight information framework, c) there are various research efforts in the general purpose and loose information framework, and d) Whois++ employs a specific and loose information framework.
このスペースに置かれたシステムに関する例は以下の通りです。 a) X.500は汎用の、そして、きつい情報フレームワーク、b)です。 DNSはフレームワーク、そこのc)が汎用の、そして、ゆるい情報フレームワークで様々な研究取り組みであるという特定の、そして、きつい情報と、d)です。 Whois++は特定の、そして、ゆるい情報フレームワークを使います。
We need to look at which parts of this spectrum we need to provide services. This may lead to concluding that several services are desirable.
私たちは、私たちがサービスを提供するために必要とするこのスペクトルのどの部分を見る必要があります。 これは、いくつかのサービスが望ましいと結論を下すのに通じるかもしれません。
3.D. WHAT SHOULD THE DEPLOYMENT STRATEGY BE?
3.D. 展開戦略は何であるべきですか?
No solution will arise simply by providing technical specifications. The solution must fit the way the Internet adopts information technology. The information systems that have gained real momentum in the Internet (WAIS, Gopher, etc.) followed the model:
ソリューションは、全く単に技術仕様書を提供することによって、起こらないでしょう。 ソリューションはインターネットが情報技術を採用する方法に合わなければなりません。 インターネット(WAIS、ゴーファーなど)で本当の加速度を増した情報システムはモデルに従いました:
-- A small group goes off and builds a piece of software that
supplies badly needed functionality at feasible effort to
providers and users.
-- 小さいグループは、去って、可能な取り組みにおけるとても必要な機能性をプロバイダーとユーザに供給するソフトウェア一本を築き上げます。
-- The community rapidly adopts the system as a de facto standard.
-- 共同体はデファクトスタンダードとして急速にシステムを採用します。
-- Many people join the developers in improving the system and
standardizing the protocols.
-- システムを改良して、多くの人々が開発者と共にプロトコルを標準化します。
What can this report do to help make this happen for Internet white pages?
このレポートは、これをインターネットホワイトページのために起こらせるのを助けるために何ができますか?
Deployment Issues.
展開問題。
-- A strict hierarchical layout is not suitable for all directory
applications and hence we should not force fit it.
-- アプリケーションとしたがって、私たちが強制するべきであるというわけではないすべてのディレクトリがそれに合ったので、厳しい階層的なレイアウトは適当ではありません。
-- A typical organization's hierarchical information itself is often
proprietary; they may not want to divulge it to the outside world.
-- 典型的な組織の階層的な情報自体はしばしば独占です。 彼らはそれを外の世界に明かしたがっていないかもしれません。
It will always be true that Institutions (not just commercial)
will always have some information that they do not wish to display
to the public in any directory. This is especially true for
Institutions that want to protect themselves from headhunters, and
sales personnel.
Institutions(ちょうど商業でない)がどんなディレクトリにもいつも彼らが公衆に表示したがっていないという何らかの情報を持っているのは、いつも本当でしょう。 ヘッドハンター、および販売スタッフから我が身をかばいたがっているInstitutionsに、これは特に本当です。
Postel & Anderson [Page 10] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[10ページ]RFC1588ホワイトページは1994年2月に報告します。
-- There is the problem of multiple directory service providers, but
see NADF work on "Naming Links" and their "CAN/KAN" technology
[7].
-- 複数のディレクトリサービスプロバイダーの問題がありますが、「リンクを命名します」に対するNADF仕事とそれらの「缶/カン」技術[7]を見てください。
A more general approach such as using a knowledge server (or a set
of servers) might be better. The knowledge servers would have to
know about which server to contact for a given query and thus may
refer to either service provider servers or directly to
institution-operated servers. The key problem is how to collect
the knowledge and keep it up to date. There are some questions
about the viability of "naming links" without a protocol
modification.
知識サーバ(または、1セットのサーバ)を使用などなどの、より一般的なアプローチは、より良いかもしれません。 知識サーバは、与えられた質問のためにどのサーバに連絡したらよいかに関して知らなければならなくて、その結果、サービスプロバイダーサーバか直接団体によって運用されたサーバを参照するかもしれません。 主要な問題は知識を集めて、それがどう時代について行かせるかということです。 「命名リンク」の生存力に関するいくつかの質問がプロトコル変更なしであります。
-- Guidelines are needed for methods of searching and using directory
information.
-- ガイドラインがディレクトリ情報を捜して、使用するメソッドに必要です。
-- A registration authority is needed to register names at various
levels of the hierarchy to ensure uniqueness or adoption of the
civil naming structure as delineated by the NADF.
-- 登録局が、NADFによって図で表わされるように民間命名構造のユニークさか採用を確実にするために階層構造の様々なレベルで名前を登録するのに必要です。
It is true that deployment of X.500 has not seen exponential growth as have other popular services on the Internet. But rather than abandoning X.500 now, these efforts, which are attempting to address some of the causes, should continue to move forward. Certainly installation complexity and performance problems with the quipu implementation need solutions. These problems are being worked on.
X.500の展開が他のポピュラーなサービスのようにインターネットで急激な増加を見ていないのは、本当です。 しかし、これらの取り組み(原因のいくつかを扱うのを試みている)は、現在X.500を捨てるよりむしろ、前方へ動き続けるべきです。 確かに、結び縄文字実装に関するインストールの複雑さと性能問題はソリューションを必要とします。 これらの問題に働いています。
One concern with the X.500 service has been the lack of ubiquitous user agents. Very few hosts run the ISODE package. The use of LDAP improves this situation. The X.500-gopher gateway has had the greatest impact on providing wide-spread access to the X.500 service. Since adding X.500 as a service on the ESnet Gopher, the use of the ESnet DSA has risen dramatically.
X.500サービスがある1回の関心が遍在しているユーザエージェントの不足です。 ほんのわずかなホストはISODEパッケージを動かします。 LDAPの使用はこの状況を改良します。 X.500-リスゲートウェイはX.500サービスへの広範囲のアクセスを提供するのにおいて最もすばらしい影響を与えました。 サービスとしてESnetゴーファーでX.500を加えて以来、ESnet DSAの使用は劇的に上昇しています。
Another serious problem affecting the deployment of X.500, at least in the U.S., is the minimal support given to building and maintaining the necessary infrastructure since the demise of the Fox Project [9]. Without funding for this effort, X.500 may not stand a chance in the United States.
少なくとも米国では、X.500の展開に影響することにおける別の深刻な問題はフォックスProject[9]の終焉以来必要なインフラを築き上げて、維持するのに与えられた最小量のサポートです。 この取り組みのための基金がなければ、X.500は合衆国で機会がないかもしれません。
Postel & Anderson [Page 11] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[11ページ]RFC1588ホワイトページは1994年2月に報告します。
4. REVIEW OF TECHNOLOGIES
4. 技術のレビュー
There are now many systems for finding information, some of these are oriented to white pages, some include white pages, and others currently ignore white pages. In any case, it makes sense to review these systems to see how they might fit into the provision of an Internet white pages service.
現在、情報を見つける多くのシステムがあります、そして、これらの或るものはホワイトページに適応します、そして、或るものはホワイトページを含んでいます、そして、他のものは現在、ホワイトページを無視します。 どのような場合でも、それらがどうインターネットホワイトページサービスの支給に収まるかもしれないかを見ると、これらのシステムはレビューに理解できます。
4.A. X.500
4. A.X.500
Several arguments in X.500's favor are its flexibility, distributed architecture, security, superiority to paper directories, and that it can be used by applications as well as by humans. X.500 is designed to provide a uniform database facility with replication, modification, and authorization. Because it is distributed, it is particularly suited for a large global White Pages directory. In principle, it has good searching capabilities, allowing searches at any level or in any subtree of the DIT (Directory Information Tree). There are DUIs available for all types of workstations and X.500 is an international standard. In theory, X.500 can provide vastly better directory service than other systems, however, in practice, X.500 is difficult, too complicated, and inconvenient to use. It should provide a better service. X.500 is a technology that may be used to provide a white pages service, although some features of X.500 may not be needed to provide just a white pages service.
X.500の好意におけるいくつかの議論が柔軟性、分配されたアーキテクチャ、セキュリティ、紙のディレクトリへの優越です、そして、アプリケーションと人間はそれを使用できます。 X.500は、模写、変更、および承認を一定のデータベース機能に提供するように設計されています。 分配されているので、それは特に大きいグローバルなホワイトページディレクトリに合っています。 原則として、それには、良い探す能力があります、どんなレベルにおける、または、DIT(ディレクトリ情報Tree)のどんな下位木における検索を許して。 すべてのタイプのワークステーションに利用可能なDUIsがあります、そして、X.500は世界規格です。 しかしながら、X.500は実際には、使用できないくらい理論上、X.500が広大に他のシステムより良いディレクトリサービスを提供できて、難しく、複雑で、不便です。 それは、より良いサービスを提供するべきです。 X.500はホワイトページサービスを提供するのに使用されるかもしれない技術です、X.500のいくつかの特徴がまさしくホワイトページサービスを提供するのに必要でないかもしれませんが。
The are three reasons X.500 deployment has been slow, and these are largely the same reasons people don't like it:
X.500展開が遅く、これらが人々がそれが好きでない主に同じ理由である3つの理由です:
1) The available X.500 implementations (mostly quipu based on the
ISODE) are very large and complicated software packages that are
hard to work with. This is partly because they solve the general
X.500 problem, rather than the subset needed to provide an
Internet white pages directory. In practice, this means that a
portion of the code/complexity is effectively unused.
1) 利用可能なX.500実装(ほとんどISODEに基づく結び縄文字)は働きにくい非常に大きくて複雑なソフトウェアパッケージです。 これは一部彼らがインターネットホワイトページディレクトリを提供するのに必要である部分集合よりむしろ一般的なX.500問題を解決するからです。 実際には、これは、事実上、コード/複雑さの部分が未使用であることを意味します。
The LDAP work has virtually eliminated this concern on the client
side of things, as LDAP is both simple and lightweight. Yet, the
complexity problem still exists on the server side of things, so
people continue to have trouble bringing up data for simple
clients to access.
LDAP仕事は実際にはもののクライアント側面でこの関心を排除しました、LDAPが簡単であって、かつ軽量であるときに。 しかし、複雑さ問題がもののサーバ側面にまだ存在しているので、人々は、純真なクライアントのためにデータをアクセサリーに持って来るのに苦労し続けています。
It has been suggested that the complexity in X.500 is due to the
protocol stack and the ISODE base. If this is true, then LDAP may
be simple because it uses TCP directly without the ISODE base. A
version of X.500 server that took the same approach might also be
"simple" or at least simpler. Furthermore, the difficulty in
getting an X.500 server up may be related to finding the data to
X.500の複雑さがプロトコル・スタックとISODEベースのためであることが提案されました。 これが本当であるなら、直接ISODEベースなしでTCPを使用するので、LDAPは簡単であるかもしれません。 また、同じアプローチを取ったX.500サーバのバージョンも、「簡単である」か少なくとも簡単であるかもしれません。 その上、データを見つけますX.500サーバを起こすことにおける苦労に関連しているかもしれない。
Postel & Anderson [Page 12] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[12ページ]RFC1588ホワイトページは1994年2月に報告します。
put in the server, and so may be a general data management problem
rather than an X.500 specific problem.
サーバを入れてください、そして、X.500の特定の問題よりむしろ一般データ管理問題もそうです。
There is some evidence that eventually a large percentage of the
use of directory services may be from applications rather than
direct user queries. For example, mail-user-agents exist that are
X.500 capable with an integrated DUA (Directory User Agent).
結局ディレクトリサービスの使用の大きな割合がユーザー・クエリーを指示するよりアプリケーションからむしろ来ているかもしれないという何らかの証拠があります。 例えば、統合DUA(ディレクトリUserエージェント)と共にできるX.500であるメールユーザエージェントは存在します。
2) You have to "know a lot" to get a directory service up and running
with X.500. You have to know about object classes and attributes
to get your data into X.500. You have to get a distinguished name
for your organization and come up with an internal tree structure.
You have to contact someone before you can "come online" in the
pilot. It's not like gopher where you type "make", tell a few
friends, and you're up and running.
2) あなたは、ディレクトリサービスがX.500と共に活動するようになるのを「大いに知らなければなりません」。 オブジェクトのクラスと属性に関して、あなたのデータはX.500に得られなければならないんでしょう? あなたは、あなたの組織のために分類名を得て、内部の木構造を思いつかなければなりません。 パイロットで「オンラインで、来ることができる」前にあなたはだれかに連絡しなければなりません。 数人の友人が、それがあなたが「作成」をタイプするところでリスに似ていないと言います、そして、あなたは活動しています。
Note that a gopher server is not a white pages service, and as
noted elsewhere in this report, there are a number of issues that
apply to white pages service that are not addressed by gopher.
リスサーバがホワイトページサービスでないことに注意してください。そうすれば、別掲のとおりこのレポートには、リスによって扱われないホワイトページサービスに適用される多くの問題があります。
Some of these problems could be alleviated by putting in place
better procedures. It should not any be harder to get connected
to X.500 than it is to get connected to the DNS, for example.
However, there is a certain amount of complexity that may be
inherent in directory services. Just compare Whois++ and X.500.
X.500 has object classes. Whois++ has templates. X.500 has
attributes. Whois++ has fields. X.500 has distinguished names.
Whois++ has handles.
より良い手順を適所に置くことによって、これらの問題のいくつかを軽減できるでしょう。 それはいくらか困難であるべきではありません。極めてX.500に接続させにくくなってください。 しかしながら、ある量のディレクトリサービスに固有であるかもしれない複雑さがあります。 ただWhois++とX.500を比較してください。 X.500には、オブジェクトのクラスがあります。 Whois++には、テンプレートがあります。 X.500には、属性があります。 Whois++には、分野があります。 X.500には、分類名があります。 Whois++には、ハンドルがあります。
3) Getting data to populate the directory, converting it into the
proper form, and keeping it up-to-date turns out to be a hard
problem. Often this means talking to the administrative computing
department at your organization.
3) ディレクトリに居住するためにデータを得て、適切なフォームにそれを変換して、それを最新に保つのは難問であると判明します。 しばしば、これは、あなたの組織のときに管理コンピューティング部と話すことを意味します。
This problem exists regardless of the protocol used. It should be
easy to access this data through the protocol you're using, but
that says more about implementations than it does about the
protocol. Of course, if the only X.500 implementation you have
makes it really hard to do, and the Whois++ implementation you
have makes it easy, it's hard for that not to reflect on the
protocols.
この問題は使用されるプロトコルにかかわらず存在しています。 あなたが使用しているプロトコルを通したプロトコルに関してそうするより実装に関する以上を言うこのデータにアクセスするのは簡単であるはずです。 もちろん、あなたが持っている唯一のX.500実装で本当にしにくいようになって、あなたが持っているWhois++実装で簡単になるなら、それはプロトコルをよく考えにくくはありません。
The fact that there are sites like University of Michigan, University of Minnesota, Rutgers University, NASA, LBL, etc. running X.500 in serious production mode shows that the problem has more to do with the current state of X.500 software procedures. It takes a lot of effort to get it going. The level of effort required to keep it going is relatively very small.
重大な生産モードにはミシガン大学、ミネソタ大学、ラトガース大学、NASA、LBL、などの実行しているX.500のようなサイトがあるという事実は、問題はX.500ソフトウェア手順の現状と、より多く関係があるのを示します。 それを開始させるのに多くの取り組みを要します。 行かせ続けるのに必要である取り組みのレベルは比較的非常に小さいです。
Postel & Anderson [Page 13] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[13ページ]RFC1588ホワイトページは1994年2月に報告します。
The yellow pages problem is not really a problem. If you look at it in the traditional phonebook-style yellow pages way, then X.500 can do the job just like the phone book does. Just organize the directory based on different (i.e., non-geographical) criteria. If you want to "search everything", then you need to prune the search space. To do this you can use the Whois++ centroids idea, or something similar. But this idea is as applicable to X.500 as it is to Whois++. Maybe X.500 can use the centroids idea most effectively.
職業別広告欄問題は本当に問題ではありません。 あなたが伝統的なphonebook-スタイル職業別広告欄でそれを見るなら、ずっと、X.500は電話帳がまさしくするように仕事できます。 すなわち、異なることに基づいてただディレクトリをまとめてください、(非、地理的である、)、評価基準。 「すべてを捜したい」なら、あなたは、検索スペースを剪定する必要があります。 これをするために、あなたは+ 図心考えと、例えば、Whois+同様を使用できます。 しかし、この考えはX.500にWhois++にはそれがあるのと同じくらい適切です。多分、X.500は最も効果的に図心考えを使用できます。
Additionally, it should be noted that there is not one single Yellow Pages service, but that according to the type of query there could be several such as querying by role, by location, by email address.
さらに、1つのただ一つのイエローページサービスがありませんが、質問のタイプに従って、数個が役割による質問などに似るかもしれないことに注意されるべきです、位置のそばで、Eメールアドレスで。
No one is failing to run X.500 because they perceive it fails to solve the yellow pages problem. The reasons are more likely one or more of the three above.
彼らが、それが職業別広告欄問題を解決しないと知覚するので、だれもX.500を実行していません。 おそらく、理由は上の3つのものの1つ以上です。
X.500's extra complexity is paying off for University of Michigan. University of Michigan started with just people information in their tree. Once that infrastructure was in place, it was easy for them to add more things to handle mailing lists/email groups, yellow pages applications like a documentation index, directory of images, etc.
X.500の付加的な複雑さはミシガン大学にうまく行っています。 ミシガン大学は彼らの木でまさしく人々情報から始まりました。 そのインフラストラクチャが適所にいったんあると、彼らがメーリングリスト/メールグループ、ドキュメンテーションインデックスのような職業別広告欄アプリケーション、イメージのディレクトリなどを扱うより多くのことを加えるのは、簡単でした。
The ESnet community is using X.500 right now to provide a White Pages service; users succeed everyday in searching for information about colleagues given only a name and an organizational affiliation; and yes, they do load data into X.500 from an Oracle database.
ESnet共同体はたった今、ページサービスをホワイトに提供するのにX.500を使用しています。 ユーザは、毎日、名前と組織的な所属だけを考えて、同僚の情報を検索するのに成功します。 はい、そして、彼らはオラクルデータベースからX.500に負荷データを翻訳します。
LBL finds X.500 very useful. They can lookup DNS information, find what Zone a Macintosh is in, lookup departmental information, view the current weather satellite image, and lookup people information.
LBLは、X.500が非常に役に立つのがわかります。 それら、缶のルックアップDNS情報、中にどんなZone aマッキントッシュがあるか、そして、ルックアップの部門の情報、現在の気象衛星が像を描く視点、およびルックアップが住ませる掘り出し物、情報。
LDAP should remove many of the complaints about X.500. Implementing a number of LDAP clients is very easy and has all the functionality needed. Perhaps DAP should be scrapped.
LDAPはX.500に関する苦情の多くを取り除くはずです。 多くのLDAPクライアントを実装するのは、非常に簡単であり、機能性が必要としたすべてを持っています。 恐らく、DAPは廃棄されるべきです。
Another approach is the interfacing of X.500 servers to WWW (the interface is sometimes called XWI). Using the mosaic program from the NCSA, one can access X.500 data.
別のアプローチはWWWへのX.500サーバの連結(インタフェースは時々XWIと呼ばれる)です。 NCSA、1からのモザイクのプログラムを使用すると、X.500データにアクセスできます。
INTERNET X.500
インターネットX.500
The ISO/ITU may not make progress on improving X.500 in the time frame required for an Internet white pages service. One approach is to have the Internet community (e.g., the IETF) take responsibility for developing a subset or profile of that part of X.500 it will use, and developing solutions for the ambiguous and undefined parts of X.500 that are necessary to provide a complete service.
インターネットホワイトページサービスに必要である時間枠でX.500を改良するとき、ISO/ITUは進展しないかもしれません。 1つのアプローチはインターネットコミュニティ(例えば、IETF)に完全なサービスを提供するのに必要なX.500のその部分の部分集合かプロフィールを開発して、それが使用するX.500のあいまいで未定義の部分の現像液への責任を取らせることです。
Postel & Anderson [Page 14] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[14ページ]RFC1588ホワイトページは1994年2月に報告します。
Tasks this approach might include are:
このアプローチが含むかもしれないタスクは以下の通りです。
1. Internet (IETF) control of the base of the core service white
pages infrastructure and standard.
1. コアサービスホワイトページインフラストラクチャと規格のベースのインターネット(IETF)コントロール。
2. Base the standard on the 1993 specification, especially
replication and access control.
2. 規格を1993年の仕様、特に模写、およびアクセスコントロールに基礎づけてください。
3. For early deployment choose which parts of the replication
protocol are really urgently needed. It may be possible to define
a subset and to make it mandatory for the Internet.
3. 早めの展開に、模写プロトコルのどの部分が本当に緊急に必要であるかを選んでください。 部分集合を定義して、それをインターネットに義務的にするのは可能であるかもしれません。
4. Define an easy and stable API (Application Program Interface) for
key access protocols (DAP, LDAP).
4. 主要なアクセス・プロトコル(DAP、LDAP)のために、簡単で安定したAPI(アプリケーションProgram Interface)を定義してください。
5. Use a standard knowledge model.
5. 標準の知識モデルを使用してください。
6. Make sure that high performance implementations will exist for the
most important servers, roles principally for the upper layers of
the DSA tree.
6. 高性能実装が最も重要なサーバ(主にDSA木の上側の層のための役割)のために存在するのを確実にしてください。
7. Make sure that servers will exist that will be able to efficiently
get the objects (or better the attributes) from existing
traditional databases for use at the leaves of the DSA tree.
7. DSA木の葉で使用のための既存の伝統的なデータベースからオブジェクト(属性を改善する)を効率的に、手に入れることができるサーバが存在するのを確実にしてください。
4.B. WHOIS++
4. B.WHOIS++
The very first discussions of this protocol started in July 1992. In less than 15 months there were 3 working public domain implementations, at least 3 more are on the way, and a Whois++ front-end to X.500. In addition, the developers who are working on the resource location system infrastructure (URL/URI) have committed to implementing it on top of Whois++ because of its superior search capabilities.
このプロトコルのまさしくその最初の議論は1992年7月に始まりました。 + + 15カ月未満には、3つの働く公共の場実装があって、少なくとももう3は途中のそうであり、WhoisはX.500へのフロントエンドです。 さらに、リソース位置測定システムインフラストラクチャ(URL/URI)に取り組んでいる開発者は優れた検索能力によるWhois++の上でそれを実装するのに公約しました。
Some of the main problems with getting a White Pages directory going have been: (1) search, (2) lack of public domain versions, (3) implementations are too large, (4) high start up cost, and (5) the implementations don't make a lot of sense for a local directory, particularly for small organizations. Whois++ can and does address all these problems very nicely.
ホワイトページディレクトリを開始させることに関する主な問題のいくつかは以下の通りです。 (1) (5) (2) (3) 検索、公共の場バージョンの不足、実装は大き過ぎます、(4)高値始動費用、そして、実装がローカルディレクトリと、特に小さい組織のための多くの意味になりません。 Whois++は、訴えて、非常にうまくこれらのそのすべての問題を訴えることができます。
Search is built into Whois++, and there is a strong commitment from the developers to keep this a high priority.
Whois++は検索に組み込まれます、そして、これが高い優先度であることを保つために、開発者からの強い委任があります。
Postel & Anderson [Page 15] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[15ページ]RFC1588ホワイトページは1994年2月に報告します。
The protocols are simple enough that someone can write a server in 3 days. And people have done it. If the protocols stay simple, it will always be easy for someone to whip out a new public domain server. In this respect, Whois++ is much like WAIS or Gopher.
プロトコルはだれかが3日間でサーバを書くことができるくらい簡単です。 そして、人々はそれをしました。 プロトコルが簡単な状態で残っていると、だれかが新しい公共の場サーバを抜き放つのは、いつも簡単でしょう。この点で、Whois++はWAISかゴーファーに似ています。
The typical Whois++ implementation is about 10 megabytes, including the WAIS source code that provides the data engine. Even assuming a rough doubling of the code as additional necessary functionality is built in, that's still quite reasonable, and compares favorably with the available implementations of X.500. In addition, WAIS is disk- based from the start, and is optimized for local searching. Thus, this requires only disk storage for the data and the indexes. In a recent test, Chris Weider used a 5 megabyte source data file with the Whois++ code. The indices came to about another 7 megabytes, and the code was under 10 megabytes. The total is 22 megabytes for a Whois++ server.
典型的なWhois++実装はデータエンジンを提供するWAISソースコードを含むおよそ10メガバイトです。 追加するとしての必要な機能性が築き上げられるコードを倍にするあぶれ者を仮定さえして、それは、まだかなり妥当であり、X.500の利用可能な実装で勝るとも劣らないです。 さらに、WAISは始めから基づくディスクであり、地方の探すために最適化されます。 したがって、これはデータとインデックスのためのディスクストレージだけを必要とします。 最近のテストで、クリス・ワイダーはWhois++コードがある5メガバイトのソースデータファイルを使用しました。 インデックスリストは別のものに関する7メガバイト、およびコードに達しました。10メガバイトの下にありました。 合計はWhois++サーバのための22メガバイトです。
The available Whois++ implementations take about 25 minutes to compile on a Sun SPARCstation IPC. Indexing a 5 megabyte data file takes about another 20 minutes on an IPC. Installation is very easy. In addition, since the Whois++ server protocol is designed to be only a front-end, organizations can keep their data in any form they want.
+ + 実装がSun SPARCstation IPCでコンパイルするにはおよそ25分かかる利用可能なWhois。 5メガバイトのデータファイルに索引をつけるのはIPCでもう20分に関して取ります。 インストールは非常に簡単です。 さらに、Whois以来、+ + サーバプロトコルはフロントエンドだけになるように設計されていて、組織は彼らが欲しいどんなフォームにもそれらのデータを保つことができます。
Whois++ makes sense as a local directory service. The implementations are small, install quickly, and the raw query language is very simple. The simplicity of the interaction between the client and the server make it easy to experiment with and to write clients for, something that wasn't true of X.500 until LDAP. In addition, Whois++ can be run strictly as a local service, with integration into the global infrastructure done at any time.
+ +がローカルディレクトリサービスとして理解できるWhois。 実装は、小さく、すばやくインストールされます、そして、生の照会言語は非常に簡単です。 クライアントとサーバとの相互作用の簡単さでクライアントに実験して、書くのが簡単になります、X.500に関してLDAPまで何か本当でなかったもの。 さらに、ローカル・サービスとして厳密にWhois++を実行できます、いつでも行われたグローバルなインフラストラクチャへの統合で。
It is true that Whois++ is not yet a fully functional White Pages service. It requires a lot of work before it will be so. However, X.500 is not that much closer to the goal than Whois++ is.
しかし、Whois++が完全な機能的なホワイトのページサービスであるというわけではないことは本当です。 したがって、必要になる前にそれは多くの仕事を必要とします。 しかしながら、X.500は目標のWhois++より近くでそれだけではありません。
Work needs to be done on replication and authentication of data. The current Whois++ system does not lend itself to delegation. Research is still needed to improve the system and see if it scales well.
仕事は、データの模写と認証のときにする必要があります。 + + システムがする現在のWhoisは委譲に適していません。 研究が、システムを改良して、それがよく比例するかどうか確認するのにまだ必要です。
Postel & Anderson [Page 16] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[16ページ]RFC1588ホワイトページは1994年2月に報告します。
4.C. NETFIND
4. C.NETFIND
Right now, the white pages service with the most coverage in the Internet is Mike Schwartz' Netfind. Netfind works in two stages: 1) find out where to ask, and 2) start asking.
'たった今、最も多くの適用範囲がインターネットにあるホワイトページサービスはマイクシュワルツ'Netfindです。 Netfindは2つの段階で働いています: 1) どこで尋ねるか調べてください。そうすれば、2は)尋ね始めます。
The first stage is based on a database of netnews articles, UUCP maps, NIC WHOIS databases, and DNS traversals, which then maps organizations and localities to domain names. The second stage consists of finger queries, Whois queries, smtp expns and vrfys, and DNS lookups.
第一段階は次に組織と場所をドメイン名に写像するネットニュース記事、UUCP地図、NIC WHOISデータベース、およびDNS縦断に関するデータベースに基づいています。 2番目のステージは指の質問、Whois質問、smtp expns、vrfys、およびDNSルックアップから成ります。
The key feature of Netfind is that it is proactive. It doesn't require that the system administrator bring up a new server, populate it with all kinds of information, keep the information in sync, worry about update, etc. It just works.
Netfindに関する重要な特色はそれが先を見越すということです。 それは、システム管理者が新しいサーバを持って来るのを必要としないで、すべての種類の情報でそれに居住してください、そして、同時性における情報、アップデートについての心配などを保ってください。 それはただ働いています。
A suggestion was made that Netfind could be used as a way to populate the X.500 directory. A tool might do a series of Netfind queries, making the corresponding X.500 entries as it progresses. Essentially, X.500 entries would be "discovered" as people look for them using Netfind. Others do not believe this is feasible.
X.500ディレクトリに居住する方法としてNetfindを使用できたという提案をしました。 進歩をしながら対応するX.500エントリーをして、ツールは一連のNetfind質問をするかもしれません。 本質的には、人々がNetfindを使用することで彼らを探すとき、X.500エントリーは「発見されるでしょう」。 他のものは、これが可能であると信じていません。
Another perhaps less interesting merger of Netfind and X.500 is to have Netfind add X.500 as one of the places it looks to find organizations (and people).
恐らくNetfindとX.500の、より少ないおもしろい合併がある別のもので、Netfindはそれが組織(そして、人々)を見つけるために見る場所の1つとしてX.500を加えます。
A search can lead you to where a person has an account (e.g., law.xxx.edu) only to find a problem with the DNS services for that domain, or the finger service is unavailable, or the machines are not be running Unix (there are lots of VMS machines and IBM mainframes still out there). In addition, there are security gateways. The trends in computing are towards the use of powerful portables and mobile computing and hence Netfind's approach may not work. However, Netfind proves to be an excellent yellow-pages service for domain information in DNS servers - given a set of keywords it lists a set of possible domain names.
検索があなたを人がそのドメインのためのDNSサービスに関する問題を見つけるためには唯一のアカウント(例えば、law.xxx.edu)を持っているところに導くことができますか、フィンガー・サービスが入手できないか、またはマシンはUnixを実行していません(それでも、多くのVMSマシンとIBMメインフレームがむこうにあります)。 さらに、セキュリティゲートウェイがあります。 コンピューティングにおける傾向は強力なportablesの使用に向かっています、そして、モバイル・コンピューティングとしたがって、Netfindのアプローチは働かないかもしれません。 しかしながら、1セットの可能なドメイン名をそれがリストアップするキーワードのセットに考えて、Netfindは、DNSサーバのドメイン情報のための素晴らしい職業別広告欄サービスであると判明します。
Suppose we store a pointer in DNS to a white-pages server for a domain. We can use Netfind to come up with a list of servers to search, query these servers, then combine the responses. However, we need a formal method of gathering white-pages data and informal methods will not work and may even get into legal problems.
私たちがドメインのためにDNSにホワイトページサーバとして指針を保存すると仮定してください。 私たちは、探すためにサーバのリストを思いつくのにNetfindを使用して、これらのサーバについて質問して、次に、応答を結合できます。 しかしながら、私たちが集会ホワイトページデータの正式なメソッドを必要として、非公式のメソッドは、働かないで、法律問題に入りさえするかもしれません。
Postel & Anderson [Page 17] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[17ページ]RFC1588ホワイトページは1994年2月に報告します。
The user search phase of Netfind is a short-term solution to providing an Internet white pages. For the longer term, the applicability of the site discovery part of Netfind is more relevant, and more work has been put into that part of the system over the past 2 years than into the user search phase.
Netfindのユーザ検索フェーズはインターネットホワイトページを提供することへの短期的なソリューションです。 より長い期間のときに、Netfindのサイト発見一部の適用性はユーザ検索フェーズより関連しています、そして、過去2年間システムのその部分により多くの仕事を入れています。
Given Netfind's "installed customer base" (25k queries per day, users in 4875 domains in 54 countries), one approach that might make sense is to use Netfind as a migration path to a better directory, and gradually phase Netfind's user search scheme out of existence. The idea of putting a record in the DNS to point to the directory service to search at a site is a good start.
Netfindの「インストールされた顧客ベース」(1日あたりの25k質問、54の国の4875のドメインのユーザ)と考えて、理解できるかもしれない1つのアプローチは、移行パスとして、より良いディレクトリにNetfindを使用して、存在からNetfindのユーザ検索体系の徐々に位相を合わせることです。 サイトで探すためにディレクトリサービスを示すためにDNSに記録を入れるという考えは好調なスタートです。
One idea for further development is to have the DNS record point to a "customization" server that a site can install to tailor the way Netfind (or whatever replaces Netfind) searches their site. This would provide sites a choice of degrees of effort and levels of service. The least common denominator is what Netfind presently does: DNS/SMTP/finger. A site could upgrade by installing a customization server that points to the best hosts to finger, or that says "we don't want Netfind to search here" (if people are sufficiently concerned about the legal/privacy issues, the default could be changed so that searches must be explicitly enabled). The next step up is to use the customization server as a gateway to a local Whois, CSO, X.500, or home grown white pages server. In the long run, if X.500 (or Whois++, etc.) really catches on, it could subsume the site indexing part of Netfind and use the above approach as an evolution path to full X.500 deployment. However, other approaches may be more productive. One key to Netfind's success has been not relying on organizations to do anything to support Netfind, however the customization server breaks this model.
さらなる開発のための1つの考えはDNS記録にサイトがNetfind(何がNetfindを取り替えても)が彼らのサイトを捜す方法を合わせるためにインストールできる「改造」サーバを示させることです。 これは取り組みの度合いとサービスのレベルの選択をサイトに提供するでしょう。 共通項はNetfindが現在することです: DNS/SMTP/指。 サイトは、示すか、中で弄る中でホスト最も良いまたは「私たちは、Netfindにここで探して欲しいと思いません」と言う改造サーバをインストールすることによって、アップグレードできるでしょう(人々が法的な/プライバシーの問題に関して十分心配しているなら、デフォルトを変えるかもしれないので、明らかに検索を可能にしなければなりません)。 上がある次のステップは地方のWhoisへのゲートウェイとして改造サーバを使用して、CSO、X.500、またはホームの成長しているホワイトページはサーバです。結局、X.500(または、Whois++など)が本当に引っかかるなら、それは、Netfindの一部に索引をつけるサイトを包括して、発展経路として完全なX.500展開に上のアプローチを使用するかもしれません。 しかしながら、他のアプローチは、より生産的であるかもしれません。 Netfindの成功の1個のキーはNetfindをサポートするようなことを何もするために組織に依存していなくて、しかしながら、改造サーバはこのモデルを壊します。
Netfind is very useful. Users don't have to do anything to wherever they store their people data to have it "included" in Netfind. But just like archie, it would be more useful if there were a more common structure to the information it gives you, and therefore to the information contained in the databases it accesses. It's this common structure that we should be encouraging people to move toward.
Netfindは非常に役に立ちます。 ユーザはどこでも、彼らがNetfindにそれを「含んだ」ように自分達の人々データを保存するところに何もする必要はありません。 しかし、まさしくarchieのように、それがあなたに教える情報と、そして、したがって、それがアクセスするデータベースに含まれた情報への、より一般的な構造があれば、より役に立つでしょうに。 それは私たちが、人々が近づくよう奨励するべきであるこの一般的な構造です。
As a result of suggestions made at the November meeting, Netfind has been extended to make use of URL information stored in DNS records. Based on this mechanism, Netfind can now interoperate with X.500, WHOIS, and PH, and can also allow sites to tune which hosts Netfind uses for SMTP or Finger, or restrict Netfind from searching their site entirely.
11月のミーティングでされた提案の結果、Netfindは、DNS記録に保存されたURL情報を利用するために広げられました。 このメカニズムに基づいて、Netfindは、現在X.500、WHOIS、およびPHと共に共同利用できて、また、サイトがNetfindがSMTPかFingerに使用するどのホストを調整するか、そして、または彼らのサイトを完全に捜すのでNetfindを制限するのを許容できます。
Postel & Anderson [Page 18] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[18ページ]RFC1588ホワイトページは1994年2月に報告します。
4.D. ARCHIE
4. D.アーチー
Archie is a success because it is a directory of files that are accessible over the network. Every FTP site makes a "conscious" decision to make the files available for anonymous FTP over the network. The mechanism that archie uses to gather the data is the same as that used to transfer the files. Thus, the success rate is near 100%. In a similar vein, if Internet sites make a "conscious" decision to make white-pages data available over the network, it is possible to link these servers to create a world-wide directory, such as X.500, or build an index that helps to isolate the servers to be searched, Whois++. Users don't have to do anything to their FTP archives to have them included in archie. But everybody recognizes that it could be more useful if only there were some more common structure to the information, and to the information contained in the archives. Archie came after the anonymous FTP sites were in wide- spread use. Unfortunately for white-pages, we are building tools, but there is no data.
それがネットワークの上でアクセス可能なファイルのディレクトリであるのでアーチーは成功です。 あらゆるFTPサイトがファイルをネットワークの上で公開FTPに利用可能にするという「意識している」決定をします。 archieがデータがそれと同じであると推測するのに使用するメカニズムは以前はよくファイルを移していました。 したがって、ほぼ100%には成功率があります。 + 似たような仕方で、ホワイトページをデータにするという「意識している」決定がインターネット・サイトでネットワークの上で利用可能になるなら、X.500などの世界的なディレクトリを作成するためにこれらのサーバをリンクするか、または捜されるためにサーバを隔離するのを助けるインデックスを造るのが可能であり、Whoisは+です。ユーザは、archieにそれらを含んだように彼らのFTPアーカイブに何もする必要はありません。 しかし、情報と、そして、アーカイブに含まれた情報へのそれ以上の一般的な構造があるだけであるなら、みんなは、それが、より役に立つかもしれないと認めるでしょうに。 公開FTPサイトが広い普及の使用であった後にアーチーは来ました。 残念ながら、ホワイトページのために、私たちはツールを築き上げていますが、データが全くありません。
4.E. FINGER
4. E.指
The Finger program that allows one to get either information about an individual with an account, or a list of currently logged in users, from a host running the server, can be used to check a suggestion that a particular individual has an account on a particular host. This does not provide an efficient method to search for an individual.
特定の個人が特定のホストの上にアカウントを持っているという提案をチェックするのに、ユーザに1つでサーバを実行するホストからアカウントをもっている個人の情報か現在のリストのどちらかを登録できるFingerプログラムを使用できます。 これは個人を捜し求める効率的なメソッドを提供しません。
4.F. GOPHER
4. F.リス
A "gateway" between Gopher and X.500 has been created so that one can examine X.500 data from a Gopher client. Similar "gateways" are needed for other white pages systems.
1つがゴーファークライアントからのX.500データを調べることができるように、ゴーファーとX.500の間の「ゲートウェイ」を作成してあります。 同様の「ゲートウェイ」が他のホワイトページシステムに必要です。
4.G. WWW
4. G.WWW
One extension to WWW would be an attribute type for the WWW URI/URL with the possibility for any client to request from the X.500 server (1) either the locator (thus the client would decide to access or not the actual data), or (2) for client not capable of accessing this data, the data itself (packed) in the ASN.1 encoded result.
WWWへの1つの拡大がどんなクライアントもX.500サーバ(1)からこのデータにアクセスできないクライアントのためのロケータ(その結果、クライアントは実際のデータではなく、アクセスに決める)か(2)のどちらかを要求する可能性があるWWW URI/URLのための属性タイプでしょう、ASN.1のコード化された結果におけるデータ(梱包される)自体。
This would give access to potentially any piece of information available on the network through X.500, and in the white pages case to photos or voice messages for persons.
これはX.500を通したフォトへのホワイトページケースか人々への音声メールのネットワークで利用可能に潜在的にどんな情報へのアクセスを与えるでしょう。
Postel & Anderson [Page 19] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[19ページ]RFC1588ホワイトページは1994年2月に報告します。
This solution is preferable to one consisting of storing this multimedia information directly in the directory, because it allows WWW capable DUIs to access directly any piece of data no matter how large. This work on URIs is not WWW-specific.
このソリューションは直接ディレクトリのこのマルチメディア情報を保存するのから成りながら、1より望ましいです、WWWのできるDUIsがどんなに大きくてもそれから直接どんなデータにアクセスできるので。 URIに対するこの仕事はWWW特有ではありません。
5. ISSUES
5. 問題
5.A. DATA PROTECTION
5. A.データ保護
Outside of the U.S., nearly all developed countries have rather strict data protection acts (to ensure privacy mostly) that governs any database on personal data.
米国の外では、ほとんどすべての先進国が個人的なデータに関するどんなデータベースも支配するかなり厳しいデータ保護条例(ほとんど秘密を守る)を持っています。
It is mandatory for the people in charge of such white pages databases to have full control over the information that can be stored and retrieved in such a database, and to provide access controls over the information that is made available.
そのようなホワイトページデータベース担当の人々にはそのようなデータベースで保存して、検索できる情報の完全なコントロールがあって、利用可能にされる情報の上にアクセス制御を提供するのは義務的です。
If modification is allowed, then authentication is required. The database manager must be able to prevent users from making available unallowed information.
変更が許されているなら、認証が必要です。 データベースマネージャは、ユーザが利用可能な非許容情報を作るのを防ぐことができなければなりません。
When we are dealing with personal records the issues are a little more involved than exporting files. We can not allow trawling of data and we need access-controls so that several applications can use the directory and hence we need authentication.
私たちが個人記録に対処しているとき、問題はファイルをエクスポートするよりかかわっています。 いくつかのアプリケーションがディレクトリを使用できて、したがって、私たちは、認証を必要とします私たちがデータを引かせることができないで、アクセス制御が必要があるので。
X.500 might have developed faster if security issues were not part of the implementation. There is tension between quick lightweight implementations and the attempt to operate in a larger environment with business issues incorporated. The initial belief was that data is owned by the people who put the data into the system, however, most data protection laws appoint the organizations holding the data responsible for the quality of the data of their individuals. Experience also shows that the people most affected by inaccurate data are the people who are trying to access the data. These problems apply to all technologies.
X.500は安全保障問題が実装の一部でなかったなら、より速く展開したかもしれません。 迅速な軽量の実装とビジネス問題が法人組織で、より大きい環境で作動する試みの間には、緊張があります。 初期の信念がデータがシステムにデータを入れる人々によって所有されているということであった、しかしながら、ほとんどのデータ保護法が彼らの個人のデータの品質のデータに責任を負わせる組織を任命します。 また、経験は、不正確なデータで最も影響を受ける人々がデータにアクセスしようとしている人々であることを示します。 これらの問題はすべての技術に適用されます。
5.B. STANDARDS
5. B.規格
Several types of standards are needed: (1) standards for interoperation between different white pages systems (e.g., X.500 and Whois++), (2) standards for naming conventions, and (3) and standards within the structured data of each system (what fields or attributes are required and optional, and what are their data types).
いくつかのタイプの規格が必要です: (1) それぞれのシステムの構造化されたデータの中の異なったホワイトページシステム(例えば、X.500とWhois++)の間のinteroperationの規格、命名規則の(2)規格、(3)、および規格(どんな分野か属性が、必要であって、任意ですか、そして、それらのデータ型であること)。
Postel & Anderson [Page 20] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[20ページ]RFC1588ホワイトページは1994年2月に報告します。
The standards for interoperation may be developed from the work now in progress on URLs, with some additional protocol developed to govern the types of messages and message sequences.
interoperationの規格は現在URLの進行中の仕事から開発されるかもしれません、何らかの追加議定書がメッセージとメッセージ系列のタイプを決定するために開発されている状態で。
Both the naming of the systems and the naming of individuals would benefit from consistent naming conventions. The use of the NADF naming scheme should be considered.
システムの命名と個人の命名の両方が一貫した命名規則の利益を得るでしょう。 NADF命名体系の使用は考えられるべきです。
When structured data is exchanged, standards are needed for the data types and the structural organization. In X.500, much effort has gone into the definition of various structures or schemas, and yet few standard schemas have emerged.
構造化されたデータを交換するとき、データ型と構造的な組織に規格を必要とします。 X.500では、多くの取り組みが様々な構造かschemasの定義に入りましたが、わずかな標準のschemasしか現れていません。
There is a general consensus that a "cookbook" for Administrators would make X.500 implementation easier and more attractive. These are essential for getting X.500 in wider use. It is also essential that other technologies such as Whois++, Netfind, and archie also have complete user guides available.
Administratorsのための「料理の本」でX.500実装が、より簡単でより魅力的になるだろうという全体的な合意があります。 より広い使用でX.500を手に入れるのに、これらは不可欠です。 また、また、Whois++、Netfind、およびarchieなどの他の技術には利用可能な完全なユーザガイドがいるのも、不可欠です。
5.C. SEARCHING AND RETRIEVING
5. C.の探すのと検索
The main complaint, especially from those who enjoyed using a centralized database (such as the InterNIC Whois service), is the need to search for all the John Doe's in the world. Given that the directory needs to be distributed, there is no way of answering this question without incurring additional cost.
特に集中データベース(InterNIC Whoisサービスなどの)を使用するのを楽しんだ人から、主な苦情は世界でジョン・ドウのすべてのものを捜し求める必要性です。 ディレクトリが、分配される必要があるなら、別途費用を被らないでこの質問に答える方法が全くありません。
This is a problem with any distributed directory - you just can't search every leaf in the tree in any reasonable amount of time. You need to provide some mechanism to limit the number of servers that need to be contacted. The traditional way to handle this is with hierarchy. This requires the searcher to have some idea of the structure of the directory. It also comes up against one of the standard problems with hierarchical databases - if you need to search based on a characteristic that is NOT part of the hierarchy, you are back to searching every node in the tree, or you can search an index (see below).
これはどんな分配されたディレクトリに関する問題ですも--あなたはどんな妥当な時間でもただ木のあらゆる葉を捜すことができるというわけではありません。 あなたは、連絡される必要があるサーバの数を制限するために何らかのメカニズムを提供する必要があります。 これを扱う伝統的な方法が階層構造と共にあります。 これは、捜索者にはディレクトリの構造の何らかの考えがあるのを必要とします。 また、あなたが、階層構造の一部でない特性に基づいて探す必要があるなら、それは階層型データベースに関する標準の問題の1つに直面しているか、あらゆるノードを捜すのにあなたが木にいるか、またはあなたがインデックスを捜すことができます(以下を見てください)。
In general:
一般に:
-- the larger the directory the more need for a distributed solution
(for upkeep and managability).
-- より多くが分配されたソリューション(維持とmanagabilityのための)に必要とするディレクトリは、より大きいです。
-- once you are distributed, the search space for any given search
MUST be limited.
-- あなたがいったん分配されていると、どんな与えられた検索のための検索スペースも制限しなければなりません。
-- this makes it necessary to provide more information as part of the
query (and thus makes the directory harder to use).
-- これで、質問(そして、その結果、ディレクトリを使用するのをより困難にする)の一部として詳しい情報を提供するのは必要になります。
Postel & Anderson [Page 21] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[21ページ]RFC1588ホワイトページは1994年2月に報告します。
Any directory system can be used in a manner that makes searching less than easy. With a User Friendly Name (UFN) query, a user can usually find an entry (presuming it exists) without a lot of trouble. Using additional listings (as per NADF SD-5) helps to hide geographic or civil naming infrastructure knowledge requirements.
簡単であるほど探すことを作らない方法でどんなディレクトリシステムも使用できます。 User Friendly Name(UFN)質問で、通常、ユーザは多くの問題なしでエントリー(それが存在すると推定する)を見つけることができます。 追加リスト(NADF SD-5に従って)を使用するのは、地理的であるか民間である命名インフラストラクチャ知識要件を隠すのを助けます。
Search power is a function of DSA design in X.500, not a function of Distinguished Naming. Search can be aided by addition in X.500 of non-distinguishing attributes, and by using the NADF Naming Scheme it is possible to lodge an entry anywhere in the DIT that you believe is where it will be looked for.
検索パワーはDistinguished Namingの機能ではなく、X.500でのDSAデザインの機能です。 追加で非区別属性のX.500で検索を支援できます、そして、NADF Naming Schemeを使用することによって、あなたがそれが探されるところであると信じているDITでどこでもエントリーに宿を貸すのは可能です。
One approach to the distributed search problem is to create another less distributed database to search, such as an index. This is done by doing a (non-interactive) pre-search, and collecting the results in an index. When a user wants to do a real time search, one first searches the index to find pointers to the appropriate data records in the distributed database. One example of this is the building of centroids that contain index information. There may be a class of servers that hold indices, called "index-servers".
分配された検索問題への1つのアプローチは探すためにインデックスのように別の、より少ない分散データベースを作成することです。 (非対話的)のプレ検索をして、インデックスの結果を集めることによって、これをします。 ユーザが分散データベースにおける適切なデータレコードに指針を見つけるためにリアルタイムの検索、1/1の検索にインデックスをしたがっているとき。 この1つの例がインデックス情報を含む図心のビルです。 「インデックスサーバ」と呼ばれるインデックスリストを保持するサーバのクラスがあるかもしれません。
5.D. INDEXING
5. D.インデックス
The suggestion for how to do fast searching is to do indexing. That is to pre-compute an index of people from across the distributed database and hold that index in an index server. When a user wants to search for someone, he first contacts the index-server. The index-server searches its index data and returns a pointer (or a few pointers) to specific databases that hold data on people that match the search criteria. Other systems which do something comparable to this are archie (for FTP file archives), WAIS, and Netfind.
どう速い探すことをするかためには提案はインデックスをすることです。 それは、分散データベースから人々のインデックスをあらかじめ計算して、インデックスサーバでそのインデックスを保持することになっています。ユーザがだれかを捜し求めたがっているとき、彼は最初に、インデックスサーバに連絡します。インデックスサーバは、検索評価基準に合っている人々に関するデータを保持する特定のデータベースに、指数データを捜して、指針(または、いくつかの指針)を返します。 これに匹敵する何かをする他のシステムは、archie(FTPファイルアーカイブのための)と、WAISと、Netfindです。
5.E. COLLECTION AND MAINTENANCE
5. E.収集とメインテナンス
The information must be "live" - that is, it must be used. Often one way to ensure this is to use the data (perhaps locally) for something other than white pages. If it isn't, most people won't bother to keep the information up to date. The white pages in the phone book have the advantage that the local phone company is in contact with the listee monthly (through the billing system), and if the address is not up to date, bills don't get delivered, and there is feedback that the address is wrong. There is even better contact for the phone number, since the local phone company must know that for their basic service to work properly. It is this aspect of directory functionality that leads towards a distributed directory system for the Internet.
情報は「ライブでなければなりません」--すなわち、それを使用しなければなりません。 しばしば、これを確実にする1つの方法はホワイトページ以外の何かに、データ(恐らく局所的である)を使用することです。 それがそうでないなら、ほとんどの人々は情報がわざわざ時代について行かせないでしょう。 電話帳のホワイトページには、毎月(支払いシステムを通して)、アドレスが最新でなく、請求書が提供されないで、アドレスがあるフィードバックが悪くあれば地方の電話会社がlisteeに接触している利点があります。 電話番号に関するさらに良い接触があります、地方の電話会社が彼らの基本サービスが適切に働くようにそれを知らなければならないので。 それはインターネットの分配されたディレクトリシステムに向かって導くディレクトリの機能性のこの局面です。
Postel & Anderson [Page 22] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[22ページ]RFC1588ホワイトページは1994年2月に報告します。
One approach is to use existing databases to supply the white pages data. It then would be helpful to define a particular use of SQL (Structured Query Language) as a standard interface language between the databases and the X.500 DSA or other white pages server. Then one needs either to have the directory service access the existing database using an interface language it already knows (e.g., SQL), or to have tools that periodically update the directory database from the existing database. Some sort of "standard" query format (and protocol) for directory queries, with "standard" field names will be needed to make this work in general. In a way, both X.500 and Whois++ provide this. This approach implies customization at every existing database to interface to the "standard" query format.
1つのアプローチはホワイトページデータを提供するのに既存のデータベースを使用することです。 それが既に知っているインタフェース言語(例えば、SQL)を使用することでディレクトリサービスを既存のデータベースにアクセスさせるか、または次に、他のホワイトページサーバデータベースとX.500 DSAか1の間の標準インターフェース言語が定期的に既存のデータベースからのディレクトリデータベースをアップデートするツールを必要とするとき、SQL(構造化問合せ言語)の特定の使用を定義するのはその時、役立っているでしょう。 ディレクトリ質問のためのある種の「標準」の質問形式(議定書を作る)、「規格」で、フィールド名が、一般に、この仕事をするのに必要でしょう。 ある意味で、X.500とWhois++の両方がこれを提供します。 このアプローチは、「標準」の質問形式に連結するようにあらゆる既存のデータベースで改造を含意します。
Some strongly believe that the white pages service needs to be created from the bottom up with each organization supplying and maintaining its own information, and that such information has to be the same -- or a portion of the same -- information the organization uses locally. Otherwise the global information will be stale and incomplete.
或るものはそのような情報は、同じくらい、または同じくらいの部分でなければなりません--ホワイトページサービスが、各組織がそれ自身の情報を提供して、保守している状態で下から作成される必要があって、組織が局所的に使用する情報と強く信じています。 さもなければ、グローバルな情報は、聞き古したである不完全になるでしょう。
One way to make this work is to distribute software that:
ある道にこれが扱う造には、ソフトウェアを分配するために、それがいます:
- is useful locally,
- 局所的に役に立ちます。
- fits into the global scheme,
- グローバルな体系への発作
- is available free, and
- 無料で利用可能です。
- works on most Unix systems.
- ほとんどのUnixシステムの上の作品。
With respect to privacy, it would be good for the local software to have controls that make it possible to put company sensitive information into the locally maintained directory and have only a portion of it exported for outsiders.
プライバシーに関して、ローカルのソフトウェアには局所的に維持されたディレクトリに会社の機密情報を入れて、部外者のためにそれの部分だけをエクスポートさせるのを可能にするコントロールがあるのは、良いでしょう。
5.F. NAMING STRUCTURE
5. 構造を命名するF.
We need a clear naming scheme capable of associating a name with attributes, without any possible ambiguities, that is stable over time, but also capable of coping with changes. This scheme should have a clear idea of naming authorities and be able to store information required by authentication mechanisms (e.g., PEM or X.509 certificates).
私たちは属性の名前を関連づけることができる明確な命名体系を必要としますが、少しも可能なあいまいさがなければ、それは、時間がたつにつれて、安定しますが、また、変化に対処できます。 この体系は、当局を任命するというはっきりした認識を持って、認証機構(例えば、PEMかX.509証明書)によって必要とされた情報を保存しているべきです。
The NADF is working to establish a National Public Directory Service, based on the use of existing Civil Naming Authorities to register entry owners' names, and to deal with the shared-entry problem with a shared public DIT supported by competing commercial service
NADFは、エントリー所有者の名前を登録するために既存のCivil Naming Authoritiesの使用に基づくNational Publicディレクトリサービスを証明して、競争している商業サービスでサポートされる共有された公共のDITに関する共有されたエントリー問題に対処するために働いています。
Postel & Anderson [Page 23] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[23ページ]RFC1588ホワイトページは1994年2月に報告します。
providers. At this point, we do not have any sense at the moment as to how [un]successful the NADF may be in accomplishing this.
プロバイダー。 ここに、私たちには現在、どんな感覚もない、どのように、[不-、]、成功、これを達成するのにおいてNADFがあるかもしれないか。
The NADF eventually concluded that the directory should be organized so entries can be found where people (or other entities) will look for them, not where civil naming authorities would place their archival name registration records.
NADFは、結局、ディレクトリが人々(または、他の実体)がそれらを探すところで民間命名当局が彼らの記録保管所の名前登録記録を置くだろうところで見つけられるのではなく、エントリーを見つけることができるようにまとめられるべきであると結論を下しました。
There are some incompatibilities between use of the NADF Naming Scheme, the White Pages Pilot Naming Scheme, and the PARADISE Naming Scheme. This should be resolved.
NADF Naming Schemeの使用と、ホワイトページPilot Naming Schemeと、PARADISE Naming Schemeの間には、何らかの非互換性があります。 これは決議されるべきです。
5.G. CLAYMAN PROPOSAL
5. G.CLAYMAN提案
RFC 1107 offered a "strawman" proposal for an Internet Directory Service. The next step after strawman is sometimes called "clayman", and here a clayman proposal is presented.
RFC1107はインターネットディレクトリサービスのために「わら人形」提案を出しました。 わら人形の後の次のステップは時々"clayman"と呼ばれます、そして、ここに、clayman提案は提示されます。
We assume only white pages service is to be provided, and we let sites run whatever access technologies they want to (with whatever access controls they feel comfortable).
私たちは、唯一のホワイトページサービスが提供されることであると思います、そして、サイトにそれらがそうしたがっているどんなアクセス技術(彼らが快適であると感じるどんなアクセス制御があるも)も実行させます。
Then the architecture can be that the discovery process leads to a set of URLs. A URL is like an address, but it is a typed address with identifiers, access method, not a protocol. The client sorts the URLs and may discard some that it cannot deal with. The client talks to "meaningful URLs" (such as Whois, Finger, X.500).
そして、アーキテクチャは発見プロセスが1セットのURLに通じるということであるかもしれません。 URLはアドレスに似ていますが、それはプロトコルではなく、識別子があるタイプされたアドレス、アクセス法です。 クライアントは、URLを分類して、それが対処できないいくつかを捨てるかもしれません。 クライアントは「重要なURL」(Whois、Finger、X.500などの)と話します。
This approach results in low entry cost for the servers that want to make information available, a Darwinian selection of access technologies, coalescence in the Internet marketplace, and a white pages service will tend toward homogeneity and ubiquity.
低いエントリーにおける結果が情報を利用可能にしたがっているサーバ、アクセス技術のダーウィン淘汰、インターネット市場の合同、およびホワイトページサービスにかかるこのアプローチは同質と偏在の傾向があるでしょう。
Some issues for further study are what discovery technology to use (Netfind together with Whois++ including centroids?), how to handle non-standard URLs (one possible solution is to put server on top of these (non-standard URLs) which reevaluates the pointer and acts as a front-end to a database), which data model to use (Finger or X.500), and how to utilize a common discovery technology (e.g., centroids) in a multiprotocol communication architecture.
さらなる研究へのいくつかの問題はどんな発見技術を使用するか、そして、(図心を含むWhois++に伴うNetfind?)どのように、標準的でないURL(1つの可能なソリューションはこれら(標準的でないURL)の上のデータベースに指針を再評価して、フロントエンドとして機能するサーバを置くことである)を扱うか、そして、どのデータモデルを使用するか、そして、(指かX.500)「マルチ-プロトコル」通信アーキテクチャでどのように、一般的な発見技術(例えば、図心)を利用するかということです。
The rationale for this meta-WPS approach is that it builds on current practices, while striving to provide a ubiquitous directory service. Since there are various efforts going on to develop WPS based on various different protocols, one can envisage a future with a meta- WPS that uses a combination of an intelligent user agent and a distributed indexing service to access the requested data from any available WPS. The user perceived functionality of such a meta-WPS
このメタ-WPSアプローチのための原理は遍在しているディレクトリサービスを提供するように努力している間現在の実務に建てるということです。 様々な異なったプロトコルに基づくWPSを開発し続ける様々な取り組みがあるので、人はどんな利用可能なWPSからも要求されたデータにアクセスするのに知的なユーザエージェントと分配された索引作成業務の組み合わせを使用するメタWPSがある未来を考えることができます。ユーザはそのようなメタ-WPSの機能性を知覚しました。
Postel & Anderson [Page 24] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[24ページ]RFC1588ホワイトページは1994年2月に報告します。
will necessarily be restricted to the lowest common denominator. One will hope that through "market" forces, the number of protocols used will decrease (or converge), and that the functionality will increase.
必ず最小公分母に制限されるでしょう。 人は「市場」力で、使用されるプロトコルの数が減少して(一点に集まってください)、機能性が増加することを望むでしょう。
The degree to which proactive data gathering is permitted may be limited by national laws. It may be appropriate to gather data about which hosts have databases, but not about the data in those databases.
先を見越すデータ集会が受入れられる度合いは国内法令で制限されるかもしれません。 それらのデータベースにどのホストにデータベースがあるかに関して資料を取り集めますが、データに関して少しも資料を取り集めるのは適切でないかもしれません。
6. CONCLUSIONS
6. 結論
We now revisit the questions we set out to answer and briefly describe the key conclusions.
私たちは、今、私たちが、答え始めるという質問を再訪させて、簡潔に主要な結論について説明します。
6.A. WHAT FUNCTIONS SHOULD A WHITE PAGES DIRECTORY PERFORM?
6.A. ホワイトページディレクトリはどんな機能を実行するはずですか?
After all the discussion we come to the conclusion that there are two functions the white pages service must provide: searching and retrieving.
すべての議論の後に、私たちはホワイトページサービスが提供しなければならない2つの機能があるという結論に達します: 捜して、検索します。
Searching is the ability to find people given some fuzzy information about them. Such as "Find the Postel in southern California". Searches may often return a list of matches.
彼らに関する何らかのファジー情報を考えて、探すのは人々を見つける能力です。 「南カリフォルニアでポステルを見つけます。」 検索はしばしば取組表を返すかもしれません。
The recognition of the importance of indexing in searching is a major conclusion of these discussions. It is clear that users want fast searching across the distributed database on attributes different from the database structure. It is possible that pre-computed indices can satisfy this desire.
探すことで索引をつける重要性の認識はこれらの議論の主要な結論です。 ユーザが、速く属性の分散データベースの向こう側に探すのにデータベース構造と異なっていて欲しいのは、明確です。 あらかじめ計算されたインデックスリストがこの願望を満たすことができるのは、可能です。
Retrieval is obtaining additional information associated with a person, such as address, telephone number, email mailbox, and security certificate.
電話番号、メールメールボックス、およびセキュリティは、検索がアドレスなどの人に関連している追加情報を得ていると証明します。
This last, security certificates, is a type of information associated with an individual that is essential for the use of end-to-end authentication, integrity, and privacy, in Internet applications. The development of secure application in the Internet is dependent on a directory system for retrieving the security certificate associated with an individual. The PEM system has been developed and is ready to go into service, but is now held back by the lack of an easily used directory of security certificates.
この最終(セキュリティ証明書)は終わりから終わりへの認証、保全、およびプライバシーの使用に、不可欠の個人に関連している情報の種類です、インターネットアプリケーションで。 インターネットでの安全なアプリケーションの開発は個人に関連しているセキュリティ証明書を検索するディレクトリシステムに依存しています。 PEMシステムは、開発されて、サービスに入る準備ができていますが、現在、セキュリティ証明書の容易に使用されたディレクトリの不足によって抑えられます。
PEM security certificates are part of the X.509 standard. If X.500 is going to be set aside, then other alternatives need to be explored. If X.500 distinguished naming is scrapped, some other structure will need to come into existence to replace it.
PEMセキュリティ証明書はX.509規格の一部です。 X.500がかたわらに置かれるなら、他の代替手段は、探検される必要があります。 X.500の顕著な命名が廃棄されると、ある他の構造は、それを取り替えるために生まれる必要があるでしょう。
Postel & Anderson [Page 25] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[25ページ]RFC1588ホワイトページは1994年2月に報告します。
6.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY?
6.B. どんなアプローチがホワイトページディレクトリを米国に提供するでしょうか?
It is clear that there will be several technologies in use. The approach must be to promote the interoperation of the multiple technologies. This is traditionally done by having conventions or standards for the interfaces and communication forms between the different systems. The need is for a specification of the simplest common communication form that is powerful enough to provide the necessary functionality. This allows a variety of user interfaces on any number of client systems communicating with different types of servers. The IETF working group (WG) method of developing standards seems well suited to this problem.
使用中のいくつかの技術があるのは、明確です。 アプローチは複合的な技術のinteroperationを促進することでなければなりません。 伝統的に異系統の間でインタフェースとコミュニケーションフォームのコンベンションか規格を開くことによって、これをします。必要性は必要な機能性を提供するほど強力な最も簡単な一般的なコミュニケーションフォームの仕様のためのものです。 これは異なったタイプのサーバとコミュニケートするいろいろなクライアントシステムの上にさまざまなユーザにインタフェースを許容します。 規格を開発するIETFワーキンググループ(WG)メソッドはこの問題によく合っているように思えます。
This "common ground" approach aims to provide the ubiquitous WPS with a high functionality and a low entry cost. This may done by singling out issues that are common for various competing WPS and coordinate work on these in specific and dedicated IETF WGs (e.g., data model coordination). The IETF will continue development of X.500 and Whois++ as two separate entities. The work on these two protocols will be broken down in various small and focussed WGs that address specific technical issues, using ideas from both X.500 and Whois++. The goal being to produce common standards for information formats, data model and access protocols. Where possible the results of such a WG will be used in both Whois++ and X.500, although it is envisaged that several WGs may work on issues that remain specific to one of the protocols. The IDS (Integrated Directory Services) WG continues to work on non-protocol specific issues. To achieve coordination that leads to convergence rather than divergence, the applications area directorate will provide guidance to the Application Area Directors as well as to the various WGs, and the User Services Area Council (USAC) will provide the necessary user perspective.
この「共通基盤」アプローチは、高い機能性と低い参入費用を遍在しているWPSに提供することを目指します。 特定の、そして、専用であるIETF WGs(例えば、データモデルコーディネート)で様々な競争しているWPSに一般的であり、これらで仕事を調整する問題を選び抜くことによってして、これはそうするかもしれません。 2が実体を切り離すのに従って、IETFはX.500とWhois++の開発を続けるでしょう。 + これらの2つのプロトコルに対する仕事は特定の専門的な問題を扱う様々な小さくて焦点を合わせられたWGsで砕けて、X.500とWhoisの両方からの使用考えは+です。目標は情報形式、データモデル、およびアクセス・プロトコルのための共通基準を生産することです。 可能であるところでは、そのようなWGの結果が両方のWhois++とX.500で使用されるでしょう、数個のWGsがプロトコルの1つに特定のままで残っている問題に取り組むかもしれないのが考えられますが。 IDS(統合ディレクトリサービス)WGは、非プロトコルの特定の問題に働き続けています。 コーディネートを達成するために、それは分岐よりむしろ集合に通じます、そして、アプリケーション領域の管理職は様々なWGsに関してまた、Application Areaディレクターに指導を提供するでしょう、そして、User Services Area Council(ユーザック)は必要なユーザ見解を提供するでしょう。
6.C. WHAT ARE THE PROBLEMS TO BE OVERCOME?
6.C. 問題は打ち勝つべき、何ですか?
There are several problems that can be solved to make progress towards a white pages service more rapid. We need:
ホワイトページサービスに向かって、より急速な状態で進展するように解決できるいくつかの問題があります。 私たちは以下を必要とします。
To make it much easier to be part of the Internet white pages than bringing up a X.500 DSA, yet making good use of the already deployed X.500 DSAs.
それをまだ有効に既に配布しているX.500 DSAsを利用していて、X.500 DSAを持って来るよりはるかにインターネットの地域でありやすいホワイトページにするように。
To define new simpler white pages services (such as Whois++) such that numerous people can create implementations.
多数の人々が実装を作成できるように、新しいより簡単なホワイトページサービス(Whois++などの)を定義するために。
To provide some central management of the X.500 system to promote good operation.
良い操作を促進するためにX.500システムの何らかの主要な管理を提供するために。
To select a naming scheme.
命名を選択するには、計画してください。
Postel & Anderson [Page 26] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[26ページ]RFC1588ホワイトページは1994年2月に報告します。
To develop a set of index-servers, and indexing techniques, to provide for fast searching.
インデックスサーバと、速く探すのに提供するためにテクニックに索引をつけるセットを発展させるように。
To provide for the storage and retrieval of security certificates.
セキュリティ証明書のストレージと検索に備えるために。
6.D. WHAT SHOULD THE DEPLOYMENT STRATEGY BE?
6.D. 展開戦略は何であるべきですか?
We should capitalize on the existing infrastructure of already deployed X.500 DSAs. This means that some central management must be provided, and easy to use user interfaces (such as the Gopher "gateway"), must be widely deployed.
私たちはX.500 DSAsであると配布された既にの既存のインフラストラクチャを利用するべきです。 これは、何らかの主要な管理を提供しなければならないことを意味します、そして、配布されて、インタフェース(ゴーファー「ゲートウェイ」などの)は、広くたやすく、意味しなければなりませんユーザを使用するために。
-- Document the selection of a naming scheme (e.g., the NADF scheme).
-- 命名体系(例えば、NADF体系)の選択を記録してください。
-- Adopt the "common ground" model. Encourage the development of
several different services, with a goal of interworking between
them.
-- 「共通基盤」モデルを採用してください。 それらの間には、織り込むことの目標がある状態で、いくつかの異なったサービスの開発を奨励してください。
-- Develop a specification of the simplest common communication form
that is powerful enough to provide the necessary functionality.
The IETF working group method of developing standards seems well
suited to this problem.
-- 必要な機能性を提供するほど強力な最も簡単な一般的なコミュニケーションフォームの仕様を開発してください。 規格を開発するIETFワーキンググループメソッドはこの問題によく合っているように思えます。
-- Make available information about how to set up new servers (of
what ever kind) in "cookbook" form.
-- どう新しいサーバをセットアップするかに関する入手可能な情報を作ってください、(いったい何、種類) 「料理の本」では、形成してくださいか。
Postel & Anderson [Page 27] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[27ページ]RFC1588ホワイトページは1994年2月に報告します。
7. SUMMARY
7. 概要
While many issues have been raised, there are just a few where we recommend the action be taken to support specific elements of the overall white pages system.
多くの問題が提起されましたが、まさしくいくつかが私たちが、行動が総合的なホワイトページシステムの特定の原理をサポートするために取られることを勧めるところにあります。
RECOMMENDATIONS
推薦
1. Adopt the common ground approach - give all protocols equal
access to all data. That is, encourage multiple client and
server types, and the standardization of an interoperation
protocol between them. The clients may be simple clients,
front-ends, "gateways", or embedded in other information access
clients, such as Gopher or WWW client programs. The
interoperation protocol will define some message types, message
sequences, and data fields. An element of this protocol should
be the use of URLs.
1. 共通基盤アプローチを取ってください--すべてのデータへの同等のアクセスをすべてのプロトコルに与えてください。 すなわち、複数のクライアントとサーバタイプ、および彼らの間のinteroperationプロトコルの標準化を奨励してください。 クライアントは、純真なクライアント、フロントエンド、「ゲートウェイ」であるかもしれないかアクセスクライアントを他の情報に埋め込みました、ゴーファーやWWWクライアントプログラムのように。interoperationプロトコルは何人かのメッセージタイプ、メッセージ系列、およびデータ・フィールドを定義するでしょう。 このプロトコルの原理はURLの使用であるべきです。
2. Promote the development of index-servers. The index-servers
should use several different methods of gathering data for their
indices, and several different methods for searching their
indices.
2. インデックスサーバの開発を促進してください。 インデックスサーバはそれらのインデックスリストのための集会データ、およびそれらのインデックスリストを捜すためのいくつかの異なったメソッドのいくつかの異なったメソッドを使用するべきです。
3. Support a central management for the X.500 system. To get the
best advantage of the effort already invested in the X.500
directory system it is essential to provide the relatively small
amount of central management necessary to keep the system
functioning.
3. X.500システムのための主要な管理をサポートしてください。 取り組みの既にX.500ディレクトリシステムに投資された中で最も良い利点を得るために、システムを機能させ続けるのに必要な主要な管理の比較的少な量を供給するのは不可欠です。
4. Support the development of security certificate storage and
retrieval from the white pages service. The most practical
approach is to initially focus on getting this supported by the
existing X.500 directory infrastructure. It should also include
design and development of the storage and retrieval of security
certificates in other white pages services, such as Whois++.
4. ホワイトページサービスからセキュリティ証明書ストレージと検索の開発をサポートしてください。 最も実用的なアプローチは初めは既存のX.500ディレクトリインフラストラクチャでこれをサポートさせるのは焦点を合わせることです。 また、それはストレージのデザインと開発と他のホワイトページサービスにおける、セキュリティ証明書の検索を含むべきです、Whois++などのように。
Postel & Anderson [Page 28] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[28ページ]RFC1588ホワイトページは1994年2月に報告します。
8. REFERENCES
8. 参照
[1] Sollins, K., "Plan for Internet Directory Services", RFC 1107,
M.I.T. Laboratory for Computer Science, July 1989.
Sollins(K.)が「インターネットディレクトリサービスのために計画している」[1]、RFC1107、マサチューセッツ工科大学コンピュータ科学研究所、1989年7月。
[2] Hardcastle-Kille, S., "Replication Requirements to provide an
Internet Directory using X.500, RFC 1275, University College
London, November 1991.
[2]Hardcastle-Kille、S.、「1991年11月にX.500、RFC1275、ユニバーシティ・カレッジロンドンを使用することでインターネットディレクトリを提供する模写Requirements。」
[3] Weider, C., and J. Reynolds, "Executive Introduction to
Directory Services Using the X.500 Protocol", FYI 13, RFC 1308,
ANS, USC/Information Sciences Institute, March 1992.
[3] ワイダー、C.、およびJ.レイノルズ、「ディレクトリサービスへのX.500プロトコルを使用する幹部社員序論」、FYI13、RFC1308、ANS(科学が1992年3月に設けるUSC/情報)。
[4] Weider, C., Reynolds, J., and S. Heker, "Technical Overview of
Directory Services Using the X.500 Protocol", FYI 14, RFC 1309,
ANS, USC/Information Sciences Institute,, JvNC, March 1992.
[4] ワイダー、C.、レイノルズ、J.、およびS.Heker、FYI14、RFC1309、ANS、科学が設けるUSC/情報、JvNC、「ディレクトリサービスの技術的な概要はX.500プロトコルを使用し」て、1992を行進させてください。
[5] Hardcastle-Kille, S., Huizer, E., Cerf, V., Hobby, R., and S.
Kent, "A Strategic Plan for Deploying an Internet X.500
Directory Service", RFC 1430, ISODE Consortium, SURFnet bv,
Corporation for National Research Initiatives, University of
California, Davis, Bolt, Beranek, and Newman, February 1993.
[5]Hardcastle-Kille、S.、Huizer、E.、サーフ、V.、Hobby、R.、S.ケント、「インターネットX.500ディレクトリサービスを配布するための長期計画」、RFC1430、ISODE Consortium、SURFnet bv、National Research Initiativesのための社、カリフォルニア大学、デイヴィス、Bolt、Beranek、およびニューマン(1993年2月)。
[6] Jurg, A., "Introduction to White pages services based on X.500",
Work in Progress, October 1993.
[6] ジュルグ、A.、「ホワイトへの紹介はX.500に基づくサービスを呼び出す」Progress、1993年10月のWork。
[7] The North American Directory Forum, "NADF Standing Documents: A
Brief Overview", RFC 1417, The North American Directory Forum",
NADF, February 1993.
[7] 北米のディレクトリフォーラム、「NADF地位は以下を記録します」。 「簡潔な概要」、RFC1417、北米のディレクトリフォーラム、」、NADF、2月1993日
[8] NADF, An X.500 Naming Scheme for National DIT Subtrees and its
Application for c=CA and c=US", Standing Document 5 (SD-5).
「[8] NADF、National DIT SubtreesのためのAn X.500 Naming Scheme、およびcのためのそのApplicationはカリフォルニアと等しいです、そして、cは米国と等しいです」、Standing Document5(サウスダコタ-5)。
[9] Garcia-Luna, J., Knopper, M., Lang, R., Schoffstall, M.,
Schraeder, W., Weider, C., Yeong, W, Anderson, C., (ed.), and J.
Postel (ed.), "Research in Directory Services: Fielding
Operational X.500 (FOX)", Fox Project Final Report, January
1992.
[9] ガルシア-ルーナ、J.、Knopper(M.、ラング、R.、Schoffstall、M.、Schraeder、W.、ワイダー、C.、Yeong、W、アンダーソン、C.、編、およびJ.ポステルの編)は「ディレクトリサービスで以下について研究します」。 「フィールディングの操作上のX.500(キツネ)」、フォックスプロジェクト最終報告書、1992年1月。
Postel & Anderson [Page 29] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[29ページ]RFC1588ホワイトページは1994年2月に報告します。
9. GLOSSARY
9. 用語集
API - Application Program Interface
COTS - commercial off the shelf
CSO - a phonebook service developed by University of Illinois
DAP - Direct Access Protocol
DIT - Directory Information Tree
DNS - Domain Name System
DUI - Directory User Interface
DUA - Directory User Agent
DSA - Directory Service Agent
FOX - Fielding Operational X.500 project
FRICC - Federal Research Internet Coordinating Committee
IETF - Internet Engineering Task Force
ISODE - ISO Development Environment
LDAP - Lightweight Direct Access Protocol
NADF - North American Directory Forum
PEM - Privacy Enhanced Mail
PSI - Performance Systems International
SQL - Structured Query Language
QUIPU - an X.500 DSA which is a component of the ISODE package
UFN - User Friendly Name
URI - Uniform Resource Identifier
URL - Uniform Resource Locator
WAIS - Wide Area Information Server
WPS - White Pages Service
WWW - World Wide Web
API--Operational Xをさばいて、アプリケーションProgram Interface COTS--商業すぐ入手できるCSO--phonebookサービスはイリノイDAP大学--ダイレクトAccessプロトコルDIT--ディレクトリ情報Tree DNS--ドメインネームシステムDUI--ディレクトリUser Interface DUA--ディレクトリUserエージェントDSA--ディレクトリサービスエージェントFOXで展開しました; 500はFRICCを映し出します--連邦政府のResearchインターネットCoordinating Committee IETF--インターネット・エンジニアリング・タスク・フォースISODE--ISO Development Environment LDAP--ライト級Direct AccessプロトコルNADF--北米のディレクトリForum PEM--プライバシーEnhancedメールPSI--パフォーマンスのSystemsの国際SQL--構造化問合せ言語QUIPU--X; 500 ISODEパッケージUFNの部品であるDSA--ユーザFriendly Name URI--Uniform Resource Identifier URL--Uniform Resource Locator WAIS--広いArea情報Server WPS--白いページService WWW--WWW
Postel & Anderson [Page 30] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[30ページ]RFC1588ホワイトページは1994年2月に報告します。
9. ACKNOWLEDGMENTS
9. 承認
This report is assembled from the words of the following participants in the email discussion and the meeting. The authors are responsible for selecting and combining the material. Credit for all the good ideas goes to the participants. Any bad ideas are the responsibility of the authors.
このレポートはメール議論とミーティングの以下の関係者の単語から組み立てられます。 作者は材料を選択して、合成するのに責任があります。 すべての名案のためのクレジットは関係者のものになります。 どんな悪い考えも作者の責任です。
Allan Cargille University of Wisconsin
Steve Crocker TIS
Peter Deutsch BUNYIP
Peter Ford LANL
Jim Galvin TIS
Joan Gargano UC Davis
Arlene Getchell ES.NET
Rick Huber INTERNIC - AT&T
Christian Huitema INRIA
Erik Huizer SURFNET
Tim Howes University of Michigan
Steve Kent BBN
Steve Kille ISODE Consortium
Mark Kosters INTERNIC - Network Solutions
Paul Mockapetris ARPA
Paul-Andre Pays INRIA
Dave Piscitello BELLCORE
Marshall Rose Dover Beach Consulting
Sri Sataluri INTERNIC - AT&T
Mike Schwartz University of Colorado
David Staudt NSF
Einar Stefferud NMA
Chris Weider MERIT
Scott Williamson INTERNIC - Network Solutions
Russ Wright LBL
Peter Yee NASA
アランCargilleウィスコンシン大学スティーブ医者TISピータードイツ語詐欺師ピーターフォードLANLジムガルビンTISジョーンガルガノUCデイヴィスアーリンゲッチェルES; ネットのリックヒューバーINTERNIC--クリスチャンのAT&TのBBNスティーブKille ISODE共同体マークHuitema INRIAエリックHuizer SURFNETティムハウズミシガン大学スティーブ・ケントKosters INTERNIC--ARPAポール-アンドレがINRIAデーヴPiscitello Bellcoreマーシャルバラドーヴァービーチコンサルティング様のSataluri INTERNICを支払うネットワークソリューションポールMockapetris--コロラドデヴィッドシュタウトNSF Einar Stefferud NMAクリスワイダー長所スコット・ウイリアムソンINTERNICのAT&Tマイクシュワルツ大学--ネットワークソリューションラス職人LBLピーターイーNASA
10. SECURITY CONSIDERATIONS
10. セキュリティ問題
While there are comments in this memo about privacy and security, there is no serious analysis of security considerations for a white pages or directory service in this memo.
プライバシーとセキュリティに関するこのメモにはコメントがありますが、このメモにおける、ホワイトページかディレクトリサービスのためのセキュリティ問題のどんな重大な分析もありません。
Postel & Anderson [Page 31] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[31ページ]RFC1588ホワイトページは1994年2月に報告します。
11. AUTHORS' ADDRESSES
11. 作者のアドレス
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: 310-822-1511 Fax: 310-823-6714 EMail: Postel@ISI.EDU
以下に電話をしてください。 310-822-1511 Fax: 310-823-6714 メールしてください: Postel@ISI.EDU
Celeste Anderson USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
空色アンダーソンUSC/情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: 310-822-1511 Fax: 310-823-6714 EMail: Celeste@ISI.EDU
以下に電話をしてください。 310-822-1511 Fax: 310-823-6714 メールしてください: Celeste@ISI.EDU
Postel & Anderson [Page 32] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[32ページ]RFC1588ホワイトページは1994年2月に報告します。
APPENDIX 1
付録1
The following White Pages Functionality List was developed by Chris Weider and amended by participants in the current discussion of an Internet white pages service.
以下のホワイトページFunctionality Listは現在のインターネットホワイトページサービスの議論でクリス・ワイダーによって開発されて、関係者によって修正されました。
Functionality list for a White Pages / Directory services
ホワイトページ/Directory servicesのための機能性リスト
Serving information on People only
Peopleだけの情報に役立ちます。
1.1 Protocol Requirements
1.1 プロトコル要件
a) Distributability
b) Security
c) Searchability and easy navigation
d) Reliability (in particular, replication)
e) Ability to serve the information desired (in particular,
multi-media information)
f) Obvious benefits to encourage installation
g) Protocol support for maintenance of data and 'knowledge'
h) Ability to support machine use of the data
i) Must be based on Open Standards and respond rapidly to correct
deficiencies
j) Serve new types of information (not initially planned) only
only upon request
k) Allow different operation modes
a) Distributability b) セキュリティc) Searchabilityと簡単なナビゲーションd) 信頼性(特に模写)のe) (特にマルチメディア情報)必要なf)に情報に役立つ能力 インストールg)を奨励する明白な利益 データのメインテナンスのプロトコルサポートと'知識'h) データi)のマシン使用をサポートする能力 オープンStandardsに基づかなければならなくて、急速に応じて、欠乏j)を修正してください。 要求k)だけでの新しいタイプの情報(初めは、計画されていない)に役立ってください。 異なったオペレーションモードを許容してください。
1.2 Implementation Requirements
1.2 実装要件
a) Searchability and easy navigation
b) An obvious and fairly painless upgrade path for organizations
c) Obvious benefits to encourage installation
d) Ubiquitous clients
e) Clients that can do exhaustive search and/or cache useful
information and use heuristics to narrow the search space in
case of ill-formed queries
f) Ability to support machine use of the data
g) Stable APIs
a) Searchabilityと簡単なナビゲーションb) 明白で組織c)におけるかなり無痛のアップグレード経路 インストールd)を奨励する明白な利益 遍在しているクライアントe) 不適格な質問f)の場合に検索スペースを狭くするのに徹底的な検索をする、役に立つ情報をキャッシュして、そして/または、発見的教授法を使用できるクライアント データg)のマシン使用をサポートする能力 安定したAPI
1.3 Sociological Requirements
1.3 社会学の要件
a) Shallow learning curve for novice users (both client and
server)
b) Public domain servers and clients to encourage experimentation
c) Easy techniques for maintaining data, to encourage users to
keep their data up-to-date
d) (particularly for organizations) The ability to hide an
organization's internal structure while making the data public.
a) 初心者ユーザ(クライアントとサーバの両方)b)のための浅いラーニングカーブ 実験c)を奨励する公共の場サーバとクライアント ユーザが、彼らのデータが最新のd)であると保つよう奨励するためにデータを保守するための簡単なテクニック (特に組織のための) データを公共にしている間に組織の内部の構造を隠す能力。
Postel & Anderson [Page 33] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[33ページ]RFC1588ホワイトページは1994年2月に報告します。
e) Widely recognized authorities to guarantee unique naming during
registrations (This is specifically X.500 centric)
f) The ability to support the privacy / legal requirements of all
participants while still being able to achieve good coverage.
g) Supportable infrastructure (Perhaps an identification of what
infrastructure support requires and how that will be
maintained)
e) 登録証明書(これは明確にX.500中心である)f)の間にユニークな命名を保証する広く認識された当局 まだ良い適用範囲g)を達成できる間にすべての関係者のプライバシー/法的必要条件をサポートする能力 我慢できるインフラストラクチャ(恐らくインフラ支援が何を必要とするか、そして、それがどのように維持されるかに関する識別)
Although the original focus of this discussion was on White Pages, many participants believe that a Yellow Pages service should be built into a White Pages scheme.
この議論の元の焦点がホワイトPagesにありましたが、多くの関係者が、ホワイトページ体系がイエローページサービスに組み込まれるべきであると信じています。
Functionality List for Yellow Pages service
イエローページサービスのための機能性List
Yellow pages services, with data primarily on people
主として人々に関するデータがある職業別広告欄サービス
2.1 Protocol Requirements
2.1 プロトコル要件
a) all listed in 1.1
b) Very good searching, perhaps with semantic support OR
b2) Protocol support for easy selection of proper keywords to
allow searching
c) Ways to easily update and maintain the information required by
the Yellow Pages services
d) Ability to set up specific servers for specific applications or
a family of applications while still working with the WP
information bases
a) すべてが1.1でb)を記載しました。 恐らく意味サポートOR b2との非常に良い探す、) サポートについて議定書の中で述べて、適切なキーワードの簡単な品揃えでc)を捜してください。 容易に情報をアップデートして、保守する方法がイエローページサービスd)で必要です。 特定のアプリケーションかアプリケーションのファミリーのためにWP情報ベースでまだ働いている間に特定のサーバをセットアップする能力
2.2 Implementation Requirements
2.2 実装要件
a) All listed in 1.2
b) Server or client support for relevance feedback
a) すべてが1.2でb)を記載しました。 関連フィードバックのサーバかクライアントサポート
2.3 Sociological Requirements
2.3 社会学の要件
a) all listed in 1.3
a) 1.3で記載されたすべて
Advanced directory services for resource location (not just people data)
リソース位置への高度なディレクトリサービス(人々データであるだけではない)
3.1 Protocol Requirements
3.1 プロトコル要件
a) All listed in 2.1
b) Ability to track very rapidly changing data
c) Extremely good and rapid search techniques
a) すべてが2.1でb)を記載しました。 非常に急速にデータc)を変えながら追跡する能力 非常に良くて急速な検索技術
Postel & Anderson [Page 34] RFC 1588 White Pages Report February 1994
ポステルとアンダーソン[34ページ]RFC1588ホワイトページは1994年2月に報告します。
3.2 Implementation Requirements
3.2 実装要件
a) All listed in 2.2
b) Ability to integrate well with retrieval systems
c) Speed, Speed, Speed
a) すべてが2.2でb)を記載しました。 情報検索システムc)とよく統合する能力 速度、速度は疾走します。
3.3 Sociological Requirements
3.3 社会学の要件
a) All listed in 1.3
b) Protocol support for 'explain' functions: 'Why didn't this
query work?'
a) すべてが1.3でb)を記載しました。 '説明してください'のプロトコルサポートは機能します: 'この質問はなぜ働いていませんでしたか?'
Postel & Anderson [Page 35]
ポステルとアンダーソン[35ページ]
一覧
スポンサーリンク
