RFC1107 日本語訳
1107 Plan for Internet directory services. K.R. Sollins. July 1989. (Format: TXT=51773 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Sollins
Request for Comments: 1107 M.I.T. Laboratory for Computer Science
July 1989
Sollinsがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1107 マサチューセッツ工科大学コンピュータ科学研究所1989年7月
A Plan for Internet Directory Services
インターネットディレクトリサービスのためのプラン
Table of Contents
目次
1. Introduction 1
1.1. The Issues 1
1.2. Project Summary 3
2. Goals and Requirements for a White Pages Service 6
3. Pre-existing Services 9
4. Proposed Approach 11
4.1. Stage 1: The Field Test 12
4.2. Stage 2: Implementation 17
4.3. Stage 3: Deployment 17
5. Conclusion 18
1. 序論1 1.1。 問題1 1.2。 概要3 2を映し出してください。 ホワイトページサービス6 3のための目標と要件。 サービス9 4を先在させます。 アプローチ11 4.1を提案しました。 ステージ1: 実地試験12 4.2。 ステージ2: 実装17 4.3。 ステージ3: 展開17 5。 結論18
Status of this Memo
このMemoの状態
This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community. Activity in this area is anticipated, and comments should be provided promptly. Distribution of this memo is unlimited.
このメモは、インターネットにディレクトリサービスを開発するために計画を提案します。 それは、召集された1989年2月に行われた会合の結果がそのようなサービスのための要件とオプションを再検討すると報告します。 この提案は、コメントのために提供されて、インターネットコミュニティの遂行された研究活動を表しません。 この領域での活動を予期します、そして、即座にコメントを提供するべきです。 このメモの分配は無制限です。
1. Introduction
1. 序論
1.1. The Issues
1.1. 問題
As part of the planned growth of the Internet (in particular, in support of the full science research community in the U.S.), an increasing need is anticipated for various sorts of directory services. The increase in the size of the community served by the Internet and the burgeoning demands for electronic mail lead to the need for a service to find people's computer mailboxes and other relevant facts, a so-called "White Pages" service. At the user level to date, there have been no such national or international white pages services in general use. As part of building the National Research Network (NRN), it is important that such a service exist, not only within the NRN community, but also crossing the boundaries from the NRN to the more global network community. This will enhance communication not only among computer scientists, but also among
インターネット(完全な科学を支持して特に、米国の共同体について研究する)の計画された成長の一部として、増加する必要性は様々な種類のディレクトリサービスのために予期されます。 共同体のサイズの増加はインターネットのそばで役立ちました、そして、電子メールの芽の要求はサービスが人々のコンピュータメールボックスと他の関連のある事実に当たる必要性につながります、いわゆる「ホワイトページ」サービス。 日付を入れるユーザレベルに、一般に、サービスが使用するそのようなどんな国家的、または、国際的なホワイトページもありませんでした。 National Research Network(NRN)を造る一部として、そのようなサービスが存在するのは、重要です、また、NRN共同体だけではなく、NRNから、よりグローバルなネットワーク共同体まで境界に交差していて。 これはまた、コンピュータ科学者だけではなく、コミュニケーションを高めるために望んでいます。
Sollins [Page 1] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[1ページ]RFC1107
scientists and engineers in other fields as well. Also important and related is a so-called "Yellow Pages" service, which permits the location of Internet resources based on their attributes.
また、他の分野の科学者と技術者。 また、重要であって、関連しているのは、いわゆる「イエローページ」サービス(それらの属性に基づくインターネット資料の位置を可能にする)です。
A "White Pages" service is one in which one can look up people in order to learn information about them for finding them. In its simplest form, a white pages service provides what the white pages telephone book provides. Based on a name, one can find an address and a telephone number. In a network environment, there may be many other kinds of location information, such as electronic mailbox, electronic calendar, or file server, where one might leave a file for the recipient. In addition, the electronic white pages may support a much more sophisticated set of mechanisms for lookup. One might match on a more complex set of attributes than first and last name. In addition, the searching might span more than one local white pages service. There are a number of naming and directory service specifications and implementations in the field. They have differing functionality and mechanisms to address that functionality.
「ホワイトページ」サービスは1つが彼らを見つけるために彼らの情報を学ぶために人々を訪ねることができるものです。 最も簡単なフォームに、ホワイトページサービスはホワイトページ電話帳が提供するものを提供します。 名前に基づいて、人はアドレスと電話番号を見つけることができます。 ネットワーク環境には、メールボックス、電子カレンダー、またはファイルサーバーなどの他の多くの種類の位置情報があるかもしれません。そこでは、1つがファイルを受取人に残すかもしれません。 さらに、電子ホワイトページはルックアップのためにはるかに高性能のセットのメカニズムをサポートするかもしれません。 1つは1番目と姓より複雑なセットの属性で合うかもしれません。 さらに、探すのは1つ以上の地方のホワイトページサービスにかかるかもしれません。 多くの命名、ディレクトリサービス仕様、および実装がその分野にあります。 彼らには、その機能性を扱う異なった機能性とメカニズムがあります。
Within the the world of networking today, there are a number of partial solutions to the directory service problem. Examples of these are the Internet Domain Naming Service (DNS), Clearinghouse, DECnet Network Architecture Naming Service (DNANS), Profile, and X.500. The Domain Naming Service provides a directory service most commonly used for host naming and mail delivery. Clearinghouse and DNANS are respectively the Xerox and DEC corporate naming services, originally for mail delivery, although having other uses as well, in both cases. Profile is part of the work of Larry Peterson to explore descriptive naming in a non-hierarchical structure.
今日のネットワークの世界の中に、ディレクトリサービス問題への多くの部分的解決があります。 これらに関する例は、インターネットDomain Naming Service(DNS)と、Clearinghouseと、DECnet Network Architecture Naming Service(DNANS)と、Profileと、X.500です。 Domain Naming Serviceはホスト命名と郵便配達に最も一般的に使用されるディレクトリサービスを提供します。 情報センターとDNANSはそれぞれゼロックスと12月の法人の名前付けサービスです、また、他の用途を持っていて元々郵便配達のために、どちらの場合も。 プロフィールは非階層構造で描写的である命名について調査するラリー・ピーターソンの仕事の一部です。
There is a CCITT recommendation X.500 (ISO DIS 9594), which defines a general directory service. One of its primary goals is the naming service needed for message handling (X.400). While X.500 is still developing, and would need further evolution to cover all the requirements of a service for the Internet, it will have an important impact on the Internet community. It will form the basis of commercial products, and it will almost certainly be the directory service of many parts of the network world, which implies a need to interoperate at a minimum. There is some concern that despite the fact that X.500 is a recognized standard, there are a number of gaps and limitations of the approach, that in turn will cause it to be inadequate for the needs of the NRN.
CCITT推薦X.500(ISO DIS9594)があります。(X.500は一般的なディレクトリサービスを定義します)。 プライマリ目標の1つはメッセージハンドリング(X.400)に必要である名前付けサービスです。 X.500がまだ展開していて、すべてのインターネットのためのサービスの要件をカバーするために一層の発展を必要としているだろうという間、それはインターネットコミュニティに重要な影響力を持つでしょう。 商品の基礎を形成するでしょう、そして、それはほぼ確実にネットワーク世界の多くの地域のディレクトリサービスになるでしょう。(ネットワーク世界は最小限で共同利用する必要性を含意します)。 X.500が認識された規格であるという事実にもかかわらず、アプローチの多くのギャップと制限があるというそれがNRNの必要性に不十分であることを順番に引き起こす何らかの関心があります。
In this context, a meeting was held to review current requirements and solutions for directory services. This RFC reports the results of that meeting, including the possibilities for a program of work in this area.
このような関係においては、会合が、ディレクトリサービスのために現在の要件とソリューションを再検討するために行われました。 このRFCはこの領域の仕事に関するプログラムのための可能性を含むそのミーティングの結果を報告します。
Sollins [Page 2] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[2ページ]RFC1107
For two days, a group representing academic, commercial, and government interests in directory services discussed both alternative candidates for a white pages service and the issues in building any such service. The meeting was kept small by inviting only a small number of representatives of each perspective. By the conclusion of the second day, a consensus was reached on how one could achieve a white pages service in three years. This is summarized in the next section.
2日間、ホワイトページサービスの議論されたともに代替の候補とどんなそのようなものも建てることにおける問題が修理するディレクトリサービスにアカデミックなコマーシャル、および政府関心を表すグループのために。 ミーティングは、それぞれの見解の少ない数の代表だけを招待することによって、小さく保たれました。 2日目の結論で、1つが3年後にどうホワイトページサービスを実現するかもしれないかに関してコンセンサスに達しました。 これは次のセクションでまとめられます。
1.2. Project Summary
1.2. プロジェクト概要
The consensus of the meeting can be summarized in the following five points:
以下の5ポイントにミーティングのコンセンサスをまとめることができます:
1. The standards and implementations are close enough to being
complete that it is reasonable to undertake provision of an NRN
"White Pages" service.
1. 規格と実装は完全にNRN「ホワイトページ」サービスの支給を引き受けるのが妥当であるほど近いです。
2. Although we are close, an effort is needed to experiment with
different levels of service, to flesh out the standards, and to
develop code.
2. 私たちは近くにいますが、取り組みが、異なったレベルのサービスを実験して、規格を太らせて、コードを開発するのに必要です。
3. An initial evaluation experiment is needed before making final
detailed plans for a production version of the service.
3. サービスの生産バージョンのための最終的な綿密な計画を作る前に、事前評価実験が必要です。
4. With strong funding and encouragement, a production service is
possible in three years.
4. 強い基金と奨励では、生産サービスは3年後に可能です。
5. It is important to act now to provide a coherent solution.
This means both having an impact on the evolving standards
and providing a unified, wide-spread solution before a plethora
of differing solutions appear.
5. 現在一貫性を持っている解決法を提供するために行動するのは重要です。 これは、発展規格と統一されて、広範囲の解決法を提供するときの異なったソリューションの過剰の前影響がともに現れさせることを意味します。
Although it has clearcut drawbacks, X.500 was identified as the most likely candidate directory service. The reasons for this are that it has rich semantics and is becoming the accepted international standard. However, there are problems with its incompleteness and with its strict hierarchy. Therefore, in order to explore these and become convinced of its viability, the consensus at the meeting was to propose field trials, as the project's first stage. The field trials would be limited in the user community, perhaps restricted to computer science departments because of their familiarity with the problems, and would be based on experimental or new software. They would include experiments with at least an X.500 implementation, Profile, and DNANS. Each of these services has strong points that must be considered as part of the evaluation. They are:
それには、明確な欠点がありますが、X.500は最もありそうな候補ディレクトリサービスとして特定されました。 この理由は豊かな意味論を持って、受け入れられた世界規格になっているということです。 しかしながら、不備とその厳しい階層構造に関する問題があります。 したがって、ミーティングにおけるコンセンサスはこれらを探検して、生存力で確信するようになるように実地試験を提案することでした、プロジェクトの第一段階として。 実地試験は、問題へのそれらの親しみのために恐らくコンピュータサイエンス部に制限されたユーザーコミュニティで制限されて、実験的であるか新しいソフトウェアに基づくでしょう。 彼らは少なくともX.500実装、Profile、およびDNANSとの実験を含んでいるでしょう。 それぞれのこれらのサービスには、評価の一部であるとみなさなければならない長所があります。 それらは以下の通りです。
Sollins [Page 3] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[3ページ]RFC1107
X.500: International standard, hierarchy, search rules and
filters for searching attributed based names.
X.500: 世界規格、階層構造は規則を捜します、そして、探索のためのフィルタはベースの名前を結果と考えました。
Profile: Descriptive naming with a richer semantics for
describing search criteria, an arbitrary network
of servers.
以下の輪郭を描いてください。 検索評価基準について説明するための、より豊かな意味論、サーバの任意のネットワークによる描写的である命名。
DNANS: Access control, replication, caching, hierarchy.
DNANS: コントロール、模写、キャッシュ、階層構造にアクセスしてください。
In summary, the plan would fall into three stages as follows:
概要では、プランは以下の3つのステージに落ちるでしょう:
- Stage 1: Field Trials.
- ステージ1: トライアルをさばいてください。
There are two aspects to the field trials. The first is to
explore several different architectures for a white pages
service. To this end, implementations of X.500, Profile, and
DNANS should be included. The second aspect of the field
trials is to distinguish issues inherent in the X.500
specification from artifacts of a particular implementation of
it. Therefore, if possible, two implementations of X.500
should be included. Only one such implementation, Quipu, was
identified as developed enough to be included in a field trial
at present, but others are under way, and will follow. This
stage must also include a careful and objective review of the
field trials.
実地試験への2つの局面があります。 1番目はホワイトページサービスのためにいくつかの異なったアーキテクチャを探ることです。 このために、X.500、Profile、およびDNANSの実装は含まれるべきです。 実地試験の第2の面はそれの特定の実装の人工物とX.500仕様の固有である問題を区別することです。 したがって、できれば、X.500の2つの実装が含まれるべきです。 そのような実装の1つ(Quipu)だけが現在のところ実地試験に含むことができるくらい開発されるように特定されましたが、他のものは進行中です、そして、続くでしょう。 また、このステージは実地試験の慎重で客観的なレビューを含まなければなりません。
- Stage 2: Implementation.
- ステージ2: 実装。
This stage will include work on both the service and user
interfaces. The field trials could result in one of a variety
of conclusions about the service. These may range from
concluding that one or another of the services suits the needs
of the NRN to proposing a compromise position based on a
combination of shortcomings of any one service and the features
of others to address those shortcomings. Because X.500 will
become the standard in other domains, an interface to X.500
will be necessary. Since all of these implementations are
still under development, in order to provide production quality
code, more implementation work will be needed.
このステージはサービスとユーザインタフェースの両方に対する仕事を含むでしょう。 実地試験はサービスに関するさまざまな結論の1つをもたらすかもしれません。 サービスのものか別のものがどんなサービスの短所とそれらの短所を扱う他のものの特徴の組み合わせにも基づく感染位置を提案するのにNRNの必要性に適していると結論を下すので、これらは及ぶかもしれません。 X.500が他のドメインで規格になるので、X.500へのインタフェースは必要になるでしょう。 これらの実装のすべてが生産品質コードを提供するためにまだ開発中であるので、より多くの実装仕事が必要でしょう。
Although some work will have been done on the user interfaces,
much more will be needed in this stage to provide a variety of
interfaces. Much emphasis should be placed on this in Stage 2.
ユーザインタフェースでいくらかの仕事をしてしまうでしょうが、さまざまなインタフェースを提供するためにこの段階ではるかに多くを必要とするでしょう。 多くの強調がStage2にこれに置かれるべきです。
- Stage 3: Deployment.
- ステージ3: 展開。
Deployment of the full white pages service requires information
gathering in order to fill the directory service, placement of
サービスがディレクトリサービスをいっぱいにするために集まる情報、プレースメントを必要とする完全なホワイトページの展開
Sollins [Page 4] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[4ページ]RFC1107
servers, distribution of and training for use of client code,
placement and management of services, and delegation of
authority within the service for authority over the contents.
Data collection and some delegation of authority as well as
training for users of the client code would begin during the
field trial. This stage would begin concurrently with the
other two. During the second year, detailed planning for
deployment must take place. This stage would conclude in three
years, at which time widespread deployment would have occurred.
サーバ、サービスのクライアントコードの使用、プレースメント、および管理のための分配とトレーニング、およびコンテンツの上の権威のためのサービスの中の権限の委任。 クライアントコードのユーザのためのトレーニングと同様にデータ収集といくらかの権限の委任が実地試験の間、始まるでしょう。 このステージは同時に他の2で始まるでしょう。 2年間目の間、展開のための詳細な計画は行われなければなりません。 このステージは3年後に終わるでしょう。その時、広範囲の展開は起こったでしょう。
In order to undertake this three stage program effectively, the group identified the following major projects:
有効にこの3ステージプログラムを引き受けるために、グループは以下の主要な計画を特定しました:
- Further implementation of code for the field trials.
- 実地試験のためのコードのさらなる実装。
In each case (e.g., Quipu, Profile, and DNANS), programs exist,
although modifications are likely to be necessary. For
example, each will need to be modified to utilize the common
file format into which the input data about users will be
gathered.
その都度(例えば、Quipu、Profile、およびDNANS)、変更は必要である傾向がありますが、プログラムは存在しています。 例えば、それぞれが、ユーザに関する入力データが集められる一般的なファイル形式を利用するように変更される必要があるでしょう。
- Design, development and evaluation of user interfaces.
- ユーザのデザイン、開発、および評価は連結します。
- Design and development of data gathering and management tools.
- データ集会と管理ツールのデザインと開発。
- Oversight and evaluation of the field trials.
- 実地試験の見落としと評価。
Careful thought and planning must go into the field trials, to
guarantee that we learn what is needed to make an evaluation
and to plan for the white pages service. The evaluation must
also produce a document that is both a general specification
(assuming no one alternative is chosen wholesale) and profiling
information, in order for later interoperability and
conformance testing.
考慮と計画は、私たちが、何が評価して、ホワイトページサービスの計画を立てるのに必要であるかを学ぶのを保証するために実地試験に入らなければなりません。 また、評価は一般仕様(代替であることの人はだれも卸値で選ばれていないと仮定する)と後の相互運用性の注文における情報の輪郭を描いて、順応テストの両方であるドキュメントを製作しなければなりません。
- Detailed planning and later management of deployment.
- 展開の詳細な計画と、より遅い管理。
This includes delegation of authority over parts of the
namespace and arbitrating the shape of the namespace
(addressing the questions about who gets what sorts of names).
This is in addition to the continued and extended data
collection and management, distributing the data, placing the
code, documentation and user education.
これは名前空間と名前空間の形を仲裁する部品の上に権限の委任を含んでいます(だれが得るかに関する質問が名前のどんな種類であるかと扱って)。 これは継続的で拡張しているデータ収集と管理に加えています、データを分配して、コード、ドキュメンテーション、およびユーザ教育を置いて。
- Standards participation is an important part of the program.
- 規格参加はプログラムの重要な部分です。
It is critical as X.500 changes during the next 4 year study
period that the United States take a strong stand on any
X.500が次の4年間の研究期間の間変化するとき、合衆国がいずれの強い態度を取るのは、重要です。
Sollins [Page 5] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[5ページ]RFC1107
changes we envision. It is encumbant on us to utilize
effectively the results of the largest field trials of this
work in the international arena. The group agreed that this
could take up to one half of one person's time in a year.
私たちが思い描く変化。 私たちでは、有効にこの仕事の国際的な場で最も大きい実地試験の結果を利用するのはencumbantです。 グループは、これが1年間で1人の人の時間の半分取ることができるのに同意しました。
- A task force or working group is necessary to provide a forum
for communication and discussion.
- 特別委員会かワーキンググループが、コミュニケーションと議論にフォーラムを提供するのに必要です。
It is important to pursue this path now, both to architect a unified solution before a collection of ad hoc solutions is deployed, and to provide effective input into the X.500 standards work based on the field trials.
現在、ともにその場かぎりの解決の収集の前の統一されたソリューションが配布される建築家までこの経路を追求して、実地試験に基づくX.500標準化作業に有効な入力を提供するのは重要です。
2. Goals and Requirements for a White Pages Service
2. ホワイトページサービスのための目標と要件
The requirements of a white pages service are the following:
ホワイトページサービスの要件は以下です:
- Functionality:
- 機能性:
The simple form of a white pages service is straightforward;
one should be able to query the service with the name of a
person, and have returned attributes of the person such as
network mail address and phone number.
ホワイトページサービスの単純形は簡単です。 人の名前でサービスについて質問して、人のネットワーク郵便の宛先や電話番号などの属性を返すことができるべきでした。
- Correctness of information:
- 情報の正当性:
The information in a white pages service is useless and
untrusted if it is not updated regularly. A white pages
service will not be used, if the information it provides is out
of date or incorrect. This will require a set of management
tools. Data integrity is an especially difficult challenge in
this area, in contrast with information that is syntactically
correct.
定期的にそれをアップデートしないなら、ホワイトページサービスにおける情報は、役に立たなくて、信頼されていないです。 それが提供する情報が時代遅れであるか、または不正確であるなら、ホワイトページサービスは利用されないでしょう。 これは管理ツールをセットに要求するでしょう。 データの保全はシンタクス上正しい情報と比べたこの領域での特に難しい挑戦です。
- Size:
- サイズ:
The science and research community has been estimated at ten
million users. The number of organizations in the United
States is on the order of ten to one hundred thousand.
科学と研究団体は1000万人のユーザと見積もられています。 10〜100000の注文には合衆国の組織の数があります。
- Usage and query rate:
- 用法と質問は評価します:
In comparison with the typical telephone book pattern of about
one lookup a week per person, users of electronic mail in the
science and research community will send more electronic mail
messages than they currently make phone calls, leading to an
estimate of ten searches a week per user for electronic as well
as paper mail and telephone information. This leads to a query
1人あたり1週間、科学と研究団体の電子メールのユーザが送るおよそ1つのルックアップの典型的な電話帳パターンとの比較では、それらより多くの電子メールメッセージが現在電話をかけます、電子と紙のメールと電話情報のために1週間あたり10の検索の1ユーザあたり1つの見積りに通じて。 これは質問に通じます。
Sollins [Page 6] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[6ページ]RFC1107
rate of 10**8 queries per week or 170 per second on average,
with much higher peak rates. The average could probably be
handled by a single server, but not the peak rates and this
would leave little room for growth. Therefore, a distributed,
multiple server solution is the only one that make sense.
1週間あたりの10**8質問か170の平均での秒あたりのレートに、多くが、より高い状態で、レートに最大限にしてください。 たぶんピークレートではなく、ただ一つのサーバで平均を扱うことができました、そして、これには、成長の余地がほとんどないでしょう。 したがって、分配された倍数サーバソリューションは理解できる唯一無二です。
- Response time:
- 応答時間:
The issue of overall query behavior must be considered
carefully. The issue arises when queries, in particular
searches, are not limited to tightly constrained sets of
entries. Since the number of queries generated will be
proportional to the number of users (and the size of the
system), the white pages design must avoid costs per query that
are related to the size of the system. The consequence,
otherwise, will be quadratic behavior in response time.
慎重に総合的な質問の振舞いの問題を考えなければなりません。 質問(特に検索)がしっかり強制的なエントリーに制限されないとき、問題は起こります。 生成された質問の数がユーザ(そして、システムのサイズ)の数に比例するようになるので、ホワイトページデザインはシステムのサイズに関連する1質問あたりのコストを避けなければなりません。 そうでなければ、結果は応答時間に二次の振舞いになるでしょう。
The response time of the service must also reflect the expected
usage. A phone book style query must respond in the waiting
time tolerable to a user, perhaps ten seconds maximum, or one
second desirable. If the service is incorporated as a
component of a larger service, then the needs of that service
determine the response time.
また、サービスの応答時間は予想された用法を反映しなければなりません。 電話帳スタイル質問は恐らく10秒のユーザにとって、許容できる待ち時間で望ましい最大、または1秒を反応させなければなりません。 サービスが、より大きくサービスのコンポーネントとして法人組織であるなら、そのサービスの必要性は応答時間を決定します。
- Partitioned Authority:
- 仕切られた権威:
The white pages service under discussion would be used by a
wide variety of organizations, ranging from small and large
companies, to network service providers, to government
agencies. Many of these would find it unacceptable to delegate
the authority over their namespaces to some other organization.
Therefore, partitioned authority including some access control,
name assignment, and information management must be possible.
議論しているホワイトページサービスはさまざまな組織によって利用されるでしょう、大小会社から変化して、ネットワークサービスプロバイダーに、政府機関に。 これらの多くが、それらの名前空間の上へ権威を代表として派遣するのが容認できないのがある他の組織においてわかるでしょう。 したがって、何らかのアクセス制御、名前課題、および情報管理を含む仕切られた権威は可能であるに違いありません。
- Access Control:
- コントロールにアクセスしてください:
The access control required by the white pages falls into two
categories, read access control, and write or modify access
control. There are at least two reasons that read access
control must be available. One is that organizations may
require limiting the access to the actual entries or parts of
them. This would be comparable to organizations not being
willing to distribute their corporate phone books or personnel
records. The other reason is that some organizations do not
want to publicize or make public their organizational
structure. Write and modify access control is necessary
because both individuals and organizations may want to prevent
inadvertent or malicious creation or modification of
アクセス制御がホワイトページ滝によって2つのカテゴリに必要とされて、アクセスコントロールを読んでください、アクセスコントロールを書くか、または変更してください。 少なくとも2つのアクセスコントロールが読まれる場合利用可能であるに違いない理由があります。 1つは組織が、アクセスをそれらの実際のエントリーか部分に制限するのを必要とするかもしれないということです。 これはそれらの法人の電話帳か人事に関する記録を配布することを望んでいない組織に匹敵しているでしょう。 もう片方の理由はいくつかの組織がそれらの組織体制をピーアールしたくはありませんし、公表したがっていないということです。 書いて、変更、個人と組織の両方が不注意であるか悪意がある作成か変更を防ぎたがっているかもしれないので、アクセスコントロールが必要です。
Sollins [Page 7] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[7ページ]RFC1107
information. Access control is an issue for both organizations
wanting to retain local control of personnel information and
individuals wanting to control access to private information
about themselves.
情報。 アクセスコントロールは人員情報の現場制御を保有したがっている組織と自分たちに関する個人情報へのアクセスを制御したがっている個人の両方のための問題です。
- Multiple Transport Protocol Support:
- 複数のトランスポート・プロトコルサポート:
Within the next three years, one cannot expect all the
organizations in the USA to convert to the OSI protocols. On
the other hand, some will. It is therefore important that any
white pages service provide interfaces on top of both OSI
protocols and TCP/IP. There currently exists a partial OSI
suite know as ISODE on top of TCP. This is being distributed
widely enough that perhaps this should also be supported.
3年以内に、人は、米国でのすべての組織がOSIプロトコルに変えることを期待できません。 他方では、何かはそうするでしょう。 したがって、どんなホワイトページサービスもOSIプロトコルとTCP/IPの両方の上でインタフェースを提供するのは、重要です。 スイートがISODEとしてTCPの上で知っている部分的なOSIは現在、存在します。 十分広く分配されているので、また、恐らく、これはサポートされるべきです。
In addition to these requirements, there are a number of features that would make a white pages service more useful. These are:
これらの要件に加えて、ホワイトページサービスをより役に立つようにする多くの特徴があります。 これらは以下の通りです。
- Additional Functionality:
- 追加機能性:
Descriptive naming with sophisticated searching based on
attributes would support a more flexible human interface than
simple name translation. Descriptive naming also would support
a general yellow pages style service.
属性に基づく洗練された探すのによる描写的である命名は単純名翻訳よりフレキシブルなヒューマンインターフェースをサポートするでしょう。 描写的である命名も、一般的な職業別広告欄スタイルがサービスであるとサポートするでしょう。
The form of a yellow pages service is less certain. One
definition of a yellow pages service is a directory that stores
a number of pre-computed inversions of the directory database,
so that entries can be retrieved very efficiently using these
predetermined attributes of the data. Another definition of a
yellow pages service is one that provides a very powerful set
of search primitives, somewhat in common with a relational
query language, to support retrieval of entries that match
complex attribute conditions. In other words, one view of a
yellow pages service is that it is constructed to avoid
expensive searches, the other is that it is to facilitate
general searches.
職業別広告欄サービスのフォームはそれほど確かではありません。 職業別広告欄サービスの1つの定義がディレクトリデータベースの多くのあらかじめ計算された逆を保存するディレクトリです、非常に効率的にデータのこれらの予定された属性を使用することでエントリーを検索できるように。 別の職業別広告欄サービスの定義は複雑な属性状態に合っているエントリーの検索をサポートするためにいくらか関係照会言語と共用して非常に強力なセットの検索基関数を提供するものです。 言い換えれば、職業別広告欄サービスの1つの視点はそれが高価な検索を避けるために組み立てられて、もう片方が一般的な検索を容易にすることになっているということであるということです。
- Accountability:
- 責任:
Accountability is important both for allocation and recovery of
costs. Vendors may provide commercial directory services,
therefore depending on accounting as part of their successful
commercial ventures.
コストの配分と回復に、責任は重要です。 したがって、それらのうまくいっているコマーシャルの一部が冒険しながら会計によって、ベンダーは商業人名簿サービスを提供するかもしれません。
- Multiple Interfaces:
- 複数のインタフェース:
There should be both human and programming interfaces to the
人間とプログラミングが連結する両方があるべきです。
Sollins [Page 8] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[8ページ]RFC1107
white pages. For example, in addition to human lookups, mail
services could effectively use a naming service allow users to
include human oriented names than the current electronic mail
addresses that are required, such as full domain names.
ホワイトページ。 例えば、人間のルックアップ、事実上、サービスが使用できたメールに加えてユーザは必要である現在の電子メールアドレスより名前付けサービスで人間の指向の名前を入れることができます、完全なドメイン名などのように。
- Multiple Clients:
- 複数のクライアント:
Several different clients should exist both to provide for a
variety of styles of human usage, and to support selection of
the most commonly used computer environments (e.g., UNIX, VMS,
MSDOS, OS2, MAC/OS).
数人の異なったクライアントが、ともにさまざまなスタイルの人間の用法に備えるために存在するべきであり、一般的に、コンピュータ環境(例えば、UNIX、VMS、MSDOS、OS2、MAC/OS)を大部分のサポート選択に使用しました。
3. Pre-existing Services
3. サービスを先在させます。
This section identifies other naming services that have been proposed or implemented for naming people. Implementations of all of these exist, although some are still only experimental.
このセクションは人々を命名するために提案されるか、または実装された他の名前付けサービスを特定します。 或るものはまだ実験的であるだけですが、これらのすべての実装は存在しています。
Internet Domain Naming Service
インターネットドメイン名前付けサービス
The Internet Domain Name Service [6,1] is used today to name
host machines. It is implemented to address the query rates
and database sizes consistent with looking up hosts as part of
mail delivery. It provides a hierarchy with delegation of
authority within the hierarchy. Aliases are also available.
There is no access control, and the service is widely
distributed throughout the Internet. It supports management of
distribution, replication and caching. It is operational, and
provides a rich base of practical experience. It was
originally intended to be extensible to cover naming of people.
It runs on a variety of different operating systems and
utilizes the TCP/IP protocol suite.
インターネットDomain Name Service[6、1]は、今日、ホスト・マシンを命名するのに使用されます。 それは、質問が郵便配達の一部としてホストを訪ねると一致したレートとデータベースサイズであると扱うために実装されます。 それは階層構造の中で権限の委任を階層構造に提供します。 また、別名も利用可能です。 アクセス制御が全くありません、そして、サービスはインターネット中に広く広げられます。 それは分配、模写、およびキャッシュの管理をサポートします。 それは、操作上であり、実用的な経験の豊かなベースを供給します。 元々、それが人々の命名をカバーするのにおいて広げることができることを意図しました。 それは、さまざまな異なったオペレーティングシステムで動いて、TCP/IPプロトコル群を利用します。
The DECnet Network Architecture Naming Service (DNANS)
DECnetネットワークアーキテクチャ名前付けサービス(DNANS)
There is a rather well developed specification [5,3] for a
naming service that is part of the DECnet architecture, which
in turn arose from work at the DEC SRC in Palo Alto. This
architecture addresses some problems not yet covered by X.500,
such as access control, replication, and caching. It was
explicitly defined to have great scalability and management
features. It provides a global hierarchy of names, which are
mapped into properties. Therefore, operations of searching
based on properties or attributes may be expensive and
difficult. At present it is only implemented on VMS using the
DNA protocols, but will be moved to UNIX and TCP in the next
year.
かなりよく開発された仕様[5、3]がパロアルトのDEC SRCでの仕事から順番に起こったDECnetアーキテクチャの一部である名前付けサービスのためにあります。 このアーキテクチャはアクセスコントロールや、模写や、キャッシュなどのX.500でまだカバーされていなかったそのいくつかの問題を訴えます。 それは、すばらしいスケーラビリティと管理機能を持つために明らかに定義されました。 それは名前のグローバルな階層構造を提供します。(名前は特性に写像されます)。 したがって、特性か属性に基づく探すことの操作は、高価であって、難しいかもしれません。 現在のところ、それは、VMSでDNAプロトコルを使用することで実装されるだけですが、翌年、UNIXとTCPに動かされるでしょう。
Sollins [Page 9] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[9ページ]RFC1107
Clearinghouse
情報センター
This service [7,2] is part of the Xerox network environment.
It operates today as a global service for Xerox. They have
considerable experience with its operation, including problems
of scale. Clearinghouse provides a three-level hierarchy of
names that are mapped to sets of properties. Loose consistency
is provided through slow propagation of updates. Both this
service and the DEC service mentioned above are to some extent
based on an earlier Xerox service called Grapevine.
このサービス[7、2]はゼロックスネットワーク環境の一部です。 それは今日、ゼロックスのためのグローバルなサービスとして作動します。 それらはスケールの問題を含む操作で経験に富みます。 情報センターは特性のセットに写像される名前の3レベルの階層構造を提供します。 アップデートの遅い伝播でゆるい一貫性を提供します。 前記のようにこのサービスと12月のサービスの両方がGrapevineと呼ばれる以前のゼロックスのサービスにある程度基づいています。
Profile
プロフィール
A project at the University of Arizona run by Larry Peterson
[8] has produced a white pages name service called Profile. It
supports descriptive naming and sophisticated lookup tools.
Profile assumes the existence of some other service such as the
DNS to navigate among Profile servers. This navigation service
need not restrict the relationship among Profile servers to a
hierarchical organization; Profile supports a non-hierarchical
global structure. Names in Profile consist of sets of
attributes. Experimental implementations are in operation
today, and the largest site currently contains about 10,000
entries. The Profile code has been available for long enough
that it has become stable. The implementation is UNIX-based
only and uses TCP.
ラリー・ピーターソン[8]によるアリゾナ大学走行におけるプロジェクトはProfileと呼ばれるホワイトページ名前サービスを起こしました。 それは描写的である命名していて精巧なルックアップツールを支えます。 プロフィールは、Profileサーバの中でナビゲートするためにDNSなどのある他のサービスの存在を仮定します。 このナビゲーションサービスはProfileサーバの中で関係を階層的な組織に制限する必要はありません。 プロフィールは非階層的なグローバル構造を支えます。 Profileの名前は属性のセットから成ります。 実験的な実現は今日稼働中です、そして、最も大きいサイトは現在、およそ1万のエントリーを含みます。 Profileコードは安定するようになるくらいの長く利用可能です。 実現がUNIXベースである、唯一、そして、用途TCP。
X.500
X.500
X.500 is the CCITT recommendation (also ISO/IEC/DIS 9594) [4]
for a directory service. Because it is a CCITT recommendation,
it evolves in four year study periods, one of which has
recently come to a close. Thus, X.500 has a stable definition
for the next four years.
X.500は電話番号案内のためのCCITT推薦(ISO/IEC/DIS9594も)[4]です。 CCITT推薦であるので、それは4年間の研究期間に発展します。その1つは最近、終わりました。 したがって、X.500には、次の4年間安定した定義があります。
In X.500, the set of all objects forms a single hierarchy, with
each object being named relative to its parent and a single
root as the topmost parent. An object consists of a set of
attributes. Searching can be done by use of a logical
combination of attribute values, known as a filter. A subset
of these attributes comprise an object's distinguished name
relative to its parent. The hierarchy as described in the
CCITT recommendation is geographic at its top level and
organizational within that. Alternatives can also be defined,
although they are not part of the CCITT or ISO documents. In
addition, there is no proposed mechanisms for distributing
information about other attribute types or object classes. As
with the other services, X.500 is a distributed service. It
X.500では、すべての物のセットはただ一つの階層構造を形成します、名が最上の親として親とただ一つの根に比例してあげられる各物は。 物は1セットの属性から成ります。 フィルタとして知られている属性値の論理結合の使用で探すことができます。 これらの属性の部分集合は親に比例して物の分類名を包括します。 CCITT推薦で説明される階層構造は、トップレベルで地理的であって、それの中で組織的です。 それらはCCITTかISOドキュメントの一部ではありませんが、また、代替手段を定義できます。 さらに、他の属性タイプか物のクラスに関する情報伝達のための提案されたメカニズムが全くありません。 他のサービスのように、X.500は分配されたサービスです。 それ
Sollins [Page 10] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[10ページ]RFC1107
specifies cooperating servers or Directory Server Agents (DSAs)
under local control and management each of which knows about
one or more parts of the hierarchy. The clients are known as
Directory User Agents (DUAs). It is defined to run on top of
the OSI protocol stack. The demonstrations of X.500 in the
context of Internet run on top of the ISODE package, which
provides OSI transport on top of TCP.
それのそれぞれが階層構造のおよそ1箇所以上を知っている現場制御と管理で協力サーバかディレクトリServerエージェント(DSAs)を指定します。 クライアントはディレクトリUserエージェント(DUAs)として知られています。 それは、OSIプロトコル・スタックの上を走るために定義されます。 インターネットの文脈における、X.500のデモンストレーションはISODEパッケージの上に走ります。パッケージはTCPの上で輸送をOSIに供給します。
X.500 is incomplete in that there are a number of identifiable
areas in which the standard says nothing, but that need to be
specified for a successful implementation. Some examples of
these are: access control (although authentication is
supported), replication, caching, the database itself (the
shape of the hierarchy), tools to limit the scope and cost of
searching, and database management tools.
規格が沈黙しますが、うまくいっている実現に指定される必要がある多くの身元保証可能な領域があるので、X.500は不完全です。 これらに関するいくつかの例は以下の通りです。 コントロールにアクセスしてください(認証は支持されますが)、模写、キャッシュしています、データベース(階層構造の形)自体、探すこと、およびデータベース管理ツールの範囲と費用を制限するツール。
There are currently a small number of implementations of X.500
in progress at such locations as University College London (the
Quipu project, on UNIX using ISODE), the University of British
Columbia (UNIX based using their own full OSI suite), MIT
(experimental, Symbolics Lisp Machine based, Lisp using TCP),
The Wollongong Group (offshoot of Quipu), The Retix
Corporation, NIST, and at least several underway in Italy and
Japan. There are probably others and a number of other
American corporations have discussed building their own. Each
of these must make its own decision in the areas in which X.500
is silent. Quipu is probably the most complete implementation
of X.500 to date. The pilot version has about 20 DUAs in seven
countries with an estimated 20,000 entries total.
現在、イタリアと日本の進行中のユニバーシティ・カレッジロンドン(ISODEを使用するUNIXに関するQuipuプロジェクト)、ブリティッシュコロンビア大学(それら自身の完全なOSIスイートを使用することで基づくUNIX)、MIT(TCPを使用する実験的で、Symbolics Lisp Machineに基づいているLisp)、ウォロンゴンGroup(Quipuの分枝)、Retix社、NIST、および少なくとも数個のような位置で進行しているX.500の少ない数の実現はあります。 たぶん他のものがいます、そして、他の多くのアメリカの会社がそれら自身のを建てるのを議論しました。 それぞれのこれらはX.500が静かである領域でそれ自身の決定をしなければなりません。 結び縄文字はたぶんこれまでのX.500の最も完全な実現です。 パイロットバージョンで、およそ2万のエントリーがある7つの国のおよそ20DUAsが総、になります。
4. Proposed Approach
4. 提案されたアプローチ
The conclusion of this report is that some form of X.500 is the most likely candidate. The reasons for this decision are that it has a rich semantics and will become the international de facto standard. There are, however, serious problems with its incompleteness and with its strict hierarchy. Therefore, in order to explore these and become convinced of its viability, the attendees at the meeting agreed on field trials, as a first stage. Initially, this would include experiments with at least one X.500 implementation (Quipu), Profile to explore a non-hierarchical structure and richer descriptive naming, and DNANS in order to explore some of the incomplete aspects of X.500 for which DNANS has architected solutions.
このレポートの結末はX.500の何らかのフォームが最もありそうな候補であるということです。 この決定の理由は豊かな意味論を持って、国際的なデファクトスタンダードになるということです。 しかしながら、不備とその厳しい階層構造には深刻な問題があります。 したがって、ミーティングにおける出席者はこれらを探検して、生存力で確信するようになるように実地試験に同意しました、第一段階として。 初めは、これは、DNANSが解決策をarchitectedしたX.500の不完全な局面のいくつかを探検するために少なくとも1つのX.500実現(結び縄文字)による実験、非階層構造の、そして、より豊かな描写的である命名について調査するProfile、およびDNANSを含んでいるでしょう。
A three-stage plan, with all three stages beginning coincidentally and as soon as possible, would provide such a service within the NRN. The first stage should be complete in a year, the second in two, and
3ステージのプランはNRNの中で一致して、そして、できるだけ早く始まるすべての3つのステージにそのようなサービスを供給するでしょう。 そして第一段階が1年、2における秒に完全であるべきである。
Sollins [Page 11] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[11ページ]RFC1107
the third in three. Stage 1 would be field trials of three approaches to naming with an emphasis on distinguishing between the specification and a particular implementation of X.500, as well. Stage 2 would be a more complete implementation of a white pages service base on the conclusions from Stage 1. Stage 3 would be widespread deployment of the implementation developed in Stage 2. The planning for Stage 3 is not outlined here in detail, because that plan would be part of the proposed work to be done. If the field trials were to lead to the conclusion that none of the services is adequate, the plan for the remainder of the work would need to be rescheduled.
3における3番目。 ステージ1は仕様を見分けることへの強調とまた、X.500の特定の実現による命名への3つのアプローチの実地試験でしょう。 Stage1からの結論のときにステージ2はホワイトページサービスベースの、より完全な実現でしょう。 ステージ3はStage2で開発された実現の広範囲の展開でしょう。 Stage3のための計画はここに詳細に概説されていません、そのプランが提案されたやるべき仕事の一部でしょう、したがって。 実地試験がサービスのいずれも適切でないという結論に通じることであるなら、余った仕事のためのプランは、時期変更される必要があります。
If the Internet community is to adopt X.500 (or any other standard), it is necessary to make a number of design and management decisions, above and beyond the implementation decisions for the DSA. Since there are a number of such decisions to be resolved, and some of these are significant, the group recommended that this planning and management function should be recognized as a distinct activity.
インターネットコミュニティがX.500(または、いかなる他の規格も)を採用するつもりであるなら、多くのデザインと管理を決定にするのが必要です、DSAのための実現決定を超えて。 決議されるというそのような多くの決定があって、これらの或るものが重要であるので、グループは、この計画と管理機能が異なった活動として認識されるべきであることを勧めました。
4.1. Stage 1: The Field Test
4.1. ステージ1: 実地試験
It was agreed that field trials would be a valuable form in which to explore the issues of building a white pages service for two reasons. First, the software is still in early stages of development or deployment. Some of it is production code, but still first release; the rest is part of research projects. Second, it is important to learn from experience with a limited and sympathetic community. The suggested community was the computer science community, in particular, computer science departments. That will not be the case completely, since the computer science community in general does not use DECnet. Therefore, for experiments with the DNANS, the NASA/DOE community was recommended. They will be using DNANS in any case, as they move to DECnet Phase V.
実地試験が2つの理由でホワイトページサービスを組み込む問題を探る貴重なフォームであるのに同意されました。 まず最初に、まだ開発か展開の初期段階に、ソフトウェアがあります。 それのいくつかが生産コードですが、それでも、1番目はリリースです。 残りは研究計画の一部です。 2番目に、制限されて同情的な共同体と共に経験から学ぶのは重要です。 提案された共同体は特定のコンピュータサイエンス部のコンピュータサイエンス共同体でした。 一般に、コンピュータサイエンス共同体がDECnetを使用しないので、それは完全にそうになるというわけではないでしょう。 したがって、DNANSとの実験において、NASA/DOE共同体はお勧めでした。 DECnet Phase Vに動くとき、どのような場合でも、彼らはDNANSを使用するでしょう。
The twofold purpose of the field trials is to explore differing directory service architectures and to refine the study of X.500 specifically, to distinguish architectural aspects of it from features of a particular implementation of X.500. Initially, the trials would include the Quipu implementation of X.500, Profile, and the DNANS. A second implementation of X.500 should be identified and included as soon as possible. Part of the emphasis of the field trials would be on gathering and maintenance of naming information. To ease this, a single common file format for storage of and access to the naming information and use of a single set of data management tools was recommended, although no particular set was identified. The various directory services would need to be retrofitted to this file format. Such consistency in file format would mean that the services could all be co-resident, sharing files, thus permitting
実地試験の二つの目的は、X.500の特定の実現の特徴とそれの建築局面を区別するために異なった電話番号案内構造を探って、明確にX.500の研究を洗練することです。 初めは、トライアルはX.500、Profile、およびDNANSのQuipu実現を含んでいるでしょう。 X.500の2番目の実現は、できるだけ早く、特定されて、含まれるべきです。 命名情報の集会と維持には実地試験の強調の一部があるでしょう。 これを緩和するために、1セットのデータ管理ツールの命名情報と使用への格納とアクセスのためのただ一つの一般的なファイル形式はお勧めでした、どんな特定のセットも特定されませんでしたが。 様々な電話番号案内は、このファイル形式に改装される必要があるでしょう。 ファイルを共有して、その結果、可能にして、ファイル形式におけるそのような一貫性は、サービスがすべて、コレジデントであるかもしれないことを意味するでしょう。
Sollins [Page 12] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[12ページ]RFC1107
single locations to participate in several parts of the field trials. This, in turn, would allow for direct comparisons.
実地試験の数個の部品に参加する単一の位置。 これは順番に直接比較を考慮するでしょう。
There are a number of issues, which are not addressed in X.500, that would need to be resolved for a large scale deployment such as a white pages for the NRN. In particular, these are: clients of the service; data collection and maintenance; distribution, replication and caching of information; access control, accountability, and information integrity; and support by non-OSI protocols. Each of the name services included in the field trials would include decisions in these areas, albeit different ones. The field trials will allow for evaluation of these different mechanisms.
NRNのためのホワイトページなどの大規模展開のために決議される必要がある多くの問題があります。(問題はX.500に記述されません)。 これらは特に、以下の通りです。 サービスのクライアント。 データ収集と維持。 情報の分配、模写、およびキャッシュ。 コントロール、責任、および情報保全にアクセスしてください。 そして、非OSIプロトコルによるサポート。 異なったものですが、実地試験にサービスというそれぞれの名前を含んでいるのはこれらの領域に決定を含んでいるでしょう。 実地試験はこれらの異なったメカニズムの評価を考慮するでしょう。
There are two other major issues that must also be addressed: functionality and size. Functionality encompasses both the first point of the nature of the interfaces to the service as well as the structure of the namespace (e.g., hierarchy). A discussion of size must include not only the number of entries handled by the service as a whole, but how those entries are distributed and the query and update patterns.
また、記述しなければならない他の2つの大変な問題があります: 機能性とサイズ。 機能性はサービスへのインタフェースの自然の最初のポイントと名前空間(例えば、階層構造)の構造の両方を包含します。 サイズの議論は、全体でサービスにもかかわらず、それらのエントリーがどのように分配されているかによって扱われたエントリーの数と質問だけを含まないで、パターンをアップデートしなければなりません。
In general, all of these issues are tightly coupled, but are separated here for the purposes of understanding the field trials and its potential effectiveness. They would also be the issues that would be the basis for the work done in Stage 2 of the project.
一般に、これらの問題のすべてが、密結合ですが、実地試験とその潜在的有効性を理解する目的のためにここに切り離されます。 また、それらはプロジェクトのStage2で行われた仕事の基礎である問題です。
- Functionality:
- 機能性:
X.500 and DNANS make strong statements about the organization
of the namespace. In both cases, it is a single, absolute
hierarchy with soft links or aliases and attribute-based naming
useful both in searches of subtrees of the hierarchy and for
storing information about the objects in the hierarchy. The
searches are based on logical combinations of attribute values.
Quipu implements the naming structure and search functionality
as specified in X.500. In contrast, Profile, provides a more
general facility that supports any form of relative names, not
just hierarchical, and a small programming language to express
the functions for searching. By including Profile in the field
trials, these more general facilities can be tested.
X.500とDNANSは名前空間の組織に関する歯に衣着せぬ陳述を作ります。 どちらの場合も、それは柔らかいリンクか別名と階層構造の下位木の検索と階層構造で物の情報を格納することの役に立つ属性ベースの命名がある単一の、そして、絶対の階層構造です。 検索は属性値の論理結合に基づいています。 結び縄文字はX.500の指定されるとしての命名構造と検索の機能性を実行します。 対照的に、Profile、探索のために機能を言い表すためにどんなフォームの相対的なちょうど階層的でない名前もサポートするより一般的な施設と小さいプログラミング言語を提供します。 実地試験にProfileを含んでいることによって、これらのより一般的な施設をテストできます。
X.500 specifies that the service is separated into two parts
for implementation of the service, known as the Directory
Service Agent (DSA), and the client, known as the Directory
User Agent (DUA). DUAs can be implemented independently of the
implementation of the white pages service. Quipu, Profile, and
DNANS have taken different approaches to the presentation model
for DUAs, so the three implementations will allow for
X.500は、サービスがディレクトリサービスエージェント(DSA)として知られているサービスの実現とクライアントのために2つの部分に切り離されて、ディレクトリUserエージェント(DUA)として知られていると指定します。 ホワイトページサービスの実現の如何にかかわらずDUAsを実行できます。 結び縄文字、Profile、およびDNANSがプレゼンテーションモデルへの異なるアプローチをDUAsに取ったので、3つの実現が考慮するでしょう。
Sollins [Page 13] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[13ページ]RFC1107
additional experience.
追加経験。
- Size:
- サイズ:
As discussed earlier, a white pages service must be prepared to
handle a minimum of 10**7 entries, although they may be
distributed, and a query rate of hundreds per second. It must
also be prepared to handle much higher peak rates. If the
address lookup that is presently provided by the DNS is also
supported by the white pages service, the query rate will be
much higher. The designers of the field trials must determine
whether or not such usage will be part of the final service and
therefore must be examined in the field trials. If so, caching
may be part of the solution. In addition, the response time
for DUAs must be reasonable for a human sitting at a console.
Furthermore, modifications to the data should occur in
reasonably short periods of time, although this could be
measured in hours.
以前に検討したことであるが、最低10**7エントリーを扱うようにホワイトページサービスを準備しなければなりません、それらは、分配されていて1秒あたりの数百の質問率であるかもしれませんが。 また、はるかに高いピークレートを扱うのも準備していなければなりません。 また、現在DNSによって提供されるアドレスルックアップがホワイトページサービスで支持されると、質問率ははるかに高くなるでしょう。 実地試験のデザイナーをそのような用法が最終的にサービスの一部になるかどうかと決心しなければならなくて、したがって、実地試験で調べなければなりません。 そうだとすれば、キャッシュは解決策の一部であるかもしれません。 さらに、コンソールに座る人間には、DUAsのための応答時間は妥当でなければなりません。 その上、何時間もこれを測定できましたが、データへの変更は適度に短い期間で起こるべきです。
The field trials must allow for experimentation under such
stressful conditions. The environment for testing must have
both large and small nodes, as well as both heavy and light
load querying and situations in which reorganization can be
tested. Such reorganization may be a simple as moving one
piece of the hierarchy to another point and handling naming
conflicts in the new environment. X.500 does not address this
issue, but it will be needed by the NRN.
実地試験はそのようなストレスが多い条件のもとで実験を考慮しなければなりません。 テストするための環境には、大きいものと同様に小さいノードがなければなりません、重くて軽い負荷質問と再編成をテストできる状況の両方と同様に。 そのような再編成はもう1ポイントに階層構造の感動的な1つの断片として簡単で扱っている命名が新しい環境で闘争するということであるかもしれません。 X.500はこの問題を記述しませんが、それはNRNによって必要とされるでしょう。
- Distribution, replication, and caching:
- 分配、模写、およびキャッシュ:
These are areas in which X.500 has very little to say, but a
great deal of work has been done in other distributed, network
naming services, in particular both the DNS and DNANS. There
seems to be general agreement that distribution of naming
services should be done on the basis of nodes in the naming
structure, which also provide the basis for administrative
partitioning. All the naming services described here support
distribution, partitioning of the information for placement on
cooperating servers. Neither X.500 (and therefore Quipu) nor
Profile is prepared to redistribute portions of the namespace,
for reallocation of administrative responsibilities or load
balancing, although this should be possible and DNANS is
prepared to do so. Replication is necessary for accessibility
in a large-scale or global namespace, although again X.500 does
not address this issue. Quipu has taken a stand on this, by
defining master and slave copies of the data; it is similar to,
but not the same as, the approach taken in the DNS. Caching is
barely touched on in X.500 and not at all in Profile, but our
これらはX.500がほとんど言うために持っていない領域ですが、他の分配されたネットワーク命名サービス、特に両方のDNS、およびDNANSで大きな仕事をしました。 命名構造のまた、管理仕切りの基礎を備えるノードに基づいて命名サービスの分配をするべきである一般協定はあるように思えます。 ここで説明されたすべての命名サービスが協力サーバで分配、プレースメントのための情報の仕切りを支持します。 X.500(そして、したがって、Quipu)もProfileも名前空間の部分を再配付するように準備されません、行政責任かロードバランシングの再配分のために、これは可能であるべきです、そして、DNANSはそうするように準備されますが。 X.500は一方この問題を記述しませんが、模写が大規模であるかグローバルな名前空間におけるアクセシビリティに必要です。 結び縄文字はデータのマスターと奴隷コピーを定義することによって、これを立場に立たせました。 それが同様ですが、同じでない、DNSで取られたアプローチ。 しかし、キャッシュがProfileでほとんどX.500と全く触れられる、私たち
Sollins [Page 14] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[14ページ]RFC1107
experience with the DNS indicates that caching is critical to
effective operation of a distributed name service. The DNANS
has an architected solution based on objects in the namespace
as the unit of distribution and replication. Again, the DNANS
solution should be explored in the field test environment.
DNSの経験は、キャッシュが分配された名前サービスの有効な操作に重要であることを示します。 DNANSは分配と模写のユニットとして名前空間でarchitected解決策を物に基づかせています。 一方、DNANS解決策は実地試験環境で探られるべきです。
- Access control, accountability, and integrity:
- コントロール、責任、および保全にアクセスしてください:
Access control and accountability require some degree of
authentication. X.500 supports authentication based on using
an RSA public key algorithm, but does not address issues of
universal registration, nor issues of access control or
accountability themselves. These are left as a local issue,
although depending on the design of the system, they may have
global implications. The problem of integrity of the
information in the name service is nowhere addressed. Profile
also does not address these issues, although it uses
authentication based on UNIX authentication, involving user ids
and passwords. DNANS takes a strong stand on access control,
architecting it in at the level of individual entries. Field
trials will force these issues out into the open.
アクセス管理と責任は認証をいくらかの必要とします。 X.500はRSA公開鍵アルゴリズムを使用することに基づいて認証を支持しますが、どんな普遍的な登録のアドレス問題もアクセス管理か責任の問題自体もしません。 彼らには、システムの設計によりますが、これらはローカルの問題として残されて、グローバルな意味があるかもしれません。 記述されて、サービスという名前の情報の保全の問題がどこにもありません。 ユーザイドとパスワードにかかわって、UNIX認証に基づく認証を使用しますが、プロフィールもこれらの問題を記述しません。 中で個人出場者のレベルでそれをarchitectingして、DNANSはアクセス管理のときに強い態度を取ります。 実地試験はこれらの問題を戸外に追い出すでしょう。
- Structure of the naming tree:
- 命名木の構造:
In the deployment of the DNS, about one year was lost to
arguments about the actual structure of the naming hierarchy.
People form strong opinions about their name, and fight for or
against certain hierarchical structures. The same issue will
arise here, and advanced planning to deal with the problem is
required.
DNSの展開では、およそ1年は命名階層構造の実際の構造の議論に失われました。 人々は階層構造を支持して、または、ある階層構造に対して彼らの名前、および戦いに関する強い意見について決めます。 同じ問題はここに起こるでしょう、そして、問題に対処する高度な計画が必要です。
In this case, the problem is made harder by the fact that the
hierarchy will be global; X.500 is an international standard,
based on the assumption that there is only one example of the
tree, partitioned by country. Probably the American White
Pages Service, at least at its root, will be run by the NIST or
its contractor. We must deal with the problem that in the
short term, various implementations may not interwork, and we
must work with NIST to support the needed services.
この場合、階層構造がグローバルになるという事実は問題をより困難にします。 X.500は世界規格です、国によって仕切られた木に関する1つの例しかないという仮定に基づいて。 たぶん、少なくとも根で、NISTかその契約者がアメリカのホワイトページServiceを走らせるでしょう。 私たちは短期で、様々な実現が織り込まないかもしれない問題に対処しなければなりません、そして、必要なサービスを支持するためにNISTと共に働かなければなりません。
Specific issues that come up related to the naming tree are:
来られて、命名木に関連した特定の問題は以下の通りです。
* How is delegation of control of the tree managed?
For example, who decides what DSA holds what parts
of the tree?
* 木のコントロールの代表団はどのように経営されますか? 例えば、だれが、どんなDSAが木のどんな部分を支えるかを決めますか?
* How is the creation of new parts of the tree
(e.g., an organizational entry) controlled?
* 木(例えば、組織的なエントリー)の新しい部分の創造はどのように制御されますか?
Sollins [Page 15] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[15ページ]RFC1107
- Support for Tree Search:
- 木探索のサポート:
Regardless of the defintion of the white pages service in the
NRN, it will need to interface to the X.500 world. The X.500
naming hierarchy can be expected to become very large, and
guidance is needed for users to help them navigate the tree.
Users need help to find their way to unknown parts of the
namespace. As in other naming services, a feature of X.500 is
that additional entries, aliases (similar to links in file
systems) can be installed to provide an easy path for a user in
one part of the tree to find other interesting parts of the
tree. By establishing a consistent policy for the use of alias
entries, learning how to navigate the tree can be made much
easier for a user. As part of setting up the tree, therefore,
these sorts of policies need to be defined.
NRNでのホワイトページサービスのdefintionにかかわらず、それは、X.500世界に連結する必要があるでしょう。 X.500命名階層構造が非常に大きくなると予想できて、ユーザが、彼らが木にナビゲートするのを助けるのに指導が、必要です。 ユーザは、名前空間の未知の部分に届くように助けを必要とします。 他の命名サービスでは、X.500の特徴がその追加エントリーであるので、木の一部のユーザが木の他のおもしろい部分を見つけるように安易な道を提供するために、別名(ファイルシステムのリンクと同様の)をインストールできます。 別名エントリーの使用のための一貫した方針を確立することによって、木にナビゲートする方法を学ぶのをユーザにとってはるかに簡単にすることができます。 したがって、木をセットアップする一部として、これらの種類の方針は、定義される必要があります。
- Definition of database structures:
- データベース構造の定義:
There are a number of data structures that need to be defined
as part of setting up each of the services. These include, for
example, the types of information stored for the entry about a
person. This information must be stored in the servers, and
passed to the clients. These structures must thus be
specified. In other words, the schema defining attributes and
object classes must be specified for the NRN.
それぞれのサービスをセットアップする一部と定義される必要がある多くのデータ構造があります。 これらは例えば人に関してエントリーに格納された情報のタイプを含んでいます。 この情報をサーバに格納されて、クライアントに渡さなければなりません。 その結果、これらの構造を指定しなければなりません。 言い換えれば、属性と物のクラスを定義する図式をNRNに指定しなければなりません。
- Load balancing:
- ロードバランシング:
The dynamic performance of the Internet system must be
estimated, so that the servers can be sized properly.
Especially at the root of the tree, the query rate must be
estimated carefully. Caching will have a strong influence on
this. Therefore, traffic patterns are very dependent on the
details of implementation.
適切にサーバを大きさで分けることができるようにインターネット・システムの動的パフォーマンスを見積もらなければなりません。 特に木の根では、慎重に質問率を見積もらなければなりません。 キャッシュはこれに強い影響力を持つでしょう。 したがって、トラフィック・パターンは実現の詳細に非常に依存しています。
- Supporting multiple protocol suites:
- 倍数を支持して、スイートについて議定書の中で述べてください:
At least three protocol suites are and will continue to be used
in the NRN environment. They are DECnet, TCP/IP, and the OSI
suite of protocols. Since the white pages service is at the
applications layer, it must run on top of at least these three
protocol suites. It is important to understand the
requirements of the white pages service for its transport
protocols.
少なくとも3つのプロトコル群が、あって、NRN環境で使用され続けるでしょう。 それらは、プロトコルのDECnetと、TCP/IPと、OSIスイートです。 ホワイトページサービスがアプリケーション層にあるので、それは少なくともこれらの上で3つのプロトコル群を動かさなければなりません。 トランスポート・プロトコルのためにホワイトページサービスの要件を理解しているのは重要です。
By addressing these issues within the field trials, we will be preparing for the further development of Stage 2. A result of Stage 1 will be a detailed specification of the white pages service,
実地試験の中にこれらの問題を記述することによって、私たちはStage2のさらなる開発の用意をするでしょう。 Stage1の結果はホワイトページサービスの仕様詳細になるでしょう。
Sollins [Page 16] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[16ページ]RFC1107
possibly an extension to or modification of X.500. This should dovetail with the activities specifying the details required for implementation (known as "profiling") by the NIST Workshop for Implementors of OSI. In addition, in order to run the field trial, the information capture problem must be addressed, providing the some of the preliminary work of Stage 3.
ことによるとX.500の拡大か変更。 活動が実現(「プロフィール」として、知られている)のためにNIST Workshopによって必要とされた詳細をOSIのImplementorsに指定している状態で、これは接合するべきです。 さらに、実地試験を走らせるために情報捕獲問題を記述しなければなりません、提供している、Stage3の準備作業のいくつか
4.2. Stage 2: Implementation
4.2. ステージ2: 実現
If the evaluation of Stage 1 concludes that some form of X.500 is acceptable, at least one of the two X.500 implementations included in the field trials should provide the basis for a production quality implementation of X.500 for general deployment. Further work will likely be needed on the basis of the evaluations of the field trials. A production version of an implementation requires both reliable servers as well as a variety of clients to provide differing interfaces on a mixture of hardware and operating systems.
Stage1の評価が、X.500の何らかのフォームが許容していると結論を下すなら、少なくとも実地試験に含まれていた2つのX.500実現の1つはX.500の生産品質実現の基礎を一般的な展開に提供するべきです。 さらなる仕事が実地試験の評価に基づいておそらく必要でしょう。 実現の生産バージョンは、ハードウェアとオペレーティングシステムの混合物の上に異なったインタフェースを提供するために高信頼のサーバとさまざまなクライアントの両方を必要とします。
In addition, especially because of the inclusion of Profile and DNANS, a variety of different DUAs will be explored by definition. Further investigation into the DUAs should begin in parallel with or in conjunction with the field trials. There should be distinct DUAs for both programs and humans. In addition, there probably should be human-user DUAs geared both to the naive user with simple usage patterns and the more sophisticated user who wants to perform complex queries. It is also important to design DUAs that do not require a great deal of computing power for the small machines still in use in great quantity. Much of the user community may not be able to afford expensive equipment upgrades.
さらに、そして、特にProfileとDNANSの包含のために、さまざまな異なったDUAsが定義上探検されるでしょう。 DUAsへのさらなる調査は実地試験か実地試験に関連して始まるべきです。 プログラムと人間の両方のための異なったDUAsがあるはずです。 さらに、ナイーブなユーザにともに適合する人間のユーザDUAsがたぶん簡単な用法パターンと複雑な質問を実行したがっているより洗練されたユーザと共にいるはずです。 また、かなりの量でまだ使用中の小さいマシンのために多くのコンピューティングパワーを必要としないDUAsを設計するのも重要です。 ユーザーコミュニティの大部分は金のかかる装置アップグレードを提供できないかもしれません。
Assuming that X.500 is deemed to be the specification of the service, the field trials will address many issues not included in X.500 as of 1989. Since it is important for the NRN to support interconnectivity beyond its own bounds, it behooves us to feed what has been learned back into the standards activities. This was identified as a separate activity because of the intellectual as well as time commitment that must be made to do this effectively.
X.500がサービスの仕様であると考えられると仮定すると、実地試験は1989年の時点でX.500に含まれていなかった多くの問題を記述するでしょう。 NRNがそれ自身の領域を超えて相互接続性を支持するのが、重要であるので、それは規格活動に学習されたことを入れ返すために私たちに当然です。 それをしなければならない時間委任と同様にインテリによる別々の活動が有効にこれをするとき、これは特定されました。
4.3. Stage 3: Deployment
4.3. ステージ3: 展開
A plan is required to develop the schedule of service introduction, and to co-ordinate the deployment as it is undertaken. This includes mediating service problems, a significant task in its own right.
プランがサービス序論のスケジュールを開発するのに必要です、そして、それとして展開を調整するのは引き受けられます。 これは、それ自体でサービス問題、重要なタスクを伝えるのを含んでいます。
The details of deployment were not discussed at the meeting, although several of the seeds of deployment lie in Stages 1 and 2. The first of these is the capture and management of information. The second is DUA development. Both of these must be included Stage 1 in order to
ミーティングで展開の詳細について議論しませんでした、展開のいくつかの種子がStages1と2にありますが。 これらの1番目は、捕獲と情報管理です。 2番目はDUA開発です。 これらの両方が含まれているStage1であるに違いない。
Sollins [Page 17] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[17ページ]RFC1107
support a usable environment for the trials. In addition, the information that will have been captured in Stage 1 could be printed producing a hard copy of the white pages information. That could be distributed to all scientists and engineers involved; such a project would provide an early white pages service. During the initial periods of both Stages 1 and 2, planning for deployment would also have to proceed, in order to provide a smooth transition to this third stage in the project.
トライアルのために使用可能な環境を支持してください。 さらに、ホワイトページ情報のハードコピーを生産しながら、Stage1で得られてしまうだろう情報は印刷できました。 科学者と技術者がかかわったすべてにそれを分配できました。 そのようなプロジェクトは早めのホワイトページサービスを提供するでしょう。 また、両方のStages1と2の原初期の間、展開は計画を立てなければならなくしかけるでしょう、プロジェクトでこの3番目のステージにスムーズな移行を供給するために。
5. Conclusion
5. 結論
The consensus of the meeting was that following a path that included X.500 was both the correct direction and feasible, although X.500 needs further elaboration. There were several important items for further study. The first is that there are many issues left unresolved in X.500 that have been addressed in other naming services, and the NRN should take advantage of the solutions in those other services. The second is that there was some reservation about certain features of X.500, especially in the area of the imposition of a hierarchy for naming, and only limited flexibility in descriptive naming. The participants believe that is important understand whether X.500 provides enough mechanisms to work around such problems by finding a higher common ground that includes the best features of all the naming services included in the field trials. The final issue with respect to X.500 was that there was agreement that X.500 will be an accepted and utilized standard in at least part of the networked community and therefore interfacing to it will be necessary. Given that, and the other reasons for choosing X.500, the consensus was that the plan described above would bring the NRN and its community of users a useful and usable white pages service.
ミーティングのコンセンサスはX.500を含んでいた小道をたどるのが両方の正しい指示であって可能であったということでした、X.500は一層の労作を必要としますが。 さらなる研究へのいくつかの重要案件がありました。 1番目は多くの問題が他の命名サービスで記述されたX.500で未定のままで残っているということです、そして、NRNはそれらの他のサービスにおける解決策を利用するはずです。 2番目はX.500のある特徴に関して何らかの予約があったということです、特に命名のための階層構造の賦課の領域、および描写的である命名における限定変動相場だけで。 関係者は、それが重要であると信じています。X.500が実地試験にすべての命名サービスの最も良い特徴を含んでいるより高い共通基盤を見つけるのによるそのような問題を含んでいて、問題に取りかかることができるくらいのメカニズムを提供するかどうか理解してください。 X.500に関する最終的な問題はX.500が受け入れられて利用された規格になるという協定が少なくともネットワーク・コミュニティの一部にあったということでした、そして、したがって、それに連結するのが必要でしょう。 それ、およびX.500を選ぶ他の理由を考えて、コンセンサスは上で説明されたプランが役に立って使用可能なホワイトページサービスをNRNとそのユーザの共同体にもたらすだろうということでした。
References
参照
1. Austein, R., "The Internet Domain Name System", Proceedings of
USA Decus, Massachusetts Institute Technology/LCS, 1987.
1. Austein、1987のR.、米国Decus、マサチューセッツの議事が設ける「インターネットドメインネームシステム」技術/LCS
2. Demers, A., D. Greene, C. Hauser, W. Irish, J. Larson, S.
Shenker, H. Sturgis, D. Swinehart, and D. Terry, "Epidemic
algorithms for replicated database maintenance", Proceedings of
the 6th Symposium on Principles of Distributed Computing, ACM,
Vancouver, B.C., Canada, pp. 12-21, August 1987.
2. Distributed Computingのプリンシプルズの第6Symposium、ACM、バンクーバーB.C.のDemersとA.とD.グリーンとC.ハウザーとW.アイルランド人とJ.ラーソンとS.ShenkerとH.スタージス、D.SwinehartとD.テリー、「模写されたデータベースメンテナンスのための流行のアルゴリズム」Proceedings、カナダのページ 12-21と、1987年8月。
3. Digital Equipment Corporation, "DNA Naming Service Functional
Specification Version 1.0.1", Order number: EK-DNANS-FS-001,
Digital Equipment Corporation, 1988.
3. DEC、「何0.1インチも、オーダーが付番するDNAの名前付けサービスの機能的な仕様バージョン1.0:」 EK-DNANS-FS-001、ディジタルイクイップメント社、1988。
4. International Organization for Standardization, "Information
4. 国際標準化機構、「情報」
Sollins [Page 18] RFC 1107 A Plan for Internet Directory Services July 1989
インターネットディレクトリサービス1989年7月のための1プランあたりSollins[18ページ]RFC1107
Processing Systems - Open Systems Interconnection - The
Directory", Draft Standard (In 8 parts), Also CCITT
Recommendation X.500, 1988.
「処理Systems--オープン・システム・インターコネクション--ディレクトリ」、Draft Standard(8つの部品の)、Also CCITT Recommendation X.500、1988。
5. Lampson, B., "Desiging a Global Name Service," Proceedings of the
5th Symposium on Principles of Distribute Computing, ACM,
Calgary, Alberta, Canada, pp. 1-10, August 1986.
5. ランプソン、B.、「Desiging aグローバル名サービス」、Distribute Computingのプリンシプルズの第5SymposiumのProceedings、ACM、カルガリー、アルバータカナダのページ 1-10と、1986年8月。
6. Mockapetris, P., "Domain Names - Concept and Facilities", RFC
1034, USC/Information Sciences Institute, November 1987.
6. Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、科学が設けるUSC/情報、11月1987日
7. Oppen, D., and Y. Dalal, "The Clearinghouse: A Decentralized
Agent for Locating Named Objects in a Distributed Environment",
Tech. Rept. OPD-T8103, Xerox Corporation, Palo Alto, CA, October
1981.
7. Oppen、D.、およびY.Dalal、「情報センター:」 「分散環境で命名されたオブジェクトの場所を見つけるための分散エージェント」、技術者。 Rept。 OPD-T8103、ゼロックス社、パロアルト(カリフォルニア)1981年10月。
8. Peterson, L., "Profile: A System for Naming Internet Resources",
Tech. Rept. 20, Department of Computer Science, University of
Arizona, June 1987.
8. ピーターソン、L.は「以下の輪郭を描きます」。 「インターネット資料を命名するシステム」、技術者。 Rept。 20 コンピュータサイエンス学部、アリゾナ大学、1987年6月。
Author's Address
作者のアドレス
Karen R. Sollins
Massachusetts Institute of Technology
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
技術の正方形のケンブリッジ、カレンR.Sollinsマサチューセッツ工科大学コンピュータ科学研究所545MA02139-1986
Phone: (617) 253-6006
以下に電話をしてください。 (617) 253-6006
EMail: SOLLINS@XX.LCS.MIT.EDU
メール: SOLLINS@XX.LCS.MIT.EDU
Sollins [Page 19]
Sollins[19ページ]
一覧
スポンサーリンク
