RFC1309 日本語訳
1309 Technical Overview of Directory Services Using the X.500Protocol. C. Weider, J. Reynolds, S. Heker. March 1992. (Format: TXT=35694 bytes) (Also FYI0014) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Weider
Request for Comments: 1309 ANS
FYI: 14 J. Reynolds
ISI
S. Heker
JvNC
March 1992
コメントを求めるワーキンググループC.ワイダーの要求をネットワークでつないでください: 1309ANS FYI: 14 1992年のJ.レイノルズのISI S.Heker JvNC行進
Technical Overview of Directory Services
Using the X.500 Protocol
X.500プロトコルを使用するディレクトリサービスの技術的な概要
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.
このドキュメントは技術に詳しくない人々のX.500規格の概要です。 それは、他のいくつかのディレクトリサービスが現在使用中の状態でインターネットでX.500に基づくディレクトリサービスを、比較して、対照します。 この論文は、また、規格の状態について説明して、X.500実装に関する詳細と技術資料の参照を提供します。
A primary purpose of this paper is to illustrate the vast functionality of the X.500 protocol and to show how it can be used to provide a global directory for human use, and can support other applications which would benefit from directory services, such as main programs.
この紙のプライマリ目的は、X.500プロトコルの広大な機能性を例証して、それがどう人間が使うためにグローバルなディレクトリを提供するのに使用できて、ディレクトリサービスの利益を得る他のアプリケーションをサポートすることができるかを示していることです、主プログラムなどのように。
This FYI RFC is a product of the Directory Information Services (pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the Internet Engineering Task Force (IETF).
このFYI RFCはディレクトリ情報Services(パイロット)インフラストラクチャ作業部会(DISI)の製品です。 インターネット・エンジニアリング・タスク・フォース(IETF)のUser ServicesとOSI Integration Areasの協力。
1. INTRODUCTION
1. 序論
As the pace of industry, science, and technological development quickened over the past century, it became increasingly probable that someone in a geographically distant location would be trying to solve the same problems you were trying to solve, or that someone in a geographically distant location would have some vital information which impinged on your research or business. The stupendous growth in the telecommunications industry, from telegraphs to telephones to computer networks, has alleviated the problem of being able to
産業、科学、および技術開発のペースが過去の世紀に速くなったとき、地理的に遠方の位置のだれかがあなたが解決しようとしていた同じ問題を解決しようとしているだろうか、または地理的に遠方の位置のだれかにはあなたの研究かビジネスに衝突した何らかの極めて重要な情報があるだろうというのがますますありえそうになりました。 電気通信事業でのすばらしい成長、コンピュータネットワークへの電話に電報を打って、できるという問題を軽減しました。
DISI Working Group [Page 1] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[1ページ]RFC1309の技術的な概要
communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH THEM.
別の人、PROVIDED THAT YOU KNOW HOW TO REACH THEMとコミュニケートしてください。
Thus, along with the expansion of the telecommunications infrastructure came the development of Directory Services. In this paper, we will discuss various models of directory services, the limitations of current models, and some solutions provided by the X.500 standard to these limitations.
その結果、テレコミュニケーションの拡張と共に、インフラストラクチャは来ました。ディレクトリサービスの開発。 この紙では、私たちはディレクトリサービスの様々なモデルについて議論するつもりです、と電流の制限がモデル化して、何らかの解決法はX.500規格でこれらの制限に前提としました。
2 MODELS OF DIRECTORY SERVICES
ディレクトリサービスの2つのモデル
2.1 The telephone company's directory services.
2.1 電話会社のディレクトリサービス。
A model many people think of when they hear the words "Directory Services" is the directory service provided by the local telephone company. A local telephone company keeps an on-line list of the names of people with phone service, along with their phone numbers and their address. This information is available by calling up Directory Assistance, giving the name and address of the party whose number you are seeking, and waiting for the operator to search his database. It is additionally available by looking in a phone book published yearly on paper.
彼らが「ディレクトリサービス」という言葉を聞くとき、多くの人々が思うモデルは地方の電話会社によって提供されたディレクトリサービスです。 地方の電話会社は電話サービスの人名のオンラインリストを保ちます、それらの電話番号とそれらのアドレスと共に。 この情報はディレクトリAssistanceを呼び出すことによって、利用可能です、彼のデータベースを捜すためにあなたが番号を求めているパーティーと、オペレータを待つ名前とアドレスを与えて。 さらに、中を見ている利用可能なa電話帳が毎年紙上で発行されたということです。
The phone companies are able to offer this invaluable service because they administer the pool of phone numbers. However, this service has some limitations. For instance, you can find someone's number only if you know their name and the city or location in which they live. If two or more people have listings for the same name in the same locality, there is no additional information which with to select the correct number. In addition, the printed phone book can have information which is as much as a year out of date, and the phone company's internal directory can be as much as two weeks out of date. A third problem is that one actually has to call Directory assistance in a given area code to get information for that area; one cannot call a single number consistently.
電話番号のプールを管理するので、電話会社はこの非常に貴重なサービスを提供できます。 しかしながら、このサービスには、いくつかの制限があります。 例えば、彼らが住んでいるそれらの名前と都市か位置を知っている場合にだけ、あなたはだれかの番号を見つけることができます。 2人以上の人が同じ場所に同じ名前のためのリストを持っているなら、追加情報が全くない、どれ、適度の数を選択するために。 さらに、印刷された電話帳は最大1年時代遅れの情報を持つことができます、そして、最大2週間が時代遅れであったなら、電話会社の内部のディレクトリは持つことができます。 3番目の問題は人が、その領域のための情報を得るために実際に与えられた市外局番におけるディレクトリ支援と呼ばなければならないということです。 人は一貫して1つの数に電話をすることができません。
For businesses which advertise in the Yellow Pages, there is some additional information stored for each business; unfortunately, that information is unavailable through Directory Assistance and must be gleaned from the phone book.
イエローページに広告を出すビジネスのために、各ビジネスのために保存された何らかの追加情報があります。 残念ながら、その情報をディレクトリAssistanceを通して入手できなく、電話帳から収集しなければなりません。
2.2 Some currently available directory services on the Internet.
2.2 インターネットのいくつかの現在利用可能なディレクトリサービス。
As the Internet is comprised of a vast conglomeration of different people, computers, and computer networks, with none of the hierarchy imposed by the phone system on the area codes and exchange prefixes, any directory service must be able to deal with the fact that the Internet is not structured; for example, the hosts foo.com and
インターネットが異なった人々、コンピュータ、およびコンピュータネットワークの広大な凝集から成る階層構造のいずれも市外局番と交換接頭語の電話システムによって課されていなく、どんなディレクトリサービスもインターネットが構造化されないという事実に対処できなければなりません。 そして例えば、ホストfoo.com。
DISI Working Group [Page 2] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[2ページ]RFC1309の技術的な概要
v2.foo.com may be on opposite sides of the world, the .edu domain maps onto an enormous number of organizations, etc. Let's look at a few of the services currently available on the Internet for directory type services.
v2.foo.comが世界の反対側、莫大な数の組織への.eduドメイン地図などにあるかもしれません。 ディレクトリタイプサービスのためにインターネットで現在利用可能であるとしてサービスのいくつかを見ましょう。
2.2.1 The finger protocol.
2.2.1 指のプロトコル。
The finger protocol, which has been implemented for UNIX systems and a small number of other machines, allows one to "finger" a specific person or username to a host running the protocol. This is invoked by typing, for example, "finger clw@mazatzal.merit.edu". A certain set of information is returned, as this example from a UNIX system finger operation shows, although the output format is not specified by the protocol:
指のプロトコル(他のUNIXシステムと少ない数のマシンのために実装された)は、プロトコルを実行するホストに特定の人かユーザ名を「弄る」ために1つを許容します。 例えば、「 clw@mazatzal.merit.edu を弄ってください」とタイプすることによって、これは呼び出されます。 ある情報を返します、UNIXシステム指の手術からのこの例が目立っているように、出力形式はプロトコルによって指定されませんが:
Login name: clw In real life: Chris Weider
Directory: /usr/clw Shell: /bin/csh
On since Jul 25 09:43:42 4 hours 52 minutes Idle Time
Plan:
Home: 971-5581
ログイン名: clw In現実: クリスワイダーDirectory: /usr/clwシェル: 7月の25 09:43:42の4時間52分のIdle Time Plan以来の/bin/csh On: ホーム: 971-5581
where the first three lines of information are taken from the UNIX operating systems information and the line(s) of information following the "Plan:" line are taken from a file named .plan which each user modifies. Limitations of the fingerd program include: a) One must already know which host to finger to find a specific person, b) since primarily UNIX machines run fingerd, people who reside on other types of operating systems are not locateable by this method, c) fingerd is often disabled on UNIX systems for security purposes, d) if one wishes to be found on more than one system, one must make sure that all the .plan files are consistent, and e) there is no way to search the .plan files on a given host to (for example) find everyone on mazatzal.merit.edu who works on X.500. Thus, fingerd has a limited usefulness as a piece of the Internet Directory.
情報の最初の3つの系列がUnixオペレーティングシステム情報から抜粋されて、情報の系列が続く、「計画してください」 系列は各ユーザが変更する.planというファイルから抜粋されます。 fingerdプログラムの限界は: a) 他のタイプのオペレーティングシステムに住んでいる人々がこのメソッドで「場所を見つけ-可能」でない、Unixマシンが主としてfingerdを実行するので、特定の人、b)を見つけるためにどのホストを弄ったらよいかを既に知らなければならなくて、c)fingerdはセキュリティ目的のUNIXシステムの上でしばしば無効にされて、d)は1台以上のシステム、1で見つけられるという1つの願望であるなら確実にそれをすべてにしなければなりません; プランファイルは一貫しています、そして、そこのe)は(例えば) X.500に勤めるmazatzal.merit.eduの上の皆を見つけるために与えられたホストの.planファイルを捜す方法ではありません。 したがって、fingerdには、インターネットディレクトリの1つの断片として限られた有用性があります。
2.2.2 whois
2.2.2 whois
The whois utility, which is available on a wide of variety of systems, works by querying a centralized database maintained at the DDN NIC, which was for many years located at SRI International in Menlo Park, California, and is now located at GSI. This database contains a large amount of information which primarily deals with people and equipment which is used to build the Internet. SRI (and now GSI) has been able to collect the information in the WHOIS database as part of its role as the Network Information Center for the TCP/IP portion of the Internet.
whoisユーティリティ(システムのバラエティーで広いaで利用可能である)は、メンローパーク(カリフォルニア)にSRIインターナショナルに位置する何年間もあって、現在GSIに位置しているDDN NICで維持された集中データベースについて質問することによって、動作します。 このデータベースは主として人々とインターネットを造るのに使用される設備に対処する多量の情報を含んでいます。 SRI(そして、現在のGSI)はインターネットのTCP/IP部分へのNetworkインフォメーション・センターとしての役割の一部としてWHOISデータベースの情報を集めることができました。
The whois utility is ubiquitous, and has a very simple interface. A
whoisユーティリティは、遍在していて、非常に簡単なインタフェースを持っています。 A
DISI Working Group [Page 3] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[3ページ]RFC1309の技術的な概要
typical whois query look like:
典型的なwhoisは以下のように外観について質問します。
whois Reynolds
whoisレイノルズ
and returns information like:
そして、以下のようなリターン情報
Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL
(702) 426-2604 (DSN) 830-2604
Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL
(908) 532-3817 (DSN) 992-3817
Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL
(DSN) 723-3358
Reynolds, Joseph T. (JTR10) JREYNOLDS@PAXRV-NES.NAVY.MIL
011-63-47-885-3194 (DSN) 885-3194
Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU (213) 822-1511
Reynolds, Keith (KR35) keithr@SCO.CO (408) 425-7222
Reynolds, Kenneth (KR94) (502) 454-2950
Reynolds, Kevin A. (KR39) REYNOLDS@DUGWAY-EMH1.ARMY.MIL
(801) 831-5441 (DSN) 789-5441
Reynolds, Lee B. (LBR9) reynolds@TECHNET.NM.ORG (505) 345-6555
レイノルズ、ジョン・F.(JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL (702)426-2604(DSN)830-2604レイノルズ、ジョン・J.(JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL (908)532-3817(DSN)992-3817レイノルズ、ジョン・W.(JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL (DSN)723-3358レイノルズ(ジョゼフT.(JTR10) JREYNOLDS@PAXRV-NES.NAVY ); ミル011-63-47-885-3194(DSN)885-3194レイノルズ、ジョイス・K.(JKR1) JKREY@ISI.EDU (213)822-1511レイノルズ、キース(KR35)・ keithr@SCO.CO (408)425-7222レイノルズ、ケネス(KR94)・(502)454-2950レイノルズ、ケビン・A.(KR39) REYNOLDS@DUGWAY-EMH1.ARMY.MIL (801)831-5441(DSN)789-5441レイノルズ、リーB.(LBR9) reynolds@TECHNET.NM.ORG (505)345-6555
a further lookup on Joyce Reynolds with this command line:
このコマンドラインをもっているジョイス・レイノルズの上のさらなるルックアップ:
whois JKR1
whois JKR1
returns:
リターン:
Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU
University of Southern California
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
(310) 822-1511
レイノルズ、ジョイスK.(JKR1) JKREY@ISI.EDU 南カリフォルニア情報Sciences Institute大学4676海軍本部Wayマリナデルレイ、カリフォルニア90292(310)822-1511
Record last updated on 07-Jan-91.
1991年1月7日にアップデートしていた状態で、記録してください。
The whois database also contains information about Domain Name System (DNS) and has some information about hosts, major regional networks, and large parts of the MILNET system.
whoisデータベースは、また、ドメインネームシステム(DNS)の情報を含んでいて、ホストの何らかの情報、主要な地域ネットワーク、およびMILNETシステムのかなりの部分を持っています。
The WHOIS database is large enough and comprehensive enough to exhibit many of the flaws of a large centralized database: a) As the database is maintained on one machine, a processor bottleneck forces slow response during times of peak querying activity, even if many of these queries are unrelated, b) as the database is maintained on one machine, a storage bottleneck forces the database administrators to severely limit the amount of information which can be kept on each entry in the database, c) all changes to the database have to be
WHOISデータベースは、大きい集中データベースの欠点の多くを示すほど十分大きくて、包括的です: a) データベースが1台のマシンの上で維持されるとき、プロセッサボトルネックは活動について質問するピークの倍の間、遅い応答を強制します、これらの質問の多くが関係なくてもデータベースとしてのb)は1台のマシンの上で主張されて、データベース管理者はストレージボトルネックによって、厳しく、やむを得ず、各データベースへの登録に保つことができる情報量を制限します、c)
DISI Working Group [Page 4] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[4ページ]RFC1309の技術的な概要
mailed to a "hostmaster" and then physically reentered into the database, increasing both the turnaround time and the likelihood for a mistake in transcription.
転写における誤りによってターンアラウンドタイムと見込みの両方を増強して、"hostmaster"に郵送されて、次に、物理的にデータベースに再入されています。
2.2.3 The Domain Name System
2.2.3 ドメインネームシステム
The Domain Name System is used in the Internet to keep track of host to IP address mapping. The basic mechanism is that each domain, such as merit.edu or k-12.edu, is registered with the NIC, and at time of registration, a primary and (perhaps) some secondary nameservers are identified for that domain. Each of these nameservers must provide host name to IP address mapping for each host in the domain. Thus, the nameservice is supplied in a distributed fashion. It is also possible to split a domain into subdomains, with a different nameserver for each subdomain.
ドメインネームシステムは、IPアドレス・マッピングにホストの動向をおさえるのにインターネットで使用されます。 基本的機構はmerit.eduかk-12.eduなどの各ドメインがNICに登録されて、登録の時にプライマリネームサーバと(恐らく)いくつかのセカンダリネームサーバがそのドメインに特定されるということです。 それぞれのこれらのネームサーバはそのドメインの各ホストのためにIPアドレス・マッピングにホスト名を提供しなければなりません。 したがって、分配されたファッションでnameserviceを供給します。 また、各サブドメインのために異なったネームサーバでドメインをサブドメインに分けるのも可能です。
Although in many cases one uses the DNS without being aware of it, because humans prefer to remember names and not IP addresses, it is possible to interactively query the DNS with the nslookup utility. A sample session using the nslookup utility:
それを意識していなくて、1つは多くの場合DNSを使用しますが、人間が、IPアドレスではなく、名前を覚えているのを好むので、nslookupユーティリティでインタラクティブにDNSについて質問するのは可能です。 nslookupユーティリティを使用するサンプルセッション:
home.merit.edu(1): nslookup
Default Server: merit.edu
Address: 35.42.1.42
home.merit.edu(1): nslookup Default Server: merit.edu Address: 35.42.1.42
> scanf.merit.edu
Server: merit.edu
Address: 35.42.1.42
>scanf.merit.edu Server: merit.edu Address: 35.42.1.42
Name: scanf.merit.edu
Address: 35.42.1.92
以下を命名してください。 scanf.merit.edu Address: 35.42.1.92
> 35.42.1.92
Server: merit.edu
Address: 35.42.1.42
>35.42.1.92サーバ: merit.edu Address: 35.42.1.42
Name: [35.42.1.92]
Address: 35.42.1.92
以下を命名してください。 [35.42 .1 .92] アドレス: 35.42.1.92
Thus, we can explicitly determine the address associated with a given host. Reverse name mapping is also possible with the DNS, as in this example:
したがって、私たちは明らかに与えられたホストに関連しているアドレスを決定できます。 また、逆の名前マッピングもこの例のようにDNSで可能です:
DISI Working Group [Page 5] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[5ページ]RFC1309の技術的な概要
home.merit.edu(2): traceroute ans.net
traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets
1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms
2 enss (35.1.1.1) 6 ms 6 ms 6 ms
.................
9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms
10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms
home.merit.edu(2): ans.netへのトレースルートans.netトレースルート、(147.225に、.2、)30が飛び越す.1は最大限にします、40バイトのパケット1t3peer、(35.1.1.33)11ms5ms5ms2enss、(35.1 .1 .1) 6 ms6ms6ms… 9 192.77 .154、.1、(192.77.154.1)51ms43ms49ms10nis.ans.net、(147.225.1.2)53ms53ms46ms
At each hop of the traceroute, the program attempts to do a reverse lookup through the DNS and displays the results when successful.
トレースルートの各ホップでは、プログラムは、うまくいくとき、DNSとディスプレイによる逆のルックアップに結果をするのを試みます。
Although the DNS has served superlatively for the purpose it was developed, i.e. to allow maintenance of the namespace in a distributed fashion, and to provide very rapid lookups in the namespace, there are, of course, some limitations. Although there has been some discussion of including other types of information in the DNS, to find a given person at this time, assuming you know where she works, you have to use a combination of the DNS and finger to even make a stab at finding her. Also, the DNS has very limited search capabilities right now. The lack of search capabilities alone shows that we cannot provide a rich Directory Service through the DNS.
DNSは目的のためにこの上なく役立ちましたが、それは開発されました、すなわち、分配されたファッションにおける、名前空間のメインテナンスを許容して、非常に急速なルックアップを名前空間に提供するために、いくつかの制限がもちろんあります。 他のタイプの情報を含む何らかの議論がDNSにありましたが、あなたが、彼女がどこで働いているかを知っていると仮定して、このとき与えられた人を見つけるなら、あなたは、一刺しを彼女を見つけるようにするのさえDNSと指の組み合わせを使用しなければなりません。 また、DNSには、たった今の非常に限られた検索能力があります。 検索能力だけの不足は、私たちがDNSを通して豊かなディレクトリサービスを提供できないのを示します。
3: THE X.500 MODEL OF DIRECTORY SERVICE
3: ディレクトリサービスのX.500モデル
X.500 is a CCITT protocol which is designed to build a distributed, global directory. It offers the following features:
X.500は分配されて、グローバルなディレクトリを造るように設計されているCCITTプロトコルです。 それは以下の特徴を提供します:
* Decentralized Maintenance:
Each site running X.500 is responsible ONLY for its local part
of the Directory, so updates and maintenance can be done instantly.
* 分散メインテナンス: 各サイトの実行しているX.500はディレクトリの地方の部分だけに責任があるので、即座にアップデートとメインテナンスができます。
* Powerful Searching Capabilities:
X.500 provides powerful searching facilities that allow users to
construct arbitrarily complex queries.
* 強力な探す能力: X.500はユーザが任意に複雑な質問を構成できる強力な探す施設を提供します。
* Single Global Namespace:
Much like the DNS, X.500 provides a single homogeneous namespace
to users. The X.500 namespace is more flexible and expandable
than the DNS.
* ただ一つのグローバルな名前空間: DNSのように、X.500はただ一つの均質の名前空間をユーザに提供します。 X.500名前空間は、DNSよりフレキシブルであって、拡張可能です。
* Structured Information Framework:
X.500 defines the information framework used in the directory,
allowing local extensions.
* 構造化された情報フレームワーク: X.500は地方の拡大を許して、ディレクトリで使用される情報フレームワークを定義します。
DISI Working Group [Page 6] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[6ページ]RFC1309の技術的な概要
* Standards-Based Directory:
As X.500 can be used to build a standards-based directory,
applications which require directory information (e-mail,
automated resource locators, special-purpose directory tools)
can access a planet's worth of information in a uniform manner,
no matter where they are based or currently running.
* 規格ベースのディレクトリ: 規格ベースのディレクトリを造るのにX.500を使用できるように、ディレクトリ情報(メール、自動化されたリソースロケータ、専用ディレクトリツール)を必要とするアプリケーションは惑星の一定の方法による情報の価値、彼らが基づいている件または現在の稼働にアクセスできません。
3.1 Acronym City, or How X.500 Works
3.1 Acronym市、またはX.500はどう働いているか。
The '88 version of the X.500 standard talks about 3 models required to build the X.500 Directory Service: the Directory Model, the Information Model, and the Security Model. In this section, we will provide a brief overview of the Directory and Information Models sufficient to explain the vast functionality of X.500.
X.500規格の88年のバージョンはX.500ディレクトリサービスを組み込むのに必要であるおよそ3つのモデルについて話します: ディレクトリモデル、情報モデル、およびセキュリティはモデル化されます。 このセクションに、私たちはX.500の広大な機能性について説明できるくらいのディレクトリと情報Modelsの簡潔な概要を供給するつもりです。
3.1.1 The Information Model
3.1.1 情報モデル
To illustrate the Information Model, we will first show how information is held in the Directory, then we will show what types of information can be held in the Directory, and then we will see how the information is arranged so that we can retrieve the desired pieces from the Directory.
情報Modelを例証するために、私たちは最初に、どのように情報がディレクトリで保持されて、次に、私たちが、ディレクトリでどんなタイプの情報を保持できるかを示すつもりであり、次に、私たちがディレクトリから必要な断片を検索できるように情報がどう整っているかを見るかを示すつもりです。
3.1.1.1 Entries
3.1.1.1 エントリー
The primary construct holding information in the Directory is the "entry". Each Directory entry contains information about one object; for example, a person, a computer network, or an organization. Each entry is built from a collection of "attributes", each of which holds a single piece of information about the object. Some attributes which might be used to build an entry for a person would be "surname", "telephonenumber", "postaladdress", etc. Each attribute has an associated "attribute syntax", which describes the type of data that attribute contains, for example, photo data, a time code, or a string of letters and numbers. As an example, let's look at part of an entry for a person.
ディレクトリにおける情報を保持するプライマリ構造物は「エントリー」です。 それぞれのディレクトリエントリーは情報およそ1オブジェクトを含んでいます。 例えば、人、コンピュータネットワーク、または組織。 各エントリーは「属性」の収集から組み込まれます。それはそれぞれ1片のオブジェクトの情報を保持します。 人のためにエントリーを組み込むのに使用されるかもしれないいくつかの属性が「姓」、"telephonenumber"、"postaladdress"でしょうなど。 各属性に、関連「属性構文」があります。(それは、例えば一連の属性が含むデータのタイプか、フォトデータか、時間コードか、手紙と数について説明します)。 例として、人のためにエントリーの一部を見ましょう。
Entry for John Smith contains:
ジョン・スミスのためのエントリーは以下を含んでいます。
attribute ---> surName= Smith <--- attribute value
|---> telephoneNumber= 999-9999 <--- attribute value
|---> title= Janitor <--- attribute value
...
属性--->姓=のスミス<。--- 属性値|--->telephoneNumberは999-9999 <と等しいです。--- 属性値|--->タイトルは管理人<と等しいです。--- 値を結果と考えてください…
The attribute syntax for the surName attribute would be CaseIgnoreString, which would tell X.500 that surName could contain any string, and case would not matter; the attribute syntax for the telephoneNumber attribute would be TelephoneNumber, which would
surName属性のための属性構文はCaseIgnoreStringでしょう、そして、ケースは重要でないでしょう。(CaseIgnoreStringは、surNameがどんなストリングも含むことができたとX.500に言うでしょう)。 telephoneNumber属性のための属性構文はTelephoneNumberでしょう。(そのTelephoneNumberはそうするでしょう)。
DISI Working Group [Page 7] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[7ページ]RFC1309の技術的な概要
specify that telephoneNumber could contain a string composed of digits, dashes, parenthesis, and a plus sign. The attribute syntax for the title attribute would also be CaseIgnoreString. A good analogy in database terms for what we've seen so far might be to think of a Directory entry as a database record, an attribute as a field in that record, and an attribute syntax as a field type (decimal number, string) for a field in a record.
telephoneNumberがケタ、ダッシュ、挿入句、およびプラスサインで構成されたストリングを含むことができたと指定してください。 また、タイトル属性のための属性構文はCaseIgnoreStringでしょう。 私たちが今までのところ見たもののためのデータベース用語による良い類推はデータベース・レコード、その記録の分野としての属性、および分野としての属性構文が(10進数、ストリング)を記録の分野にタイプするときディレクトリエントリーを考えることであるかもしれません。
3.1.1.2 Object Classes
3.1.1.2 オブジェクトのクラス
At this point in our description of the information model, we have no way of knowing what type of object a given entry represents. X.500 uses the concept of an "object class" to specify that information, and an attribute named "objectClass" which each entry contains to specify to which object class(es) the entry belongs.
ここに、情報モデルの記述では、私たちは与えられたエントリーがどんなタイプのオブジェクトを表すかを知る方法を全く持っていません。 X.500はその情報を指定するのに「オブジェクトのクラス」の概念を使用します、そして、各エントリーがどのオブジェクトのクラス(es)にエントリーを指定するかために含む「objectClass」という属性は属します。
Each object class in X.500 has a definition which lists the set of mandatory attributes, which must be present, and a set of optional attributes, which may be present, in an entry of that class. An given object class A may be a subclass of another class B, in which case object class A inherits all the mandatory and optional attributes of B in addition to its own.
X.500のそれぞれのオブジェクトのクラスには、義務的な属性の存在しなければならないセットと1セットの存在するかもしれない任意の属性を記載する定義があります、そのクラスのエントリーで。 与えられたオブジェクトのクラスAがもう1人のクラスBのサブクラスであるかもしれない、その場合、オブジェクトのクラスAはそれ自身に加えたBのすべての義務的で任意の属性を引き継ぎます。
The object classes in X.500 are arranged in a hierarchical manner according to class inheritance; the following diagram shows a part of the object class hierarchy.
クラス継承に応じて、X.500のオブジェクトのクラスは階層的な方法でアレンジされます。 以下のダイヤグラムはオブジェクトクラス階層構造の一部を示しています。
DISI Working Group [Page 8] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[8ページ]RFC1309の技術的な概要
_____________
| | "top" has one mandatory
| top | attribute "objectClass",
|_____________| and nooptional attributes.
| | |
| | | every other object class is a
________________| | | subclass of "top"...
| | ...
______|________ _____|_______
| | | |"organization" inherits one
| country | | organization |mandatory attribute from
|_______________| |_______________|"top", "objectClass"; adds one
more mandatory attribute "O"
"country" inherits one (for organization), and has
mandatory attribute from "top", many optional attributes. Any
"objectClass", adds one more subclass of "organization"
mandatory attribute "c" (for would inherit all of the
country), and has two optional mandatory and optional
attributes, "description" and attributes from "organization"
"searchGuide". Any subclass of including the attribute which
"country" would inherit all of the "organization" inherited
mandatory and optional attributes from "top".
of the "country" class, including
the attribute which "country"
inherited from "top".
_____________ | | 「先端」で、1つは義務的になります。| トップ| 「objectClass」を結果と考えてください。|_____________| そして、nooptional属性。 | | | | | | 他のあらゆるオブジェクトのクラスがaです。________________| | | 「先端」のサブクラス… | | ... ______|________ _____|_______ | | | |「組織」は1つを引き継ぎます。| 国| | 組織|義務的な属性|_______________| |_______________|「先端」、「objectClass」。 もうひとつの義務的な属性「O」「国」が1つ(組織のための)を引き継ぐと言い足して、「先端」、多くの任意の属性からの義務的な属性を持っています。 いずれも「objectClass」と、「組織」義務的の、より多くのサブクラスが結果と考える人が言い足す、「c」、(国のすべてを引き継ぐだろう、)、「組織」"searchGuide"からの2つの任意の義務的で任意の属性、「記述」、および属性を持っています。 それの「国」が「組織」のすべてを引き継ぐ属性を含むどんなサブクラスも「先端」から義務的で任意の属性を引き継ぎました。属性を含む「国」のクラスについてどの「国」が「先端」から世襲されましたか?
Figure 1.
図1。
One major benefit of the object class concept is that it is in many cases very easy to create a new object class which is only a slight modification or extension of a previous class. For example, if I have already defined an object class for "person" which contains a person's name, phone number, address, and fax number, I can easily define an "Internet person" object class by defining "Internet person" as a subclass of "person", with the additional optional attribute of "e-mail address". Thus in my definition of the "Internet Person" object class, all my "person" type attributes are inherited from "person". There are other benefits which are beyond the scope of this paper.
オブジェクトクラス概念の1つの主要な利益は多くの場合、前のクラスのわずかな変更か拡大であるにすぎない新しいオブジェクトのクラスを創設するのが非常に簡単であるということです。 例えば、既に「人」のための人の名前、電話番号、アドレス、およびファックス番号を含むオブジェクトのクラスを定義したなら、私は「人」のサブクラスと「インターネットをよく使う人」を定義することによって、容易に「インターネットをよく使う人」オブジェクトのクラスを定義できます、「Eメールアドレス」の追加任意の属性で。 したがって、私の「インターネット人」オブジェクトのクラスの定義では、私のすべての「人」タイプ属性が「人」から引き継がれます。 この紙の範囲にある諸手当があります。
3.1.1.3 X.500's namespace.
3.1.1.3 X.500の名前空間。
X.500 hierarchically organizes the namespace in the Directory Information Base (DIB); recall that this hierarchical organization is called the Directory Information Tree (DIT). Each entry in the DIB occupies a certain location in the DIT. An entry which has no children is called a leaf entry, an entry which has children is called a non-leaf node. Each entry in the DIT contains one or more
X.500はディレクトリInformation基地(DIB)の中で階層的で名前空間を組織化します。 この階層的な組織がディレクトリ情報Tree(DIT)と呼ばれたと思い出してください。 DIBの各エントリーはDITで、ある位置を占領します。 子供が全くいないエントリーは葉のエントリーと呼ばれて、子供がいるエントリーは非葉のノードと呼ばれます。 DITの各エントリーは1つ以上を含んでいます。
DISI Working Group [Page 9] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[9ページ]RFC1309の技術的な概要
attributes which together comprise the Relative Distinguished Name (RDN) of that entry, there is a "root" entry (which has no attributes, a special case) which forms the base node of the DIT. The Distinguished Name of a specific entry is the sequence of RDNs of the entries on the path from the root entry to the entry in question. A diagram here will help to clarify this:
属性、どれは、一緒にそのエントリーのRelative Distinguished Name(RDN)を包括して、DITのベースノードを形成するa「根」エントリー(属性がない、特別なケースを持っている)がありますか? 特定のエントリーのDistinguished Nameは根のエントリーから問題のエントリーまでの経路のエントリーのRDNsの系列です。 ここのダイヤグラムは、これをはっきりさせるのを助けるでしょう:
Level of DIT Root RDN Distinguished Name
デイット根のRDN分類名のレベル
root * nothing { }
/ | \
country (other / | \
things at this / | \ c=us {c=us}
level) c=gb c=us c=ca
/ | \
/ | \
/ | \
organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit}
(other things / | \
at this level) / | \
/ | \
Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit,
cn=Chris Weider}
*を根づかせてください、無、/| \国、(もう一方/| \もの、この/| \c=私たちでは、cが私たちと等しい、レベル) c=gb cが私たちと等しい、c=ca/| \ / | \ / | \組織o=SRI o=長所o=12月oが長所と等しい、cが私たちと等しく、oが長所と等しい、(他のもの/| このレベルにおける\)/| \ / | \クリスワイダー第3レベルcn=cnはクリス・ワイダーと等しいです。cは私たちと等しく、oは長所と等しく、cnはクリス・ワイダーと等しいです。
Figure 2: Building a DN from RDNs (adapted from a
diagram in the X.500 (88) Blue Book)
図2: RDNsからDNを造ります。(X.500(88)青のBookでのダイヤグラムから適合する)です。
Each entry in this tree contains more attributes than have been shown
here, but in each case only one attribute for each entry has been
used for that entry's RDN. As noted above, any entry in the tree
could use more than one attribute to build its RDN. X.500 also allows
the use of alias names, so that the entry {c=us, o=Merit, cn=Chris
Weider} could be also found through an alias entry such as {c=us,
o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first
entry.
この木の各エントリーはここに示されたより多くの属性を含んでいますが、その都度各エントリーあたり1つの属性だけがそのエントリーのRDNに使用されました。 上で述べたように、木のどんなエントリーも、RDNを造るのに1つ以上の属性を使用するかもしれません。 cは私たちと等しいです、o=SRI、ou=FOX Project、cn=無人機1。また、X.500は別名の使用を許します、c=私たち、o=長所、エントリークリス・cn=ワイダーがまた、別名エントリーでそのようなものを設立することであることができるように初記入を示す。
3.1.2 The Directory Model
3.1.2 ディレクトリモデル
Now that we've seen what kinds of information can be kept in the Directory, we should look at how the Directory stores this information and how a Directory users accesses the information. There are two components of this model: a Directory User Agent (DUA), which accesses the Directory on behalf of a user, and the Directory System Agent, which can be viewed as holding a particular subset of the DIB, and can also provide an access point to the Directory for a DUA.
ディレクトリでどんな種類の情報を保つことができるかを見たので、私たちはディレクトリがどのようにこの情報を保存するか、そして、ディレクトリユーザがどのように情報にアクセスするか見るべきです。 このモデルの2つの部品があります: (そのエージェントは、ユーザを代表してディレクトリにアクセスします)。ディレクトリUserエージェント(DUA)とディレクトリSystemエージェント。(そのエージェントは、DIBの特定の部分集合を保持すると見なすことができて、また、DUAのためにアクセスポイントをディレクトリに提供できます)。
Now, the entire DIB is distributed through the world-wide collection of DSAs which form the Directory, and the DSAs employ two techniques
現在、全体のDIBはディレクトリを形成するDSAsの世界的な収集で分配されます、そして、DSAsは2つのテクニックを使います。
DISI Working Group [Page 10] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[10ページ]RFC1309の技術的な概要
to allow this distribution to be transparent to the user, called "chaining" and "referral". The details of these two techniques would take up another page, so it suffices to say that to each user, it appears that the entire global directory is on her desktop. (Of course, if the information requested is on the other side of the world, it may seem that the desktop directory is a bit slow for that request...)
「推論と紹介」と呼ばれるユーザにとって、この分配がわかりやすいのを許容するために。 これらの2つのテクニックの詳細はもう1ページを取るでしょう、したがって、言うために、各ユーザにとって、彼女のデスクトップの上に全体のグローバルなディレクトリがあるように見えるのが十分です。 (もちろん、世界の反対側の上に要求された情報があるなら、その要求には、デスクトップディレクトリが少し遅いように思えるかもしれません…)
3.2 The functionality of X.500
3.2 X.500の機能性
To describe the functionality of X.500, we will need to separate three stages in the evolution of X.500: 1) the 1988 standard, 2) X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard. We will list some of the features described in the 1988 standard, show how they were implemented in QUIPU, and discuss where the 1992 standard will take us. The QUIPU implementation was chosen because a) it is widely used in the U.S. and European Directory Services Pilot projects, and b) it works well. For a survey of other X.500 implementations and a catalogue of DUAs, see [Lang].
X.500の機能性について説明するために、私たちは、X.500の発展で3つのステージを切り離す必要があるつもりです: 1) 1988年の規格、2) QUIPU、および3で実装されるX.500)、(提案されます) 1992年の規格。 私たちは、1988年の規格で説明された特徴のいくつかを記載して、それらがQUIPUでどう実装されたかを示していて、1992年の規格がどこで私たちを連れて行くかと議論するつもりです。 QUIPU実装は、それがよく働かせる米国とヨーロッパ人ディレクトリサービスPilotプロジェクト、およびb)で広く使用されるので、選ばれました。 他のX.500実装の調査とDUAsのカタログに関しては、[ラング]を見てください。
3.2.1 Functionality in X.500 (88)
3.2.1 X.500の機能性(88)
There are a number of advantages that the X.500 Directory accrues simply by virtue of the fact that it is distributed, not limited to a single machine. Among these are:
X.500ディレクトリが単にそれが単一マシンに制限されるのではなく、分配されるという事実によって生じさせる多くの利点があります。 これらの中に、以下があります。
* An enormously large potential namespace.
Since the Directory is not limited to a single machine, many
hundreds of machines can be used to store Directory entries.
* 途方もないほど大きい潜在的名前空間。 ディレクトリが単一マシンに制限されないので、ディレクトリエントリーを保存するのに何百台ものマシンを使用できます。
* The ability to allow local administration of local data.
An organization or group can run a local DSA to master their
information, facilitating much more accurate data throughout
the Directory.
* ローカルのデータの地方行政を許容する能力。 組織かグループがそれらの情報をマスタリングするために地方のDSAを実行できます、ディレクトリ中でずっと多くの正確なデータを容易にして。
The functionality built into the X.500(88) standard includes:
X.500(88)規格が組み込まれた機能性は:
* Advanced searching capabilities.
The Directory supports arbitrarily complex searches at an
attribute level. As the object classes a specific entry
belongs to is maintained in the objectClass attribute, this
also allows Directory searches for specific types of objects.
Thus, one could search the c=US subtree for anyone with a last
name beginning with S, who also has either a fax number in the
(313) area code or an e-mail address ending in umich.edu.
This feature of X.500 also helps to provide the basic
functionality for a Yellow Pages service.
* 高度な探す能力。 ディレクトリは属性レベルで任意に複雑な検索をサポートします。 また、特定のエントリーが属すオブジェクトのクラスがobjectClass属性で維持されるように、これは特定のタイプのオブジェクトのディレクトリ検索を許します。 したがって、1つは姓がSと共に始まっているだれのためにもc=米国下位木を捜すかもしれません。(また、だれでもumich.eduに(313)市外局番かEメールアドレス結末におけるファックス番号を持っています)。 また、X.500のこの特徴は、イエローページサービスのための基本機能を提供するのを助けます。
DISI Working Group [Page 11] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[11ページ]RFC1309の技術的な概要
* A uniform namespace with local extensibility.
The Directory provides a uniform namespace, but local
specialized directories can also be implemented. Locally
defined extensions can include new object classes, new
attributes, and new attribute types.
* 地方の伸展性がある一定の名前空間。 ディレクトリは一定の名前空間を提供しますが、また、ローカルの専門化しているディレクトリを実装することができます。 局所的に定義された拡大は新しいオブジェクトのクラス、新しい属性、および新しい属性タイプを含むことができます。
* Security issues.
The X.500 (88) standards define two types of security for
Directory data: Simple Authentication (which uses passwords),
and Strong Authentication (which uses cryptographic keys).
Simple authentication has been widely implemented, strong
authentication has been less widely implemented. Each of
these authentication techniques are invoked when a user or
process attempts a Directory operation through a DUA.
* 安全保障問題。 X.500(88)規格はディレクトリデータのために2つのタイプのセキュリティを定義します: 簡単なAuthentication(パスワードを使用する)、およびStrong Authentication(暗号化キーを使用します)。 簡易認証は広く実装されて、強い認証はそれほど広くなく実装されていません。 ユーザかプロセスがDUAを通してディレクトリ操作を試みると、それぞれのこれらの認証のテクニックは呼び出されます。
In addition to the global benefits of the X.500 standard, there are many local benefits. One can use their local DSA for company or campus wide directory services; for example, the University of Michigan is providing all the campus directory services through X.500. The DUAs are available for a wide range of platforms, including X-Windows systems and Macintoshes.
X.500規格のグローバルな利益に加えて、多くの地方の利益があります。 1つは会社かキャンパスの広いディレクトリサービスに地元のDSAを使用できます。 例えば、ミシガン大学はX.500を通してすべてのキャンパスディレクトリサービスを提供しています。 DUAsはXウィンドウシステムとマッキントッシュを含むさまざまなプラットホームに利用可能です。
3.2.2 Functionality added by QUIPU.
3.2.2 QUIPUによって加えられた機能性。
Functionality beyond the X.500 (88) standard implemented by QUIPU includes:
QUIPUによって実装されたX.500(88)規格を超えた機能性は:
* Access control lists.
An access control list is a way to provide security for each
attribute of an entry. For example, each attribute in a given
entry can be permitted for detect, compare, read, and modify
permissions based on the reader's membership in various groups.
For example, one can specify that some information in a given
entry is public, some can be read only by members of the
organization, and some can only be modified by the owner of
the entry.
* アクセスコントロールリスト。 アクセスコントロールリストはエントリーの各属性にセキュリティを提供する方法です。 例えば、与えられたエントリーにおける属性を受入れることができるそれぞれが、様々なグループで読者の会員資格に基づく許容を、検出して、比較して、読んで、変更します。 例えば、1つは、与えられたエントリーにおける何らかの情報が公共であると指定できます、そして、何かが組織のメンバーによる書き込み禁止であるかもしれません、そして、エントリーの所有者は或るものを変更できるだけです。
* Replication.
Replication provides a method whereby frequently accessed
information in a DSA other than the local one can be kept by
the local DSA on a "slave" basis, with updates of the "slave"
data provided automatically by QUIPU from the "master" data
residing on the foreign DSA. This provides alternate access
points to that data, and can make searches and retrievals
more rapid as there is much less overhead in the form or
network transport.
* 模写。 模写は地方のDSAが「奴隷」ベースに地方のもの以外のDSAの頻繁にアクセスされた情報を保つことができるメソッドを提供します、「奴隷」データのアップデートがQUIPUによって外国DSAにある「マスター」データから自動的に提供されている状態で。 これで、代替のアクセスポイントをそのデータに提供して、まして、フォームかネットワーク輸送におけるオーバーヘッドがあるとき、検索とretrievalsは、より急速になる場合があります。
DISI Working Group [Page 12] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[12ページ]RFC1309の技術的な概要
3.3 Current limitations of the X.500 standard and implementations.
3.3 X.500規格と実装の現在の制限。
As flexible and forward looking as X.500 is, it certainly was not designed to solve everyone's needs for all time to come. X.500 is not a general purpose database, nor is it a Data Base Management System (DBMS). X.500 defines no standards for output formats, and it certainly doesn't have a report generation capability. The technical mechanisms are not yet in place for the Directory to contain information about itself, thus new attributes and new attribute types are rather slowly distributed (by hand).
確かに、それは、皆のすべての未来の必要性を解決するようにX.500としてのフレキシブルで前進の見ることと異なって設計されませんでした。 X.500は汎用のデータベースではありません、そして、それはデータベース管理システム(DBMS)ではありません。 X.500は出力形式の規格を全く定義しません、そして、確かに、それには、レポート作成能力がありません。 ディレクトリがそれ自体の情報を含むように、技術的機構は今まで適所にありません、その結果、新しい属性と新しい属性タイプはかなりゆっくり(手で)分配されます。
Searches can be slow, for two reasons: a) searches across a widely distributed portion of the namespace (c=US, for example) has a delay which is partially caused by network transmission times, and can be compounded by implementations that cache the partial search returns until everyone has reported back, and b) some implementations are slow at searching anyway, and this is very sensitive to such things as processor speed and available swap space. Another implementation "problem" is a tradeoff with security for the Directory: most implementations have an administrative limit on the amount of information which can be returned for a specific search. For example, if a search returns 1000 hits, 20 of those might be displayed, with the rest lost. Thus a person performing a large search might have to perform a number of small searches. This was implemented because an organization might want to make it hard to "troll" for the organization's entire database.
検索は2つの理由で遅い場合があります: a) 検索で横切って、名前空間(例えば、c=米国)の広く分配された部分は、部分的にネットワーク送信倍引き起こされる遅れを持って、捜すいくつかの実装がとにかく遅い実装皆が報告を持ちかえるまで部分的な検索が返すそのキャッシュ、およびb)で合成できて、これはプロセッサ速度と利用可能なスワップ領域のようなものに非常に敏感です。 別の実装「問題」はディレクトリのためのセキュリティがある見返りです: ほとんどの実装が特定の検索のために返すことができる情報量に管理限界を持っています。 例えば、検索が1000のヒットを返すなら、それらの20の力が、表示されて、残りに負けました。 したがって、大きい検索を実行している人は多くの小さい検索を実行しなければならないかもしれません。 組織が組織の全体のデータベースのために「輪唱」であることを困難にしたがっているかもしれないので、これは実装されました。
Also, there is at the moment no clear consensus on the ideal shape of the DIT, or on the idea structure of the object tree. This can make it hard to add to the current corpus of X.500 work, and the number of RFCs on various aspects of the X.500 deployment is growing monthly.
また、DITの理想的な形の上、または、オブジェクト木の考え構造の上にどんな明確なコンセンサスも現在、ありません。 これで、X.500仕事の現在のコーパスに加えるのは困難になる場合があります、そして、X.500展開の種々相のRFCsの数は月毎になっています。
Despite this, however, X.500 is very good at what it was designed to do; i.e., to provide primary directory services and "resource location" for a wide band oftypes of information.
しかしながら、これにもかかわらず、X.500はそれがするように設計されたことが非常に上手です。 すなわち、情報の広いバンドoftypesのためにサービスと「リソース位置」を基本登録簿に供給するために。
3.4 Things to be added in X.500 (92).
3.4のX.500(92)で加えられるべきもの。
The 1988 version of the X.500 standard proved to be quite sufficient to start building a Directory Service. However, many of the new functions implemented in QUIPU were necessary if the Directory were to function in a reasonable manner. X.500 (92) will include formalized and standardized versions of those advances, including
1988年のX.500規格のバージョンはディレクトリサービスを組み込み始めるためにかなり十分であると判明しました。 しかしながら、QUIPUで実装された新しい機能の多くがディレクトリが合理的な方法で機能することであったなら必要でした。 X.500(92)はそれらの進歩、包含の正式にされて標準化されたバージョンを含むでしょう。
* A formalized replication procedure.
* 正式にされた模写手順。
* Enhanced searching capacities.
* 探す能力を高めました。
DISI Working Group [Page 13] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[13ページ]RFC1309の技術的な概要
* Formalization of access control mechanisms, including access
control lists.
* アクセスコントロールリストを含むアクセス管理機構の形式化。
Each of these will provide a richer Directory, but you don't have to wait for them! You can become part of the Directory today!
それぞれのこれらは、より豊かなディレクトリを提供するでしょうが、あなたはそれらを待つ必要はありません! あなたは今日、ディレクトリの一部になることができます!
4: WHAT X.500 CAN DO FOR YOU TODAY
4: X.500が今日あなたのためにできることが
4.1 Current applications of X.500
4.1 X.500の現在のアプリケーション
X.500 is filling Directory Services needs in a large number of countries. As a directory to locate people, it is provided in the U.S. as the White Pages Pilot Project, run by PSI, and in Europe under the PARADISE Project as a series of nation-wide pilots. It is also being used by the FOX Project in the United States to provide WHOIS services for people and networks, and to provide directories of objects as disparate as NIC Profiles and a pilot K-12 Educators directory. It is also being investigated for its ability to provide resource location facilities and to provide source location for WAIS servers. In fact, in almost every area where one could imagine needing a directory service (particularly for distributed directory services), X.500 is either providing those services or being expanded to provide those services.
X.500は多くの国にディレクトリサービスの必要性をいっぱいにしています。 人々の居場所を見つけるディレクトリとして、PSIによって実行されたホワイトページPilot Projectとしての米国とPARADISE Projectの下の一連の全国的なパイロットとしてのヨーロッパにそれを提供します。 また、それは、人々とネットワークのためにサービスをWHOISに供給して、NIC Profilesと同じくらい異種のオブジェクトのディレクトリとパイロット幼小中高Educatorsディレクトリを供給するのに合衆国のFOX Projectによって使用されています。 また、それはリソース位置の施設を提供して、ソースの位置をWAISサーバに提供する性能のために調査されています。 事実上、1つがディレクトリサービス(特に分配されたディレクトリサービスのための)を必要とすると想像できたほとんどあらゆる領域では、X.500は、それらのサービスを提供するか、またはそれらのサービスを提供するために広げられています。
In particular, X.500 was envisioned by its creators as providing directory services for electronic mail, specifically for X.400. It is being used in this fashion today at the University of Michigan: everyone at the University has a unified mail address, e.g. Chris.Weider@umich.edu. An X.500 server then reroutes that mail to the appropriate user's real mail address in a transparent fashion. Similarly, Sprint is using X.500 to administrate the address space for its internal X.400 mail systems.
特に、X.500は電子メールと、特にX.400にディレクトリサービスを供給するとクリエイターによって思い描かれました。 それはこんなやり方で今日、ミシガン大学で使用されています: 大学の皆は統一された郵便の宛先、例えば Chris.Weider@umich.edu を持っています。 そして、X.500サーバは見え透いたファッションで適切なユーザの本当の郵便の宛先にそのメールを別ルートで送ります。 同様に、スプリントは、内部のX.400メールシステムのためのアドレス空間を管理するのにX.500を使用しています。
Those of us working on X.500 feel that X.500's strengths lie in providing directory services for people and objects, and for providing primary resource location for a large number of online services. We think that X.500 is a major component (though not the only one) of a global Yellow Pages service. We would also like to encourage each of you to join your national pilot projects; the more coverage we can get, the easier you will be able to find the people you need to contact.
X.500に働いている私たちのものは、人々とオブジェクトと、プライマリリソース位置を多くのオンラインサービスに提供するのにディレクトリサービスを供給するのにおいてX.500の強さがあると感じます。 私たちは、X.500が主要なグローバルにイエローページサービスのコンポーネント(もっとも、唯一無二でない)であると思います。 また、あなた達各人があなたの国家の試験計画に加わるよう奨励したいと思います。 私たちが得ることができるより多くの適用範囲であり、より簡単なあなたは連絡するのが必要である人々を見つけることができるでしょう。
DISI Working Group [Page 14] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[14ページ]RFC1309の技術的な概要
5. For Further Information
5. 詳細のために
For further information, the authors recommend the following documents:
詳しくは、作者は以下のドキュメントを推薦します:
Weider, C., and J. Reynolds, "Executive Introduction to Directory
Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI,
March 1992.
ワイダー、C.、およびJ.レイノルズ、「ディレクトリサービスへのX.500プロトコルを使用する幹部社員序論」、FYI13、RFC1308、ANS、ISI(1992年3月)。
Lang, R., and R. Wright, Editors, "A Catalog of Available X.500
Implementations", FYI 11, RFC 1292, SRI International, Lawrence
Berkeley Laboratory, January 1992.
ラング、R.、およびR.ライト、エディターズ、「利用可能なX.500実装のカタログ」、FYI11、RFC1292、SRIインターナショナル、ローレンスバークレイ研究所(1992年1月)。
Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
X.500 Schema", RFC 1274, University College London, November 1991.
RFC1274、ユニバーシティ・カレッジロンドン1991年11月のバーカー、P.、S.Hardcastle-Kille、および「コサインとインターネットX.500図式」
Hardcastle-Kille, S., "Replication Requirements to provide an
Internet Directory using X.500", RFC 1275, University College
London, November, 1991.
Hardcastle-Kille、S.、「インターネットディレクトリを提供するX.500を使用する模写Requirements」、RFC1275、ユニバーシティ・カレッジロンドン1991年11月。
Hardcastle-Kille, S., "Replication and Distributed Operations
extensions to provide an Internet Directory using X.500", RFC
1276, University College London, November 1991.
RFC1276、ユニバーシティ・カレッジロンドン1991年11月のHardcastle-Killeと、S.と、「X.500を使用することでインターネットディレクトリを提供する模写とDistributed Operations拡張子」
Hardcastle-Kille, S., "Encoding Network Addresses to support
operation over non-OSI lower layers", RFC 1277, University College
London, November 1991.
S.「非OSIの低級層の上の操作をサポートするためにNetwork Addressesをコード化すること」でのRFC1277、ユニバーシティ・カレッジロンドン1991年11月のHardcastle-Kille。
Hardcastle-Kille, S., " A string encoding of Presentation
Address", RFC 1278, University College London, November 1991.
Hardcastle-Kille、S.、「Presentation Addressの五弦コード化」、RFC1278、ユニバーシティ・カレッジロンドン1991年11月。
Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University
College London, November 1991.
RFC1279、ユニバーシティ・カレッジロンドン1991年11月のHardcastle-Killeと、S.と、「X.500とドメイン」
6. Security Considerations
6. セキュリティ問題
Security issues are discussed in section 3.
セクション3で安全保障問題について議論します。
DISI Working Group [Page 15] RFC 1309 Technical Overview of X.500 March 1992
X.500行進1992年のDISI作業部会[15ページ]RFC1309の技術的な概要
7. Authors' Addresses
7. 作者のアドレス
Chris Weider
Advanced Network and Services, Inc.
2901 Hubbard G-1
Ann Arbor, MI 48105-2437
クリス・ワイダーは48105-2437に、ネットワークとServices Inc.2901ハバード第一部アナーバー(MI)を唱えました。
Phone (313) 663-2482
E-mail: weider@ans.net
(313)663-2482メールに電話をしてください: weider@ans.net
Joyce K. Reynolds
Information Sciences Institute
University of Southern California
4676 Admirality Way
Marina del Rey, CA 90292
ジョイスK.レイノルズ情報Sciences Institute南カリフォルニア大学4676Admirality Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511
EMail: jkrey@isi.edu
以下に電話をしてください。 (310) 822-1511 メールしてください: jkrey@isi.edu
Sergio Heker
JvNCnet
Princeton University
6 von Neumann Hall
Princeton, NJ 08544
セルジオHeker JvNCnetプリンストン大学6フォンノイマン・Hallプリンストン、ニュージャージー 08544
Phone: (609) 258-2400
Email: heker@nisc.jvnc.net
以下に電話をしてください。 (609) 258-2400 メールしてください: heker@nisc.jvnc.net
DISI Working Group [Page 16]
DISI作業部会[16ページ]
一覧
スポンサーリンク
