RFC1430 日本語訳
1430 A Strategic Plan for Deploying an Internet X.500 DirectoryService. S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. February 1993. (Format: TXT=47587 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Hardcastle-Kille
Request for Comments: 1430 ISODE-Consortium
E. Huizer
SURFnet bv
V. Cerf
Corporation for National Research Initiatives
R. Hobby
University of California, Davis
S. Kent
Bolt, Beranek and Newman
February 1993
Hardcastle-Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: National Research Initiatives R.Hobbyカリフォルニア大学のための1430ISODE-共同体E.Huizer SURFnet bv V.サーフ社、デイヴィス・S.ケントBolt、Beranek、およびニューマン1993年2月
A Strategic Plan for Deploying an
Internet X.500 Directory Service
インターネット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
要約
There are a number of reasons why a new Internet Directory Service is required. This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. It then describes in more detail the initial steps which need to be taken in order to achieve these goals, and how work already undertaken by Internet Engineering Task Force Working Groups (IETF WGs) is working towards these goals.
新しいインターネットディレクトリサービスが必要である多くの理由があります。 このドキュメントはインターネットでディレクトリサービスを配布するための総合的な戦略を説明します、OSI X.500ディレクトリサービスに基づいて。 そして、それはさらに詳細にこれらの目標を達成するために取られる必要がある初期段階と、インターネット・エンジニアリング・タスク・フォースWorking Groups(IETF WGs)によって既に引き受けられた仕事がどうこれらの目標をめざして努力するかであるかを説明します。
Table of Contents
目次
1. REQUIREMENTS 2 2. SUMMARY OF SOLUTION 3 3. INFORMATION FRAMEWORK 3 3.1 The Technical Model 3 3.2 Extending the Technical Model 4 3.3 The Operational Model 5 4. NAME ASSIGNMENT 5 5. DIRECTORY INFRASTRUCTURE 6 5.1 Short Term Requirements 7 5.2 Medium Term Requirements 9 5.3 Long Term Requirements 9 6. DATAMANAGEMENT 9 6.1 Legal Issues 10 7. TECHNICAL ISSUES 10
1. 要件2 2。 ソリューション3 3の概要。 情報フレームワーク3 3.1 技術的なモデル4 3.3にオペレーショナル・モデル5 4を広げる技術的なモデル3 3.2 課題5 5を命名してください。 ディレクトリインフラストラクチャ6 5.1の短期間要件7 5.2の中期要件9 5.3の長期要件9 6。 DATAMANAGEMENT9 6.1の法律問題10 7。 専門的な問題10
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 1] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[1ページ]RFC1430X.500戦略1993年2月
7.1 Schema 11 7.2 Use on the Internet 11 7.3 Replication of Knowledge and Data 12 7.4 Presentation of Directory Names 13 7.5 DSA Naming and MD Structure 13 8. SECURITY 13 8.1 Directory Provision of Authentication 14 8.2 Directory Security 15 9. RELATION TO DNS 16 10. EXTERNAL CONNECTIONS 16 11. REFERENCES 17 12. Security Considerations 19 13. Authors' Addresses 20
7.1図式11 7.2がインターネットで使用する、11、7.3模写、知識とデータ、12、7.4プレゼンテーション、ディレクトリ名13 7.5のDSA命名とMD構造、13、8 認証14 8.2ディレクトリセキュリティ15 9のセキュリティ13 8.1ディレクトリ支給。 DNS16 10との関係。 外部のコネクションズ16 11。 参照17 12。 セキュリティ問題19 13。 作者のアドレス20
1. REQUIREMENTS
1. 要件
There is substantial interest in establishing a new Directory Service on the Internet. In the short term, there is pressure to establish two new services:
インターネットで新しいディレクトリサービスを確立することへのかなりの関心があります。 短期で、2つの新種業務を確立する圧力があります:
- White Pages lookup of users;
- ユーザの白いページルックアップ。
- Support for X.509 Authentication for a range of applications in
particular for Privacy Enhanced mail [Lin89].
- 特にPrivacy Enhancedメール[Lin89]のさまざまなアプリケーションのためのX.509 Authenticationのために、サポートします。
In the medium term, there are likely to be many requirements for Directory Services, including:
中期で、である:ディレクトリサービスのための多くの要件がありそうです。
- General resource lookup, for information ranging from committee
structures to bibliographic data;
- 委員会の構造から図書目録のデータまで及ぶ情報のための一般リソースルックアップ。
- Support of management of the Internet infrastructure, and
integration of configuration information into the higher level
directory;
- インターネット基盤の管理のサポート、および、より高い平らなディレクトリへの設定情報の統合。
- Support of applications on the Internet. For example:
- インターネットにおけるアプリケーションのサポート。 例えば:
o Electronic distribution lists;
o Capability information on advanced user agents;
o Location of files and archive services.
o 電子発送先リスト。 o アドバンスド・ユーザーエージェントの能力情報。 o ファイルの、そして、アーカイブサービスの位置。
- Support for Mail Handling Systems; Be they RFC-822 based or X.400
based (IETF MHS-DS WG), e.g.,:
- メール取り扱いには、システムをサポートしてください。 それらになってください。基づくRFC-822かX.400が例えば(IETF MHS-DS WG)を基礎づけました:
o Support for routing;
o Info on User agent capabilities; essential for a usage of
Multimedia mail like MIME (Multipurpose Internet Mail
Extensions).
o ルーティングのサポート。 o Userエージェント能力に関するインフォメーション。 Multimediaメールの用法において、MIME(マルチパーパスインターネットメールエクステンション)のように、不可欠です。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 2] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[2ページ]RFC1430X.500戦略1993年2月
For the longer term, more sophisticated usages of X.500 are possible extending it into a useful and fast yellow pages service.
より長い期間のときに、X.500の、より高度な使用法は、役に立って速い職業別広告欄サービスにそれを広げながら、可能です。
2. SUMMARY OF SOLUTION
2. ソリューションの概要
In principle, the current Internet Domain Name System (DNS) could be used for many of these functions, with appropriate extensions. However, it is suggested that a higher level of directory service is needed. It is proposed to establish an Internet Directory Service based on X.500. This provides appropriate functionality for the services envisaged and gives flexibility for future extension. This extension could be achieved either by tracking the evolution of the OSI Standard or by work specific to the Internet. In practice, it is likely to be a mixture of both.
原則として、これらの機能の多くに、適切な拡大で現在のインターネットドメインネームシステム(DNS)を使用できました。 しかしながら、より高いレベルのディレクトリサービスが必要であることが提案されます。 それは、X.500に基づくインターネットディレクトリサービスを証明するために提案されます。 これは、適切な機能性を考えられたサービスに提供して、今後の拡大のために柔軟性を与えます。 OSI Standardの発展を追跡するか、インターネットに特定の仕事でこの拡大を達成できるでしょう。 実際には、それは両方の混合物である傾向があります。
By deploying X.500 in some form on the Internet, a truly global and universal Directory Service can be built that will provide Internet users with fast access to all kinds of data. The X.500 Directory Service in this case may range from a simple white pages service (information on people and services) to coupling various existing databases and information repositories in a universal way.
インターネットの何らかのフォームでX.500を配布することによって、すべての種類のデータへの速いアクセスをインターネットユーザに提供する本当にグローバルで普遍的なディレクトリサービスは組み込むことができます。 この場合、X.500ディレクトリサービスは普遍的な方法で様々な既存のデータベースと情報倉庫を結合することに対する簡単なホワイトページサービス(人々とサービスの情報)から変化するかもしれません。
Currently, several different but cooperating X.500 Directory Services pilots are taking place on the Internet. These pilots form an important base for experimenting with this new service. Starting with these pilots, with the X.500 products arriving on the market today, and given sufficient funding for the central services described in this paper an operational X.500 Directory Service can be deployed.
現在、数人の異なりましたが、協力関係を持っているX.500ディレクトリサービスのパイロットがインターネットで行われています。 これらのパイロットはこの新しいサービスを実験するための重要なベースを形成します。 これらのパイロットから始めて、X.500製品が今日、市場に出回って、主要なサービスのための与えられた十分な基金がこの紙で説明されている状態で、操作上のX.500ディレクトリサービスを配布することができます。
The final goal of the strategy described in this paper is to deploy a fully operational Directory Service on the Internet, providing the functions mentioned in the previous section.
この紙で説明された戦略の究極の目標はインターネットで完全に操作上のディレクトリサービスを配布することです、前項で言及された機能を提供して。
3. INFORMATION FRAMEWORK
3. 情報フレームワーク
The most critical aspect of the Directory Service is to establish an Internet Information Framework. When establishing a sophisticated distributed directory with a coherent information framework, it involves substantial effort to map data onto this framework. This effort is an operational effort and far outweighs the technical effort of establishing servers and user agents.
ディレクトリサービスの最もきわどい局面はインターネット情報Frameworkを設立することです。 一貫性を持っている情報フレームワークで高性能の分配されたディレクトリを確立するとき、それは、このフレームワークにデータを写像するためにかなりの取り組みにかかわります。 この取り組みは遠くに操作上の取り組みです。サーバとユーザエージェントを確立する技術的な取り組みを重いです。
3.1 The Technical Model
3.1 技術的なモデル
By choosing the X.500 model as a basis for the information framework, it will also be part of a (future) global information framework. The key aspects of this model are:
また、情報フレームワークの基礎としてX.500モデルを選ぶことによって、それは(将来)のグローバルな情報フレームワークの一部になるでしょう。 このモデルの特徴は以下の通りです。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 3] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[3ページ]RFC1430X.500戦略1993年2月
- A hierarchical navigational system that couples distributed
databases (of various kinds), which allows for management of the
data by the organization/person responsible for the data;
- 分散データベース(様々な種類の)を結合して、データに責任がある組織/人によるデータの管理を考慮する階層的なナビゲーション上のシステム。
- Each object in this information structure (called the Directory
Information Tree, DIT) is represented as an entry;
- この情報構造(ディレクトリを情報Tree、DITと呼ぶ)の各オブジェクトはエントリーとして表されます。
- Objects are typed by an "object class", which permits multiple
inheritance;
- オブジェクトは複数の継承を可能にする「オブジェクトのクラス」によってタイプされます。
- An object is described by a set of attributes;
- オブジェクトは1セットの属性によって説明されます。
- Each attribute is typed. Attribute types are hierarchical;
- 各属性はタイプされます。 属性タイプは階層的です。
- Each attribute type has an associated attribute syntax, which may
be generic or shared with other attributes (e.g., Integer Syntax;
Distinguished name Syntax); This allows for representation of
simple attributes (e.g., strings or bitmaps) or complex ones with
detailed structures.
- 各属性タイプは、ジェネリックであるかもしれない関連属性構文を持っていたか、または他の属性(例えば、Integer Syntax; 分類名Syntax)と共有しました。 これは詳細な構造がある簡単な属性(例えば、ストリングかビットマップ)か複雑なものの表現を考慮します。
- Each entry has an unambiguous and unique global name;
- 各エントリーには、明白でユニークなグローバル名があります。
- Alternate hierarchies may be built by use of aliases or pointers of
distinguished name syntax.
- 代替の階層構造は別名の使用か分類名構文の指針によって築き上げられるかもしれません。
This framework allows for representation of basic objects such as users within organizations. It is also highly extensible, and so can be used for a range of other applications.
このフレームワークは組織の中のユーザなどの基本的なオブジェクトの表現を考慮します。 また、非常に広げることができるので、他のさまざまなアプリケーションにそれを使用できます。
3.2 Extending the Technical Model
3.2 技術的なモデルを広げること。
In the longer term, the model could be extended to deal with a number of other requirements which potentially must be met by an Internet Directory Service. Possible extensions include:
より長い期間で、インターネットディレクトリサービスで潜在的に満たさなければならない他の多くの必要条件に対処するためにモデルを広げることができるでしょう。 可能な拡大は:
- Support of ordered attributes (needed by some applications such as
message storage);
- 命令された属性(メッセージストレージなどのいくつかの応用で、必要である)のサポート。
- Extensions to allow unification with management information,
associated with SNMP (Simple Network Management Protocol) [CFSD90]
or other management protocols;
- 経営情報がある統一を許す拡大、SNMPに関連している(簡単なNetwork Managementプロトコル)[CFSD90]または他の管理プロトコル。
- Handling of non-hierarchical data in a better manner for searching
and retrieval, whilst retaining the basic hierarchy for management
purposes. This is essentially building a general purpose resource
location service on top of the basic infrastructure. It will need
work on the information model, and not just the access protocols.
- 管理目的のための基本的な階層構造を保有している間の探すのと検索のための、より良い方法における非階層データの取り扱い。 これは基本的なインフラストラクチャの上で本質的には汎用のリソース位置のサービスを組み込んでいます。 それはアクセス・プロトコルだけではなく、情報モデルへの作業を必要とするでしょう。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 4] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[4ページ]RFC1430X.500戦略1993年2月
It is noted that although X.500 may not provide the ultimate solution to information retrieval, it has good potential for solving a lot of information service related problems.
X.500が情報検索の根本的な解決を提供しないかもしれませんが、それにはサービスが問題を関係づけたという多くの情報を解決する良い可能性があることに注意されます。
3.3 The Operational Model
3.3 オペレーショナル・モデル
To make the Directory Service with a coherent information framework really operational requires a lot of effort. The most probable operational model is one where larger organizations on the Internet maintain their part of the DIT on their own DSA (Directory System Agent). Smaller organizations will "rent" DSA space from regional networks or other service providers. Together these DSAs will form the Internet Directory Service Infrastructure. To couple the various parts of the DIT that are contained on these Internet DSAs, a special DSA containing the Root for the naming hierarchy within the DIT has to be established and maintained.
一貫性を持っている情報フレームワークが本当に操作上でディレクトリサービスをするのは多くの取り組みを必要とします。 最もありえそうなオペレーショナル・モデルはインターネットにおけるより大きい組織がそれらのそれら自身のDSA(ディレクトリSystemエージェント)の上のDITの部分を維持するものです。 より小さい組織はスペースを地域ネットワークか他のサービスプロバイダーからDSAに「賃借するでしょう」。 これらのDSAsはインターネットディレクトリサービスInfrastructureを一緒に、形成するでしょう。 DITの中に命名階層構造のためのRootを含む特別なDSAは、これらのインターネットDSAsに含まれているDITの様々な部分を結合するために、設立されて、維持されなければなりません。
The following tasks can be foreseen:
以下のタスクについて見通すことができます:
- Defining the naming hierarchy; See section 4. - Creating the Directory Infrastructure; See section 5. - Getting the Data into the directory; and - Managing the data in the Directory. See section 6.
- 命名階層構造を定義します。 セクション4を見てください。 - ディレクトリインフラストラクチャを作成します。 セクション5を見てください。 - Dataをディレクトリに手に入れます。 そして、--ディレクトリにおけるデータを管理します。 セクション6を見てください。
4. NAME ASSIGNMENT
4. 名前課題
In order to deploy the Internet Directory Service, it is important to define how the naming hierarchy will be structured. Although the basic model suggests a simple monolithic "database" containing all of the Internet's information infrastructure, with a namespace divided along geographic boundaries, this may not be the definite model that turns out to be the most appropriate to the Internet. Different models may evolve according to the needs of the Internet and the applications used on the Internet (i.e., some parts of the DIT may be assigned at the root for the Internet). Below this one can envisage several loosely coupled namespaces each with their own area of applicability. This should be handled as a part of the general operation of a directory service. An example of this might be assignment of a representation of the Domain Namespace under the root of the DIT. This is further discussed in [BHK91a].
インターネットディレクトリサービスを配布するために、命名階層構造がどう構造化されるかを定義するのは重要です。 インターネットの情報インフラストラクチャのすべてを含んで、基本型は簡単な一枚岩的な「データベース」を勧めますが、これは名前空間が地理的な境界に沿って分割されている、インターネットに最も適切なものであることを判明する明確なモデルでないかもしれません。 インターネットの必要性とインターネットで使用されるアプリケーションに従って、異なったモデルは発展するかもしれません(DITのすなわちいくつかの部分が根でインターネットに割り当てられるかもしれません)。 この人はそれら自身の適用性の領域でそれぞれいくつかの緩く結合した名前空間を考えることができます。 これはディレクトリサービスの一般的な操作の一部として扱われるべきです。 この例はDITの根の下におけるDomain Namespaceの表現の課題であるかもしれません。 [BHK91a]でさらにこれについて議論します。
However, the core DIT information will be nationally assigned. The parts of the DIT below country level will be managed differently in each country. In many countries, registration authorities will be established according to the OSI Standard [ISO]. This has been done in some countries by the national ISO member body representative (for example in the UK by BSI).
しかしながら、コアDIT情報は全国的に割り当てられるでしょう。 国のレベルの下におけるDITの部分は各国で異なって管理されるでしょう。 多くの国に、OSI Standard[ISO]によると、登録局は設立されるでしょう。 これがいくつかの国で国家のISOメンバーボディー代表(例えば、BSIによるイギリスの)によって行われました。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 5] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[5ページ]RFC1430X.500戦略1993年2月
The lower parts of the hierarchy will, in general, be delegated to organizations who will have control over Name Assignment in that part of the tree. There is no reason to mandate how to assign this hierarchy, although it is appropriate to give guidelines. Proposed solutions to assignment of namespace are given in [BHK92].
一般に、木のその部分でName Assignmentを管理する組織へ階層構造の下部を代表として派遣するでしょう。 ガイドラインを与えるのが適切ですが、どうこの階層構造を割り当てるかを強制する理由が全くありません。 [BHK92]で名前空間の課題への提案された解決を与えます。
In North America, there is an alternative approach being developed by the North American Directory Forum (NADF), which leverages existing registration mechanisms [For91]. It is not yet clear what form a final North American Directory Service will take. It is expected that similar initiatives will be taken in other places, such as Europe. For the Internet, the Internet Society (ISOC) has been suggested as a possible Naming Authority.
北アメリカに、北米のディレクトリForum(NADF)によって開発される代替的アプローチがあります。Forumは既存の登録がメカニズム[For91]であると利用します。 最終的な北米のディレクトリサービスがどんな形を取るかは、まだ明確ではありません。 同様のイニシアチブがヨーロッパなどの他の場所で取られると予想されます。 インターネットにおいて、インターネット協会(ISOC)は可能なNaming Authorityとして示されました。
A discussion of the main issues involved with representing the Real World in the Directory Service is part of the work undertaken by the IETF OSI DS Working Group.
ディレクトリサービスでレアルWorldを表すのにかかわる本題の議論はIETF OSI DS作業部会によって引き受けられた仕事の一部です。
The core of the Internet Directory will therefore come to exist of a country based structure with different national naming schemes below the countries. It is clearly desirable that the Internet Directory Service follows any evolving national and international hierarchies. However, this should not be allowed to cause undue delay. The strategy proposed is to proceed with name assignment as needed, and to establish interim registration authorities where necessary, taking practical steps to be aligned with emerging national authorities wherever possible.
したがって、インターネットディレクトリのコアは国の下に異なった国家の命名体系がある状態で国に基づいている構造が存在するようになるでしょう。 インターネットディレクトリサービスが国家的、そして、国際的な階層構造を発展しながらいずれにも続くのは、明確に望ましいです。 しかしながら、これは不当な遅延を引き起こすことができないべきです。 提案された戦略は、必要に応じて名前課題を続けて、必要であるところに当座の登録局を設立することです、国内当局としてどこでも、可能であるところに現れるのに並べられるために実用的な方法を取って。
It is suggested that the Internet Directory Service does two things:
インターネットディレクトリサービスが2つのことをすることが提案されます:
First, each national part of the Internet DIT namespace should be delegated to an appropriate organization, which will usually be in the country of question. Second, the delegated organization should assign names for that country as part of the Internet Directory Service. This should be done in a manner which is appropriately aligned with any emerging local or national service, but does not unduly delay the deployment of the Internet Directory Service. For most countries, this will fit in as a natural evolution of the early directory piloting, where operators of pilots have acted as interim name registration authorities.
まず最初に、インターネットDIT名前空間のそれぞれの国家の部分を適切な組織へ代表として派遣するべきです。(通常、それは、質問の国にあるでしょう)。 2番目に、代表として派遣された組織はインターネットディレクトリサービスの一部としてその国に名前を配属するべきです。 これは、どんな現れも地方で適切に並べられる方法か徴兵でするべきですが、インターネットディレクトリサービスの展開を過度に遅らせません。 ほとんどの国に関しては、これは早いディレクトリ操縦の自然な発展として適合するでしょう、パイロットのオペレータが当座の名前登録局として務めたところで。
5. DIRECTORY INFRASTRUCTURE
5. ディレクトリインフラストラクチャ
To provide access to the Internet Directory Service, an infrastructure has to be built. Although the technical components of an X.500 infrastructure are clear: DSAs (that hold the actual data) and DUAs (that allow users and applications to access the data), a lot more is needed for deployment of an Internet Directory Service.
インターネットディレクトリサービスへのアクセスを提供するために、インフラストラクチャは築き上げられなければなりません。 X.500インフラストラクチャの技術的要素は明確ですが: DSAs(それは実際のデータを保持する)とDUAs(それで、ユーザとアプリケーションはデータにアクセスできる)、さらにいろいろな事がインターネットディレクトリサービスの展開に必要です。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 6] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[6ページ]RFC1430X.500戦略1993年2月
The Integrated Directory Services (IDS) Working Group of the IETF is playing a key role in solving most of the issues that are related to the building of an appropriate infrastructure.
IETFのIntegratedディレクトリサービス(IDS)作業部会は適切なインフラストラクチャのビルに関連する問題の大部分を解決する際に重要な役割を果たしています。
Many of the issues cited in this section have come forward out of interim pilots that have been established on the Internet:
このセクションで引用される問題の多くがインターネットに設立された当座のパイロットから進み出ました:
PSI White Pages Pilot
This is a pilot service which is operating X.500 on the Internet.
In many ways it is operating as an Internet wide pilot.
PSIホワイトページPilot ThisはインターネットのX.500を操作しているパイロットサービスです。 様々な意味で、それはインターネットの広いパイロットとして作動しています。
FOX
Fielding Operational X.500, a project to explore the development
and interoperability of X.500 implementations.
FOX Fielding Operational X.500、X.500実現の開発と相互運用性について調査するプロジェクト。
Paradise (Piloting A ReseArch DIrectory Service in Europe)
This project has been providing the necessary glue to hold the
various national activities together [Par91].
このプロジェクトが持っている必要な接着剤を提供することである[Par91]様々な国家の活動を結合するために天国(ヨーロッパでA ReseArch DIrectory Serviceを操縦します)。
5.1 Short Term Requirements
5.1 短期間要件
- Central Operations. There is a need for a number of operations
to be managed as a service for the whole Internet. These services
are:
- 主要な操作。 手術件数が全体のインターネットのためのサービスとして管理される必要があります。 これらのサービスは以下の通りです。
o A root DSA; containing the top-level of the DIT, has to be
provided. Currently, this root DSA is managed by the Paradise
project.
o 根のDSA。 DITのトップレベルを含んでいて、提供しなければなりません。 現在、この根のDSAはParadiseプロジェクトによって管理されます。
o Name assignment; Inserting names into the Directory, this has
been discussed in section 4. This could be done in conjunction
with the appropriate Registration Authority or by the
Registration Authority. In most cases it is likely to be the
former, and mechanisms will need to be set up to allow
organizations to get their names installed into the directory,
either direct or through the registration authority.
o 課題を命名してください。 名前をディレクトリに挿入して、セクション4でこれについて議論しました。 適切なRegistration Authorityに関連したRegistration Authorityはこれができました。 多くの場合、それは前者である傾向があります、そして、メカニズムは組織がディレクトリの中、または、ダイレクトにか登録局を通してそれらの名前をインストールさせるのを許容するためにセットアップされる必要があるでしょう。
o Knowledge management; i.e., the information on "which DSA holds
what part of the DIT, and how can that DSA be accessed". DSAs
will be established by Organizations. There will be a need to
centrally coordinate the management of the knowledge information
associated with these DSAs. This is likely to be coupled to the
name assignment.
o ナレッジ・マネジメント。 すなわち、「どのDSAが離れているDITのものを保持するか、そして、どうしたらそのDSAにアクセスできること」の情報。 DSAsはOrganizationsによって設立されるでしょう。 これらのDSAsに関連している知識情報の管理が中心で調整される必要があるでしょう。 これは課題という名前と結合されそうです。
o Knowledge and Data replication; For the Directory to perform
well, knowledge and data high up in the DIT must be
significantly replicated. A service must be provided to make
replicated information available to DSAs that need it.
o 知識とData模写。 ディレクトリがよく振る舞うために、高くDITの知識とデータをかなり模写しなければなりません。 模写された情報をそれを必要とするDSAsに利用可能にするようにサービスを提供しなければなりません。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 7] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[7ページ]RFC1430X.500戦略1993年2月
It is suggested that for the time being, Paradise should be used
as the initial basis for handling the top-level of the DIT and for
provision of the central services. However, the services mentioned
above need to be provided at a national level for every
participating country in the Internet Directory Service. Whenever
an organization starts a new country branch of the DIT in the
Internet Directory Service the central operations will have to
help out to make sure that these services will be properly
installed on a national level.
当分の間ParadiseがDITのトップレベルを扱って、主要にサービスの支給の初期の基礎として使用されるべきであると示唆されます。 しかしながら、前記のようにサービスは、全国レベルでインターネットディレクトリサービスにおけるあらゆる参加国に提供される必要があります。 組織がインターネットディレクトリサービスでDITの新しい国のブランチを始めるときはいつも、主要な操作は、外にこれらのサービスが適切に全国レベルにインストールされるのを確実にするのを助けなければならないでしょう。
- An effective service will need to have sufficient implementations,
in order to give full coverage over different hardware and software
platforms, and to demonstrate openness. The recent Directory
Information Services (pilot) Infrastructure Working Group's (DISI)
Survey of Directory Implementations suggests that there will not be
a problem here. This provides a list of available X.500
implementations and their capabilities [LW91].
- 有効なサービスは、異なったハードウェアとソフトウェアプラットホームの上に完全適用範囲を与えるために十分な実現を持って、風通しの良さを示す必要があるでしょう。 最近のディレクトリ情報Services(パイロット)インフラストラクチャ作業部会のディレクトリImplementationsの(DISI)調査は、問題がここにないのを示します。 これは利用可能なX.500実現と彼らの能力[LW91]のリストを提供します。
- An executive summary, necessary to convince the management of
computer centers to invest manpower into setting up a X.500
Directory Service. This is provided by DISI [WR92].
- X.500ディレクトリサービスをセットアップするのに労働力を投資するために管理にコンピュータセンターを納得させるのに必要な要約。 これはDISI[WR92]によって提供されます。
- Due to the possible different and rather independent structured
namespaces that can be envisaged in the DIT for different purposes,
DUAs will have to be "tuned intelligently" for the applications that
they are used for.
- 異なる役割のためにDITで考えることができる可能な異なってかなり独立している構造化された名前空間のために、DUAsはそれらが使用されるアプリケーションのために「知的に調整されなければならないでしょう」。
- To allow users easy access to the Internet Directory Service even
from low powered workstations, a lightweight protocol has to be
developed over TCP/IP. Already two private protocols that do this
have been developed: The Michigan DIXIE protocol [HSB91] and the PSI
Directory Assistance Service [Ros91]. The IETF OSI Directory
Services Working Group (OSI-DS WG) is currently working on a
standard lightweight protocol called LDAP.
- 低い動力付きのワークステーションからさえユーザにインターネットディレクトリサービスへの簡単なアクセスを許すために、軽量のプロトコルはTCP/IPの上で開発されなければなりません。 既に、これをする2つの個人的なプロトコルを開発してあります: ミシガンデキシープロトコル[HSB91]とPSIディレクトリAssistance Service[Ros91]。 IETF OSIディレクトリサービス作業部会(OSI-DS WG)は現在、LDAPと呼ばれる標準の軽量のプロトコルに取り組んでいます。
- Although the Internet Directory Service does not have to make any
mandatory requirements about the use of lower layers, it is noted
that the use of STD 35, RFC 1006 to allow use of OSI applications on
top of TCP/IP is essential for deployment in the Internet. Other
stacks like the ones using CLNS, CONS and X.25(80) will probably
also be deployed in parts of the Internet. DSAs with different
stacks will be linked through use of either application level relays
(chaining) or Transport Service bridges.
- インターネットディレクトリサービスはそうしませんが、下層では、それに注意するというSTD35、TCP/IPの上でOSIアプリケーションの使用を許すRFC1006の使用がある使用に関するあらゆる義務的な要件を造に持ってください。インターネットでの展開において、不可欠です。 また、CLNS、コンズ、およびX.25(80)を使用するもののような他のスタックはたぶんインターネットの地域で配備されるでしょう。 異なったスタックがあるDSAsはアプリケーションレベルリレー(推論)かTransport Service橋のどちらかの使用でリンクされるでしょう。
- There are multiple issues that are not dealt with (properly) in the
X.500 standard and thus prevent the building of an Internet
Directory service. Intermediate solutions for these issues have to
be established in an "open" way. The results will have to be
- (適切に)X.500規格で対処されていなくて、その結果インターネットディレクトリサービスのビルを防ぐ複数の問題があります。 これらの問題の中間的解決は「開いている」方法で確立されなければなりません。 意志は結果でなければなりません。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 8] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[8ページ]RFC1430X.500戦略1993年2月
deployed as well as to be fed back into the relevant standard
committees. The IETF OSI-DS WG deals with these issues. Section 7
describes several of these issues.
また、関連標準の委員会にフィードバックされるほど展開しました。 IETF OSI-DS WGはこれらの問題に対処します。 セクション7はこれらのいくつかの問題について説明します。
- Site support. The IETF IDS WG is looking at providing the necessary
documentation to help with the provision of support for Directory
users at participating sites.
- サイトサポート。 IETF IDS WGは参加サイトのディレクトリユーザのサポートの支給を助ける必要なドキュメンテーションに提供するのを検討しています。
5.2 Medium Term Requirements
5.2 中期要件
- Enhanced performance is necessary to allow for a real global usage;
- 高められた性能が全くグローバルな用法を考慮するのに必要です。
- The schema has to be extended to allow for various kinds of data,
e.g.,:
- 図式は例えば様々な種類に関するデータを考慮するために広げられなければなりません:
o NIC data;
o Resource location;
o NICデータ。 o リソース位置。
- Support for Internet Message Handling services (RFC-822, MIME and
X.400). This work is already undertaken by the IETF MHS-DS WG.
- インターネットMessage Handlingには、サービス(RFC-822、MIME、およびX.400)を支持してください。 この仕事はIETF MHS-DS WGによって既に引き受けられます。
5.3 Long Term Requirements
5.3 長期要件
- To make sure that X.500 evolves into an operational service, it is
essential to track its evolution, and to feed back into the
evolution process.
- X.500が操作上のサービスに発展するのを確実にするために、発展を追跡して、発展の過程にフィードバックするのは不可欠です。
- Interface existing RDBMS into the Directory Service.
- 既存のRDBMSをディレクトリサービスに連結してください。
- To increase the performance of the directory, and thereby making it
useful for an even wider range of applications (e.g., policy based
routing), a lightweight protocol for access and system usage is
needed.
- ディレクトリと、その結果、それをさらに広い範囲のアプリケーション(例えば、方針はルーティングを基礎づけた)の役に立つようにする性能を向上させるように、アクセスとシステム使用のための軽量のプロトコルが必要です。
6. DATAMANAGEMENT
6. DATAMANAGEMENT
The whole of the Directory Infrastructure won't stand much chance without proper datamanagement of the data contained within the DIT. Procedures need to be established to assure a certain Level of Quality of the data contained in the DIT.
ディレクトリInfrastructureの全体には、見込みがDITの中に含まれたデータの適切なdatamanagementなしであまりないでしょう。 手順は、DITに含まれたデータのQualityをあるLevelに保証するために設立される必要があります。
Due to the very nature of X.500, the management of the data is distributed over various sources. This has the obvious advantage that the data will be maintained by the owner of the data. It does however, make it quite impossible to describe one single procedure for datamanagement.
X.500のまさしくその自然のため、データの管理は様々なソースにわたって広げられます。 これには、データがデータの所有者によって保守される明白な利点があります。 しかしながら、それをして、datamanagementのために1つのただ一つの手順について説明するのを十分不可能にしてください。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 9] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[9ページ]RFC1430X.500戦略1993年2月
For the Internet Directory Service, guidelines will have to be developed (by the IETF IDS WG), to help organizations that start with deployment of X.500 on how to manage data in their part of the DIT. The guidelines should describe a minimum level of quality that has to be supplied to make the service operational. The IETF OSI-DS WG will initiate a pilot on Quality of Service parameters in the Directory, that will be of use.
インターネットディレクトリサービスにおいて、ガイドラインは、それらのDITの部分でどうデータを管理するかにおけるX.500の展開から始まる組織を助けるために開発されなければならないでしょう(IETF IDS WG)。 ガイドラインはサービスを操作上にするように供給されなければならない最低水準の品質について説明するべきです。 IETF OSI-DS WGはディレクトリにおけるServiceパラメタのQualityでパイロットを開始して、それは役に立ちます。
Pilot datamanagement projects will have to be done (e.g., existing databases should be connected to the Internet Directory Service). Tools that are developed to achieve this should be made available to the Internet community for possible future use.
パイロットdatamanagementプロジェクトは果たされなければならないでしょう(例えば既存のデータベースはインターネットディレクトリサービスに関連づけられるべきです)。 これを達成するために開発されるツールを可能な今後の使用にインターネットコミュニティに利用可能にするべきです。
6.1 Legal Issues
6.1 法的な問題
Most countries connected to the Internet have some sort of law that dictates how data on people can and cannot be made available. These laws deal with privacy and registration issues, and will differ from country to country. It is suggested that each of the national organizations within the Internet that manages the Internet Directory Services master for that country, undertake some research as to the applicability of laws within that country on data made public through use of X.500.
インターネットにつなげられたほとんどの国がどう人々に関するデータはすることができて、利用可能にすることができないかを決めるある種の法を持っています。 これらの法は、プライバシーと登録問題に対処して、国から国まで異なるでしょう。 それぞれインターネットの中の全国的な組織では、それがその国のインターネットディレクトリサービスマスターを管理することが提案されて、X.500の使用で公表されたデータのその国の中で法の適用性に関して何らかの研究を引き受けてください。
In the mean time, a general "User Bill of Rights" should be established to indicate what the proper use of the Internet Directory Service is. This "Bill of Rights" could be drafted by the IETF IDS WG. As a basis, the NADF "User Bill of Rights" [For92] can be used.
その間に、一般的な「ユーザ権利の章典」は、インターネットディレクトリサービスの適切な使用が何であるかを示すために設立されるべきです。 IETF IDS WGはこの「権利の章典」を作成できました。 基礎として、NADF「ユーザ権利の章典」[For92]を使用できます。
7. TECHNICAL ISSUES
7. 専門的な問題
The IETF has established the OSI-DS WG. The major component of the initial work of this group is to establish a technical framework for deploying a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b]. This section describes the work already done by this working group, which has been implicitly focused on the technical infrastructure needed to deploy the Internet Directory service.
IETFはOSI-DS WGを設立しました。 このグループの初期の仕事の主要なコンポーネントはインターネットでディレクトリサービスを配備するために技術的な枠組みを確立することです、X.500プロトコルとサービス[CCI88b]を利用して。 このセクションはそれとなく技術インフラにインターネットディレクトリサービスを配備するのに必要である焦点を合わせられたこのワーキンググループによって既に行われた仕事について説明します。
The OSI Directory Standards do not yet contain sufficient specifics to enable the Internet Directory Service to be built. Full openness and interoperability are a key goal, so we may need Internet specific agreements, at least until the ISO standards are more complete. This section notes areas where the standards do not have sufficient coverage, and indicates the RFCs which have been written to overcome these problems.
OSIディレクトリStandardsはまだインターネットディレクトリサービスが組み込まれるのを可能にすることができるくらいの詳細を含んでいません。 私たちは完全な風通しの良さと相互運用性が主要な目標であるのでインターネットの特定の協定を必要とするかもしれません、ISO規格が少なくとも完全になるまで。 このセクションは、規格が十分な取材を持っていない領域に注意して、これらの問題を克服するために書かれているRFCsを示します。
The work is being limited to (reasonably well) understood issues.
仕事は(かなり良い)の理解されている問題に制限されています。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 10] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[10ページ]RFC1430X.500戦略1993年2月
This means that whilst we will attempt to solve a wider range of problems, not all potential requirements will necessarily be met.
これは、私たちが、より広い範囲の問題を解決するのを試みるつもりである間すべての潜在的必要条件が必ず満たされるというわけではないことを意味します。
The technical work is done in conjunction with the RARE WG on Network Application Support WG (formerly RARE WG3). The IETF WGs and the RARE WG have a common technical mailing list. It is intended that this will lead to a common European and North American technical approach.
Network Application Support WG(以前RARE WG3)の上のRARE WGに関連して技術的な仕事をします。 IETF WGsとRARE WGには、一般的な技術的なメーリングリストがあります。 これが一般的なヨーロッパの、そして、北米の技術的なアプローチに通じることを意図します。
7.1 Schema
7.1 図式
A Directory needs to be used in the context of an Information Framework. The standard directory provides a number of a attributes and object classes to enable basic operation. It is certain that the Internet community will have requirements for additional attributes and object classes. There is a need to establish a mechanism to register such information.
ディレクトリは、情報Frameworkの文脈で使用される必要があります。 標準のディレクトリは、基本的な操作を可能にするために属性と物のクラスの数を提供します。 インターネットコミュニティには追加属性と物のクラスのための要件があるのは、確かです。 そのような情報を登録するためにメカニズムを確立する必要があります。
Pilots in the European RARE Community and the US PSI White Pages Pilot have based their information framework on the THORN and RARE Naming Architecture. This architecture should be used for the Internet Directory Service, in conjunction with COSINE based services in Europe. A revised version of the Naming Architecture, with a mechanism for registration of new attributes and object classes, has been released as RFC 1274 [BHK91a].
ヨーロッパのRARE CommunityとUS PSIホワイトページPilotのパイロットのそれらの情報枠組みはTHORNとRARE Naming Architectureに基づいていました。 この構造はインターネットディレクトリサービスにヨーロッパでのCOSINEのベースのサービスに関連して使用されるべきです。 新しい属性と物のクラスの登録のためのメカニズムで、Naming Architectureの改訂版はRFC1274[BHK91a]としてリリースされました。
7.2 Use on the Internet
7.2 インターネットにおける使用
It is a recognized policy on the Internet to deploy OSI Applications over non-OSI lower layers (such as STD 35, RFC 1006) [RC87]. This policy allows deployment of OSI Applications before an OSI lower layer infrastructure has been deployed. Thus, the Internet Directory Service will decouple deployment of the OSI Directory from deployment of the OSI lower layers. As the Internet Directory service will extend into the far corners of the Internet namespace, where the underlying technology is not always TCP/IP, the Internet Directory Service will not make any mandatory requirements about use of lower layers. When configuring the Internet Directory Services, variations in the lower layers must be considered. The following options are possible:
インターネットに関して、非OSI下層(STD35、RFC1006年などの)[RC87]の上でOSI Applicationsを配備するのは、認識された方針です。 OSI下層インフラストラクチャが配備される前にこの方針はOSI Applicationsの展開を許します。 したがって、インターネットディレクトリサービスはOSIの低級層の展開からOSIディレクトリの展開の衝撃を吸収するでしょう。 インターネットディレクトリサービスがインターネット名前空間の遠い角(基本的な技術はいつもTCP/IPであるというわけではない)に広がるとき、インターネットディレクトリサービスは下層の使用に関するどんな義務的な要件も作らないでしょう。 インターネットディレクトリサービスを構成するとき、下層の変化を考えなければなりません。 以下のオプションは可能です:
- Operation on top of TCP/IP using a lightweight protocol.
- 軽量のプロトコルを使用するTCP/IPの上の操作。
- Operation over TCP/IP using STD 35, RFC 1006. This is a practical
requirement of deployment at very many Internet sites, and is the
basis of the existing services. It is highly recommended that all
participating DSAs support this stack.
- STD35、RFC1006を使用するTCP/IPの上の操作。 これは、非常に多くのインターネット・サイトでの展開の実際的な要件であり、既存にサービスの基礎です。 すべて参加しているDSAsがこのスタックを支えるのは、非常にお勧めです。
- Use of OSI Network Service (Connection Oriented or Connectionless).
- OSIネットワーク・サービス(接続指向の、または、コネクションレスな)の使用。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 11] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[11ページ]RFC1430X.500戦略1993年2月
- X.25(80) will probably not be used in the core infrastructure of
the Internet Directory Service, but is the basis of some European
activities. It may be needed later to interconnect with US
commercial systems not on the Internet. There will be a practical
need to interwork with DSAs which only support this stack.
- X.25(80)はたぶんインターネットディレクトリサービスのコアインフラストラクチャでは使用されませんが、いくつかのヨーロッパの活動の基礎です。 それが、後で米国商業の体系がいずれのインターネットにもなく内部連絡するのに必要であるかもしれません。 このスタックを支えるだけであるDSAsと共に織り込む実用的な必要があるでしょう。
This approach has the following implications:
このアプローチには、以下の意味があります:
1. There is a need to represent TCP/IP addresses within OSI Network
Addresses. This is specified in RFC 1277 [HK91a].
1. OSI Network Addressesの中にTCP/IPアドレスを表す必要があります。 これはRFC1277[HK91a]で指定されます。
2. It will be desirable to have a uniform method to present Network
Addresses of this style. Therefore, a string representation of
presentation addresses is specified in RFC 1278 [HK91d].
2. このスタイルのNetwork Addressesを寄贈する一定の方法を持っているのは望ましいでしょう。 したがって、プレゼンテーションアドレスのストリング表現はRFC1278[HK91d]で指定されます。
3. This approach leads to the situation where not all DSAs can
communicate directly due the different choice of lower layers.
This is already a practical result of many European sites operating
DSAs over X.25. When the Internet Directory Service is deployed,
the issue of which DSAs operate which stacks must be considered in
order to achieve a coherent service. In particular, there may be a
need to require DSAs that serve parts higher up in the DIT to serve
multiple stacks. This will be tackled as an operational issue.
3. このアプローチはすべてのDSAsが直接支払われるべきものを伝えることができるというわけではないところで状況につながります。下層の異なった選択。 これは既に多くのヨーロッパのサイトがX.25の上でDSAsを操作するという実際的な結果です。 インターネットディレクトリサービスが配備されるとき、一貫性を持っているサービスを達成するために、DSAsがどのスタックを操作する問題を考えなければなりません。 特に、DITで部品をより高く供給するDSAsが複数のスタックに役立つのが必要である必要があるかもしれません。 これは操作上の問題として取り組まれるでしょう。
4. There may be a requirement to extend the distributed operations, so
that there is no requirement for full connectivity (i.e., each DSA
supports each stack). A solution to this problem, by defining
"relay DSAs" is specified in RFC 1276 [HK91b].
4. 分配された操作を広げるという要件があるかもしれません、完全な接続性のための要件が全くない(すなわち各DSAは各スタックを支える)ように。 この問題の解決であり、定義することによって、「リレーDSAs」はRFC1276[HK91b]で指定されます。
7.3 Replication of Knowledge and Data
7.3 知識とデータの模写
There are a number of requirements on replication, both of data (the actual information on objects in the directory) and knowledge (the information on where do I find what data) information, which must be met before an Internet Directory can be deployed. The 1988 standard cannot be used as is, because it does not deal with replication or caching. This leads to serious problems with performance. There is a partial solution available in the 1992 version of the standard, however there are no products available yet that implement this solution. These issues are discussed in more detail in RFC 1275 [HK91c].
データ(ディレクトリのオブジェクトの実際の情報)と知識の模写に関する多くの要件がある、(情報、どこに関して、私は何というデータ) 情報を見つけますか?(インターネットディレクトリを配布することができる前にそれを満たさなければなりません)。 模写かキャッシュに対処しないので、そのままで1988年の規格を使用できません。 これは性能の深刻な問題に通じます。 1992年の規格のバージョンで利用可能な部分的解決があります、利用可能な製品がないのにもかかわらず、その道具がどんなにそこのこのソリューションであっても。 さらに詳細にRFC1275[HK91c]でこれらの問題について議論します。
As it took too long for 1992 implementations to arrive to be of any help to the already rapidly growing pilot that urgently needed a solution, an option was chosen to use a simple interim approach as defined in RFC 1276. It will be clearly emphasized that this is an interim approach, which will be phased out as soon as the appropriate standards are available and stable implementations are deployed. The
1992の実装がソリューションを緊急に必要とした既に急速に成長しているパイロットにはどんな助けもあるように到着するようにまた、時間がかかったとき、オプションは、簡単な当座のアプローチを使用するためにRFC1276で定義されるように選ばれました。 これが当座のアプローチであると明確に強調されて、安定した実装は配布されます。(適切な規格が利用可能であるとすぐに、アプローチは段階的に廃止されるでしょう)。 The
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 12] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[12ページ]RFC1430X.500戦略1993年2月
interim approach is based on the approach used in the QUIPU Implementation and it is widely deployed in the existing pilots.
当座のアプローチはQUIPU Implementationで使用されるアプローチに基づいています、そして、それは既存のパイロットで広く配布されます。
7.4 Presentation of Directory Names
7.4 ディレクトリ名のプレゼンテーション
The standard does not specify a means to present directory names to the user. This is seen as a serious deficiency, and a standard for presenting directory names is required. For Distinguished Names, a string representation is defined in [HK92a]. However, as the distinguished name is not very friendly for the user, a more user oriented specification of a standard format for representing names, and procedures to resolve them is chosen on the Internet, and is specified in [HK92b].
規格はユーザにディレクトリ名を提示する手段を指定しません。 これは重大な欠乏と考えられます、そして、ディレクトリ名を提示する規格が必要です。 Distinguished Namesに関しては、ストリング表現は[HK92a]で定義されます。 しかしながら、ユーザには、分類名がそれほど好意的でないのでそれらを決議するために名前、および手順を表すための標準書式の、より多くのユーザ指向の仕様は、インターネットで選ばれていて、[HK92b]で指定されます。
7.5 DSA Naming and MD Structure
7.5 DSA命名とMD構造
There are some critical issues related to naming of DSAs and the structure of Directory Management Domains. The main issues are:
DSAsの命名とディレクトリManagement Domainsの構造に関連するいくつかの重要な問題があります。 本題は以下の通りです。
- It is hard to achieve very high replication of knowledge
information as this is very widely spread;
- これが非常に広く広げられるとき、知識情報の非常に高い模写を達成しにくいです。
- There is a need to give DSAs more reasonable names, which will
contain an indication on the role of the DSA; This is necessary for
DSAs high up the DIT.
- より妥当な名前をDSAsに与える必要があります。名前はDSAの役割に指示を含むでしょう。 これが高くDITでDSAsに必要です。
- There is too much DIT clutter in the current pilots;
- あまりに多くのDIT散乱が現在のパイロットにあります。
- There is no real concept of a DMD (Directory Management Domain)
authority.
- DMD(ディレクトリManagement Domain)権威のどんな本当の概念もありません。
These will be significant as the directory increases in size by orders of magnitude. The IETF OSI-DS WG is working to develop a solution in this area.
ディレクトリが何桁も大きくなるのに応じて、これらは重要になるでしょう。 IETF OSI-DS WGは、この領域で解決策を見いだすために働いています。
8. SECURITY
8. セキュリティ
A Directory can be an important component in the overall provision of security in a distributed system environment, especially when public-key cryptographic technology is employed. The directory can serve as a repository for authentication information, which, in turn, forms the basis of a number of OSI Authentication Services (e.g., X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM). The directory may also use this and other stored authentication information to provide a wide range of security Services used by the Directory system itself.
ディレクトリは分散システム環境へのセキュリティの総合的な支給で重要なコンポーネントであるかもしれません、特に公開鍵の暗号の技術が採用しているとき。 ディレクトリは認証情報のための倉庫として機能できます(例えば、プライバシーがメールを高めました、PEM)。(順番に、認証情報は多くのOSI Authentication Services(例えば、X.400)と非OSI Servicesの基礎を形成します)。 また、ディレクトリは、ディレクトリシステム自体によって使用されるさまざまなセキュリティServicesを提供するのにこれと他の保存された認証情報を使用するかもしれません。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 13] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[13ページ]RFC1430X.500戦略1993年2月
8.1 Directory Provision of Authentication
8.1 認証のディレクトリ支給
The directory will be used to provide X.509 strong authentication. This places minimal requirements on the directory. To use this infrastructure, users of authentication services must have access to the directory. In practice, this type of authentication can be deployed only on a limited scale without use of a directory, and so this provision is critical for applications such as Privacy Enhanced Mail [Lin93]. The PEM development is considering issues relating to deploying Certification Authorities, and this discussion is not duplicated here.
ディレクトリは、強い認証をX.509に供給するのに使用されるでしょう。 これは最小量の要件をディレクトリに置きます。 このインフラストラクチャを使用するために、認証サービスのユーザはディレクトリに近づく手段を持たなければなりません。 実際には、限定された規模でディレクトリの使用だけなしでこのタイプの認証を配布することができるので、Privacy Enhancedメール[Lin93]などのアプリケーションに、この支給は重要です。 PEM開発はCertification Authoritiesを配布するのに関係する問題を考えています、そして、この議論はここにコピーされません。
PEM defines a key management architecture based on the use of public-key certificates, in support of the message encipherment and authentication procedures defined in [Lin93]. The PEM certificate management design [Ken93] makes use of the authentication framework defined by X.509. In this framework, as adopted by PEM, a "certification authority" representing an organization applies a digital signature to a collection of data consisting of a user's public component, various information that serves to identify the user, and the identity of the organization whose signature is affixed. This establishes a binding between these user credentials, the user's public component and the organization which vouches for this binding. The resulting, signed, data item is called a certificate. The organization identified as the certifying authority for the certificate is the "issuer" of that certificate. The format of the certificate is defined in X.509.
PEMは公開鍵証明書の使用に基づくかぎ管理アーキテクチャを定義します、[Lin93]で定義されたメッセージ暗号文と認証手順を支持して。 PEM証明書管理デザイン[Ken93]はX.509によって定義された認証フレームワークを利用します。 このフレームワークでは、PEMによって採用されるように、組織を代表する「証明権威」はユーザの公共のコンポーネントから成るデータの収集、ユーザを特定するのに役立つ様々な情報、および署名が付けられる組織のアイデンティティにデジタル署名を適用します。 これはこの結合を保証するこれらのユーザ資格証明書の間の結合、ユーザの公共のコンポーネント、および組織を確立します。 結果になることであり、署名されて、データ項目は証明書と呼ばれます。 証明書のための公認権威として特定された組織はその証明書の「発行人」です。 証明書の書式はX.509で定義されます。
In signing the certificate, the certification authority vouches for the user's identification, in the context specified by the identity of the issuer. Various types of organization may issue certificates, including corporate, educational, professional, or governmental entities. Moreover, these issuers may operate under different certification policies, so that not all certificates may be equally credible (i.e., some certificates may be more trustworthy as accurate identifiers of users, organizations, mailing lists, etc). The PEM certificate management design allows for this diversity of certification policies, while ensuring that any certificate can be traced unambiguously to the policy under which it was issued.
証明書に署名する際に、証明権威はユーザの識別を保証します、発行人のアイデンティティによって指定された文脈で。 様々なタイプの組織は法人の、または、教育的であるか、プロの、または、政府の実体を含む証明書を発行するかもしれません。 そのうえ、これらの発行人は異なった証明方針の下で作動するかもしれません、すべての証明書がどんな等しく確かであることができるというわけではなく(すなわちいくつかの証明書がユーザ、組織、メーリングリストなどの正確な識別子として、より信頼できるかもしれません)なるように。 明白にそれが発行された方針にどんな証明書もたどることができるのを確実にしている間、PEM証明書管理デザインは証明方針のこの多様性を考慮します。
The digital signature is affixed on behalf of that organization and is in a form which can be recognized by all members of the privacy- enhanced electronic mail community. This ability to universally verify any PEM certificate results because the PEM certification design is a singly rooted tree, in which the Internet Society acts as the root. Once generated, certificates can be stored in directory servers, transmitted via unsecure message exchanges, or distributed via any other means that make certificates easily accessible to
デジタル署名は、その組織を代表して付けられて、プライバシーの高められた電子メール共同体のすべてのメンバーが認めることができるフォームにあります。 PEM証明デザインが単独で根づいている木であるので一般にどんなPEM証明書についても確かめるこの能力は結果として生じます。そこでは、インターネット協会が根として機能します。 いったん生成されると、証明書をディレクトリサーバで保存するか、unsecure交換処理で伝えられるか、または証明書を容易にアクセスしやすくするいかなる他の手段でも配布できます。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 14] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[14ページ]RFC1430X.500戦略1993年2月
message originators, without regard for the security of the transmission medium.
トランスミッション媒体のセキュリティへの尊敬のないメッセージ創始者。
8.2 Directory Security
8.2 ディレクトリセキュリティ
A number of security services are possible with the directory:
多くのセキュリティー・サービスがディレクトリで可能です:
Peer Authentication at Bind
Authentication (one or two way) between DUA/DSA and DSA/DSA,
established during the bind operation. This authentication may be
provided using simple passwords (not recommended), one-way hashed
passwords (more secure), or via public key cryptography (most
secure). The various authentication options are specified in
X.500(88), but most existent implementations implement only simple
password authentication.
ひもの操作の間に設立されたDUA/DSAとDSA/DSAの間のBind Authentication(1かツーウェイ)の同輩Authentication。 簡単なパスワード(推薦されない)、一方向ハッシュ化されたパスワード(より安全な)を使用することで提供するか、公開鍵暗号(最も安全な)でこの認証はあるかもしれません。 様々な認証オプションはX.500(88)で指定されますが、ほとんどの目下の実装が簡単なパスワード認証だけを実装します。
Per-operation Authentication and Integrity
This is usually used to identify the DUA originating an operation
to the Directory (e.g., to authenticate prior to data
modification). It may also be used to verify the identity of the
DSA which provided data in a response to the user. In both
examples, the integrity of the data also is ensured through the
use of digital signatures. This is specified in X.500(88), but not
yet widely implemented.
通常、操作のAuthenticationとIntegrity Thisは、ディレクトリに操作を溯源するDUAを特定するのに使用されます(例えばデータ変更の前に認証する)。 また、それは、ユーザへの応答にデータを提供したDSAのアイデンティティについて確かめるのに使用されるかもしれません。 両方の例では、データの保全もデジタル署名の使用で確実にされます。 これは、X.500(88)で指定されますが、まだ広く実装されていません。
Single Entry Access Control
This is used to control which users (DUAs) can access and modify
data within an entry. This is specified in X.500(92) and most DSA
implementations provide this function.
独身のEntry Access Control Thisは、どのユーザ(DUAs)がエントリーの中でデータにアクセスして、変更できるかを制御するのに使用されます。 これはX.500(92)で指定されます、そして、ほとんどのDSA実装がこの機能を提供します。
Multiple Entry Access Control
This is used to control search and list operations, in order to
allow location of information by searching, but to deter
"trawling" of information and organizational structure. Usually,
these access controls are limited in their ability to prevent
trawling because of the conflicting goal of allowing a certain
level of legitimate browsing in support of "white pages"
functionality.
複数のEntry Access Control Thisが検索とリスト操作を制御するのに使用されます、しかし、探すのによる情報の位置が情報と組織体制が「トロール網」であることを思いとどまらせるのを許容するために。 通常、これらのアクセス制御は「ホワイトページ」の機能性を支持してあるレベルの正統のブラウジングを許容するという闘争目標のために引くのを防ぐ彼らの能力が制限されます。
Service Authorization
This allows DSAs to control service in a data independent manner,
based on peer authentication. For example, one might prevent
students from making non-local queries, while permitting such
queries by faculty and staff.
サービスAuthorization ThisはDSAsに同輩認証に基づいてデータの独立している方法でサービスを制御させます。 例えば、1つによって、学生は教授陣とスタッフによるそのような質問を可能にしている間、非地方の質問をすることができないかもしれません。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 15] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[15ページ]RFC1430X.500戦略1993年2月
Security Policy
This term encompasses the security goals for which data access
control, service authorization, and authentication mechanisms are
used to implement. For example, a local security policy might
require that all directory database modifications employ strong
authentication and originate from a computer at a known (local)
location.
セキュリティPolicy This用語はデータ・アクセスコントロール、サービス承認、および認証機構が実装するのにおいて使用されているセキュリティ目標を包含します。 例えば、ローカルの安全保障政策は、すべてのディレクトリデータベース変更が知られている(地方の)位置に強い認証を使って、コンピュータから発するのを必要とするかもしれません。
Data Confidentiality
The directory does not include explicit features to protect the
confidentiality of data while in transit (e.g., between a DUA and
DSA or between DSAs). Instead, it is assured that lower layer
security protocols or other local security facilities will be
employed to provide this security service. Ongoing work on
adaptation of the Network Layer Security Protocol (NLSP) is a
candidate for provision of this security service with directories.
トランジット(例えば、DUAとDSAかDSAsの間の)にはある間、ディレクトリがするデータConfidentialityはデータの秘密性を保護する明白な特徴を含んでいません。 代わりに、下層セキュリティプロトコルか他の地方のセキュリティ施設がこのセキュリティー・サービスを提供するのに使われることが保証されます。 Network Layer Securityプロトコル(NLSP)の適合に対する進行中の仕事はディレクトリによるこのセキュリティー・サービスの支給の候補です。
There is no specification of any Internet-wide security policy for directories, nor are there currently any security mechanisms required of all directories. Deployment of a directory could be based on a variety of policies:
ディレクトリのためのどんなインターネット全体の安全保障政策の仕様も全くありません、そして、現在、すべてのディレクトリについて必要であるセキュリティー対策がありません。 ディレクトリの展開はさまざまな方針に基づくことができました:
- Read only system, containing only public data and restricted to
local modification.
- 公衆データだけを含んでいて、地方の変更に制限されたシステムだけを読んでください。
- Use of X.509 authentication, and private access control mechanisms
(this will not allow open access control management, but this is not
seen as a fundamental problem).
- X.509認証、および個人的なアクセス管理機構(開架コントロール管理を許さないでしょうが、これは基本的な問題と考えられない)の使用。
It will be important to understand if global Internet requirements for minimum essential directory security mechanisms will be required to promote widespread use of directories. We recommend that an informational RFC be written to analyze this issue, with an operational policy guidelines or applicability statement RFC to follow.
最小の不可欠のディレクトリセキュリティー対策のための世界的なインターネット要件がディレクトリの普及使用を促進するのに必要であるかどうか理解しているのは重要でしょう。 私たちは、続くように操作上の政策文書か適用性証明RFCと共に情報のRFCがこの問題を分析するために書かれることを勧めます。
9. RELATION TO DNS
9. DNSとの関係
It is important to establish the relationship between the proposed Internet Directory, and the existing Domain Name System. An Experimental Protocol RFC (RFC 1279) proposes a mapping of DNS information onto the Directory. Experiments should be conducted in this area [HK91e].
提案されたインターネットディレクトリと、既存のドメインネームシステムとの関係を確立するのは重要です。 ExperimentalプロトコルRFC(RFC1279)はDNS情報に関するマッピングをディレクトリに提案します。 実験がこの領域[HK91e]で行われるべきです。
10. EXTERNAL CONNECTIONS
10. 外部の接続
It will be important for this activity to maintain suitable external liaisons. In particular to:
この活動が適当な外部の連絡を維持するのは、重要でしょう。 特定で:
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 16] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[16ページ]RFC1430X.500戦略1993年2月
Other Directory Services and Directory Pilots
他のディレクトリサービスとディレクトリのパイロット
To ensure a service which is coherent with other groups building
X.500 services. e.g.,:
他のグループが建てられている状態で一貫性を持っているサービスにX.500サービスを確実にするために例えば:
- Paradise
- NADF
- FOX
- PSI White Pages
- 天国--NADF--キツネ--ψホワイトページ
Standards Bodies
標準化団体
To feed back experience gained from this activity, so that the
next round of standards meets as many of the Internet requirements
as possible. e.g.,:
この活動から行われた経験、規格の次のラウンドが可能なインターネット同じくらい要件の多くとして会う給送の逆そう例えば:
- CCITT/ISO
- RARE WG-NAS
- EWOS/OIW
- ETSI
- CCITT/ISO--まれなWG-NAS--EWOS/OIW--ETSI
11. REFERENCES
11. 参照
[BHK91a] Barker, P., and S. Hardcastle-Kille, "The COSINE and
Internet X.500 Schema", RFC 1274, Department of Computer
Science, University College London, November 1991.
[BHK91a] バーカー、P.、S.Hardcastle-Kille、および「コサインとインターネットX.500図式」、RFC1274、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドン(1991年11月)
[BHK92] Barker, P., and S. Hardcastle-Kille, "Naming Guidelines for
Directory Pilots", RFC 1384, Department of Computer Science,
University College London, ISODE Consortium, January 1993.
[BHK92] バーカー、P.とS.Hardcastle-Kille、「ディレクトリのパイロットへの命名ガイドライン」、RFC1384、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドン、ISODE共同体(1993年1月)。
[CCI88a] The Directory --- authentication framework, December 1988.
CCITT Recommendation X.509.
[CCI88a] ディレクトリ--- 1988年12月の認証フレームワーク。 CCITT推薦X.509。
[CCI88b] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[CCI88b] ディレクトリ--- 1988年12月の概念の、そして、モデルの、そして、サービスの概要。 CCITT X.500シリーズ勧告。
[CCI90] The Directory --- part 9 --- replication, October 1990.
ISO/IEC CD 9594-9 Ottawa output.
[CCI90] ディレクトリ--- パート9--- 1990年10月の模写。 ISO/IEC CD9594-9オタワの出力。
[CFSD90] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
Simple Network Management Protocol", STD 15, RFC 1157,
SNMP Research, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[CFSD90]ケースとJ.とヒョードルとM.とSchoffstall、M.とJ.デーヴィン、「簡単なネットワーク管理プロトコル」STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 17] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[17ページ]RFC1430X.500戦略1993年2月
[For91] The North American Directory Forum, "A Naming Scheme
for C=US", RFC 1255, NADF, September 1991.
Also NADF-175. (See also RFC 1417.)
[For91] 北米のディレクトリフォーラム、「Cの命名体系は米国と等しい」RFC1255、NADF、1991年9月。 NADF-175も。 (また、RFC1417を見てください。)
[For92] The North American directory Forum, "User Bill of Rights
for Entries and Listing in the Public Directory", RFC 1295,
NADF, January 1992. (See also RFC 1417.)
[For92] 北米のディレクトリForum、「公共のディレクトリにおけるエントリーとリストのためのユーザ権利の章典」、RFC1295、NADF(1992年1月)。 (また、RFC1417を見てください。)
[HK91a] Hardcastle-Kille, S., "Encoding network addresses to
support operation over non-OSI lower layers", RFC 1277,
Department of Computer Science, University College London,
November 1991.
S. [HK91a]Hardcastle-Kille、「非OSIの低級層の上の操作をサポートするためにネットワーク・アドレスをコード化すること」でのRFC1277、コンピュータScience、ユニバーシティ・カレッジロンドン(1991年11月)の部。
[HK91b] Hardcastle-Kille, S., "Replication and distributed
operations extensions to provide an internet directory
using X.500", RFC 1276, Department of Computer Science,
University College London, November 1991.
[HK91b] Hardcastle-Killeと、S.と、「模写とX.500を使用することでインターネットディレクトリを提供する分配された操作拡大」、RFC1276、コンピュータScience、ユニバーシティ・カレッジロンドン(1991年11月)の部
[HK91c] Hardcastle-Kille, S., "Replication requirement to
provide an internet directory using X.500", RFC 1275,
Department of Computer Science, University College
London, November 1991.
[HK91c] Hardcastle-Kille、S.、「インターネットディレクトリを提供するというX.500を使用する模写要件」、RFC1275、コンピュータScience、ユニバーシティ・カレッジロンドン(1991年11月)の部。
[HK91d] Hardcastle-Kille, S., "A string encoding of presentation
address", RFC 1278, Department of Computer Science,
University College London, November 1991.
[HK91d] Hardcastle-Kille、S.、「プレゼンテーションアドレスの五弦コード化」、RFC1278、コンピュータScience、ユニバーシティ・カレッジロンドン、1991年11月の部。
[HK91e] Hardcastle-Kille, S., "X.500 and domains", RFC 1279,
Department of Computer Science, University College
London, November 1991.
[HK91e]Hardcastle-Killeと、S.と、「X.500とドメイン」、RFC1279、コンピュータScience、ユニバーシティ・カレッジロンドン11月1991の部
[HK92a] Hardcastle-Kille, S., "A string representation of
Distinguished Names", Department of Computer Science,
University College London, Work in Progress.
[HK92a] Hardcastle-Kille、S.、「Distinguished Namesの五弦表現」、ProgressのコンピュータScience、ユニバーシティ・カレッジロンドンWorkの部。
[HK92b] Hardcastle-Kille, S., "Using the OSI directory to achieve
user friendly naming", Department of Computer Science,
University College London, Work in Progress.
S. [HK92b]Hardcastle-Kille、「ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用すること」でのコンピュータScience、ユニバーシティ・カレッジロンドン(ProgressのWork)の部。
[HSB91] Howes, R., Smith, M., and B. Beecher, "DIXIE Protocol
Specification", RFC 1249, University of Michigan,
July 1991.
[HSB91] ハウズとR.とスミス、M.とB.ビーチャー、「デキシープロトコル仕様」、RFC1249、ミシガン大学、1991年7月。
[ISO] Procedures for the operation of OSI registration
authorities --- part 1: general procedures. ISO/IEC 9834-1.
OSI登録局の操作のための[ISO]手順--- 第1部: 基本手順。 ISO/IEC9834-1。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 18] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[18ページ]RFC1430X.500戦略1993年2月
[Ken93] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II - Certificate-based Key Management, RFC 1422,
BBN, February 1993.
[Ken93]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 IIを分けてください--証明書ベースのKey Management、RFC1422、BBN、2月1993日。
[Kil88] Kille, S., "The QUIPU Directory Service", In IFIP WG 6.5
Conference on Message Handling Systems and Distributed
Applications, pages 173--186. North Holland Publishing,
October 1988.
[Kil88] KilleとS.と「結び縄文字ディレクトリサービス」とMessage Handling Systemsの上のIn IFIP WG6.5コンファレンスとDistributed Applications(173--186ページ)。 1988年10月に発行される北のオランダ。
[Kil89] Kille, S., "The THORN and RARE Naming Architecture",
Technical report, Department of Computer Science,
University College London, June 1989. THORN Report UCL-64
(version 2).
[Kil89] Technicalは、Killeと、S.と、「刺とまれな命名構造」と報告して、コンピュータScience、ユニバーシティ・カレッジロンドン6月の部は1989です。 刺のレポートUCL-64(バージョン2)。
[Lin93] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I - Message Encryption and Authentication
Procedures", RFC 1421, February 1993.
[Lin93]リン、J.、「インターネット電子メールのためのプライバシー増進:」 「Iを分けてください--暗号化と認証手順を通信させてください」、RFC1421、1993年2月。
[LW91] Lang, R., and R. Wright, "A Catalog of Available X.500
Implementations", FYI 11, RFC 1292, SRI International,
Lawrence Berkeley Laboratory, January 1992.
[LW91]ラング、R.とR.ライト、「利用可能なX.500実現のカタログ」FYI11、RFC1292、SRIインターナショナル、ローレンスバークレイ研究所(1992年1月)。
[Lyn91] Lynch, C., "The Z39.50 information retrieval protocol: An
overview and status report", Computer Communication Review,
21(1):58--70, January 1991.
[Lyn91] リンチ、C.、「Z39.50情報検索は以下について議定書の中で述べます」。 「概観と現状報告」、21(1): 58--70、1月1991コンピュータCommunication Review、日
[Par91] Paradise International Report, Cosine. Paradise project,
Department of Computer Science, University College London.
November 1991.
[Par91]天国国際報道、コサイン。 天国プロジェクト、コンピュータScience、ユニバーシティ・カレッジロンドンの部。 1991年11月。
[RC87] Rose, M., and D. Cass, "ISO Transport Services on
top of the TCP", STD 35, RFC 1006, Northrop Corporation
Technology Center, May 1987.
[RC87]ローズ、M.とD.キャス、「TCPの上のISO Transport Services」STD35(RFC1006、ノースロップ社のTechnologyセンター1987年5月)。
[Ros91] Rose, M., "Directory Assistance Service", RFC 1202,
Performance Systems International, February 1991.
[Ros91] ローズ、M.、「ディレクトリ支援サービス」、RFC1202、国際言語運用機構、1991年2月。
[WR92] Weider, C., and J. Reynolds, "Executive Introduction to
Directory Services Using the X.500 Protocol", FYI 13,
RFC 1308, ANS, ISI, March 1992.
[WR92] ワイダー、C.、およびJ.レイノルズ、「ディレクトリサービスへのX.500プロトコルを使用する幹部社員序論」、FYI13、RFC1308、ANS、ISI(1992年3月)。
12. Security Considerations
12. セキュリティ問題
Security issues are discussed in Section 8.
セクション8で安全保障問題について議論します。
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 19] RFC 1430 X.500 Strategy February 1993
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[19ページ]RFC1430X.500戦略1993年2月
13. Authors' Addresses
13. 作者のアドレス
Steve Hardcastle-Kille ISODE Consortium PO box 505 SW11 1DX London England Phone: +44-71-223-4062 EMail: S.Kille@isode.com
スティーブHardcastle-Kille ISODE Consortium PO箱505のSW11 1DXロンドンイギリス電話: +44-71-223-4062 メールしてください: S.Kille@isode.com
Erik Huizer SURFnet bv PO box 19035 3501 DA Utrecht The Netherlands Phone: +31-30 310290 Email: Erik.Huizer@SURFnet.nl
エリックHuizer SURFnet bv PO箱19035 3501のDAユトレヒトオランダ電話: +31-30 310290はメールされます: Erik.Huizer@SURFnet.nl
Vinton Cerf Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091 Phone: (703) 620-8990 EMail: vcerf@cnri.reston.va.us
レストン、Suite100ヴァージニア 1895年のプレストンの白いドライブ、22091が電話をする国家の研究イニシアチブのためのビントンサーフ社: (703) 620-8990 メールしてください: vcerf@cnri.reston.va.us
Russ Hobby University of California, Davis Computing Services Surge II Room 1400 Davis, CA 95616 Phone: (916) 752-0236 EMail: rdhobby@ucdavis.edu
ラス趣味カリフォルニア大学、デイヴィス、デイヴィスComputing Services大波II部屋1400カリフォルニア 95616は以下に電話をします。 (916) 752-0236 メールしてください: rdhobby@ucdavis.edu
Steve Kent Bolt, Beranek, and Newman 50 Moulton Street Cambridge, MA 02138 Phone: (617) 873-3988 EMail: skent@bbn.com
ケンブリッジ、MA 02138が電話をするスティーブ・ケントBolt、Beranek、およびニューマン50モールトン通り: (617) 873-3988 メールしてください: skent@bbn.com
Hardcastle-Kille, Huizer, Cerf, Hobby & Kent [Page 20]
Hardcastle-Kille、Huizer、サーフ、趣味、およびケント[20ページ]
一覧
スポンサーリンク
