RFC1330 日本語訳
1330 Recommendations for the Phase I Deployment of OSI DirectoryServices (X.500) and OSI Message Handling Services (X.400) within theESNET Community. ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet). May 1992. (Format: TXT=192925 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group ESCC X.500/X.400 Task Force
Request for Comments: 1330 ESnet Site Coordinating Committee (ESCC)
Energy Sciences Network (ESnet)
May 1992
コメントを求めるワーキンググループESCC X.500/X.400特別委員会要求をネットワークでつないでください: エネルギー科学ネットワーク(ESnet)1992年5月に委員会の(ESCC)を調整する1330年のESnetサイト
Recommendations for the Phase I Deployment of
OSI Directory Services (X.500) and
OSI Message Handling Services (X.400)
within the ESnet Community
フェーズのためのOSIディレクトリサービス(X.500)とOSIメッセージハンドリングのI展開がESnet共同体の中で(X.400)を修理するという推薦
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.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Overview
概観
The Energy Sciences Network (ESnet) is a nation-wide computer data communications network managed and funded by the United States Department of Energy, Office of Energy Research (U.S. DOE/OER), for the purpose of supporting multiple program, open scientific research. ESnet is intended to facilitate remote access to major Energy Research (ER) scientific facilities, provide needed information dissemination among scientific collaborators throughout all ER programs, and provide widespread access to existing ER supercomputer facilities.
Energy Sciences Network(ESnet)は合衆国エネルギー省によって管理されて、資金を供給された、全国的なコンピュータデータ通信網です、エネルギー課Research(U.S. DOE/OER)、複数のプログラムをサポートする目的のために、開いている科学的調査。 ESnetは主要なEnergy Research(ER)の科学的施設に遠隔アクセスを容易にして、すべてのERプログラムの間中科学的共同制作者に必要な情報普及を提供して、既存のERスーパーコンピュータ施設への広範囲のアクセスを提供することを意図します。
Coordination of ER-wide network-related technical activities over the ESnet backbone is achieved through the ESnet Site Coordinating Committee (ESCC). This committee is comprised of one technical contact person from each backbone site, as well as some members of the ESnet management and networking staff. As the need for new levels of ESnet services arise, the ESCC typically creates task forces to investigate and research issues relating to these new services. Each task force usually results in a whitepaper which makes recommendations to the ESnet community on how these services should be deployed to meet the mission of DOE/OER.
ESnet背骨の上のER全体のネットワーク関連の技術的な活動のコーディネートはESnet Site Coordinating Committee(ESCC)を通して達成されます。 この委員会はそれぞれの背骨サイト、およびESnet管理とネットワークスタッフの何人かのメンバーから1人の技術連絡担当者の人から成ります。 ESnetの新しいレベルの必要性として、サービスは起こって、ESCCはこれらの新種業務に関連する調査する特別委員会と研究課題を通常作成します。 通常、各特別委員会は推薦状をこれらのサービスがDOE/OERの任務に会うためにどう配備されるべきであるかのESnet共同体にするwhitepaperをもたらします。
This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force.
このRFCはESnet Site Coordinating CommitteeのX.500/X.400 Task Forceによって生産されたwhitepaperの近い逐語的なコピーです。
Table of Contents
目次
Status of this Document ....................................... 4 Acknowledgments ............................................... 4
このDocumentの状態… 4つの承認… 4
ESCC X.500/X.400 Task Force [Page 1] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[1ページ]RFC1330X.500とX.400プラン
1 Introduction ............................................... 5 1.1 Abstract and Introduction ................................ 5 1.2 Structure of this Document ............................... 5 2 X.500 - OSI Directory Services ............................. 6 2.1 Brief Tutorial ........................................... 6 2.2 Participation in the PSI White Pages Pilot Project ....... 7 2.3 Recommended X.500 Implementation ......................... 7 2.4 Naming Structure ......................................... 8 2.4.1 Implications of the Adoption of RFC-1255 by PSI ........ 9 2.4.2 Universities and Commercial Entities ................... 10 2.4.3 Naming Structure Below the o=<site> Level .............. 10 2.5 Information Stored in X.500 .............................. 13 2.5.1 Information Security ................................... 14 2.6 Accessing the X.500 Directory Service .................... 14 2.6.1 Directory Service via WHOIS ............................ 15 2.6.2 Directory Service via Electronic Mail .................. 15 2.6.3 Directory Service via FINGER ........................... 15 2.6.4 Directory Service via Specialized Applications ......... 15 2.6.5 Directory Service from PCs and MACs .................... 16 2.7 Services Provided by ESnet ............................... 16 2.7.1 X.500 Operations Mailing List .......................... 17 2.7.2 Accessing the X.500 Directory .......................... 17 2.7.3 Backbone Site Aliases .................................. 18 2.7.4 Multiprotocol Stack Support ............................ 18 2.7.5 Managing a Site's X.500 Information .................... 19 2.7.5.1 Open Availability of Site Information ................ 19 2.7.5.2 Access Methods for Local Users ....................... 19 2.7.5.3 Limitations of Using ESnet Services .................. 20 2.8 ESnet Running a Level-0 DSA for c=US ..................... 20 2.9 X.500 Registration Requirements .......................... 21 2.10 Future X.500 Issues to be Considered .................... 21 2.10.1 ADDMDS Interoperating with PRDMDS ..................... 21 2.10.2 X.400 Interaction with X.500 .......................... 21 2.10.3 Use of X.500 for NIC Information ...................... 22 2.10.4 Use of X.500 for Non-White Pages Information .......... 22 2.10.5 Introduction of New X.500 Implementations ............. 22 2.10.6 Interaction of X.500 and DECdns ....................... 22 3 X.400 - OSI Message Handling Services ...................... 23 3.1 Brief Tutorial ........................................... 23 3.2 ESnet X.400 Logical Backbone ............................. 25 3.3 Naming Structure ......................................... 25 3.3.1 Participating in the ESnet Private Management Domain ... 25 3.3.2 Operating a Site Private Management Domain ............. 26 3.3.3 Detailed Name Structure ................................ 26 3.4 X.400 Routing ............................................ 26 3.4.1 Responsibilities in Operating an X.400 PRMD MTA ........ 28 3.4.2 Responsibilities in Operating an X.400 Organizational MTA 29 3.5 Services Provided by ESnet ............................... 29
1つの序論… 5 1.1の概要と序論… 5 1.2 このDocumentの構造… 5 2X.500--OSIディレクトリサービス… 6 2.1 チュートリアルに事情を知らせてください… 6 2.2 ψホワイトページのパイロットへの参加は突出しています… 7 2.3のお勧めのX.500実現… 7 2.4 構造を命名します… 8 2.4 RFC-1255のpsiの採用の.1の含意… 9 2.4 .2の大学と商業実体… 10 2.4 .3 Structure Belowをoと命名するのは<サイト>Levelと等しいです… 10 X.500に格納された2.5情報… 13 2.5 .1 情報セキュリティ… 14 2.6 X.500ディレクトリサービスにアクセスします… 14 2.6 WHOISを通した.1ディレクトリサービス… 15 2.6 Electronicメールを通した.2ディレクトリサービス… 15 2.6 FINGERを通した.3ディレクトリサービス… 15 2.6 Specialized Applicationsを通した.4ディレクトリサービス… 15 2.6 PCとMACsからの.5ディレクトリサービス… 16 ESnetによって提供された2.7のサービス… 16 2.7 .1X.500操作メーリングリスト… 17 2.7 .2 X.500ディレクトリにアクセスします… 17 2.7 .3 背骨サイト別名… 18 2.7 .4 Multiprotocolはサポートを積み重ねます… 18 2.7 .5 サイトのX.500情報を管理します… 19 2.7 .5 .1 サイト情報の有用性を開いてください… 19 2.7 .5 .2 ローカルユーザーのために方法にアクセスしてください… 19 2.7 .5 ESnetが修理する使用の.3の制限… 20 2.8 cのためにレベル-0DSAを走らせるESnetが米国と等しいです… 20 2.9 X.500登録要件… 21 2.10 Consideredである将来のX.500 Issues… 21 2.10.1 PRDMDSと共に共同利用するADDMDS… 21 2.10.2 X.500とのX.400相互作用… 21 2.10.3 X.500のNIC情報の使用… 22 2.10.4 X.500の非ホワイトページ情報の使用… 22 2.10.5 新しいX.500実現の導入… 22 2.10.6 X.500とDECdnsの相互作用… 22 3 X.400--OSIメッセージ通信処理サービス… 23 3.1 チュートリアルに事情を知らせてください… 23 3.2 ESnet X.400の論理的な背骨… 25 3.3 構造を命名します… 25 3.3 .1 ESnet自営業ドメインに参加します… 25 3.3 .2 サイト自営業ドメインを操作します… 26 .3が詳しく述べた3.3は構造を命名します… 26 3.4 X.400ルート設定… 26 3.4 X.400 PRMD MTAを操作することにおける.1の責任… 28 3.4 3.5のサービスがESnetで提供したX.400の組織的なMTA29を操作することにおける.2の責任… 29
ESCC X.500/X.400 Task Force [Page 2] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[2ページ]RFC1330X.500とX.400プラン
3.5.1 X.400 Operations Mailing List .......................... 30
3.5.2 MTA Routing Table on ESnet Information Server .......... 30
3.5.3 MTA Routing Table Format ............................... 30
3.5.4 Gateway Services and Multiprotocol Stack Support ....... 30
3.5.5 Registering/Listing your PRMD or Organizational MTA with
ESnet .................................................. 31
3.6 X.400 Message Routing Between ADMDS and PRMDS ............ 32
3.7 X.400 Registration Requirements .......................... 32
3.8 Future X.400 Issues to be Considered ..................... 33
3.8.1 X.400 Mail Routing to International DOE Researchers .... 33
3.8.2 X.400 (1984) and X.400 (1988) .......................... 33
3.8.3 X.400 Interaction with X.500 ........................... 33
4 OSI Name Registration and Issues ........................... 33
4.1 Registration Authorities ................................. 34
4.2 Registration Versus Notification ......................... 34
4.3 Sources of Nationally Unique Name Registration ........... 35
4.4 How to Apply for ANSI Organization Names ................. 35
4.5 How to Apply for GSA Organization Names .................. 36
4.5.1 GSA Designated Agency Representatives .................. 36
4.5.2 Forwarding of ANSI Registrations to GSA ................ 37
4.6 How to Apply for U.S. DOE Organization Names ............. 37
4.7 Why Apply for a Trademark with the PTO? .................. 38
4.8 How to Apply for a Trademark with the PTO ................ 38
4.9 Future Name Registration Issues to be Considered ......... 39
4.9.1 ANSI Registered ADMD and PRMD Names .................... 39
Glossary ...................................................... 40
Appendix A: Current Activities in X.500 ...................... 49
Appendix B: Current Activities in X.400 ...................... 55
Appendix C: How to Obtain QUIPU, PP and ISODE ................ 58
Appendix D: Sample X.500 Input File and Restricted Character
List ............................................. 65
Appendix E: ESnet Backbone Sites ............................. 68
Appendix F: Local Site Contacts for DOE Naming Authorities ... 70
Appendix G: Recommended Reading .............................. 77
Appendix H: Task Force Member Information .................... 83
Security Considerations ....................................... 86
Authors' Addresses ............................................ 86
3.5.1 X.400操作メーリングリスト… 30 3.5 .2 ESnet情報サーバのMTA経路指定テーブル… 30 3.5 .3 MTA経路指定テーブル形式… 30 3.5 .4のゲートウェイサービスとMultiprotocolはサポートを積み重ねます… 30 3.5 .5 ESnetと共にあなたのPRMDかOrganizational MTAを登録するか、または記載します… 31 3.6 ADMDSとPRMDSの間のX.400メッセージルーティング… 32 3.7 X.400登録要件… 32 3.8 Consideredである将来のX.400 Issues… 33 3.8 .1 X.400は国際DOE研究者にルート設定を郵送します… 33 3.8 .2 X.400(1984)とX.400(1988)… 33 3.8 X.500との.3X.400相互作用… 33 4 OSIは登録と問題を命名します… 33 4.1の登録局… 34 4.2登録対通知… 34 全国的にユニークな名前登録の4.3の源… 35、4.4、どうANSI組織名に申し込むか… 35、4.5、どうGSA組織名に申し込むか… 36 4.5 .1 GSAは政府機関代表を任命しました… 36 4.5 .2 GSAへのANSI登録証明書の推進… 37、4.6、どう米国DOE組織名に申し込むか… 37 4.7 なぜPTOと共に商標に申し込みますか? .................. 38、4.8、PTOと共に商標にどう申し込むか… 38 4.9 Consideredである将来のName Registration Issues… 39 4.9 .1 ANSIはADMDとPRMD名を登録しました… 39用語集… 40 付録A: X.500の現在の活動… 49 付録B: X.400の現在の活動… 55 付録C: どう結び縄文字、pp、およびISODEを入手するか… 58 付録D: サンプルX.500はファイルを入力して、キャラクターリストを制限しました… 65 付録E: ESnet背骨サイト… 68 付録F: ローカル・サイトはDOEのために命名当局に連絡します… 70 付録G: 読むことを勧めます… 77 付録H: 特別委員会メンバー情報… 83 セキュリティ問題… 86人の作者のアドレス… 86
ESCC X.500/X.400 Task Force [Page 3] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[3ページ]RFC1330X.500とX.400プラン
Recommendations for the Phase I Deployment of
OSI Directory Services (X.500) and
OSI Message Handling Services (X.400)
within the ESnet Community
フェーズのためのOSIディレクトリサービス(X.500)とOSIメッセージハンドリングのI展開がESnet共同体の中で(X.400)を修理するという推薦
ESnet Site Coordinating Committee X.500/X.400 Task Force
ESnetサイト協調委員会X.500/X.400特別委員会
Version 1.1
バージョン1.1
March 1992
1992年3月
Status of this Document
このDocumentの状態
This document makes recommendations for the Phase I deployment of OSI Directory Services and OSI Message Handling Services within the ESnet Community. This document is available via anonymous FTP on the ESnet Information Server (nic.es.net, 128.55.32.3) in the directory [ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT. The distribution of this document is unlimited.
このドキュメントはESnet Communityの中でPhase Iのための推薦状をOSIディレクトリサービスとOSI Message Handling Servicesの展開にします。 このドキュメントがESnet情報Serverの上の公開FTPで利用可能である、(nic.es.net、128.55 .32 .3) ファイルESNET-X500-X400-バージョン1-1.TXTのディレクトリ[ANONYMOUS.ESNET-DOC]で。 このドキュメントの分配は無制限です。
Acknowledgments
承認
The following individuals have participated in and contributed to the ESCC X.500/X.400 Task Force. Several of these individuals have also authored portions of this document. See Appendix H for additional information regarding task force members and contributing authors.
以下の個人は、ESCC X.500/X.400 Task Forceに参加して、貢献しました。 また、何人かのこれらの個人がこのドキュメントの一部を書きました。 特別委員会のメンバーと作者を寄付することに関する追加情報に関してAppendix Hを見てください。
Allen Sturtevant (Chair) Lawrence Livermore National Laboratory Bob Aiken U.S. DOE/OER/SCS (now with NSF) Joe Carlson Lawrence Livermore National Laboratory Les Cottrell Stanford Linear Accelerator Center Tim Doody Fermi National Accelerator Laboratory Tony Genovese Lawrence Livermore National Laboratory Arlene Getchell Lawrence Livermore National Laboratory Charles Granieri Stanford Linear Accelerator Center Kipp Kippenhan Fermi National Accelerator Laboratory Connie Logg Stanford Linear Accelerator Center Glenn Michel Los Alamos National Laboratory Peter Mierswa Digital Equipment Corporation Jean-Noel Moyne Lawrence Berkeley Laboratory Kevin Oberman Lawrence Livermore National Laboratory Dave Oran Digital Equipment Corporation Bob Segrest Digital Equipment Corporation Tim Streater Stanford Linear Accelerator Center Mike Sullenberger Stanford Linear Accelerator Center Alan Turner Pacific Northwest Laboratory Linda Winkler Argonne National Laboratory Russ Wright Lawrence Berkeley Laboratory
アレン・スタートバント(議長)ローレンス・リバモア国立研究所ボブエーケン米国; DOE/OER/SCS(現在、NSFと)ジョー・カールソン・ローレンス・リバモア国立研究所レス・コットレル・スタンフォード線型加速器センターティム・ドゥーディ・フェルミ国立加速研究所トニー・Genoveseローレンス・リバモア国立研究所アーリン・ゲッチェル・ローレンス・リバモア国立研究所チャールズ・Granieriスタンフォード線型加速器センターキップ・Kippenhanフェルミ国立加速研究所コニー・Loggスタンフォード線型加速器センターグレン・ミシェル・ロスアラモス国家です; 研究所ピーターMierswa DECジーン-Noel Moyneローレンスバークレイ研究所ケビンObermanローレンス・リバモア国立研究所デーヴオランディジタルイクイップメント社ボブSegrest DECティムStreaterスタンフォード線型加速器センターマイクSullenbergerスタンフォード線型加速器センターアランターナーパシフィックノースウェスト研究所リンダ地上げ屋アルゴンヌ国立研究所ラス職人ローレンスバークレイ研究所
ESCC X.500/X.400 Task Force [Page 4] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[4ページ]RFC1330X.500とX.400プラン
1. Introduction
1. 序論
1.1. Abstract and Introduction
1.1. 概要と序論
This document recommends an initial approach for the Phase I deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet community. It is anticipated that directly connected ESnet backbone sites will participate and follow the suggestions set forth in this document.
このドキュメントはESnet共同体の中でOSIディレクトリサービス(X.500)とOSI Message Handling Services(X.400)のI展開をPhaseのための初期のアプローチに推薦します。 直接接続されたESnet背骨サイトが参加して、本書では詳しく説明された提案に続くと予期されます。
Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March 1991) cites the need for further research and investigation in the areas of electronic mail and directory services. The ESCC X.500/X.400 Task Force was created to address this need. Additionally, the task force is addressing the issues of a coordinated, interoperable deployment of OSI Directory Services and OSI Message Handling within the entire ESnet community. Since only a small subset of this community is actively pursuing these avenues, considerable effort must be made to establish the necessary "base" to build upon. If directly connected ESnet sites participate in these services, a consistent transition path will be ensured and the services provided will be mutually valuable and useful.
「ESnetプログラムプラン」(時代遅れの1991年3月のDOE/OER-0486T)のセクション7は電子メールと電話番号案内の領域でさらなる研究と調査の必要性を引用します。 ESCC X.500/X.400 Task Forceは、この必要性を記述するために作成されました。 さらに、特別委員会は全体のESnet共同体の中にOSIディレクトリサービスとOSI Message Handlingの連携していて、共同利用できる展開の問題を記述しています。 この共同体の小さい部分集合だけが活発にこれらの大通りにつきまとっているので、当てにする必要な「ベース」を設立するのをかなりの努力をしなければなりません。 提供されたサービスは、直接接続されたESnetサイトがこれらのサービスに参加すると、一貫した変遷経路が確実にされて、互いに貴重であって、役に立ちます。
X.500 and X.400 are continuously evolving standards, and are typically updated every four years. U.S. GOSIP (Government OSI Profile) Requirements are updated to define additional functionality as needed by the U.S. Federal Government, usually every two years. As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements are extended, consideration must be given as to the effect this may have on these existing services in the ESnet community. At these cross-roads, or when a sizeable increase in service functionality is desired, another "phase of deployment" may be in order. In this sense, there isn't a specific "final phase" goal, but rather several new releases (updates) to the level of existing services.
X.500とX.400を絶え間なく規格を発展していて、4年毎に通常アップデートします。 必要に応じて米国連邦政府、通常2年毎で追加機能性を定義するためにU.S. GOSIP(政府OSI Profile)要件をアップデートします。 X.500とX.400規格が発展して、米国GOSIP Requirementsが拡張されているのに従って、これがこれらの既存のサービスのときにESnet共同体に持っているかもしれない効果に関して考慮を払わなければなりません。 これらの交差点かそれともサービスの機能性のかなり大きい増加がいつ望まれているかとき、別の「展開のフェーズ」は整然としているかもしれません。 この意味で、特定の「最終段階」目標、しかし、既存にサービスのレベルへのむしろいくつかの新版(アップデート)がありません。
1.2. Structure of this Document
1.2. このDocumentの構造
X.500 is presented first. The issues of DSA (Directory Service Agent) deployment, DSA registration, naming schema, involvement in the PSI White Pages Pilot Project, recommended object classes, recommended attribute types, information security, search optimization, user friendly naming and update frequency are addressed.
最初に、X.500を寄贈します。 DSA(ディレクトリサービスエージェント)展開の問題、DSA登録、図式を命名して、PSIホワイトページPilot Projectのかかわり合い(お勧めの物のクラス)は属性タイプ、情報セキュリティ、検索最適化、ユーザフレンドリーな命名、およびアップデート頻度が宛てられることを勧めました。
In the area of X.400, issues relating to MTA (Message Transfer Agent) deployment, ESnet X.400 well-known entry points, ESnet backbone site X.400 well-known entry points, MTA registration, naming hierarchy, PRMD peering, bidirectional X.400-SMTP relaying and
そしてX.400の領域、MTA(メッセージTransferエージェント)展開に関係する問題では、ESnet X.400の周知のエントリーは指します、ESnet背骨サイトX.400周知のエントリー・ポイント、MTA登録、階層構造、PRMDのじっと見る双方向のX.400-SMTPリレーを命名して。
ESCC X.500/X.400 Task Force [Page 5] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[5ページ]RFC1330X.500とX.400プラン
private/commercial X.400 routing are discussed.
個人的であるか商業のX.400ルーティングについて議論します。
Finally, the issues in name registration with ANSI (American National Standards Institute), GSA (General Services Administration) and the U.S. Department of Commerce, Patent and Trademark Office (PTO) are discussed.
最終的に、ANSI(American National Standards Institut)、GSA(共通役務庁)と商務省、米国特許・商標局(PTO)との名前登録における問題について議論します。
2. X.500 - OSI Directory Services
2. X.500--OSIディレクトリサービス
2.1. Brief Tutorial
2.1. 簡潔なチュートリアル
X.500 is a CCITT/ISO standard which defines a global solution for the distribution and retrieval of information (directory service). The X.500 standard includes the following characteristics: decentralized management, powerful searching capabilities, a single global namespace, and a structured framework for the storage of information. The 1988 version of the X.500 standard specifies four models to define the Directory Service: the Information Model, the Functional Model, the Organizational Model and the Security Model. As is the nature of International standards, work continues on the 1992 X.500 standard agreements.
X.500は分配と情報の検索(電話番号案内)のグローバルな解決策を定義するCCITT/ISO規格です。 X.500規格は以下の特性を含んでいます: 管理、強力な探す能力、ただ一つのグローバルな名前空間、および構造化された枠組みを情報の格納に分散しました。 1988年のX.500規格のバージョンはディレクトリサービスを定義するために4つのモデルを指定します: 情報モデル、機能論的モデル、組織的なモデル、およびセキュリティはモデル化されます。 国際規格の本質のように、仕事は1992年のX.500の標準の協定で続きます。
The Information Model specifies how information is defined in the directory. The Directory holds information objects, which contain information about "interesting" objects in the real-world. These objects are modeled as entries in an information base, the Directory Information Base (DIB). Each entry contains information about one object: ie, a person, a network, or an organization. An entry is constructed from a set of attributes each of which holds a single piece of information about the object. For example, to build an entry for a person the attributes might include "surname", "telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail address), "mhsORAddresses" (X.400 mail address) and "facsimileTelephoneNumber". Each attribute has an attribute syntax which describes the data that the attribute contains, for example, an alphanumeric string or photo data. The OSI Directory is extensible in that it defines several common types of objects and attributes and allows the definition of new ones as new applications are developed that make use of the Directory. Directory entries are arranged in a hierarchical structure, the Directory Information Tree (DIT). It is this structure which is used to uniquely name entries. The name of an entry is its Distinguished Name (DN). It is formed by taking the DN of the parent's entry, and adding the the Relative Distinguished Name (RDN) of the entry. Along the path, the RDNs are collected, each naming an arc in the path. Therefore, a DN for an entry is built by tracing the path from the root of the DIT to the entry.
情報Modelは情報がディレクトリでどう定義されるかを指定します。 ディレクトリは情報物を保持します。(物は本当の世界に「おもしろい」物の情報を保管しています)。 これらの物はエントリーとして情報ベース、ディレクトリInformation基地(DIB)の中でモデル化されます。 各エントリーは情報およそ1物を含んでいます: ie、人、ネットワーク、または組織。 エントリーはそれのそれぞれが1片の物の情報を保持する1セットの属性から組み立てられます。 例えば、人のためにエントリーを組み込むために、属性は「姓」、"telephoneNumber"、「postalAddress」"rfc822Mailbox"(SMTP郵便の宛先)、「mhsORAddresses」(X.400郵便の宛先)、および"facsimileTelephoneNumber"を含むかもしれません。 各属性に、例えば属性が含むデータ、英数字のストリングまたは写真データについて説明する属性構文があります。 ディレクトリを利用する開発された新しいアプリケーションとして数人の普通形の物と属性を定義して、新しいものの定義を許すので、OSIディレクトリは広げることができます。 ディレクトリエントリーは階層構造、ディレクトリ情報Tree(DIT)に配置されます。 それは唯一エントリーを命名するのに使用されるこの構造です。 エントリーの名前はそのDistinguished Name(DN)です。 それは、親のエントリーのDNを取って、エントリーのRelative Distinguished Name(RDN)を加えることによって、形成されます。 経路に沿って、経路でそれぞれアークを命名して、RDNsは集められます。 したがって、エントリーへのDNは、DITの根からエントリーまで経路をたどることによって、造られます。
The Functional Model defines how the information is stored in the
Functional Modelは情報がどう中に格納されるかを定義します。
ESCC X.500/X.400 Task Force [Page 6] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[6ページ]RFC1330X.500とX.400プラン
directory, and how users access the information. There are two components of this model: the Directory User Agent (DUA), an application-process which interacts with the Directory on behalf of the user, and the Directory System Agent (DSA), which holds a particular subset of the Directory Information Tree and provides an access point to the Directory for a DUA.
ディレクトリと、ユーザはどう情報にアクセスするか。 このモデルの2つの部品があります: ディレクトリUserエージェント(DUA)(ユーザを代表してディレクトリと対話して、DUAのために、ディレクトリSystemエージェント(DSA)と対話するアプリケーション・プロセス)。そのエージェントは、ディレクトリ情報Treeの特定の部分集合を保持して、アクセスポイントをディレクトリに提供します。
The Organizational Model of the OSI Directory describes the service in terms of the policy defined between entities and the information they hold. The model defines how portions of the DIT map onto DSAs. A Directory Management Domain (DMD) consists of one or more DSAs, which collectively hold and manage a portion of the DIT.
OSIディレクトリのOrganizational Modelは実体の間で定義された方針とそれらが保持する情報に関してサービスについて説明します。 モデルはその方法を定義します。DSAsへのDIT地図の一部。 ディレクトリManagement Domain(DMD)を1DSAsから成らせます。(DSAsはDITの一部をまとめて保持して、管理します)。
The Security Model defines two types of security for Directory data: Simple Authentication (using passwords) and Strong Authentication (using cryptographic keys). Authentication techniques are invoked when a user or process attempts a Directory operation through a DUA.
Security Modelはディレクトリデータのために2つのタイプのセキュリティを定義します: 簡単なAuthentication(パスワードを使用する)とStrong Authentication(暗号化キーを使用します)。 ユーザか過程がDUAを通してディレクトリ操作を試みると、認証のテクニックは呼び出されます。
2.2. Participation in the PSI White Pages Pilot Project
2.2. ψホワイトページ試験計画への参加
The PSI White Pages Pilot Project is currently the most well- established X.500 pilot project within the United States. For the country=US portion of the DIT, PSI currently has over 80 organization names registered. Of these, several are ESnet-related.
PSIホワイトページPilot Projectは合衆国の中の現在最も良い設立したX.500試験計画です。 DITの国=米国部分に、PSIは現在、80以上の組織名を登録させます。 これらでは、数個がESnet関連です。
The PSI White Pages Pilot Project is also connected to the Pilot International Directory Service, PARADISE. This pilot project interconnects X.500 Directory Services between Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and Yugoslavia. The combined totals for all of these countries (including the United States) as of December 1991 are:
PARADISE、また、PSIホワイトページPilot ProjectはPilotの国際ディレクトリサービスに接続されます。 この試験計画はオーストラリアと、オーストリアと、ベルギーと、カナダと、デンマークと、フィンランドと、フランスと、ドイツと、ギリシアと、アイスランドと、アイルランドと、イスラエルと、イタリアと、日本と、ルクセンブルクと、オランダと、ニュージーランドと、ノルウェーと、ポルトガルと、スペインと、スウェーデンと、スイスと、イギリスとユーゴスラビアの間のX.500ディレクトリサービスとインタコネクトします。 1991年12月現在これらの国(合衆国を含んでいる)のすべてのための結合した合計は以下の通りです。
DSAs: 301
Organizations: 2,132
White Pages Entries: 581,104
DSAs: 301の組織: 2,132 ホワイトページエントリー: 581,104
Considering the large degree of national, and international, connectivity within the PSI White Pages Pilot Project, it is recommended that directly connected ESnet backbone sites join this pilot project.
PSIホワイトページPilot Projectの中で大きい度の国家的、そして、国際的な接続性を考える場合、直接接続されたそれはESnet背骨サイトがこの試験計画に加わることが勧められます。
2.3. Recommended X.500 Implementation
2.3. お勧めのX.500実現
Interoperability testing has not been performed on most X.500 implementations. Further, some X.500 functions are not mature standards and are often added by implementors as noninteroperable
相互運用性テストはほとんどのX.500実現に実行されていません。 さらに、いくつかのX.500機能が、熟している規格でなく、「非-共同利用でき」として作成者によってしばしば加えられます。
ESCC X.500/X.400 Task Force [Page 7] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[7ページ]RFC1330X.500とX.400プラン
extensions.
拡大。
To ensure interoperability for the entire ESnet community, the University College London's publicly available X.500 implementation (QUIPU) is recommended. This product is known to run on several UNIX-derivative platforms, operates over CLNS and RFC-1006 (with RFC-1006 being the currently recommended stack), and is currently in wide-spread use around the United States and Europe, including several ESnet backbone sites.
全体のESnet共同体に相互運用性を確実にするために、ユニバーシティ・カレッジロンドンの公的に利用可能なX.500実現(QUIPU)はお勧めです。 この製品は、いくつかのUNIX-派生物プラットホームで走るのが知られて、CLNSとRFC-1006(現在お勧めのスタックであるRFC-1006での)の上で作動して、現在合衆国とヨーロッパの周りで広範囲に使用中です、いくつかのESnet背骨サイトを含んでいて。
Appendix C contains information on how to obtain QUIPU.
付録CはどうQUIPUを入手するかの情報を含んでいます。
A later phase deployment of X.500 services within the ESnet community will recommend products (either commercial or public domain) which pass conformance and interoperability tests.
ESnet共同体の中のX.500サービスの後期展開は順応と相互運用性テストに合格する製品(コマーシャルか公共の場のどちらか)を推薦するでしょう。
2.4. Naming Structure
2.4. 構造を命名します。
As participants in the PSI White Pages Pilot Project, ESnet backbone sites will align with the naming structure used by the Pilot. This structure is based upon a naming scheme for the US portion of the DIT developed by the North American Directory Forum (NADF) and documented in RFC-1255. Using this scheme, an organization with national standing would be listed directly under the US node in the global DIT. Organizations chartered by the U.S. Congress as well as organizations who have alphanumeric nameforms registered with ANSI are said to have national standing. Therefore, a backbone site which is a national laboratory would be listed under country=US:
PSIホワイトページPilot Projectの関係者として、ESnet背骨サイトはPilotによって使用される命名構造に並ぶでしょう。 この構造は、北米のディレクトリForum(NADF)によって開発されたDITの米国の部分の命名計画に基づいていて、RFC-1255に記録されます。 この計画を使用して、国家の地位がある組織はグローバルなDITの米国ノードの直接下で記載されているでしょう。 英数字のnameformsをANSIに登録させる組織と同様に米国議会によってチャーターされた組織は国家の地位を持っていると言われています。 したがって、国家の実験室である背骨サイトは国=の米国の下に記載されているでしょう:
@c=US@o=Lawrence Livermore National Laboratory
@c= US@o はローレンス・リバモア国立研究所と等しいです。
As would a site with an ANSI-registered organization name:
ANSIによって登録された組織とのサイトであるだろうことのように、以下を命名してください。
@c=US@o=National Energy Research Supercomputer Center
@c= US@o は国家のエネルギー研究スーパーコンピュータセンターと等しいです。
A university would be listed below the state in which it is located:
大学はそれが位置している状態の下に記載されているでしょう:
@c=US@st=Florida@o=Florida State University
@c= フロリダ US@st =@oはフロリダ州立大学と等しいです。
And a commercial entity would be listed under the city or state in which it is doing business, or "Doing Business As", depending upon where its DBA is registered:
そして、商業実体は、都市の下に記載されているか、またはDBAがどこによって、それがビジネスをするか、または「ビジネスをしている」もので登録されているかを述べるでしょう:
@c=US@st=California@o=General Atomics
(or)
@c=US@st=California@l=San Diego@o=General Atomics
@c= US@st =カリフォルニア@o=一般原子学(or)@c= US@st は一般カリフォルニア@l=サン Diego@o =原子学と等しいです。
A list of the current ESnet backbone sites, and their locations, is
現在のESnet背骨サイトのリスト、およびそれらの位置があります。
ESCC X.500/X.400 Task Force [Page 8] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[8ページ]RFC1330X.500とX.400プラン
provided in Appendix E.
付録Eに供給します。
Directly connected ESnet backbone sites will be responsible for administering objects which reside below their respective portions of the DIT. Essentially, they must provide their own "Name Registration Authority". Although this may appear as an arduous task, it is nothing more than the establishment of a procedure for naming, which ensures that duplicate entries do not occur at the same level within a sub-tree of the DIT. For example, the Name Registration Authority for MIT could create an Organizational Unit named "Computer Science". This would appear in the DIT as:
直接接続されたESnet背骨サイトはそれらのDITのそれぞれの部分の下にある物を管理するのに原因となるようになるでしょう。 本質的には、彼らはそれら自身の「名前登録局」を提供しなければなりません。 これは激務として現れるかもしれませんが、それはただ命名のための手順の確立です。(命名は写しエントリーがDITの下位木の中に同じレベルで現れないのを確実にします)。 例えば、MITのためのName Registration Authorityは「コンピュータサイエンス」というOrganizational Unitを作成できました。 これは以下としてDITに現れるでしょう。
@c=US@st=Massachusetts@o=MIT@ou=Computer Science
@c= マサチューセッツ@o= US@st = MIT@ou はコンピュータサイエンスと等しいです。
Similarly, all other names created under the "@c=US@st=Massachusetts@o=MIT" portion of the DIT would be administered by the same MIT Name Registration Authority. This ensures that every Organizational Unit under "@c=US@st=Massachusetts@o=MIT" is unique. By default, each ESnet Site Coordinator is assumed to be the Name Registration Official for their respective site. If an ESnet Site Coordinator does not wish to act in this capacity, they may designate another individual, at their site, as the Name Registration Official.
」 @c= US@st はマサチューセッツ@o=MITと等しいです。「同様に、他のすべての名前が下を作成した、」 DITの一部が同じMIT Name Registration Authorityによって管理されるでしょう。 「これは、」 @cの下のあらゆるOrganizational Unitが US@st =マサチューセッツ@o=MITと等しいのを確実にすること」がユニークです。 デフォルトで、各ESnet Site CoordinatorはそれらのそれぞれのサイトへのName Registration Officialであると思われます。 ESnet Site Coordinatorがこの立場で行動したくないなら、彼らは別の個人を任命するかもしれません、それらのサイトで、Name Registration Officialとして。
2.4.1. Implications of the Adoption of RFC-1255 by PSI
2.4.1. RFC-1255のpsiの採用の含意
The North American Directory Forum (NADF) is comprised of commercial vendors positioning themselves to offer commercial X.500 Directory Services. The NADF has produced several documents since its formation. The ones of notable interest are those which define the structure and naming rules for the commercially operated DIT under country=US. Specifically, for an Organization to exist directly under c=US, it must be an organization with national-standing. From pages 12-13 of RFC-1255, national-standing is defined in the following way:
北米のディレクトリForum(NADF)は商業X.500ディレクトリサービスを提供するために自分たちを置く商業業者から成ります。 構成以来NADFはいくつかのドキュメントを製作しています。 注目に値する関心のひとりは、構造を定義するものであり、商業的に操作されたDITのための国=の下の規則を米国と命名しています。 明確に、Organizationがc=米国の直接下に存在するように、それは国家の地位がある組織でなければなりません。 12-13RFC-1255ページから、国家の地位は以下の方法で定義されます:
"An organization is said to have national-standing if it is
chartered (created and named) by the U.S. Congress. An example
of such an organization might be a national laboratory. There
is no other entity which is empowered by government to confer
national-standing on organizations. However, ANSI maintains an
alphanumeric nameform registration of organizations, and this
will be used as the public directory service basis for
conferring national-standing on private organizations."
「それが米国議会によってチャーターされるなら(作成されて、命名されます)、組織は国家の地位を持っていると言われます。」 そのような組織に関する例は国家の実験室であるかもしれません。 国家の地位を組織に授与するのに政府によって権限を与えられる他の実体は全くありません。 「しかしながら、ANSIは組織の英数字のnameform登録を維持します、そして、これは国家の地位を民間に授与する公共の電話番号案内基礎として使用されるでしょう。」
Thus, it appears that National Laboratories (e.g. LBL, LLNL) are considered organizations with national-standing. However, those ESnet backbone sites which are not National Laboratories may wish to
したがって、National研究所(例えば、LBL、LLNL)が国家の地位がある組織であると考えられるように見えます。 しかしながら、National研究所でないそれらのESnet背骨サイトはそうしたがっているかもしれません。
ESCC X.500/X.400 Task Force [Page 9] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[9ページ]RFC1330X.500とX.400プラン
register with ANSI to have their organization list directly under c=US, but only if this is what they desire. It is important to note that NADF is not a registration authority, but a group of service providers defining a set of rules for information sharing and mutual interoperability in a commercial environment.
cの直接下のそれらの組織リストがこれが彼らが望んでいることである場合にだけ米国との等しさにするようにANSIとともに記名してください。 NADFが登録局ではなく、情報共有と互いの相互運用性のために商業環境で1セットの規則を定義するサービスプロバイダーのグループであることに注意するのは重要です。
For further information on registering with ANSI, GSA or the U.S. Patent and Trademark office, refer to Section 4 of this document. For more information on PSI, refer to Appendix A.
ANSIかGSAか米国PatentとTrademarkオフィスとともに記名する詳細について、このドキュメントのセクション4を参照してください。 PSIに関する詳しい情報について、Appendix Aを参照してください。
2.4.2. Universities and Commercial Entities
2.4.2. 大学と商業実体
Several of the ESnet backbone sites are not National Laboratories (e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Typically, at these sites, a small collection of researchers are involved in performing DOE/OER funded research. Thus, this set of researchers at a given site may not adequately represent the total X.500 community at their facility. Additionally, ESnet Site Coordinators at these facilities may not be authorized to act as the Name Registration Official for their site. So the question is, how do these sites participate in the recommended Phase I deployment of ESnet X.500 services. There are two possible solutions for this dilemma:
いくつかのESnet背骨サイトはNational研究所(例えば、CIT、FSU、ジョージア、ISU、MIT、NYU、UCLA、およびUTA)ではありません。 通常、サイト、これらの研究者のわずかな収集はDOE/OER受託研究を実行するのにかかわります。 したがって、与えられたサイトのこのセットの研究者は彼らの施設で適切に総X.500共同体を代表しないかもしれません。 さらに、これらの施設のESnet Site CoordinatorsがそれらのサイトへのName Registration Officialとして機能するのが認可されないかもしれません。 それで、質問があって、これらのサイトはどのようにESnet X.500サービスのお勧めのPhase I展開に参加しますか? このジレンマの2つの可能な解決策があります:
1. If the site is not currently operating an X.500 DSA, the ESnet
Site Coordinator may be able to establish and administer a
DSA to master the DOE/OER portion of the site's local DIT,
e.g. "@c=US@st=<st>@o=<site>@ou=Physics". Before attempting
this action, it would be prudent for the Site Coordinator to
notify or seek approval from some responsible entity. At such
time that the site wishes to manage its own organization
within the X.500 DIT, the ESnet Site Coordinator would have to
make arrangements to put option 2 into effect.
1. 「サイトであるなら、現在のX.500 DSA、ESnet Site Coordinatorが設立して、管理できるかもしれない作動は例えばサイトの地方のDITのDOE/OER部分を習得するDSAではありません」@cが US@st =と等しい、lt;、 st>@o が等しい、lt;、 site>@ou が物理学と等しい、」 この動作を試みる前に、Site Coordinatorが何らかの原因となる実体から承認を通知するか、または求めるのが、慎重でしょう。 サイトがX.500 DITの中でそれ自身の組織を経営したがっているくらいの時に、ESnet Site Coordinatorは効果へのプットオプション2に支度しなければならないでしょう。
2. If the site is currently operating an X.500 DSA, the ESnet
Site Coordinator may be able to work out an agreement with the
current DSA administrator to administer a portion of the
site's local DIT which would represent the DOE/OER community
at that site. For example, if the site were already
administering the organization "@c=US@st=
Massachusetts@o=Massachusetts Institute of Technology", the
ESnet Site Coordinator might then be able to administer the
organizational unit "@c=US@st=Massachusetts@o=Massachusetts
Institute of Technology@ ou=Physics".
2. サイトが現在X.500 DSAを操作しているなら、ESnet Site Coordinatorは、そのサイトでDOE/OER共同体を代表するサイトの地方のDITの一部を管理するために現在のDSA管理者との協定を考え出すことができるかもしれません。 「例えば、サイトは既に」 @c組織= US@st = Massachusetts@o =マサチューセッツ工科大学を管理していた」なら、ESnet Site Coordinatorがその時マサチューセッツ@o=マサチューセッツ工科大学@ou=」 @c組織的なユニット= US@st =物理学を管理できるかもしれない、」
2.4.3. Naming Structure Below the o=<site> Level
2.4.3. o=<サイト>LevelとStructure Belowを命名します。
The structure of the subtree below the organization's node in the DIT is a matter for the local organization to decide. A site's DSA
DITの組織のノードの下における下位木の構造は地方の組織が決める問題です。 サイトのDSA
ESCC X.500/X.400 Task Force [Page 10] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[10ページ]RFC1330X.500とX.400プラン
manager will probably want to enlist input from others within the organization before deciding how to structure the local DIT.
地方のDITを構造化する方法を決める前に、マネージャはたぶん組織の中で他のものからの入力を得たくなるでしょう。
Some organizations currently participating in the Pilot have established a simple structure, choosing to limit the number of organizational units and levels of hierarchy. Often this is done in order to optimize search performance. This approach has the added benefit of insulating the local DIT from administrative restructuring within the organization. Others have chosen to closely model their organization's departmental structure. Often this approach seems more natural and can enhance the information obtained from browsing the Directory.
現在Pilotに参加するいくつかの組織が単純構造を確立しました、組織的なユニットとレベルの階層構造の数を制限するのを選んで。 しばしば、検索性能を最適化するためにこれをします。 このアプローチには、組織の中で管理企業再構築から地方のDITを隔離する付加利益があります。 他のものは、密接に彼らの組織の部門の構造をモデル化するのを選びました。 このアプローチは、しばしば、より自然に見えて、ディレクトリをブラウズするのから得られた情報を高めることができます。
Below are experiences from current DSA managers, describing the way they structured their local DIT and the reasons for doing so. A site may find this information helpful in determining how to structure their local DIT. Ultimately this decision will depend upon the needs of the local organization and expectations of Directory usage.
以下に、現在のDSAマネージャからの経験があります、彼らが地元のDITを構造化した方法とそうする理由を述べて。 サイトによって、この情報が地元のDITを構造化する方法を決定するのに有用であることがわかるかもしれません。 結局、この決定は地方の組織の必要性とディレクトリ用法への期待によるでしょう。
Valdis Kletnieks of the Virginia Polytechnic Institute:
バージニア州工芸協会のヴァルディスKletnieks:
"For Virginia Tech, it turned out to be a reasonably
straightforward process. Basically, the University is
organized on a College/Department basis. We decided to model
that "real" structure in the DIT for two major reasons:
「バージニア工科大に関して、合理的に簡単な過程であると判明しました。」 基本的に、大学は大学/部のベースで組織化されます。 私たちは、2つの主要な理由でDITのその「本当」の構造をモデル化すると決めました:
"(a) It duplicates the way we do business, so interfacing the
X.500 directory with the "real world" is easier.
「(a) 私たちがビジネスをする方法をコピーするので、「本当の世界」にX.500ディレクトリを連結するのは、より簡単です。」
"(b) With 600+ departmental units and 11,000+ people (to be
30,000+ once we add students), a "zero" (everybody at top) or
"one" deep (600 departments at top) arrangement just didn't
hack it - it was deemed necessary that you be able to do a
some 120 or 140 county office entries under the Extension
service, it's a BIT unwieldy there). However, with some 20
college-level entries at the top, and the "average" college
having 30 departments, and the "average" department being from
10 to 40 people, it works out pretty well."
「(b) 600+部門のユニットと1万1000で、+ 人々(私たちがいったん学生を加えたあとに、3万+になる)、aは(先端のみんな)か「1つ」を深く「ゼロに合わせる」(先端の600の部) アレンジメントはただそれをハックしませんでした--あなたがExtensionサービスの下の120か140のカウンティーのオフィスエントリーがaにいくつかできるのが必要です、それがそこで扱いにくいBITであると考えられました)。」 「しかしながら、先端のおよそ20の大学レベルエントリー、30の部を持っている「平均した」大学、および10〜40人の人である「平均した」部と共にかなりよく解決します。」
Jeff Tannehill of Duke University:
デューク大学のジェフTannehill:
"Our DIT is flat. We get the entire database of people at Duke
from Tel-Com and just put everyone directly under "O=Duke
University".
「私たちのDITは平坦です。」 私たちは、デュークでTel-Comから人々の全体のデータベースを得て、ただ直接皆を「Oはデューク大学と等しく」下に置きます。
"Actually, there is an exception, when the DSA was first set up
and we had not received a database yet, I configured the DIT to
include "OU=Computer Science", under which myself and one other
「DSAが第一セットであったときに、実際に、例外が上にありました、そして、私たちはデータベースを受け取っていませんでしたが、私は「OU=コンピュータサイエンス」を含むようにDITを構成しました、下である、どれ、自分とあるもう一方、」
ESCC X.500/X.400 Task Force [Page 11] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[11ページ]RFC1330X.500とX.400プラン
System Administrator have entries. Upon getting the database
for everyone else I decided not to attempt to separate the
people in the database into multiple ou's."
システムAdministratorには、エントリーがあります。 「他の人皆にデータベースを届けるとき、私は、データベースでouの複数のものに人々を切り離すのを試みないと決めました。」
Joe Carlson of Lawrence Livermore National Laboratory:
ローレンス・リバモア国立研究所のジョー・カールソン:
"We tried both flat (actually all under the same OU) and
splitting based on internal department name and ended up with
flat. Our primary reason was load and search times, which were
2-3 times faster for flat organization."
「私たちは、アパート(実際に同じOUの下の)と内部の部の名に基づく分かれることの両方を試みて、アパートで終わりました。」 「私たちのプライマリ理由は、負荷と検索時間でした。」2-3 (平坦な組織には、時間は何倍も、より速かったです)。
Paul Mauvais of Portland State University:
ポートランドのポールMauvaisは大学を述べます:
"We originally set up our DIT by simply loading our campus
phone book into one level down from the top (e.g. OU=Faculty
and Staff, OU=Students, OU=Computing Services).
「私たちは元々、先端から1つのレベルへの私たちのキャンパス電話帳を単にどっさり積むことによって、DITをセットアップします(例えば、OUが教授陣とStaffと等しいです、OU=学生、OU=コンピューターサービス)。」
"I'd love to have an easy way to convert our flat faculty and
staff area into departments and colleges, but the time to
convert the data into the separate OU's is probably more than I
have right now."
「私は、私たちの平坦な教授陣とスタッフ領域を部と大学に変換する簡単な方法が欲しいと思いますが、別々のOUのものにデータを変換する時間はたぶんたった今、私にはある以上です。」
Mohamed Ellozy of Dana-Farber Cancer Institute:
ダナ-ファーバー癌協会のモハメドEllozy:
"Here we have a phone database that includes department, so we
got the ou's with no effort. We thus never went the flat space
way."
「ここに、部を含んでいる電話データベースを持っているので、私たちは取り組みなしでouのものを手に入れました。」 「その結果、私たちは平坦なスペース方法で決して行きませんでした。」
Dan Moline of TRW:
TRWのダンモーリン:
"Well - we're still in the process of defining our DIT. TRW
comes under the international companies DBA. Our part under
the PSI White Pages Pilot defines the DIT for our space and
defense organization here in Redondo Beach (however, I
organized the structure to adhere to TRW corporate). We input
from our manpower DB for our S&D personnel. We're trying to
get corporate's DB for possible input.
「さて--まだ私たちのDITを定義することの途中に私たちはいます。」 TRWは国際的な会社のDBAに該当します。 PSIホワイトページPilotの下の私たちの部分はここ、リドンドビーチの私たちのスペースと防衛機構のためにDITを定義します(しかしながら、私は、構造がTRW法人に付着するのを組織化しました)。 私たちはS&D人員のために私たちの労働力からDBを入力しました。 私たちは得ようとして、法人であることが、可能な入力のためのDBであるということです。
"However, arranging your DIT by organizations (at least for
corps) presents a problem; things are always being reorganized!
We were DSO now we're SSO!!! We still have some of our old
domain name for DNS tied to organizations that have not existed
for years!
「しかしながら、組織(少なくとも軍団のための)であなたのDITをアレンジすると、問題は提示されます」。 ものはいつも再編成されています! 今や、私たちはDSOでした。SSOです! 私たちはDNSのための私たちの古いドメイン名のいくつかを長年存在していない組織にまだ結ばせています!
"So we are currently redesigning our DIT to try to fit NADF 175
(something more geographically). Our reasoning was that
organizations may change but buildings and localities do not."
「したがって、私たちが現在NADF175に合おうとするようにDITを再設計している、(何か、 より地理的)、」 「私たちの推理は組織が変化するかもしれないということでしたが、ビルと場所はことであったというわけではありません。」
ESCC X.500/X.400 Task Force [Page 12] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[12ページ]RFC1330X.500とX.400プラン
Ruth Lang of SRI:
様のルース・ラング:
"There has been no SRI-wide policy or decision to participate
in the PSI White Pages Pilot. @c=US@O=SRI International
supports the information for one OU only (i.e., a local policy
and decision). In order to not give the false impression that
all SRI information was contained under this O=SRI
International, I used OU=Network Information Systems Center.
If I were to structure the DIT for all of SRI, I'm sure that my
thinking would yield a much different structure."
「PSIホワイトページPilotに参加するために、どんなSRI全体の方針も決定もありませんでした。」 @c= US@O =SRIインターナショナルは、1OUのための情報が(すなわち、ローカルの方針と決定)であるだけであるとサポートします。 すべてのSRI情報がこのO=SRIインターナショナルの下に含まれたという間違った印象を与えないように、私はネットワーク情報システムOU=センターを使用しました。 「SRIのすべてのためにDITを構造化するつもりであったなら、私は私の考えが多くの異なった構造をもたらすのを確信しています。」
Russ Wright of Lawrence Berkeley Laboratory:
ローレンスバークレイ研究所のラス・ライト:
"Since we don't have much organizational information in current
staff database, I have to stick to a fairly flat structure. I
have two OUs. One is for permanent staff, the other is for
guests (there is a flag in our database that is set for
guests).
「私たちには現在のスタッフデータベースの多くの組織的な情報がないので、私はかなり平坦な構造に執着しなければなりません。」 私は2OUsを持っています。 1つは永久的なスタッフのためのものであり、もう片方がゲストのためのもの(ゲストに設定される私たちのデータベースには旗がある)です。
"I may add an additional level of OUs to our current structure.
The top level would contain different 'types' of information.
For example, one OU may be 'Personnel', another may be called
publications). Staff and Guests would reside under the
Personnel OU."
「私はOUsの追加レベルを私たちの現在の構造に追加するかもしれません。」 トップレベルは異なった'タイプ'の情報を含んでいるでしょう。 例えば、あるOUによる'人員'、別のものが刊行物と呼ばれるかもしれないということであるかもしれない、) 「スタッフとGuestsはPersonnel OUの下に住んでいるでしょう。」
Peter Yee of NASA Ames:
NASAのエームズのピーター・イー:
"I broke up my DIT at the NASA Center level. NASA is made of
nearly 20 Centers and Facilities. The decision to break up at
this level was driven by several factors:
「私はNASAセンターレベルでDITを壊れさせました。」 NASAはおよそ20センターズとFacilitiesで作られています。 このレベルで壊れるという決定はいくつかの要素によって動かされました:
"1. Control of the local portion of the DIT should reside with
the Center in question, particularly since the Center probably
supplies the data in question and controls the matching DSA.
"1. センターがはっきりしていなかった状態で、DITの地方の部分のコントロールはあるはずです、センターが特にたぶん問題のデータを提供して、合っているDSAを制御するので。
"2. Each Center ranges in size from 1,000 to 16,000 persons.
This seems to be the range that works well on moderate sized
UNIX servers. Smaller would be a waste, larger would require
too much memory.
"2. 各センターはサイズ1,000〜16,000人々のねらいを定めます。 これは適度の大きさで分けられたUnixサーバーでうまくいく範囲であるように思えます。 より小さく、浪費で、大きいでしょう。あまりに多くのメモリを必要とするでしょう。
"3. Representatives from several Centers have contacted me
asking if they could run their own DSAs so that they can
experiment with X.500. Thus the relevant DSA needs to be under
their control."
"3. 彼らがX.500を実験できるようにそれら自身のDSAsを実行できるかどうか尋ねながら、数個のセンターズからの代表は私に連絡しました。 「その結果、関連DSAは、彼らのコントロールの下にある必要があります。」
2.5. Information Stored in X.500
2.5. X.500に保存された情報
The Phase I deployment of X.500 should be limited to "white pages"-
X.500のPhase I展開が「ホワイトページ」に制限されるべきである、-
ESCC X.500/X.400 Task Force [Page 13] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[13ページ]RFC1330X.500とX.400プラン
type information about people. Other types of objects can be added in later Phases, or added dynamically as the need arises.
人々の情報をタイプしてください。 他のタイプのオブジェクトを後のPhasesで加えるか、またはダイナミックに必要に応じて加えることができます。
To make X.500 truly useful to the ESnet community as a White Pages service, it is recommended that the following minimum information should be stored in the X.500 database:
X.500を本当に、ホワイトのページサービスとしてESnet共同体の役に立つようにするように、以下の最小の情報がX.500データベースに保存されるのは、お勧めです:
Information ASN.1 Attribute Type Example
----------- -------------------- -------
Locator Info commonName Allen Sturtevant
surname Sturtevant
postalAddress LLNL
P.O. Box 5509, L-561
Livermore, CA 94551
telephoneNumber +1 510 422 8266
facsimileTelephoneNumber +1 510 422 0435
情報ASN.1属性タイプの例----------- -------------------- ------- ロケータInfo commonNameアレンスタートバント姓のスタートバントpostalAddress LLNL私書箱5509、L-561リバーモア(カリフォルニア)94551telephoneNumber+1 510 422 8266facsimileTelephoneNumber+1 510 422、0435
E-Mail Info rfc822Mailbox Sturtevant@es.net
mhsORAddresses /PN=Allen Sturtevant/O=NERSC/
/PRMD=ESnet/ADMD= /C=US/
otherMailbox DECnet: ESNIC::APS
メールインフォメーションrfc822Mailbox Sturtevant@es.net mhsORAddresses /PNはアレンスタートバント/O=NERSC//PRMD=ESnet/ADMD=/C=米国/otherMailbox DECnetと等しいです: ESNIC:、:APS
The above list of attributes comprises a minimum set which is recommended for a person's entry. However, you may chose to omit some attributes for reasons of privacy or legality. Note that the X.500 standard requires that the surname and commonName attributes be present. If an individual's phone number and/or address cannot be provided, they should be replaced by the site's "Information Phone Number" and postal address to allow some means of contacting the person.
属性の上記のリストは人のエントリーに推薦される最小のセットを包括します。 しかしながら、あなたは選ぶことができます。プライバシーか合法の理由でいくつかの属性を省略するのを選びました。 X.500規格が、姓とcommonName属性が存在しているのを必要とすることに注意してください。 個人の電話番号、そして/または、アドレスを提供できないなら、人に連絡するいくつかの手段を許容するためにそれらをサイトの「情報電話番号」と郵便の宛先に取り替えるべきです。
2.5.1. Information Security
2.5.1. 情報セキュリティ
It is understood that placing this type of information in X.500 is equivalent to putting the "Company Phone Book" on-line in the Internet. Different sites may treat this information differently. Some may view it as confidential, while others may view this data as open to the public. In any case, it was recommended that ESnet sites discuss the implications with their respective legal departments before actually making their information openly available. There currently exists minimal access control in several X.500 implementations.
X.500のこの情報の種類を置くのがインターネットのオンラインの「会社電話帳」を置くのに同等であることが理解されています。 異なったサイトはこの情報を異なって扱うかもしれません。 或るものは、それが秘密であるとみなすかもしれませんが、他のものは、このデータが公開されているとみなすかもしれません。 どのような場合でも、ESnetサイトが実際にそれらの情報をオープンに利用可能にする前のそれらのそれぞれの法務部と含意について議論するのは、お勧めでした。 いくつかのX.500実装におけるアクセスコントロールは現在、最小量であることで存在します。
2.6. Accessing the X.500 Directory Service
2.6. X.500ディレクトリサービスにアクセスします。
The PSI White Pages Pilot Project software provides numerous interfaces to the information in the X.500 Directory. Non- interactive access mechanisms (e.g. WHOIS, FINGER and Electronic
PSIホワイトページPilot ProjectソフトウェアはX.500ディレクトリで多数のインタフェースを情報に提供します。 非インタラクティブのアクセス機構、(例えば、WHOIS、FINGER、およびElectronic
ESCC X.500/X.400 Task Force [Page 14] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[14ページ]RFC1330X.500とX.400プラン
Mail) make use of capabilities or services which already reside on many workstations and hosts. Such hosts could immediately take advantage of the X.500 service with no additional software or reconfiguration needed. However, since these methods are non- interactive, they only provide a way to search for and read information in the Directory but no way to modify information.
メール) 多くのワークステーションとホストの上に既にある能力かサービスを利用してください。 どんな付加ソフトウェアも再構成も必要でなくそのようなホストはすぐに、X.500サービスを利用できました。 しかしながら、これらのメソッドが非インタラクティブであるので、ディレクトリにおける情報を検索して、読む方法を提供しますが、それらは情報を変更するどんな方法も提供するだけではありません。
2.6.1. Directory Service via WHOIS
2.6.1. WHOISを通したディレクトリサービス
The Pilot Project software allows you to configure the X.500 Directory service to be made available via a network port offering an emulation of the SRI-NIC WHOIS service. UNIX-based hosts and VMS hosts running Multinet typically come configured with the WHOIS service. Users at their workstations would then be able to issue a simple WHOIS command to a known host running a DSA to retrieve information about colleagues at their site or at other ESnet sites. For example, the command:
Pilot Projectソフトウェアで、あなたは、SRI-NIC WHOISサービスのエミュレーションを提供しながらネットワークポートを通して利用可能に作られているためにX.500ディレクトリサービスを構成できます。 UNIXベースのホストとMultinetを実行するVMSホストがWHOISサービスによって構成にされているので通常来ます。 彼らのワークステーションのユーザはその時、彼らのサイトにおいて、または、他のESnetサイトで同僚の情報を検索するためにDSAを実行する知られているホストに簡単なWHOISコマンドを発行できるでしょう。 例えば、コマンド:
whois -h wp.lbl.gov wright
whois-h wp.lbl.gov職人
will return information about Russ Wright at Lawrence Berkeley Lab. It is recommended that all sites which bring up such a service, should provide an alias name for the host running their DSA of the form <wp.site.domain> for consistency within the ESnet community.
ローレンスバークレーLabでラス・ライトの情報を返すでしょう。 それはそのようなサービスを持って来るすべてのサイト、ESnet共同体の中の一貫性のためにそれらのフォーム<wp.site.domain>のDSAを実行するホストに別名を提供するべきであることが勧められます。
2.6.2. Directory Service via Electronic Mail
2.6.2. Electronicメールを通したディレクトリサービス
The Pilot Project software also allows the X.500 Directory service to be made available via electronic mail. A user who sends an electronic mail message to a known host running a DSA containing a WHOIS-like command on the subject line, would then receive a return mail message containing the results of their query.
また、Pilot Projectソフトウェアで、X.500ディレクトリサービスは電子メールを通して利用可能にします。 件名にWHOISのようなコマンドを含むDSAを実行する知られているホストに電子メールメッセージを送って、次に彼らの質問の結果を含むリターンメール・メッセージを受け取るユーザ。
2.6.3. Directory Service via FINGER
2.6.3. FINGERを通したディレクトリサービス
The X.500 Directory service could also be made available via the FINGER service. Although this access method does not come with the PSI Pilot Project software, several sites have already implemented a FINGER interface to the X.500 Directory. For ease of use and consistency, a single FINGER interface should be selected, then individual implementations within the ESnet community should conform to this interface.
また、X.500ディレクトリサービスをFINGERサービスで利用可能にすることができました。 このアクセス法はPSI Pilot Projectソフトウェアと共に来ませんが、いくつかのサイトが既にX.500ディレクトリにFINGERインタフェースを実装しました。 使いやすさと一貫性において、単一のFINGERインタフェースは選択されるべきであり、次に、ESnet共同体の中の個々の実装はこのインタフェースに従うべきです。
2.6.4. Directory Service via Specialized Applications
2.6.4. Specialized Applicationsを通したディレクトリサービス
Many X.500 Directory User Agents (DUAs) are widely available. Some of these come with the PSI Pilot Project software. Other DUAs, which have been developed by third parties to fit into the pilot software,
多くのX.500ディレクトリUserエージェント(DUAs)が広く手があいています。 これらの或るものはPSI Pilot Projectソフトウェアと共に来ます。 他のDUAs。(そのDUAsは、パイロットソフトウェアに収まるように第三者によって開発されました)。
ESCC X.500/X.400 Task Force [Page 15] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[15ページ]RFC1330X.500とX.400プラン
are publicly available. These user agents support interactive access to the X.500 Directory allowing browsing, searching, listing and modifying data in the Directory. However, in most cases, use of these DUAs requires the Pilot Project software be installed on the host system. Only a few of these DUAs and their capabilities are described below.
公的に利用可能です。 これらのユーザエージェントはディレクトリにおけるデータをブラウズして、捜して、リストアップして、変更するX.500ディレクトリへの対話的なアクセスをサポートします。 多くの場合、これらのDUAsの使用がどのようにPilot Projectソフトウェアを必要としても、ホストシステムにインストールされてください。 ほんのこれらのDUAsと彼らの能力のいくつかは以下で説明されます。
o DISH - A User Agent which provides a textual interface to the
X.500 Directory. It gives full access to all elements of the
Directory Access Protocol (DAP) and as such may be complex for
novice users. DISH is most useful to the DSA administrator.
o DISH--原文のインタフェースをX.500ディレクトリに提供するUserエージェント。 それは、ディレクトリAccessプロトコル(DAP)のすべての原理への完全なアクセスを与えて、初心者ユーザには、そういうものとして複雑であるかもしれません。 DISHはDSA管理者の最も役に立ちます。
o FRED - A User Agent which has been optimized for "white pages"
types of queries. The FRED program is meant to be similar to
the WHOIS network service. FRED supports reading, searching,
and modifying information in the X.500 Directory.
o フレッド--質問の「ホワイトページ」タイプのために最適化されたUserエージェント。 フレッドプログラムがWHOISネットワーク・サービスと同様であることが意味されます。 フレッドは読書、探索、および変更にX.500ディレクトリにおける情報をサポートします。
o POD - An X-windows based User Agent intended for novice users.
POD relies heavily on the concept of the user "navigating"
around the DIT. Pod supports reading and searching. There are
no facilities to add entries or to modify the RDNs of entries,
though most other entry modifications are allowed.
o POD--X-windowsは初心者ユーザのために意図するUserエージェントを基礎づけました。 PODはDITの周りで大いに「ナビゲートユーザ」の概念を当てにします。 さやは読書と探すことをサポートします。 エントリーを加えるか、またはエントリーのRDNsを変更するために、施設は全くありません、他のほとんどのエントリー変更が許されていますが。
2.6.5. Directory Service from PCs and MACs
2.6.5. PCとMACsからのディレクトリサービス
Smaller workstations and personal computers lack the computing power or necessary software to implement a full OSI protocol stack. As a consequence, several "light-weight" protocols have been developed whereby the DAP runs on a capable workstation and exports a simpler interface to other end-systems. One such "light weight" protocol, the Directory Assistance Service (DAS), is incorporated in the PSI Pilot Project software. Another "light weight" protocol, DIXIE, was developed at the University of Michigan. Publicly available User Agents for both the MAC and PC have been developed using the DA- service and the DIXIE protocol. So long as you have the Pilot Project software running on one host, you can provide these User Agents on many end-systems without having to install the Pilot software on all those end-systems.
より小さいワークステーションとパーソナルコンピュータは完全なOSIがプロトコル・スタックであると実装するコンピューティングパワーか必要なソフトウェアを欠いています。 結果として、DAPができるワークステーションと輸出のときに他のエンドシステムにより簡単なインタフェースを実行するいくつかの「軽量」のプロトコルを開発してあります。そのようなプロトコルの「軽量」1つ(ディレクトリAssistance Service(DAS))はPSI Pilot Projectソフトウェアに組み込んでいます。 別の「軽量」プロトコル、デキシーはミシガン大学で開発されました。 MACとPCの両方のための公的に手があいているUserエージェントは、DAサービスとデキシープロトコルを利用することで開発されました。 Pilot Projectソフトウェアに1人のホストで動かせる限り、それらのすべてのエンドシステムの上にPilotソフトウェアをインストールする必要はなくて、あなたは多くのエンドシステムの上でこれらのUserエージェントを提供できます。
For further information about available Directory User Agents, see RFC-1292, "Catalog of Available X.500 Implementations".
手があいているディレクトリUserエージェントに関する詳細に関しては、RFC-1292、「利用可能なX.500実装のカタログ」を見てください。
2.7. Services Provided by ESnet
2.7. ESnetによって提供されたサービス
Currently, there are several ESnet backbone sites which are operating their own DSAs within the PSI White Pages Pilot Project. It is anticipated that directly connected ESnet backbone sites will eventually install and operate their own X.500 DSAs. In the interim,
現在、PSIホワイトページPilot Projectの中でそれら自身のDSAsを操作しているいくつかのESnetバックボーンサイトがあります。 直接接続されたESnetバックボーンサイトが結局それら自身のX.500 DSAsをインストールして、操作すると予期されます。 その間
ESCC X.500/X.400 Task Force [Page 16] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[16ページ]RFC1330X.500とX.400プラン
ESnet will provide complete support for ESnet backbone sites which presently do not have the time, expertise or equipment to establish X.500 services. The mechanism for doing this is described in Section 2.7.5 below. Additionally, ESnet will provide a variety of services in support of the entire X.500 community. These are also described in the following sections.
現在時間を持っていないESnetバックボーンサイト、専門的技術または設備がX.500サービスを証明するように、ESnetは完全なサポートを提供するでしょう。 これをするためのメカニズムはセクション2.7.5未満で説明されます。 さらに、ESnetは全体のX.500共同体を支持してさまざまなサービスを提供するでしょう。 また、これらは以下のセクションで説明されます。
2.7.1. X.500 Operations Mailing List
2.7.1. X.500操作メーリングリスト
ESnet maintains a mailing list for the discussion of relevant X.500 topics. This mailing list provides a means for sharing information, experiences, and expertise about X.500 in the ESnet community. New sites joining the ESnet X.500 community will be announced on the mailing list. New DSA administrators will be able to solicit help from more experienced administrators. When a site brings up a new X.500 DSA, the DSA manager should notify the ESnet DSA manager so as to ensure they are promptly added to the mailing list.
ESnetは関連X.500話題の議論のためのメーリングリストを維持します。 このメーリングリストはESnet共同体のX.500に関する情報交換、経験、および専門的技術に手段を提供します。 ESnet X.500共同体に加わる新しいサイトがメーリングリストで発表されるでしょう。 新しいDSA管理者は、より経験豊富な管理者から助けに請求できるでしょう。 サイトが新しいX.500 DSAを持って来るとき、DSAマネージャは、それらが即座にメーリングリストに追加されるのを確実にするためにESnet DSAマネージャに通知するべきです。
General discussion: x500-ops@es.net
To subscribe: x500-ops-request@es.net
一般議論: 申し込む x500-ops@es.net : x500-ops-request@es.net
2.7.2. Accessing the X.500 Directory
2.7.2. X.500ディレクトリにアクセスします。
ESnet has made the X.500 service openly available to the entire ESnet community via each of the access methods described in Section 2.6 above. Host WP.ES.NET provides TELNET access, FINGER and WHOIS emulations, querying via electronic mail, as well as remote access via light-weight protocols. By making these services widely available, we hope to acquaint more users with the features and capabilities of X.500.
ESnetはX.500サービスを上のセクション2.6で説明されたそれぞれのアクセス法でオープンに全体のESnet共同体に利用可能にしました。 ホストWP.ES.NETは模倣、電子メールを通した質問、および軽量のプロトコルを通した遠隔アクセスをTELNETアクセス、FINGER、およびWHOISに供給します。 これらのサービスを広く利用可能にすることによって、私たちは、より多くのユーザをX.500の特徴と能力に詳しいことを望んでいます。
To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET and login as user "fred"; no password is required. You have the choice of running the Fred or Pod User Agents. Fred provides a command line interface while Pod provides an X-windows based interface. You can browse through the global X.500 DIT, search for persons in various organizations, and even modify your own entry if you have one.
何人かのX.500 Userエージェント、単にTELNETをWP.ES.NETに十分に試して、ユーザ"fred"としてログインするために。 パスワードは全く必要ではありません。 あなたには、フレッドかPod Userエージェントを車で送ることの選択があります。 PodはX-windowsに基づいているインタフェースを提供しますが、フレッドはコマンドラインインタフェースを提供します。 1がありましたら、あなたは、グローバルなX.500 DITをブラウズして、様々な組織で人々を捜し求めて、あなた自身のエントリーを変更さえできます。
Host WP.ES.NET also provides access to the X.500 Directory via emulations of the FINGER and WHOIS utilities. These interfaces support a user-friendly-naming (UFN) scheme that simplifies the syntax necessary to search for persons in other organizations. The following WHOIS command lines illustrate searching for persons at various ESnet sites, utilizing the UFN syntax (similar FINGER command lines could also be constructed):
また、ホストWP.ES.NETはFINGERとWHOISユーティリティの模倣でX.500ディレクトリへのアクセスを提供します。 これらのインタフェースは他の組織で人々を捜し求めるのに必要な構文を簡素化するユーザに優しい命名(UFN)計画を支持します。 以下のWHOISコマンドラインは様々なESnetサイトで人々を捜し求めながら、例証します、UFN構文を利用して(また、同様のFINGERコマンドラインを構成できました):
ESCC X.500/X.400 Task Force [Page 17] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[17ページ]RFC1330X.500とX.400プラン
whois -h wp.es.net leighton,nersc
whois -h wp.es.net servey,doe
whois -h wp.es.net logg,slac
whois -h wp.es.net "russ wright",lbl
whois-h wp.es.net leighton、nersc whois-h wp.es.net servey、doe whois-h wp.es.net logg、slac whois-h wp.es.net「russ職人」、lbl
For further information about User Friendly Naming, see Steve Hardcastle-Kille's working document titled, "Using the OSI Directory to Achieve User Friendly Naming".
User Friendly Namingに関する詳細に関しては、スティーブHardcastle-Killeの働くドキュメントが題をつけられるのを見てください、「ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用し」て。
2.7.3. Backbone Site Aliases
2.7.3. 背骨サイト別名
As ESnet backbone sites join the X.500 pilot, their organizations' entries will be placed in various parts of the DIT. For example, National Laboratories will be placed directly under the c=US portion of the DIT, while universities and commercial entities will most likely be placed under localities, such as states or cities.
ESnet背骨サイトがX.500パイロットに加わるとき、彼らの組織のエントリーはDITの様々な部分に置かれるでしょう。 例えば、National研究所はDITのc=米国部分の直接下に置かれるでしょう、大学と商業実体はたぶん場所の下で置かれるでしょうが、州や都市のように。
In order to facilitate searching for the ESnet community as a whole, ESnet backbone sites will also be listed as organizational units under the node "@c=US@o=Energy Sciences Network". These entries will actually be aliases which point to the site's "real" organizational entry. Therefore, ESnet backbone sites will be listed in two different places in the DIT and one could search for them in either location.
「また、全体でESnet共同体を捜し求めるのを容易にするために、ESnet背骨サイトは組織的なユニットに」 @c= US@o =エネルギー科学がネットワークでつなぐノードのように記載されるでしょう。」 これらのエントリーはサイトへのそれのポイントが「本当である」別名が組織的なエントリーであったなら実際にそうするでしょう。 したがって、ESnet背骨サイトはDITの2つの異なった場所で記載されるでしょう、そして、1つは位置でそれらを捜し求めるかもしれません。
2.7.4. Multiprotocol Stack Support
2.7.4. Multiprotocolスタックサポート
OSI applications currently run over many different transport/network protocols, a factor which hinders communication between OSI end nodes. In order to facilitate communication, the ISODE may be configured at compile time to support any combination of the following stacks:
OSIアプリケーションは現在、多くの異なった輸送/ネットワーク・プロトコル、OSIエンドノードのコミュニケーションを妨げる要素に目を通します。 コミュニケーションを容易にして、ISODEはコンパイル時に以下のスタックのどんな組み合わせもサポートするために構成されるかもしれません:
RFC-1006 over TCP/IP
TP0 over X.25
TP0 over X.25 (84)
TP0 over the TP0-bridge
TP4 over CLNP
CLNPの上のTP4TP0-橋の上のX.25(84)TP0の上のX.25 TP0の上のTCP/IP TP0の上のRFC-1006
Within the ESnet community, the stacks of interest are RFC-1006 over TCP/IP, TP4 over CLNP, and TP0 over X.25. If a backbone site's DSA is not running over all three of these stacks, it may eventually receive referrals to a DSA that it can not connect to directly, so the operation can not proceed. Since the ESnet DSAs will be configured to operate over all of the "stacks of interest," they can serve as relay DSAs between site DSAs that do not have direct connectivity. The site's DSA manager will need to contact the ESnet DSA manager to arrange for this relaying to occur. Backbone sites
ESnet共同体の中では、興味があるスタックは、TCP/IPの上のRFC-1006と、CLNPの上のTP4と、X.25の上のTP0です。 背骨サイトのDSAがこれらのすべての3つのスタックをひいているというわけではないなら、結局直接接続できないDSAに紹介を受けるかもしれないので、操作は続くことができません。 ESnet DSAsが「興味があるスタック」のすべて上で作動するために構成されるので、それらはダイレクト接続性を持っていないサイトDSAsの間のリレーDSAsとして機能できます。 サイトのDSAマネージャは、このリレーのために起こるように手配するためにESnet DSAマネージャに連絡する必要があるでしょう。 背骨サイト
ESCC X.500/X.400 Task Force [Page 18] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[18ページ]RFC1330X.500とX.400プラン
will be encouraged to eventually provide as many of the three stacks of interest as possible.
結局興味があるできるだけ多くの3つのスタックを提供するよう奨励されるでしょう。
2.7.5. Managing a Site's X.500 Information
2.7.5. サイトのX.500情報を管理します。
For sites which do not initially wish to operate their own DSA, ESnet's DSA will master their site's portion of the DIT, enabling the site to join the PSI Pilot Project and the ESnet X.500 community. In order to accomplish this, the site must provide the ESnet DSA manager with information about the people to be included in the X.500 Directory. This information can usually be obtained from your Site's Personnel Database.
初めはそれら自身のDSAを操作したがっていないサイトに、ESnetのDSAはそれらのサイトのDITの一部を習得するでしょう、サイトがPSI Pilot ProjectとESnet X.500共同体に加わるのを可能にして。 これを達成して、サイトは、X.500ディレクトリに含まれるように人々の情報をESnet DSAマネージャに提供しなければなりません。 通常、あなたのSiteのPersonnel Databaseからこの情報を得ることができます。
ESnet will only maintain a limited amount of information on behalf of each person to be represented in the Directory. The attribute types listed in the table in Section 2.5 show the maximum amount of information which the ESnet DSA will support for a person's entry in the Directory. This set of attribute types is a small subset of the attribute types offered by the PSI Pilot Project software. Therefore, if a site wishes to include additional attribute types, they should consider installing and operating their own DSA.
ESnetは、ディレクトリで表されるために各人を代表して限られた情報量を維持するだけでしょう。 セクション2.5にテーブルに記載された属性タイプは、ESnet DSAがディレクトリにおける人のエントリーにどれを支持するかを最大の情報量に示します。 このセットの属性タイプはPSI Pilot Projectソフトウェアによって提供された属性タイプの小さい部分集合です。 したがって、サイトが追加属性タイプを含みたいなら、彼らは、それら自身のDSAをインストールして、操作すると考えるべきです。
The format of the information to be provided to the ESnet DSA manager is as follows: the data should be contained in a flat, ASCII text file, one record (line) per person, with a specified delimiter separating the fields of the record. More detailed information and a sample of a site-supplied data file can be found in Appendix D.
ESnet DSAマネージャに提供される情報の形式は以下の通りです: データはアパートに保管されるべきです、ASCIIテキスト・ファイル、1人あたり1つの記録(線)、指定されたデリミタが記録の野原を分離していて。 Appendix Dでサイトに供給されたデータファイルの、より詳細な情報とサンプルを見つけることができます。
2.7.5.1. Open Availability of Site Information
2.7.5.1. サイト情報の開いている有用性
Although the PSI Pilot Project allows you to control who may access Directory objects and their attributes, any information you provide about persons at your site to be stored in the ESnet DSA will be considered world readable. This policy is necessary in order to minimize the administrative cost of managing potentially many organizational objects within the ESnet DSA. If your site decides that it does not wish to have certain information about its employees publicly known (e.g. work telephone number) then you should not provide this information to the ESnet DSA manager or you should consider installing and administering your own DSA.
PSI Pilot Projectはだれがディレクトリ物とそれらの属性にアクセスするかもしれないかをあなたを制御させますが、あなたがESnet DSAに格納されるためにサイトで人々に関して提供するどんな情報も世界的で読み込み可能であると考えられるでしょう。 この方針が、ESnet DSAの中の潜在的に多くの組織的な物を管理する管理費を最小にするのに必要です。 あなたは、あなたのサイトが、それには公的に知られている従業員のある情報がありたくないと決めるなら(例えば、電話番号を扱ってください)、あなたがESnet DSAマネージャにこの情報を前提とするべきではありませんし、またあなた自身のDSAをインストールして、管理すると考えるべきです。
2.7.5.2. Access Methods for Local Users
2.7.5.2. ローカルユーザーのためのアクセス法
Backbone sites which choose the option of having the ESnet DSA master their organization's X.500 information should make the availability of the X.500 service known to their local users. All of the methods described in Section 2.7.2 are available for use, but none of these methods will assume the query is relative to the local site.
ESnet DSAに彼らの組織のX.500情報を習得させるオプションを選ぶ背骨サイトで、地元のユーザにとってX.500サービスの有用性を知るべきです。 セクション2.7.2で説明された方法のすべてが使用に利用可能ですが、これらの方法のいずれも、質問がローカル・サイトに比例していると仮定しないでしょう。
ESCC X.500/X.400 Task Force [Page 19] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[19ページ]RFC1330X.500とX.400プラン
To facilitate querying relative to the local environment, the site will need to make one host available to run the emulation of the FINGER service. Although the resulting query will ultimately be directed to the remote ESnet DSA, the search will appear to be local to the users at that site. For example, a user on a workstation at site XYZ could type the following, omitting their local domain name as this is implied:
地方の環境に比例して質問するのを容易にするために、サイトは、1人のホストをFINGERサービスのエミュレーションを走らせるために利用可能にする必要があるでしょう。 結果として起こる質問は結局リモートESnet DSAに向けられるでしょうが、検索はそのサイトのユーザにとって地方であるように見えるでしょう。 例えば、サイトXYZのワークステーションの上のユーザは以下をタイプできました、これが含意されるようにそれらの局所領域名を省略して:
finger jones@wp
指の jones@wp
This will retrieve information about user Jones at site XYZ (wp is the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The site coordinator will need to contact the ESnet DSA manager to arrange the set up for this service.
これはサイトXYZでユーザジョーンズの情報を検索するでしょう(wpがサイトXYZのホストの名前か別名です、すなわち、wp.XYZ.GOV)。 サイトコーディネータは、このサービスにおいて、候補になっているセットをアレンジするためにESnet DSAマネージャに連絡する必要があるでしょう。
2.7.5.3. Limitations of Using ESnet Services
2.7.5.3. ESnetが修理する使用の制限
Since the ESnet DSA will potentially be mastering information on behalf of numerous backbone sites, limits will need to be placed on the volume of site information stored in the ESnet DSAs. These are enforced to ensure DSA responsiveness, as well as to reduce administrative maintenance. The limits are:
ESnet DSAが潜在的に多数の背骨サイトを代表して情報を習得するので、限界は、ESnet DSAsに格納されたサイト情報のボリュームに置かれる必要があるでしょう。 これらは、DSAに反応性を確実にして、管理維持を変えるために実施されます。 限界は以下の通りです。
Item Maximum Limit
---- -------------
X.500 Organizations 1
Organizational Units 50
Organizational Unit Depth 3
Object Entries 5,000
Update Frequency 1 Month
Aliases n/a
Object/Attribute Access Control n/a
項目の最大の限界---- ------------- なし、Object/が結果と考えるX.500組織1Organizational Units50Organizational Unit Depth3Object Entries5,000Update Frequency1Month Aliases、Access Control、なし。
One week before each monthly update cycle, a message will be sent on the x500-ops@es.net mailer to remind the sites that an update cycle is approaching. If no changes are required to the site information, the reminder message can be ignored and the existing version of this information will be used. If the information is to be updated, a complete replacement of all information must be supplied to the ESnet DSA manager before the next update cycle. More detailed information and a sample of a site-supplied data file can be found in Appendix D.
それぞれの毎月のアップデートサイクルの1週間前に、アップデートサイクルにアプローチする予定であるのをサイトに思い出させるために x500-ops@es.net 郵送者でメッセージを送るでしょう。 変化は全くサイト情報に必要でないなら、思い出させるものメッセージを無視できます、そして、この情報の既存のバージョンは使用されるでしょう。 情報がアップデートすることであるなら、次のアップデートサイクルの前にすべての情報の完全な交換品をESnet DSAマネージャに提供しなければなりません。 Appendix Dでサイトに供給されたデータファイルの、より詳細な情報とサンプルを見つけることができます。
2.8. ESnet Running a Level-0 DSA for c=US
2.8. cのためにレベル-0DSAを走らせるESnetが米国と等しいです。
For ESnet to provide high quality X.500 services to the ESnet community, the ESnet DSAs must operate as Level-0 (first level) DSAs. It is currently planned that these DSAs will act as slave, Level-0 DSAs to PSI's master, Level-0 DSAs. Once the ESnet DSAs are in
ESnetがESnet共同体に対する高品質のX.500サービスを提供するように、ESnet DSAsはLevel-0(最初に、レベル)DSAsとして作動しなければなりません。 計画されていて、現在、これらのDSAsが奴隷、PSIのマスターへのLevel-0 DSAs、Level-0 DSAsとして機能するのは、そうです。 中に一度、ESnet DSAsがあります。
ESCC X.500/X.400 Task Force [Page 20] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[20ページ]RFC1330X.500とX.400プラン
production service, it is recommended that directly connected ESnet backbone sites operating their own X.500 DSAs configure them with one of the ESnet DSAs as their parent DSA. This provides several advantages to the ESnet community:
生産サービス、直接接続されたそれはそれら自身のX.500 DSAsを操作するESnet背骨サイトが彼らの親DSAとしてESnet DSAsの1つで彼らを構成することが勧められます。 これはESnet共同体のいくつかの利点を提供します:
1. The ESnet DSAs will be monitored by the NERSC's 24-hour
Operations Staff. Additionally, ESnet plans to deploy two
(2) DSAs in geographically disperse locations to ensure
reliability and availability.
1. ESnet DSAsはNERSCの24時間のOperations Staffによってモニターされるでしょう。 さらに、地理的に2(2)DSAsを配備するESnetプランは、信頼性と有用性を確実にするために位置を分散します。
2. All queries to Level-0 DSAs remain within the ESnet high-speed
backbone.
2. Level-0 DSAsへのすべての質問がESnet高速バックボーンに残っています。
3. If network connectivity is lost to all external Level-0 DSAs,
X.500 Level-0 connectivity will still exist within the ESnet
backbone.
3. ネットワークの接続性がすべての外部のLevel-0 DSAsに失われていると、それでも、X.500 Level-0の接続性はESnet背骨の中に存在するでしょう。
2.9. X.500 Registration Requirements
2.9. X.500登録要件
X.500 organization names must be nationally unique if they appear directly below the c=US level in the DIT structure. Nationally unique names must be registered through an appropriate registration authority, i.e., one which grants nationally unique names.
DIT構造の米国c=レベルの直接下のように見えるなら、X.500組織名は全国的にユニークであるに違いありません。 すなわち、適切な登録局、全国的にユニークな名前を与えるものを通して全国的にユニークな名前を登録しなければなりません。
X.500 organizational unit names need to be unique relative to the node directly superior to them in the DIT. Registration of these names should be conducted through the "owner" of the superior node.
X.500の組織的なユニットはそれらよりDITで直接優れたノードに比例して特有になる必要性を命名します。 これらの名前の登録が優れたノードの「所有者」を通して行われるべきです。
The registration of X.500 names below the organization level are usually a local matter. However, all siblings under a given node in the DIT must have unique RDNs.
通常、組織レベルの下におけるX.500名の登録は地域にかかわる事柄です。 しかしながら、DITの与えられたノードの下におけるすべての兄弟がユニークなRDNsを持たなければなりません。
See Section 4 for a more complete description of OSI registration issues and procedures.
OSI登録問題と手順の、より完全な記述に関してセクション4を見てください。
2.10. Future X.500 Issues to be Considered
2.10. Consideredである将来のX.500 Issues
2.10.1. ADDMDS Interoperating with PRDMDS
2.10.1. PRDMDSと共に共同利用するADDMDS
This is a problem which currently does not have an answer. The issue of Administrative Directory Management Domains (ADDMDs) interacting with Private Directory Management Domains (PRDMDs) is just beginning to be investigated by several groups interested in solving this problem.
これは現在、答えがない問題です。 この問題を解決したがっていたいくつかのグループによってただ兵士のディレクトリManagement Domains(PRDMDs)と対話するAdministrativeディレクトリManagement Domains(ADDMDs)の問題によって調査され始めています。
2.10.2. X.400 Interaction with X.500
2.10.2. X.500とのX.400相互作用
The current level of understanding is that X.400 can benefit from the
X.400が利益を得ることができる現在のレベルの理解があります。
ESCC X.500/X.400 Task Force [Page 21] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[21ページ]RFC1330X.500とX.400プラン
use of X.500 in two ways:
2つの方法におけるX.500の使用:
1. Lookup of message recipient information.
1. メッセージ受取人情報のルックアップ。
2. Lookup of message routing information.
2. メッセージルーティング情報のルックアップ。
X.400 technology and products, as they stand today, do not support both of these features in a fully integrated fashion across multiple vendors. As the standards and technology evolve, consideration will have to be given in applying these new functions to the production ESnet X.500/X.400 services environment.
今日立って、X.400技術と製品は複数の業者の向こう側に完全に統合しているファッションでこれらの特徴の両方を支持しません。 規格と技術が発展するとき、生産ESnet X.500/X.400サービス環境にこれらの新しい機能を適用する際に考慮を払わなければならないでしょう。
2.10.3. Use of X.500 for NIC Information
2.10.3. X.500のNIC情報の使用
Work is currently being performed in the IETF to place NIC information on-line in an Internet-based X.500 service.
現在、インターネットを利用するX.500サービスにおけるオンラインのNIC情報を置くためにIETFで仕事をしています。
2.10.4. Use of X.500 for Non-White Pages Information
2.10.4. X.500の非ホワイトページ情報の使用
The PSI White Pages Pilot Project has caused increasing and popular use of X.500 as a white pages services within the Internet community. However, the X.500 standard provides for much more than just this service. Application processes, devices and security objects are just a few of the objects to be considered for future incorporation in the global X.500 database.
PSIホワイトページPilot Projectはインターネットコミュニティの中でホワイトページとしてのX.500の増加と一般的な使用にサービスを引き起こしました。 しかしながら、X.500規格はまさしくこのサービスよりはるかに多くに備えます。 アプリケーション・プロセス、装置、およびセキュリティ物はただグローバルなX.500データベースにおける今後の編入のために考えられる物のいくつかです。
2.10.5. Introduction of New X.500 Implementations
2.10.5. 新しいX.500実現の導入
Thought will have to be given to the use of commercial X.500 products in the future as QUIPU (the implementation recommended in this paper) may not meet all of the needs of the ESnet community. As commercial products mature and become stable, they will have to be incorporated into the ESnet X.500 service in a way which ensures interoperability and reliability.
QUIPU(この紙のお勧めの実現)がESnet共同体の必要性のすべてに会わないとき、将来、商業X.500製品の使用に考えを与えなければならないでしょう。 商品が熟して、安定するようになるとき、それらは相互運用性と信頼性を確実にする方法でESnet X.500サービスに組み入れられなければならないでしょう。
2.10.6. Interaction of X.500 and DECdns
2.10.6. X.500とDECdnsの相互作用
There is every indication that DECdns and X.500 will interoperate in some fashion in the future. Since there is an evolving DECdns namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF), some consideration should be given to how these two name trees will interact. All of this will be driven by the Digital Equipment Corporation's decisions on how to expand and incorporate its DECdns product with X.500.
DECdnsとX.500が将来何らかのファッションで共同利用するというあらゆる指示があります。 発展しているDECdns名前空間(すなわち、OMNI)と発展しているX.500 DIT(すなわち、NADF)があるので、これらの2本の名前木がどう相互作用するかに対して何らかの考慮を払うべきです。 このすべてが、どう広がるかに関するDECの決定で運転されて、X.500と共にDECdns製品を組み込むでしょう。
ESCC X.500/X.400 Task Force [Page 22] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[22ページ]RFC1330X.500とX.400プラン
3. X.400 - OSI Message Handling Services
3. X.400--OSIメッセージ通信処理サービス
3.1. Brief Tutorial
3.1. 簡潔なチュートリアル
In 1984 CCITT defined a set of protocols for the exchange of electronic messages called Message Handling Systems (MHS) and is described in their X.400 series of recommendations. ISO incorporated these recommendations in their standards (ISO 10021). The name used by ISO for their system was MOTIS (Message-Oriented Text Interchange Systems). In 1988 CCITT worked to align their X.400 recommendations with ISO 10021. Currently when people discuss messaging systems they use the term X.400. These two systems are designed for the general purpose of exchanging electronic messages in a store and forward environment. The principle use being made of this system today is to support electronic mail. This section will give an overview of X.400 as used for electronic mail. In the following sections, the term X.400 will be used to describe both the X.400 and MOTIS systems.
1984年に、CCITTは、Message Handling Systems(MHS)と呼ばれる電子メッセージの交換のために1セットのプロトコルを定義して、彼らの推薦のX.400シリーズで説明されます。 ISOはそれらの規格(ISO10021)にこれらの推薦を取り入れました。 それらのシステムにISOによって使用された名前はMOTIS(メッセージで指向のText Interchange Systems)でした。 1988年に、CCITTは、彼らのX.400推薦をISO10021に一直線にするために働いていました。 現在、人々がメッセージシステムについて議論するとき、それらはX.400という用語を使用します。 これらの2台のシステムが店と前進の環境における電子メッセージを交換する汎用のために設計されています。 今日このシステムでされる原則使用は電子メールを支持することです。 このセクションは電子メールに使用されるようにX.400の概観を与えるでしょう。 以下のセクションでは、X.400という用語は、X.400とMOTISシステムの両方について説明するのに使用されるでしょう。
The basic model used by X.400 MHS is that of a Message Transfer System (MTS) accessed via a User Agent (UA). A UA is an application that interacts with the Message Transfer System to submit messages on behalf of a user. A user is referred to as either an Originator (when sending a message) or a Recipient (when receiving one). The process starts out when an Originator prepares a message with the assistance of their UA. The UA then submits the message to the MTS for delivery. The MTS then delivers the message to one or more Recipient UAs.
X.400 MHSによって使用された基本型はMessage Transfer Systemでは、(MTS)がUserエージェントを通して(UA)にアクセスしたということです。 UAはユーザを代表してメッセージを提出するためにMessage Transfer Systemと対話するアプリケーションです。 ユーザはOriginator(メッセージを送るとき)かRecipientのどちらかと呼ばれます(1を受け取るとき)。 OriginatorがそれらのUAの支援でメッセージを準備するとき、過程は始めます。 そして、UAは配送のためにMTSにメッセージを提出します。 そして、MTSは1Recipient UAsにメッセージを渡します。
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
______ | _______ _______ | ______
| | | MTS | | | | | | |
| UA |<----|---->| MTA |<------>| MTA |<---|--->| UA |
|______| | |_______| |_______| | |______|
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ______ | _______ _______ | ______ | | | MTS| | | | | | | | Ua| <、-、-、--、|、-、-、--、>| MTA| <、-、-、-、-、--、>| MTA| <、-、--、|、-、--、>| Ua| |______| | |_______| |_______| | |______| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
The MTS provides the general store-and-forward message transfer service. It is made up of a number of distributed Message Transfer Agents (MTA). Operating together, the MTAs relay the messages and deliver them to the intended recipient UAs, which then makes the messages available to the recipient (user).
MTSは一般的な店とフォワードメッセージ転送サービスを提供します。 それは多くの分配されたMessage Transferエージェント(MTA)で作られます。 一緒に作動して、MTAsは意図している受取人UAsにメッセージをリレーして、それらを渡します。(次に、UAsはメッセージを受取人(ユーザ)にとって利用可能にします)。
The basic structure of an X.400 message is an envelope and content (i.e. message). The envelope carries information to be used when transferring the message through the MTS. The content is the piece of information that the originating UA wishes delivered to the recipient UA. There are a number of content types that can be carried in X.400 envelopes. The standard user message content type defined by X.400 is called the Interpersonal (IP) message. An IP
X.400メッセージの基本構造は、封筒と内容(すなわち、メッセージ)です。 封筒は、MTSを通してメッセージを移すとき、使用されるために情報を運びます。 内容は由来しているUA願望が受取人UAに配送されたという情報の断片です。 X.400封筒で運ぶことができる多くの満足しているタイプがあります。 X.400によって定義された標準のユーザメッセージ内容タイプはInterpersonal(IP)メッセージと呼ばれます。 IP
ESCC X.500/X.400 Task Force [Page 23] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[23ページ]RFC1330X.500とX.400プラン
message consists of two parts, the heading and body. The heading contains the message control information. The body contains the user message. The body may consist of a number of different body parts. For example one IP message could carry voice, text, Telex and facsimile body parts.
メッセージは2つの部品、見出し、およびボディーから成ります。 見出しはメッセージ制御情報を含んでいます。 ボディーはユーザメッセージを含みます。 ボディーは多くの異なった身体の部分から成るかもしれません。 例えば、1つのIPメッセージが、声、テキスト、Telexを運んで、身体の部分を電送するかもしれません。
The Management domain (MD) concept within the X.400 recommendations defines the ownership, operational and control boundary of an X.400 administration. The collection consisting of at least one MTA and zero or more UAs owned by an organization or public provider constitutes a management domain (MD). If the MD is managed by a public provider it is called an Administration Management Domain (ADMD). The MD managed by a company or organization is called a Private Management Domain (PRMD). A Private MD is considered to exist entirely within one country. Within that country a PRMD may have access to one or more ADMDs.
X.400推薦の中のManagementドメイン(MD)概念は所有権、X.400管理の操作上と規制境界を定義します。 組織か公共のプロバイダーによって所有されていた少なくとも1MTAとゼロか、より多くのUAsから成る収集は管理ドメイン(MD)を構成します。 MDが公共のプロバイダーによって管理されるなら、それは政権Management Domain(ADMD)と呼ばれます。 会社か組織によって管理されたMDは兵士のManagement Domain(PRMD)と呼ばれます。 兵士のMDが1つの国の中に完全に存在すると考えられます。 その国の中では、PRMDは1ADMDsに近づく手段を持っているかもしれません。
Each MD must ensure that every user (i.e UA) in the MD has at least one name. This name is called the Originator/Recipient (O/R) Name. O/R Names are constructed from a set of standard attributes:
各MDは、MDのすべてのユーザ(i.e UA)には少なくとも1つの名前があるのを確実にしなければなりません。 この名前はOriginator/受取人(O/R)名と呼ばれます。 O/R名は1セットの標準の属性から構成されます:
o Country Name
o 国の名
o Administration Management Domain
o 政権管理ドメイン
o Private Management Domain
o 自営業ドメイン
o Organization Name
o 組織名
o Organizational Unit Name
o 組織的なユニット名
o Surname
o 姓
o Given name
o 名
o Initials
o イニシャル
o Generational Qualifier
o 世代の資格を与える人
An O/R name must locate one unambiguous O/R UA if the message is to be routed correctly through the Message Transfer Service. Currently each MD along the route a message takes determines the next MD's MTA to which the message should be transferred. No attempt is made to establish the full route for a message, either in the originating MD or in any other MD that acquires the store and forward responsibility for the message.
O/R名はメッセージがMessage Transfer Serviceを通して正しく発送されることであるなら1明白なO/R UAの場所を見つけなければなりません。 メッセージが取るルートに沿った現在各MDはメッセージが移されるべきである次のMDのMTAを決定します。 由来しているMDかメッセージへの店と前進の責任を取得するいかなる他のMDでもメッセージのために完全なルートを確立するのを試みを全くしません。
Messages are relayed by each MD on the basis of the Management domain
メッセージはManagementドメインに基づいて各MDによってリレーされます。
ESCC X.500/X.400 Task Force [Page 24] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[24ページ]RFC1330X.500とX.400プラン
portion of their O/R Name until arrival at the recipient MD. At which point, the other attributes in the name are used to further route to the recipient UA. Internal routing within a MD is the responsibility of each MD.
それらの受取人MDへの到着までのO/R Nameの一部。 どのポイントで、名前の他の属性は、さらにUAを受取人に発送するのに使用されるか。 MDの中の内部のルーティングはそれぞれのMDの責任です。
3.2. ESnet X.400 Logical Backbone
3.2. ESnet X.400の論理的な背骨
Currently within the ESnet community message handling services are implemented with a number of different mail products, resulting in what is classically known as an "n-squared" problem. For example, let's say that LLNL only uses QuickMail on site, PPPL only uses MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail. For LLNL to send mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on- site. Likewise for PPPL to send mail to LLNL and CEBAF, it must support MAIL-11 and QuickMail locally. Identically, this scenario exists for CEBAF.
現在、ESnetの中では、共同体メッセージ通信処理サービスは多くの異なったメール製品で実行されます、「nで二乗された」問題として古典的に知られていることをもたらして。 例えば、LLNLがサイトのQuickMailを使用するだけであり、PPPLがメール-11(VMS MAIL)しか使用しないで、CEBAFがSMTPメールを使用するだけであると言いましょう。 LLNLがPPPLとCEBAFにメールを送るように、必須サポートメール-11とSMTPは局所的にオンです。サイト。 同様に、PPPLがLLNLとCEBAFにメールを送るように、それは局所的にメール-11とQuickMailを支持しなければなりません。 同様に、このシナリオはCEBAFのために存在しています。
To alleviate this problem, a logical X.400 backbone must be established through out the entire ESnet backbone. Then, each ESnet backbone site will be responsible for only providing connectivity between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or even native X.400) and the logical X.400 backbone. One of the long- term goals is to establish X.400 as the "common denominator" between directly connected ESnet backbone sites.
この問題を軽減するために、全体のESnet背骨から論理的なX.400背骨を通じて確立しなければなりません。 その時、それぞれのESnet背骨サイトは地元のメール・ドメイン(QuickMail、メール-11、SMTPメール、またはネイティブのX.400さえ)と論理的なX.400背骨の間に接続性を提供するだけに原因となるようになるでしょう。 目標という長い期間の1つは、直接接続されたESnet背骨サイトの間の「共通点」とX.400を書き立てることになっています。
3.3. Naming Structure
3.3. 構造を命名します。
The name-spaces for X.500 and X.400 are completely different and are structured to meet different needs. The X.500 name-space is typically organized to allow quick, optimized searching; while the X.400 ORname is used to forward an X.400 message through several "levels" of MTAs (X.400 Message Transfer Agents).
X.500とX.400のための名前空間は、完全に異なって、異なった需要を満たすために構造化されます。 X.500名前スペースが迅速で、最適化された探すことを許すのが通常組織化されます。 X.400 ORnameはMTAs(X.400 Message Transferエージェント)の数個の「レベル」を通してX.400メッセージを転送するのに使用されますが。
ESnet backbone sites will participate in the X.400 environment through one of two options; either participating in the ESnet Private Management Domain (PRMD) or operating a site PRMD. For most sites, utilizing the ESnet PRMD will be the simpler and preferable choice.
2つのオプションの1つでESnet背骨サイトはX.400環境に参加するでしょう。 ESnet兵士のManagement Domain(PRMD)に参加するか、またはサイトPRMDを操作します。 ESnet PRMDを利用するのはほとんどのサイトへの、より簡単で望ましい選択になるでしょう。
3.3.1. Participating in the ESnet Private Management Domain
3.3.1. ESnet自営業ドメインに参加します。
ESnet backbone sites participating in the ESnet PRMD will have an X.400 name syntax as follows:
ESnet PRMDに参加するESnet背骨サイトで、X.400名前構文は以下の通りになるでしょう:
/.../O=<site>/PRMD=ESnet/ADMD= /C=US/
/.../Oは<サイト>/PRMD=ESnet/ADMD=/C=U.S./と等しいです。
A few examples of a possible X.400 ORnames using the above syntax are:
上の構文を使用する可能なX.400 ORnamesに関するいくつかの例は以下の通りです。
ESCC X.500/X.400 Task Force [Page 25] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[25ページ]RFC1330X.500とX.400プラン
/PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
/PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/
/PN=スミス/OU=計算/O=LLNL/PRMD=ESnet/ADMD=/C=米国//PN=ジョーンズ/OUは物理学/O=PPPL/PRMD=ESnet/ADMD=/C=U.S./と等しいです。
These sites will operate an MTA at the /O=<organization> level in the name hierarchy.
これらのサイトは<組織>/O=レベルでMTAを名前階層構造で操作するでしょう。
3.3.2. Operating a Site Private Management Domain
3.3.2. サイト自営業ドメインを操作します。
ESnet backbone sites which operate a PRMD will have an X.400 name syntax as follows:
PRMDを操作するESnet背骨サイトで、X.400名前構文は以下の通りになるでしょう:
/.../O=<org>/PRMD=<site>/ADMD= /C=US/
/.../O=<org>/PRMDは<サイト>/ADMD=/C=U.S./と等しいです。
A few examples of a possible X.400 ORnames using the above syntax are:
上の構文を使用する可能なX.400 ORnamesに関するいくつかの例は以下の通りです。
/PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/
/PN=Jones/O=Physics/PRMD=PPPL/ADMD= /C=US/
/PN=スミス/O=計算/PRMD=LLNL/ADMD=/C=米国//PNはジョーンズ/O=物理学/PRMD=PPPL/ADMD=/C=U.S./と等しいです。
These sites will operate an MTA at the /PRMD=<PRMD> level in the name hierarchy. This MTA will peer with the ESnet PRMD MTA.
これらのサイトは/PRMD=<PRMD>レベルでMTAを名前階層構造で操作するでしょう。 このMTAはESnet PRMD MTAと共にじっと見るでしょう。
3.3.3. Detailed Name Structure
3.3.3. 詳細な名前構造
GOSIP places several limits on allowable ORnames. After the /O=<organization> name, up to four levels of /OU=<organizational_unit> names are allowed. The ORname string is then completed with the /PN=<personal_name> field.
GOSIPはいくつかの限界を許容できるORnamesに置きます。 /Oが組織>が命名する<と等しかった後に、>が命名する最大4つのレベルの<の組織的な_/OU=単位は許容されています。 そして、ORnameストリングは/<個人的な_名前>PN=分野で完成します。
All ORname fields must use characters from the ISO printable character set. Additionally, the following name length restrictions apply:
すべてのORname分野がISOの印刷可能な文字の組からキャラクタを使用しなければなりません。 さらに、以下の名前長さの制限は適用されます:
PRMD Names 16 characters
Organization Names 64 characters
Organizational Unit Names 32 characters
Personal Names 64 characters
PRMD Names16キャラクタOrganization Names64キャラクタOrganizational Unit Names32キャラクタパーソナルNames、64のキャラクタ
NOTE: A 40 character limit for Personal Names is now being
studied by the CCITT.
以下に注意してください。 パーソナルNamesのための40キャラクタ限界は現在、CCITTによって研究されています。
Within these name constraints, the architecting of an organization's name space is a local matter. Sites are encouraged to consider ease of use and stability when determining their naming structure.
これらの名前規制の中では、組織名スペースのarchitectingは地域にかかわる事柄です。 彼らが構造を命名することを決定するとき、サイトが使いやすさと安定性を考えるよう奨励されます。
3.4. X.400 Routing
3.4. X.400ルート設定
In the IP environment a SMTP MTA could use the Domain Name Service
IP環境で、SMTP MTAはDomain Name Serviceを使用できました。
ESCC X.500/X.400 Task Force [Page 26] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[26ページ]RFC1330X.500とX.400プラン
(DNS) to locate connection information for the host closest to the recipient. With X.400, MTAs must know the remote MTAs name and password along with connection information. This is because of access control requirements on some X.400 systems. In X.400 MHS this information will, at some future date, be provided by X.500. In the mean time the routing and connection process within the X.400 community is table driven. This solution requires a coordination and distribution effort to ensure a quick and reliable update of these tables.
(DNS) 受取人の最も近くでホストへの接続情報の場所を見つけるように。 X.400と共に、MTAsは接続情報に伴うリモートMTAs名とパスワードを知らなければなりません。 いくつかのX.400システムに関するアクセス管理要件のためにこれはそうです。X.400 MHSに、この情報はいつかの将来の期日にX.500によって提供されるでしょう。 その間に、X.400共同体の中のルーティングと接続の過程は動かされたテーブルです。 この解決策はコーディネートとこれらのテーブルの迅速で信頼できるアップデートを確実にするための分配の努力を必要とします。
The current thinking on the problem of X.400 routing is to decompose the X.400 address space into a hierarchy, with each node in this hierarchy representing the entry point for an X.400 domain. These nodes have been commonly called Well Known Entry Points (WEPs). Each of these WEPs represent one X.400 MHS domain. For example:
X.400ルーティングの問題の現在の考えはX.400アドレス空間を階層構造に分解することです、この階層構造の各ノードがX.400ドメインにエントリー・ポイントを表していて。 これらのノードは一般的にWell Known Entry Points(WEPs)と呼ばれました。 それぞれのこれらのWEPsは1つのX.400 MHSドメインを表します。 例えば:
/O=LBL/PRMD=ESnet/ADMD= /C=US/
/O=NERSC/PRMD=ESnet/ADMD= /C=US/
/PRMD=ESnet/ADMD= /C=US/
/PRMD=ANL/ADMD= /C=US/
/PRMD=PNL/ADMD= /C=US/
/O=LBL/PRMD=ESnet/ADMD=/Cは米国//O=NERSC/PRMD=ESnet/ADMD=/C=米国//PRMD=ESnet/ADMD=/C=米国//PRMD=ANL/ADMD=/C=米国//PRMD=PNL/ADMD=/C=U.S./と等しいです。
To minimize the number of hops between Originators and Recipients it is the current recommendation of the X.400 community that every PRMD peer with all other PRMDs.
OriginatorsとRecipientsの間のホップの数を最小にするために、それはあらゆるPRMDが他のすべてのPRMDsと共にじっと見るというX.400共同体の現在の推薦です。
The ESnet backbone will provide connectivity between multiple PRMDs (the ESnet PRMD and any site operated PRMDs), each with associated well-know entry point MTAs. Each of these PRMD-level MTAs must be configured with routing and mapping information about each other to enable peer-to-peer PRMD routing. These routing tables should be updated immediately upon the discovery of new/changed X.400 connectivity information. These tables will be made available to the ESnet community via the ESnet Information Server. Once placed on- line, a notification message announcing the availability of this new routing information will be sent to every WEP owner via the E-mail mechanism described in Section 3.5.1. It is recommended that WEP administrators should retrieve this new routing information and update their MTAs within 10 working days.
ESnet背骨は複数のPRMDsの間に接続性を供給するでしょう(ESnet PRMDとどんなサイトもPRMDsを操作しました)、それぞれ関連よく知っているエントリー・ポイントMTAsと共に。 互いに関するルーティングとマッピング情報でそれぞれのこれらのPRMD-レベルMTAsを構成して、ピアツーピアPRMDルーティングを可能にしなければなりません。 すぐ新しいか変えられたX.400接続性情報の発見のときにこれらの経路指定テーブルをアップデートするべきです。 これらのテーブルをESnet情報Serverを通してESnet共同体に利用可能にする、一度入賞する、オンである、線、セクション3.5で.1に説明されたメールメカニズムでこの新しいルーティング情報の有用性を発表する通知メッセージをすべてのWEP所有者に送るでしょう。 WEP管理者がこの新しいルーティング情報を検索して、10営業日以内に彼らのMTAsをアップデートするのは、お勧めです。
The well-known entry point MTA for each PRMD can route down to an Organizational level MTA or laterally to the well-known entry point of a peer PRMD MTA.
各PRMDのための周知のエントリー・ポイントMTAは横に同輩PRMD MTAの周知のエントリー・ポイントにレベルMTAをOrganizationalまで発送できます。
For example, the ESnet MTA would route a message with the address:
例えば、ESnet MTAはアドレスでメッセージを発送するでしょう:
/PN=Funk/OU=CS/O=PPPL/PRMD=ESnet/ADMD= /C=US/
/PN=ファンク/OU=Cs/O=PPPL/PRMD=ESnet/ADMD=/CはU.S./と等しいです。
ESCC X.500/X.400 Task Force [Page 27] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[27ページ]RFC1330X.500とX.400プラン
to a well-known entry point for PPPL (O=PPPL). PPPL must own and operate their own X.400 MTA, and it must be configured to accept X.400 messages from the ESnet MTA. Thus, the interpretation of remaining "/PN=Funk/OU=CS" is left to the PPPL MTA to route.
周知のエントリーに、PPPL(O=PPPL)のために指してください。 PPPLはそれら自身のX.400 MTAを所有して、操作しなければなりません、そして、ESnet MTAからX.400メッセージを受け入れるのは構成していなければなりません。 「その結果、」 /PN=ファンク/OUのままで残る解釈はCsと等しいこと」が発送するのがPPPL MTAに残されます。
Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD) to be eventually routed to its destination.
PPPLのMTAから送られたメールは、結局目的地に発送されるためにESnetのMTA(PRMD)に発送されるでしょう。
The ESnet MTA will also route to peer MTAs which are well-known entry points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes Air Craft, NASA, CDC). For example, the ESnet MTA would route a message with the address:
また、ESnet MTAは他のPRMDs(例えば、ESnet背骨サイトPRMDs、XNREN、ヒューズAir Craft、NASA、CDC)のための周知のエントリー・ポイントであるMTAsを同輩に発送するでしょう。 例えば、ESnet MTAはアドレスでメッセージを発送するでしょう:
/PN=Smith/OU=MS/O=RL/PRMD=PNL/ADMD= /C=US/
/PN=スミス/OU=さん/O=RL/PRMD=PNL/ADMD=/CはU.S./と等しいです。
to a well-known entry point for PNL (PRMD=PNL). PNL must own and operate their own X.400 MTA, and it must be configured to accept X.400 messages from the ESnet MTA (as well as possibly other PRMDs). Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is left to the PNL MTA to route.
周知のエントリーに、PNL(PRMD=PNL)のために指してください。 PNLはそれら自身のX.400 MTAを所有して、操作しなければなりません、そして、ESnet MTA(ことによると他のPRMDsと同様に)からX.400メッセージを受け入れるのは構成していなければなりません。 「その結果、残り」 /PN=スミス/OU=MS/O=RLの解釈」は発送しますPNL MTAに残される。
Mail sent from PNL's MTA (PRMD) would be routed to the well-known entry point for the PRMD indicated in the destination address.
PNLのMTA(PRMD)から送られたメールは送付先アドレスで示されたPRMDのために周知のエントリー・ポイントに発送されるでしょう。
Additionally, a site operated PRMD must be able to route mail to any other peer-PRMD within the ESnet community.
さらに、サイトの操作されたPRMDはESnet共同体の中のいかなる他の同輩-PRMDにもメールを発送できなければなりません。
3.4.1. Responsibilities in Operating an X.400 PRMD MTA
3.4.1. X.400 PRMD MTAを操作することにおける責任
If the X.400 world were to operate exactly as the standard recommends, PRMDs would only peer with other PRMDs when connectivity is available and traffic demand is sufficient, and would utilize ADMD services to reach all other PRMDs. In reality, many PRMDs will not subscribe to an ADMD service and will only be reachable through PRMD peering.
ちょうど規格が推薦するようにX.400世界が作動するなら、PRMDsは、接続性が利用可能であり、交通需要が十分であるときにだけ、他のPRMDsと共にじっと見て、他のすべてのPRMDsに達するのにADMDサービスを利用するでしょうに。 多くのPRMDsがADMDサービスに加入しないで、単にPRMDのじっと見ることでほんとうは、届くようになるでしょう。
Most communities, such as the ESnet, desire the fullest PRMD interconnectivity possible to minimize the need for ADMD services. Community PRMD operational requirements stem from a policy of achieving large scale peering among PRMD operators within the community.
ESnetなどのほとんどの共同体が、可能な最もふくよかなPRMDの相互接続性がADMDサービスの必要性を最小にすることを望んでいます。 共同体のPRMDの操作上の要件は共同体の中のPRMDオペレータの中の大規模じっと見ることを達成する方針によります。
Work is continuing in the IETF X.400 Operations Working Group to produce an RFC that specifies the operational requirements that must be implemented by X.400 Management Domains. "Requirements for X.400 Management Domains (MDs) Operating in the Global Research and Development X.400 Service", this document is listed in Appendix G. ESnet will comply with all the requirements outlined in this
仕事はIETF X.400 Operations作業部会でX.400 Management Domainsが実行しなければならない操作上の要件を指定するRFCを生産し続けていることです。 「X.400 Management Domains(MDs)のための要件はGlobal ResearchとDevelopment X.400 Serviceで作動する」と、リストアップされたこのドキュメントはAppendix G.ESnetでこれに概説されているすべての要件に応じるでしょう。
ESCC X.500/X.400 Task Force [Page 28] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[28ページ]RFC1330X.500とX.400プラン
document. It is the recommendation that all ESnet PRMDs follow the requirements specified in this document.
記録します。 それはすべてのESnet PRMDsが本書では指定された要件に続くという推薦です。
As an overview, this document specifies that each PRMD will provide at least one WEP and that all PRMDs must be interconnected. There are a number of PRMDs in the International X.400 service that have different communication stack requirements. For example:
概観として、このドキュメントは各PRMDが少なくとも1WEPを提供して、すべてのPRMDsとインタコネクトしなければならないと指定します。 国際X.400サービスにおける異なったコミュニケーションスタック要件を持っている多くのPRMDsがあります。 例えば:
Stack 1 Stack 2 Stack 3 Stack 4
------- ------- ------- -------
Transport Layer 4 TP0 TP4 RFC-1006 TP0
Network Service 1-3 X.25 CLNS TCP/IP CONS
スタック1スタック2スタック3スタック4------- ------- ------- ------- トランスポート層4TP0 TP4 RFC-1006 TP0ネットワーク・サービス1-3X.25 CLNS TCP/IPまやかし
To meet the requirement that all PRMDs must be interconnected a PRMD must support one or more of the above stacks. For stacks that are not supported the PRMD must negotiate with another PRMD or ADMD to relay messages to a Management Domain that does support the other stacks.
すべてのPRMDsとインタコネクトしなければならないという必要条件を満たすために、PRMDは上のスタックの1つ以上を支持しなければなりません。 支えられないスタックに関しては、PRMDは他のスタックを支えるManagement Domainにメッセージをリレーする別のPRMDかADMDと交渉しなければなりません。
The PRMD requirements also suggest that PRMDs support downgrading of X.400 1988 to X.400 1984. Also, the PRMD must be reachable from the Internet Mail service. This means the PRMD must maintain an Internet Mail/X.400 gateway.
また、PRMD要件はX.400 1988のそのPRMDsサポート格下げをX.400 1984に示します。 また、PRMDもインターネットメールサービスによって届いているに違いありません。 これは、PRMDがインターネットメール/X.400ゲートウェイを維持しなければならないことを意味します。
In all cases, members of the ESnet community who operate a PRMD should notify ESnet of the WEP and MTA information required to perform peering.
すべての場合では、PRMDを運用するESnet共同体のメンバーは情報がじっと見ることを実行するのを必要としたWEPとMTAについてESnetに通知するべきです。
3.4.2. Responsibilities in Operating an X.400 Organizational MTA
3.4.2. X.400の組織的なMTAを操作することにおける責任
ESnet will provide PRMD service to the ESnet community. ESnet will peer with the other PRMDs in the International X.400 service and provide a WEP for the ESnet community. An Organization/site needs to decide if they are going to comply with the above PRMD requirements or act as an organization associated to the ESnet PRMD. Minimally, an organizational MTA will only have to support one of the protocol stacks provided by it associated PRMD. But in all cases, the site will need to provide a WEP and register/list their MTA(s) with ESnet.
ESnetはESnet共同体に対するサービスをPRMDに供給するでしょう。 ESnetは他のPRMDsと共に国際X.400サービスでじっと見て、ESnet共同体にWEPを提供するでしょう。 Organization/サイトは、組織がESnet PRMDと交際したので彼らが上記のPRMD要件か行為に従うだろうかどうか決める必要があります。 最少量で、組織的なMTAはスタックがそれで関連PRMDを提供したプロトコルの1つを支持するだけでよいでしょう。 しかし、すべての場合では、サイトは、ESnetと共にそれらのMTA(s)をWEPを提供して、登録するか、または記載する必要があるでしょう。
3.5. Services Provided by ESnet
3.5. ESnetによって提供されたサービス
ESnet will provide PRMD service to those members of the ESnet community who desire it. ESnet will peer with other PRMDs in the International community (e.g. XNREN, Hughes Air Craft, NASA, CDC) and provide a WEP for the ESnet community; the intent is to provide the fullest PRMD level X.400 services.
ESnetはそれを望んでいるESnet共同体のそれらのメンバーに対するサービスをPRMDに供給するでしょう。 ESnetは国際共同体(例えば、XNREN、ヒューズAir Craft、NASA、CDC)の他のPRMDsと共にじっと見て、ESnet共同体にWEPを提供するでしょう。 意図は最もふくよかなPRMD平らなX.400サービスを提供することです。
ESnet will deploy two, PRMD level, X.400 MTAs in geographically
ESnetは中で地理的に2、PRMDレベル、X.400 MTAsを配備するでしょう。
ESCC X.500/X.400 Task Force [Page 29] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[29ページ]RFC1330X.500とX.400プラン
disperse locations. These MTAs will be able to forward mail for directly connected ESnet backbone sites, as well as to and from the peered PRMDs.
位置を分散してください。 これらのMTAsは直接接続されたESnet背骨サイトのためのメールを転送できるでしょう、PRMDsと、そして、よくじっと見たPRMDsように。
3.5.1. X.400 Operations Mailing List
3.5.1. X.400操作メーリングリスト
ESnet will provide an X.400 operations mailer for announcements and to allow the sharing of X.400 operational information in the ESnet community.
ESnetは、発表、ESnet共同体でのX.400運用情報の共有を許すためにX.400操作郵送者を提供するでしょう。
General discussion: x400-ops@es.net
To subscribe: x400-ops-request@es.net
一般議論: 申し込む x400-ops@es.net : x400-ops-request@es.net
3.5.2. MTA Routing Table on ESnet Information Server
3.5.2. ESnet情報サーバのMTA経路指定テーブル
ESnet will maintain forwarding information about ESnet community MTAs at the /PRMD=<PRMD> or /O=<organization> levels (depending on what level the site MTA is operating). This information will be available for use in configuring directly connected ESnet site operated MTAs. This information will be made available in a machine independent format on the ESnet Information Server.
ESnetは、/PRMDでESnet共同体MTAsの情報を転送するのが<PRMD>と等しい、または/Oが<組織>レベルと等しいと(サイトMTAがどんなレベルを操作しているかによって)主張するでしょう。 この情報は直接接続されたESnetサイトがMTAsを操作したのを構成することにおける使用に利用可能になるでしょう。 この情報をESnet情報Serverでマシンの独立している形式で利用可能にするでしょう。
3.5.3. MTA Routing Table Format
3.5.3. MTA経路指定テーブル形式
The ESnet staff will determine the details of information format, update frequency, obtaining, and disseminating the information based on operational experience and constraints.
ESnetスタッフは情報形式の詳細を決定するでしょう、アップデート頻度、運用経験と規制に基づく情報を得て、広めて。
3.5.4. Gateway Services and Multiprotocol Stack Support
3.5.4. ゲートウェイサービスとMultiprotocolスタックサポート
The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail gateway capabilities, and will operate over the OSI CLNS protocol (as defined by GOSIP) and RFC-1006 stacks. Configuration and operation of mail protocol gateway functions will be governed by the ESnet staff.
ESnet MTAsは双方向のSMTP-X.400メール・ゲートウェイ能力を最少量で支持して、OSI CLNSプロトコルの上で作動するでしょう、そして、(GOSIPによって定義されるように)RFC-1006は積み重ねます。 メールプロトコルゲートウェイ機能の構成と操作はESnetスタッフによって決定されるでしょう。
Backbone site MTAs which service ORnames at the /O=<site> level under the ESnet PRMD must utilize one of the ESnet PRMD supported protocol stacks. This requirement assures that all users of the ESnet PRMD will be able to communicate to one another via the ESnet PRMD MTA.
/O=<サイト>のサービスORnamesがESnet PRMDの下で平らにする背骨サイトMTAsは支持されたプロトコルが積み重ねるESnet PRMDの1つを利用しなければなりません。 この要件は、ESnet PRMDのすべてのユーザがESnet PRMD MTAを通ってお互いに交信できることを保証します。
Backbone site MTAs which service ORnames in PRMDs other than /PRMD=ESnet must utilize the OSI CLNS stack for GOSIP conformance. Use of the RFC-1006 stack is optional. This requirement assures that all PRMDs in the ESnet community will be able to peer with the ESnet PRMD.
/PRMD=ESnet以外のPRMDsでORnamesを調整する背骨サイトMTAsはGOSIP順応にOSI CLNSスタックを利用しなければなりません。 RFC-1006スタックの使用は任意です。 この要件は、ESnet共同体のすべてのPRMDsがESnet PRMDと共にじっと見ることができることを保証します。
ESCC X.500/X.400 Task Force [Page 30] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[30ページ]RFC1330X.500とX.400プラン
3.5.5. Registering/Listing your PRMD or Organizational MTA with ESnet
3.5.5. ESnetと共にあなたのPRMDかOrganizational MTAを登録するか、または記載します。
To provide for the connection and routing requirements in X.400 you will need to register/list your MTA with ESnet. This information will be maintained in tables on the ESnet Information Server. ESnet will also maintain information on the International X.400 service. ESnet will use the same format for information as maintained by the International X.400 service. This is described in detail in a IETF X.400 operations paper "Routing Coordination for X.400 MHS Services within a Multiprotocol/Multinetwork Environment". This paper is a working draft, see Appendix G. It describes a machine independent form for distribution of X.400 information.
X.400に接続とルーティング要件に備えるために、あなたは、ESnetと共にあなたのMTAを登録するか、または記載する必要があるでしょう。 この情報はまたServer. ESnetが国際X.400サービスの情報であることを支持するESnet情報でテーブルで保守されるでしょう。 ESnetは情報に国際X.400サービスで維持されるように同じ形式を使用するでしょう。 これはIETF X.400操作論文「Multiprotocol/Multinetwork環境の中のX.400 MHSサービスのためのルート設定コーディネート」で詳細に説明されます。 Appendix G.は、この紙が概要版であると考えます。ItはX.400情報の分配のためのマシンの独立しているフォームについて説明します。
There are three tables that must be maintained and exchanged by the top level WEPS.
最高平らなWEPSが維持されて、交換しなければならない3個のテーブルがあります。
1. The Community Document
1. 共同体ドキュメント
2. The WEP Document
2. WEPドキュメント
3. The Domain Document
3. ドメインドキュメント
ESnet will submit these documents to the International X.400 community on behalf of the ESnet Community. If an ESnet PRMD wishes to peer with the International PRMDs they will need to submit these documents to that community.
ESnetはESnet Communityを代表して国際X.400共同体にこれらのドキュメントを提出するでしょう。 ESnet PRMDが国際PRMDsと共にじっと見たいなら、彼らは、その共同体にこれらのドキュメントを提出する必要があるでしょう。
The Community document is used to list the central coordination point and file server where all MHS documents will be stored. It also lists the communication stacks used by the MHS community. This document will be submitted to the International X.400 service by ESnet for the ESnet Community. ESnet PRMDs and Organizations do not need to submit this form to ESnet. If an ESnet PRMD wishes to peer with the International X.400 service then they must submit this form to that community.
Communityドキュメントは、すべてのMHSドキュメントが格納されるところに主要なコーディネートポイントとファイルサーバーを記載するのに使用されます。 また、それはMHS共同体によって使用されたコミュニケーションスタックを記載します。 このドキュメントはESnet CommunityのためにESnetによって国際X.400サービスに提出されるでしょう。 ESnet PRMDsとOrganizationsはこのフォームをESnetに提出する必要はありません。 ESnet PRMDが国際X.400サービスでじっと見たいなら、彼らはその共同体にこのフォームを提出しなければなりません。
Each ESnet MHS domain will need to submit a WEP and Domain Document to ESnet. The WEP document is used to list the WEPs used by an ESnet MHS domain. It will contain all the information that is needed for MTA connection and access control. ESnet will submit the ESnet community WEP and Domain Documents to the International X.400 service. The WEP document consists of a list of WEPs, with the following information for each one:
それぞれのESnet MHSドメインは、WEPとDomain DocumentをESnetに提出する必要があるでしょう。 WEPドキュメントは、ESnet MHSドメインによって使用されるWEPsを記載するのに使用されます。 それはMTA接続とアクセス管理に必要であるすべての情報を含むでしょう。 ESnetはESnet共同体のWEPとDomain Documentsを国際X.400サービスに提出するでしょう。 WEPドキュメントはそれぞれへの以下の情報でWEPsのリストから成ります:
o The MTA Name
o MTA名
o Password
o パスワード
ESCC X.500/X.400 Task Force [Page 31] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[31ページ]RFC1330X.500とX.400プラン
o Which MTS supported
o どのMTSが支持されますか?
o Which standard, 84 and/or 88
o どの規格、84、そして/または、88
o Connection information outbound
o 接続情報外国行きです。
o Connection information inbound
o 接続情報本国行きです。
o Computer system information
o コンピュータ・システム情報
o Point of contact
o 連絡先
The Domain Document specifies all the X.400 domains managed by a site. It indicates the person responsible and which WEP services which Domain. This document contains the following information repeated for each Domain:
Domain Documentはサイトによって管理されたすべてのX.400ドメインを指定します。 それは、責任がある人とどのWEPがどのDomainを調整するかを示します。 このドキュメントは各Domainのために繰り返された以下の情報を含んでいます:
o X.400 Domain
o X.400ドメイン
o Point of Contact
o 連絡先
o Relaying WEP(s)
o WEPをリレーします。(s)
3.6. X.400 Message Routing Between ADMDS and PRMDS
3.6. ADMDSとPRMDSの間のX.400メッセージルーティング
While ESnet will provide X.400 routing service for systems, it cannot provide routing via commercial X.400 carriers at this time. The FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25 packet charges. This could result in a charge of several dollars for large messages, a real possibility with the multi-media capacity of X.400. The payment of this fee is not within the charter of ESnet and the provision of a charging mechanism to charge member sites is not currently contemplated.
ESnetがシステムのためのルーティングサービスをX.400に供給している間、それはこのとき、商用X.400キャリヤーを通してルーティングを提供しないことができます。 ルーティングX.400メッセージのためのFTS-2000料金は、.45ドルの(米国)とX.25パケット料金です。 これは大きいメッセージ(X.400のマルチメディア容量がある現実に起こり得ること)のための数ドルの料金をもたらすかもしれません。 ESnetの特許の中にこの料金の支払いがありません、そして、料金メンバーサイトへの充電メカニズムに関する条項は現在、熟考されません。
3.7. X.400 Registration Requirements
3.7. X.400登録要件
It is recommended by the CCITT that all X.400 PRMD names be nationally unique. This is a current CCITT agreement and allows direct PRMD-PRMD peer routing. Since national uniqueness is required, registration should be performed through an appropriate registration authority (such as ANSI).
すべてのX.400 PRMD名が全国的にユニークであることがCCITTによって推薦されます。 これは、現在のCCITT協定であり、ダイレクトPRMD-PRMD同輩ルーティングを許します。 国家のユニークさが必要であるので、登録は適切な登録局(ANSIなどの)を通して実行されるべきです。
X.400 organization names must be unique within a PRMD. There is no need for national uniqueness. Registration of an X.400 organization name should be conducted through the PRMD operator.
X.400組織名はPRMDの中でユニークであるに違いありません。 国家のユニークさの必要は全くありません。 X.400組織名の登録がPRMDオペレータを通して行われるべきです。
The registration of X.400 names below the organization level are usually a local matter. Uniqueness within the context of a superior
通常、組織レベルの下におけるX.400名の登録は地域にかかわる事柄です。 上司の文脈の中のユニークさ
ESCC X.500/X.400 Task Force [Page 32] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[32ページ]RFC1330X.500とX.400プラン
name should always be maintained.
名前はいつも維持されるべきです。
See Section 4 for a more complete description of OSI registration issues and procedures.
OSI登録問題と手順の、より完全な記述に関してセクション4を見てください。
3.8. Future X.400 Issues to be Considered
3.8. Consideredである将来のX.400 Issues
3.8.1. X.400 Mail Routing to International DOE Researchers
3.8.1. X.400は国際DOE研究者にルート設定を郵送します。
Currently there are DOE researchers located in Switzerland, Japan, Germany, China and Brazil. PRMD level connectivity to these international locations does not exist presently. Since ESnet is not chartered to pay for commercial X.400 services on behalf of the ESnet community, "buying" this service is not a viable option.
現在、スイス、日本、ドイツ、中国、およびブラジルに位置するDOE研究者がいます。 これらの国際的な位置へのPRMDの平らな接続性は現在、存在しません。 ESnetがESnet共同体を代表して商業X.400サービスの代価を払うためにチャーターされないので、このサービスが「購入」であることは、実行可能なオプションではありません。
There are efforts taking place to provide international X.400 service over the (international) Internet. Once this becomes fully operational, further research will have to be performed to see if this provides the X.400 connectivity needed to support the DOE researchers located abroad.
(国際的)のインターネットを国際的なX.400サービスオーバーに提供する場所を取る努力があります。 これがいったん完全に操作上になると、さらなる研究は、これが海外に位置したDOE研究者を支持するのに必要であるX.400の接続性を提供するかどうかを見るために実行されなければならないでしょう。
3.8.2. X.400 (1984) and X.400 (1988)
3.8.2. X.400(1984)とX.400(1988)
The ESnet MTAs will initially support the 1984 version of the X.400 standard. As the use of 1988 X.400 becomes more prevalent, support for the newer standard will need to be addressed. One important point, once the ESnet MTAs become 1988 X.400 compliant, they will also have so support "downgrading" to 1984 X.400 to ensure reliable X.400 mail delivery to the ESnet community.
ESnet MTAsは初めは、1984年のX.400規格のバージョンを支持するでしょう。 1988X.400の使用が、より一般的になるとき、より新しい規格のサポートは、記述される必要があるでしょう。 重要な1ポイントによって、ESnet MTAsがいったん1988X.400対応するのになると、また、彼らには信頼できるX.400郵便配達をESnet共同体に確実にするためにX.400を1984に「格下げする」サポートがあるでしょう。
3.8.3. X.400 Interaction with X.500
3.8.3. X.500とのX.400相互作用
This is discussed in Section 2.10.2.
セクション2.10.2でこれについて議論します。
4. OSI Name Registration and Issues
4. OSI名前登録と問題
Implementing OSI services requires that certain information objects (e.g., people, information processing systems and applications) must be unambiguously identifiable on a global basis. These objects may be defined by a variety of organizations, e.g., ISO/IEC, CCITT, commercial, and government.
OSIサービスを実行するのは、ある情報物(例えば、人々、情報処理システム、およびアプリケーション)が明白に地球規模で身元保証可能でなければならないことを必要とします。 これらの物はさまざまな組織、例えば、ISO/IEC、CCITT、コマーシャル、および政府によって定義されるかもしれません。
To meet this requirement ISO/IEC and CCITT have established a hierarchical structure of names (a tree). The top level of the naming tree, shared by ISO and CCITT, represents the global naming- domain. Naming domains are managed by registration authorities. A registration authority can delegate authority for part of its naming-domain to another (lower level) registration authority, thus
この必要条件を満たすために、ISO/IECとCCITTは名前(木)の階層構造を確立しました。 ISOとCCITTによって共有された命名木のトップレベルはグローバルな命名ドメインを表します。 命名ドメインは登録局によって管理されます。 その結果、登録局は別の(下のレベル)登録局への命名ドメインの一部に権限を委ねることができます。
ESCC X.500/X.400 Task Force [Page 33] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[33ページ]RFC1330X.500とX.400プラン
forming the tree.
木を形成します。
Each object can be given a unique and unambiguous name by registering the object's name with an OSI registration authority at an appropriate level in the naming tree.
命名木の適正水準におけるOSI登録局の物の名前を登録しながらユニークで明白な名前を物に与えることができるそれぞれ。
OSI name registration authorities and their procedures are expected to change over time. Since names are intended to be stable, these changes (hopefully!) will have minimal impact on existing OSI name registrations.
OSI名前登録局とそれらの手順が時間がたつにつれて変化すると予想されます。 名前が安定していることを意図するので、これらの変化は(希望をいだいて)!既存のOSI名前登録証明書に最小量の影響力を持つでしょう。
This section describes the role of OSI registration authorities, the difference between a "registration" and a "notification", and sources of nationally unique names. Information about three OSI name registration authorities; the American National Standards Institute (ANSI), the General Services Administration (GSA), and the U.S. Department of Energy (U.S. DOE); are given.
このセクションはOSI登録局の役割、「登録」と「通知」の違い、および全国的にユニークな名前の源について説明します。 情報およそthree OSIは登録局を命名します。 American National Standards Institut(ANSI)、共通役務庁(GSA)と米国エネルギー省(米国DOE)。 与えます。
Registration of a name often requires stating a "right" to that name. However, an OSI name registration does not guarantee legal name rights. Name rights should be reviewed by legal experts prior to registration. Information about the U.S. Department of Commerce, Patent and Trademark Office (PTO) (potentially useful in asserting or defending name rights) is given below.
名前の登録は、しばしばその名前への「権利」を述べるのを必要とします。 しかしながら、OSI名前登録は法的な名前権利を保証しません。 名前権利は登録の前に法律専門家によって見直されるべきです。 米国商務省、特許・商標局(PTO)(潜在的に名前権利を主張するか、または守るのにおいて役に立つ)の情報を以下に与えます。
4.1. Registration Authorities
4.1. 登録局
OSI names are obtained through OSI name registration authorities by a registration process. The selection of which particular registration authority to use is determined by the desired level of the OSI name in the naming hierarchy, possible restrictions on the names allocated by each registration authority, and the applicability rules (will they service your request) of each registration authority.
OSI名前登録局を通して登録手続でOSI名を得ます。 どの特定の登録局を使用したらよいかに関する選択が命名階層構造のOSI名の必要なレベル、各登録局によって割り当てられた名前における可能な制限、および適用性規則で決定する、(修理する、あなたの要求) それぞれの登録局について。
An OSI name registration authority allocates OSI names from the particular naming-domain it controls. Every registration authority can trace its naming authority to its parent registration authority, and ultimately to the top (global) level of the naming hierarchy.
OSI名前登録局は名前をそれが制御する特定の命名ドメインからOSIに割り当てます。 あらゆる登録局が、結局親登録局と権威を命名するのを命名階層構造のトップ(グローバルな)のレベルにたどることができます。
4.2. Registration Versus Notification
4.2. 登録対通知
Registering an OSI name guarantees its uniqueness and lack of ambiguity. For a name to be useful however, other parties (besides the registration authority) will need to be notified of the name and its usage.
OSI名を登録すると、そのあいまいさのユニークさと不足は保証されます。 しかしながら、名前が役に立つように、相手(登録局以外に)は、名前とその用法について通知される必要があるでしょう。
There is a clear distinction between registration (obtaining an OSI name) and notification (informing others of a name and its use).
登録(OSI名を得る)と通知(名前について他のものに知らせて、使用)の間には、明らかな区別があります。
ESCC X.500/X.400 Task Force [Page 34] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[34ページ]RFC1330X.500とX.400プラン
Often the term "registration" is used to describe both activities, this is a potential source of confusion.
しばしば、「登録」という用語は両方の活動について説明するのに使用されて、これは混乱の可能な源です。
For example, NADF and PSI (see Section 2) are not OSI registration authorities. NADF may operate state registration authorities in the future, if delegated that administrative right by the states. PSI operates an X.500 pilot project and needs to be notified of registered names when organizations join their pilot.
例えば、NADFとPSI(セクション2を見る)はOSI登録局ではありません。 まさしく州のそばでそんなに管理であることで代表として派遣するなら、NADFは将来、州の登録局を経営するかもしれません。 組織が彼らのパイロットに加わるとき、PSIは、X.500試験計画を経営して、登録名について通知される必要があります。
X.400 ADMD operators are also not OSI registration authorities, although they accept notification of X.400 PRMD names used by their customers.
また、X.400 ADMDオペレータはOSI登録局ではありません、彼らの顧客によって使用されたX.400 PRMD名の通知を受け入れますが。
The PTO is not an OSI registration authority. PTO names have no meaning in an OSI context.
PTOはOSI登録局ではありません。 PTO名には、OSI文脈での意味がありません。
4.3. Sources of Nationally Unique Name Registration
4.3. 全国的にユニークな名前登録の源
There are four potential sources of nationally unique names which are of interest to the ESnet community. These are ANSI, GSA, U.S. DOE and the states. An overview of the ANSI, GSA, and U.S. DOE procedures are given in later sections.
ESnet共同体に興味がある全国的にユニークな名前の4つの可能な源があります。 これらは、ANSIと、GSAと、U.S. DOEと州です。 手順が後のセクションで与えられているANSI、GSA、およびU.S. DOEの概観。
In order to maintain national uniqueness "constructed name syntax" is used by GSA, U.S. DOE, and the states. The form of each name is shown below, "name" is the name presented to the registration authority for registration.
国家のユニークさを維持するために、「組み立てられた名前構文」はGSA、U.S. DOE、および州によって使用されます。 それぞれの名前の書式は「名前」が以下では、登録のために登録局に提示された名前であることが示されます。
1. ANSI names are of the form "name".
1. ANSI名はフォーム「名前」のものです。
2. GSA names are of the form "GOV+name".
2. GSA名はフォーム「GOV+名前」のものです。
3. U.S. DOE names are of the form "GOV+USDOE+name".
3. U.S. DOE名はフォーム「GOV+USDOE+名前」のものです。
4. State names are of the form "CA+name" (using California).
4. 州の名はフォーム「カリフォルニア+名前」のもの(カリフォルニアを使用して)です。
State name registration authorities are not in operation at this time. The use of U.S. DOE as a nationally unique name registration source is not recommended due to the awkwardness of a double constructed name.
州の名前登録局はこのとき、稼働中ではありません。 全国的にユニークな名前登録ソースとしてのU.S. DOEの使用は二重組み立てられた名前の不器用さのため推薦されません。
4.4. How to Apply for ANSI Organization Names
4.4. ANSI組織名に申し込む方法
ANSI is the root U.S. source of OSI recognized nationally unique organization names. ANSI registration costs $2500 and results in both an alphanumeric name and an associated numeric name. These names may be used for a variety of purposes in X.400, X.500, and other OSI services.
ANSIはOSIの米国の源が、全国的にユニークな組織が命名すると認めた根です。 ANSI登録は英数字の名前と関連数値名前の両方で2500ドルと結果かかります。 これらの名前はX.400、X.500、および他のOSIサービスにおけるさまざまな目的に使用されるかもしれません。
ESCC X.500/X.400 Task Force [Page 35] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[35ページ]RFC1330X.500とX.400プラン
For ANSI OSI organization name registration forms and instructions, you should send your request to:
ANSI OSI組織名前登録用紙と指示のために、あなたは要求を以下に送るべきです。
American National Standards Institute, Inc.
Attn: Beth Somerville
OSI Registration Coordinator
11 West 42nd Street
New York, NY 10036
Phone: (212) 642-4976
American National Standards Institut Inc.Attn: ニューヨーク、ベスサマービルのOSI登録コーディネータ11の西42nd Streetニューヨーク 10036は以下に電話をします。 (212) 642-4976
ANSI registration procedures include a 90 day public review period during which name requests can be easily challenged.
ANSI登録手順は容易に名前要求に挑戦できる90日の公開レビューの期間を含んでいます。
There is a mechanism to forward ANSI requests to the GSA, it is discussed in the GSA section below.
GSAへの要求をANSIに転送するために、メカニズムがあって、下のGSA部でそれについて議論します。
4.5. How to Apply for GSA Organization Names
4.5. GSA組織名に申し込む方法
GSA is the registration authority for government use of GOSIP, their registration services are free for federal government organizations. Names assigned by GSA always begin with the characters "GOV+" and are limited to 16 characters. By agreement with ANSI, these GSA assigned names are national unique.
GSAがGOSIPの政府使用のための登録局である、連邦政府組織において、彼らの登録サービスは無料です。 GSAによって割り当てられた名前は、いつもキャラクタ「GOV+」で始まって、16のキャラクタに制限されます。 ANSIに、名前が割り当てられたこれらのGSAは国立申し合わせて、ユニークです。
For GSA OSI Organization Name registration forms and instructions, you should send your request to:
GSA OSI Organization Name登録用紙と指示のために、あなたは要求を以下に送るべきです。
General Services Administration
Office of Telecommunications Services
Registration Services, Room 1221-L KBA
18th and F Streets, N.W.
Washington, D.C. 20405
余地の共通役務庁の電気通信事務所サービス登録サービスと1221-L KBA18番目とF通り、北西ワシントンDC20405
4.5.1. GSA Designated Agency Representatives
4.5.1. 政府機関代表に指定されたGSA
When preparing the GSA registration form a designated agency representative must sign where it says "Registration Official Name and Signature". GSA will refuse requests missing this signature.
GSA登録用紙を準備するとき、指定された政府機関代表はそれが「登録正式名称と署名」を示すところで署名しなければなりません。 GSAはこの署名を逃す要求を拒否するでしょう。
The GSA designated Agency Representative for the Department of Energy is:
エネルギー省のAgency代表に指定されたGSAは以下の通りです。
ESCC X.500/X.400 Task Force [Page 36] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[36ページ]RFC1330X.500とX.400プラン
Steve Hackman
Electronics Engineer
U.S. Department of Energy
AD-241.3/GTN
Washington, D.C. 20585
Office Phone: (301) 903-6111
Office FAX: (301) 903-4125
E-Mail: hackman@gosip.xosi.doe.gov
スティーブ貸し馬車屋電子工学の技術者米国エネルギー省西暦-241.3/GTNワシントンDC20585会社の電話: (301) 903-6111 オフィスファックス: (301) 903-4125 メールしてください: hackman@gosip.xosi.doe.gov
4.5.2. Forwarding of ANSI Registrations to GSA
4.5.2. GSAへのANSI登録証明書の推進
ANSI registration requests can be forwarded automatically to the GSA. This is the equivalent of registering with both ANSI and GSA. The result is two nationally unique OSI name registrations, "name" from ANSI and "GOV+name" from GSA.
自動的にANSI登録要求をGSAに転送できます。 これはANSIとGSAの両方とともに記名する同等物です。 結果は2つの全国的にユニークなOSI名前登録証明書、GSAからのANSIと「GOV+名前」からの「名前」です。
There is no GOSIP requirement for GSA registration but many feel the additional GSA registration may be useful.
GSA登録のためのGOSIP要件が全くありませんが、多くが、追加GSA登録が役に立つかもしれないと感じます。
Assuming your organization is a federal government organization, answer the last three questions on the ANSI registration form as shown below:
あなたの組織が連邦政府組織であると仮定して、以下に示すようにANSI登録用紙の最後の3つの問題に答えてください:
1. Do you wish the information supplied in the request to remain
confidential? NO.
1. あなたは秘密のままで残っているという要求で提供された情報を願っていますか? いいえ
2. Do you wish to have your organization name registered with the
U.S. GOSIP Registration Authority (a.k.a. GSA)? YES.
2. あなたは米国GOSIP Registration Authority(通称GSA)に組織名を登録して頂きたいですか? はい。
3. Is your organization an organization of the Federal Government?
YES.
3. あなたの組織は連邦政府の組織ですか? はい。
You must indicate on the application form the approval of the GSA designated agency representative (Steve Hackman). He does not sign as "Signature of Requestor", but some notation of his approval must be attached or GSA will reject the forwarded application.
あなたは申込み書の上に政府機関代表(スティーブ・ハックマン)に指定されたGSAの承認を示さなければなりません。 彼の賛成の何らかの記法を付けなければならない、彼は「要請者の署名」として署名しませんが、さもなければ、GSAは転送された申し込みを拒絶するでしょう。
4.6. How to Apply for U.S. DOE Organization Names
4.6. 米国DOE組織名に申し込む方法
ESnet sites are encouraged to review the DOE GOSIP procedures and guidelines in planning their GOSIP activities. This document does not conflict with current DOE GOSIP policies.
ESnetサイトが彼らのGOSIP活動を計画する際にDOE GOSIP手順とガイドラインを再検討するよう奨励されます。 このドキュメントは現在のDOE GOSIP方針と衝突しません。
DOE can assign nationally unique names which are prefixed by the string "GOV+USDOE+". Use of this name source is not recommended; there is no apparent advantage in using U.S. DOE over GSA as a source of nationally unique names.
DOEはストリング「GOV+USDOE+」によって前に置かれている全国的にユニークな名前を割り当てることができます。 この名前ソースの使用は推薦されません。 全国的にユニークな名前の源としてGSAの上でU.S. DOEを使用するのにおいてどんな見かけの利点もありません。
ESCC X.500/X.400 Task Force [Page 37] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[37ページ]RFC1330X.500とX.400プラン
Copies of current U.S. DOE GOSIP policies, guidelines, and registration forms may be obtained through site DOE naming authorities or Steve Hackman.
サイトDOE命名当局かスティーブ・ハックマンを通して現在のU.S. DOE GOSIP方針、ガイドライン、および登録用紙のコピーを入手するかもしれません。
4.7. Why Apply for a Trademark with the PTO?
4.7. なぜPTOと共に商標に申し込みますか?
Legal issues may arise concerning the rights to use a desired name. OSI name registrations are not intended to "legally protect" name usage rights; that is not their function.
法律問題は必要な名前を使用する権利に関して起こるかもしれません。 OSI名前登録証明書が名前用法権利を「法的に保護すること」を意図しません。 それはそれらの機能ではありません。
Consultation with legal experts concerning the rights to use a name being registered is strongly advised, this recommendation does not offer specific legal guidance. Applying for a trademark may be considered as a means to assert or protect the rights to a name.
登録されていて、名前を使用する権利に関する法律専門家との相談は強く教えられて、この推薦は特定の法的な指導を提供しません。 商標に申し込むのは名前への権利を主張するか、または保護する手段であるとみなされるかもしれません。
Per the PTO trademark application instructions there may be several benefits in obtaining a trademark.
PTO商標出願指示に従って、商標を得るのにおいていくつかの利益があるかもしれません。
o The filing date of the application is a constructive date of
first use of the mark in commerce (this gives registrant
nationwide priority as of the date).
o アプリケーションの出願日は最初に、商業におけるマークの使用の建設的な期日(これは日付現在、記入者の全国的な優先を与える)です。
o The right to sue in Federal court for trademark infringement.
o 商標権侵害で連邦政府の法廷で訴える権利。
o Constructive notice of claim of ownership.
o 所有権のクレームに関する推定告知。
o Limited grounds for attacking a registration once it is five
years old.
o 株式会社は、登録をいったん5になると攻撃するために歳を地面に置きます。
4.8. How to Apply for a Trademark with the PTO
4.8. PTOと共に商標に申し込む方法
You should obtain a trademark application and detailed instructions from the U.S. Department of Commerce, Patent and Trademark Office. This can be done by mailing your request to the address below, or calling the PTO at the phone number below:
あなたは米国商務省、特許・商標局から商標出願と細かい指示を得るべきです。 以下で電話番号でアドレスへのあなたの要求を下に郵送するか、またはPTOを呼ぶことによって、これができます:
U.S. Department of Commerce
Patent and Trademark Office
Washington, D.C. 20231
Phone: (703) 557-INFO
米国商務省特許・商標局ワシントンDC20231は以下に電話をします。 (703) 557インフォメーション
NOTE: The following information is based on ESnet experience in
filing for a trademark based on prior use.
以下に注意してください。 以下の情報は先の使用に基づく商標を申し込むESnet経験に基づいています。
After you receive your application, you will need to perform the following steps.
あなたのアプリケーションを受け取った後に、あなたは、以下のステップを実行する必要があるでしょう。
1. Complete the written application form. If you have more than
1. 書かれた願書を作成してください。 あなたには、以上があります。
ESCC X.500/X.400 Task Force [Page 38] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[38ページ]RFC1330X.500とX.400プラン
one name you are filing, you must complete a separate form for
each name.
ファイルしているある名前であり、あなたは各名前のための別々の用紙に記入しなければなりません。
2. Provide a black-and-white drawing of the mark. In the case
where there is no artwork, only text, the text must be
centered on the page in uppercase.
2. マークの墨絵を提供してください。 アートワークが全くない場合では、ページの大文字でテキストだけ、テキストを中心に置かなければなりません。
3. Provide a check in the amount of $175 (for each application)
made payable to the Commissioner of Patents and Trademarks.
3. 特許庁長官とTrademarksに支払い満期にされた175ドル(各アプリケーションのための)の量にチェックを提供してください。
4. Provide three specimens showing actual use of the mark on or
in connection with the goods or services.
4. サービスか商品かサービスに関してマークの実際の使用を示している3個の標本を提供してください。
The class of goods/services associated with this trademark must be specified on the registration form. The currently defined classes of services are:
登録用紙の上でこの商標に関連している商品の種類/サービスを指定しなければなりません。 現在定義されたクラスのサービスは以下の通りです。
35 Advertising and business.
36 Insurance and financial.
37 Construction and repair.
38 Communication.
39 Transportation and storage.
40 Material treatment.
41 Education and entertainment.
42 Miscellaneous.
35の広告とビジネス。 36 保険的で財政的です。 37 工事と修理。 38 コミュニケーション。 39 輸送とストレージ。 40 物質的な処理。 41 教育とエンターテインメント。 42 その他。
So, for example, there could be two (or more) "ESnet" trademarks, with each trademark associated with a different service class. Thus, trademarks are not nationally unique.
そのように、例えば、異なったサービスのクラスに関連しているそれぞれの商標がある2つ(さらに)の"ESnet"商標があるかもしれません。 したがって、商標は全国的にユニークではありません。
Before submitting your form, you should see if your trademark is already registered to someone else (for the service class you specified). This is typically done by your legal department through the PTO Trademark Search Library.
あなたのフォームを提出する前に、あなたは、あなたの商標が既に他の誰かに登録されるかどうか(サービスのクラスとして、あなたは指定しました)わかるべきです。 これがPTO Trademark検索図書館を通ってあなたの法務部によって通常行われます。
Since the PTO form is a legal document, you must involve your legal department and the documents may only be signed by someone who is a legally recognized representative of your organization. For example, in applying for the service mark "ESnet", the "Applicant Name" was "The Regents of the University of California", and the legally recognized representative was Dr. John Nuckolls, the director of the Lawrence Livermore National Laboratory.
PTOフォームが法律関係書類であるので、あなたは法務部にかかわらなければなりません、そして、書類はあなたの組織の法的に認識された代表であるだれかによって署名されるだけであるかもしれません。 例えば、サービスマーク"ESnet"に申し込むことにおいて、「応募者名」は「カリフォルニア大学理事会」でした、そして、法的に認識された代表はドクター・ジョンNuckollsでした、ローレンス・リバモア国立研究所の指導官。
4.9. Future Name Registration Issues to be Considered
4.9. Consideredである将来のName Registration Issues
4.9.1. ANSI Registered ADMD and PRMD Names
4.9.1. ANSIはADMDとPRMD名を登録しました。
There are discussions in the ANSI and CCITT communities revolving
ANSIとCCITT共同体での回転する議論があります。
ESCC X.500/X.400 Task Force [Page 39] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[39ページ]RFC1330X.500とX.400プラン
around the idea of having a formal registration of all ADMD and PRMD Names (not just ANSI Organization Names). The ideas being exchanged include having a separate ANSI national registry for these names, and having to pay a periodic "license" fee. This is just in the idea discussion phase now, but it may impact the cost of ANSI ADMD and PRMD Name registration in the near future.
すべてのADMDとPRMD Names(ANSI Organization Namesであるだけではない)の正式な登録を持っているという考えの周りで。 交換される考えは、これらの名前のための別々のANSI国家の登録を持って、周期的な「ライセンス」料金を支払わなければならないのを含んでいます。 現在、これがまさしく考え議論フェーズにありますが、それは近い将来、ANSI ADMDの費用とPRMD Name登録に影響を与えるかもしれません。
Glossary
用語集
AA - See ADMINISTRATIVE AUTHORITY.
AA--職務権限を見てください。
ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN.
ADDMD--管理ディレクトリ管理領域を見てください。
ADMD - See ADMINISTRATION MANAGEMENT DOMAIN.
ADMD--管理管理ドメインを見てください。
ADMINISTRATION - An Administration denotes a public telecommunications
administration or other organization offering public
telecommunications services.
政権--政権は公共の遠距離通信サービスを提供する公立のテレコミュニケーション機関か他の組織を指示します。
ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain
(ADMD) is a management domain managed by an Administration;
generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint,
etc.).
ADMINISTRATION MANAGEMENT DOMAIN--Administrative Management Domain(ADMD)は政権によって管理された管理ドメインです。 一般に運輸業者(例えば、AT&T、MCI、米国スプリントなど)のひとり。
ADMINISTRATIVE AUTHORITY - An entity which has administrative control
over all entries stored within a single Directory System Agent
(DSA).
ADMINISTRATIVE AUTHORITY--すべてのエントリーにわたる運営管理コントロールを持っている実体は独身のディレクトリSystemエージェントの中に(DSA)を保存しました。
ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory
Management Domain (ADDMD) is a Directory Management Domain (DMD)
which is managed by an administration.
ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN--AdministrativeディレクトリManagement Domain(ADDMD)は管理によって管理されるディレクトリManagement Domain(DMD)です。
AE - See APPLICATION ENTITY.
AE--アプリケーション実体を見てください。
ALIAS - An entry of the class "alias" containing information used to
provide an alternative name for an object.
アリア--情報を含むクラス「別名」のエントリーは以前はよく代替名をオブジェクトに供給していました。
ANSI - The American National Standards Institute. ANSI is the official
representative of the United States to ISO.
ANSI--American National Standards Institut。 ANSIはISOへの合衆国の公式代表者です。
AP - See APPLICATION PROCESS.
AP--アプリケーション・プロセスを見てください。
APPLICATION ENTITY - An application entity is the OSI portion of an
Application Process (AP).
APPLICATION ENTITY--アプリケーション実体はApplication Process(AP)のOSI部分です。
APPLICATION LAYER - The application layer is the portion of an OSI
system ultimately responsible for managing communication between
application processes (APs).
APPLICATION LAYER--応用層は結局アプリケーション・プロセス(APs)のコミュニケーションを管理するのに原因となるOSIシステムの一部です。
ESCC X.500/X.400 Task Force [Page 40] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[40ページ]RFC1330X.500とX.400プラン
APPLICATION PROCESS - An application process is an object executing in a
real system (computer).
APPLICATION PROCESS--アプリケーション・プロセスは実システム(コンピュータ)で実行されるオブジェクトです。
APPLICATION SERVICE ELEMENT - An application service element (ASE) is
the building block of an application entity (AE). Each AE consists
of one or more service elements, as defined by its application
context.
APPLICATION SERVICE ELEMENT--応用サービス要素(ASE)はアプリケーション実体(AE)のブロックです。 各AEはアプリケーション文脈によって定義されるように1つ以上のサービス要素から成ります。
ASE - See APPLICATION SERVICE ELEMENT.
ASE--応用サービス要素を見てください。
ATTRIBUTE - An attribute is the information of a particular type
concerning an object and appearing in an entry describing that
object in the Directory Information base (DIB).
ATTRIBUTE--属性はディレクトリ情報ベース(DIB)の中でそのオブジェクトについて説明するオブジェクトに関する特定のタイプとエントリーにおける排臨の情報です。
ATTRIBUTE TYPE - An attribute type is that component of an attribute
which indicates the class of information given by that attribute.
ATTRIBUTE TYPE--属性タイプはその属性によって与えられた情報のクラスを示す属性のそのコンポーネントです。
ATTRIBUTE VALUE - An attribute value is a particular instance of the
class of information indicated by an attribute type.
ATTRIBUTE VALUE--属性値は属性タイプによって示された情報のクラスの特定のインスタンスです。
BASE ATTRIBUTE SET - A minimum set of attributes whose values
unambiguously identify a particular management domain.
BASE ATTRIBUTE SET--値が明白に特定の管理ドメインを特定する最小のセットの属性。
BODY - The body of the IP-message is the information the user wishes to
communicate.
BODY--IP-メッセージのボディーはユーザが伝えたがっている情報です。
CCITT - An international standards making organization specializing in
international communications standards and chartered by the United
Nations. "CCITT" is a french acronym meaning the International
Telephone and Telegraph Consultative Committee.
CCITT--国連によって国際通信規格を専攻して、チャーターされた組織を作る世界規格。 「CCITT」は国際TelephoneとTelegraph Consultative Committeeを意味するフレンチ頭文字語です。
CHAINING - Chaining is a mode of interaction optionally used by a
Directory System Agent (DSA) which cannot perform an operation
itself. The DSA chains by invoking the operation of another DSA
and then relaying the outcome to the original requestor.
CHAINING--推論は操作自体を実行できないディレクトリSystemエージェント(DSA)によって任意に使用された相互作用のモードです。 DSAは、別のDSAの操作を呼び出して、次に、オリジナルの要請者に結果をリレーすることによって、鎖を作ります。
CLNP - The OSI Connectionless Network Protocol. CLNP's use is required
by GOSIP.
CLNP--OSIのコネクションレスなネットワーク・プロトコル。 CLNPの使用はGOSIPによって必要とされます。
CONTENT - The piece of information that the originating User Agent (UA)
wishes delivered to the recipient UA. For inter-personal messaging
(IPM) UAs, the content consists of either an IP message or an IPM-
status-report.
CONTENT--起因しているUserエージェント(UA)が願っているという情報の断片は受取人UAに配送されました。 相互個人的なメッセージング(IPM)UAsに関しては、内容はIPメッセージかIPM現状報告のどちらかから成ります。
COOPERATING USER AGENT - A User Agent (UA) that cooperates with another
recipient's UA in order to facilitate the communication between
originator and recipient.
COOPERATING USER AGENT--創始者と受取人とのコミュニケーションを容易にするために別の受取人のUAと協力するUserエージェント(UA)。
ESCC X.500/X.400 Task Force [Page 41] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[41ページ]RFC1330X.500とX.400プラン
DAP - See DIRECTORY ACCESS PROTOCOL.
ちょと浸してください--ディレクトリアクセス・プロトコルを見てください。
DELIVERY - The interaction by which the Message Transfer Agent (MTA)
transfers to a recipient User Agent (UA) the content of a message
plus the delivery envelope.
DELIVERY--Message Transferエージェント(MTA)が受取人Userエージェント(UA)にメッセージの内容と配送封筒を移す相互作用。
DELIVERY ENVELOPE - The envelope which contains the information related
to the delivery of the message.
DELIVERY ENVELOPE--情報を含む封筒はメッセージの配送に関連しました。
DESCRIPTIVE NAME - A name that denotes one and only one user in the
Message Handling System (MHS).
DESCRIPTIVE NAME--Message Handling System(MHS)の唯一無二の1人のユーザを指示する名前。
DIB - See DIRECTORY INFORMATION BASE.
DIB--ディレクトリ情報ベースを見てください。
DIRECTORY - The Directory is a repository of information about objects
and which provides directory services to its users which allow
access to the information.
ディレクトリ--ディレクトリは情報へのオブジェクトの情報の倉庫とどれがユーザへのアクセスを許すディレクトリサービスを提供するかということです。
DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the
protocol used between a Directory user Agent (DUA) and a Directory
System Agent (DSA).
DIRECTORY ACCESS PROTOCOL--ディレクトリAccessプロトコル(DAP)はディレクトリユーザエージェント(DUA)とディレクトリSystemエージェント(DSA)の間で使用されるプロトコルです。
DIRECTORY ENTRY - A Directory Entry is a part of the Directory
Information Base (DIB) which contains information about an object.
DIRECTORY ENTRY--ディレクトリEntryはオブジェクトの情報を含むディレクトリInformation基地(DIB)の一部です。
DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the
complete set of information to which the Directory provides access
and which includes all pieces of information which can be read or
manipulated using the operations of the Directory.
ディレクトリINFORMATION基地--ディレクトリInformation基地(DIB)はディレクトリの操作を使用することで読むか、または操ることができるすべての情報を含んでいるディレクトリがアクセスを提供する情報の完全なセットです。
DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the
Directory Information Base (DIB), considered as a tree, whose
vertices (other than the root) are the Directory entries.
DIRECTORY INFORMATION TREE--ディレクトリ情報Tree(DIT)は木であるとみなされた頭頂(根を除いた)がディレクトリエントリーであるディレクトリInformation基地(DIB)です。
DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a
collection of one or more Directory System Agents (DSAs) and zero
or more Directory User Agents (DUAs) which is managed by a single
organization.
DIRECTORY MANAGEMENT DOMAIN--ディレクトリManagement Domain(DMD)は1人以上のディレクトリSystemエージェントの収集(DSAs)とゼロであるか、より多くのディレクトリUserエージェントが単純組織によって管理される(DUAs)です。
DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI
application process which is part of the Directory.
DIRECTORY SYSTEM AGENT--ディレクトリSystemエージェント(DSA)はディレクトリの一部であるOSIアプリケーション・プロセスです。
DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the
protocol used between two Directory System Agents (DSAs).
DIRECTORY SYSTEM PROTOCOL--ディレクトリSystemプロトコル(DSP)は2人のディレクトリSystemエージェント(DSAs)の間で使用されるプロトコルです。
DIRECTORY USER - A Directory user is the entity or person that accesses
the Directory.
DIRECTORY USER--ディレクトリユーザは、ディレクトリにアクセスする実体か人です。
ESCC X.500/X.400 Task Force [Page 42] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[42ページ]RFC1330X.500とX.400プラン
DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI
application process which represents the user in accessing the
Directory.
DIRECTORY USER AGENT--ディレクトリUserエージェント(DUA)はディレクトリにアクセスする際にユーザの代理をするOSIアプリケーション・プロセスです。
DISTINGUISHED NAME - The distinguished name of a given object is the
sequence of relative distinguished names (RDNs) of an entry which
represents the object and those of all of its superior entries (in
descending order).
DISTINGUISHED NAME--与えられたオブジェクトの分類名はオブジェクトを表すエントリーの親類分類名(RDNs)と優れたエントリー(降順に)のすべてのものの系列です。
DIT - See DIRECTORY INFORMATION TREE.
デイット--ディレクトリ情報木を見てください。
DMD - See DIRECTORY MANAGEMENT DOMAIN.
DMD--ディレクトリ管理領域を見てください。
DN - See DISTINGUISHED NAME.
DN--分類名を見てください。
DNS - See DOMAIN NAME SERVICE.
DNS--ドメイン名サービスを見てください。
DOMAIN NAME SERVICE - A hierarchical, distributed naming service
currently used in the Internet. DNS names typically take the form
of <machine.site.domain>, where <.domain> may be ".COM", ".EDU",
".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>".
DOMAIN NAME SERVICE--現在インターネットで使用されている階層的で、分配された名前付けサービス。 「DNS名は<machine.site.domain>、<.domain>がどこの".COM"であるかもしれないか、そして、".EDU"、".GOV"、".MIL"、「.NET」、".ORG"または」 . <国名略号>の形を通常取ります。」
DSA - See DIRECTORY SYSTEM AGENT.
DSA--ディレクトリシステムエージェントを見てください。
DSP - See DIRECTORY SYSTEM PROTOCOL.
DSP--ディレクトリシステムが議定書を作るのを見てください。
DUA - See DIRECTORY USER AGENT.
DUA--ディレクトリユーザエージェントを見てください。
ENCODED INFORMATION TYPE - It is the code and format of information that
appears in the body of an IP-message (examples of coded information
types are Telex, TIFO (Group 4 Facsimile), and voice).
ENCODED INFORMATION TYPE--それは、IP-メッセージのボディーに現れる情報のコードと形式(コード化された情報タイプに関する例は、Telexと、TIFO(グループ4Facsimile)と、声である)です。
ENVELOPE - A place in which the information to be used in the
submission, delivery and relaying of a message is contained.
ENVELOPE--メッセージの服従、配送、およびリレーに使用されるべき情報が保管されている場所。
FIPS - Federal Information Processing Standard. FIPS are produced by
NIST and specify a standard for the federal government, most FIPS
reference other formal standards from ANSI, IEEE, ISO or CCITT.
FIPS--連邦情報処理基準。 FIPSはNISTによって生産されて、連邦政府の規格を指定して、ほとんどのFIPS参照がANSI、IEEE、ISOまたはCCITTからの他の正規の標準規格です。
GOSIP - The Government Open System Interconnection (OSI) Profile. GOSIP
is a FIPS which defines the elements of OSI to be required by
government purchasers and how those elements should be implemented.
GOSIP is based on OSI standards and OIW implementor's agreements.
GOSIP--政府開放形システム相互接続(OSI)プロフィール。 GOSIPは政府の購入者が必要であるようにOSIの要素を定義するFIPSとそれらの要素がどう実装されるべきであるかということです。 GOSIPはOSI規格とOIW作成者の協定に基づいています。
HEADING - The heading of an IP-message is the control information that
characterizes an IP-message.
HEADING--IP-メッセージに関する見出しはIP-メッセージを特徴付ける制御情報です。
INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication
INTERPERSONAL MESSAGING--個人間のMessaging(IPM)はコミュニケーションです。
ESCC X.500/X.400 Task Force [Page 43] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[43ページ]RFC1330X.500とX.400プラン
between persons by exchanging messages.
メッセージを交換するのによる人々の間で。
INTERPERSONAL MESSAGING SERVICE - The set of service elements which
enable users to exchange interpersonal messages.
INTERPERSONAL MESSAGING SERVICE--ユーザが個人間のメッセージを交換するのを可能にするサービス要素のセット。
INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System
(IPMS) is the collection of User Agents (UAs) and Message Transfer
Agents (MTAs), which provide the Interpersonal Messaging Service.
INTERPERSONAL MESSAGING SYSTEM--Interpersonal Messaging System(IPMS)はUserエージェント(UAs)とMessage Transferエージェント(MTAs)の収集です。(そのエージェントは、Interpersonalメッセージサービスを提供します)。
IP - A non-OSI network protocol, the Internet Protocol, used extensively
in the Internet. CLNP is the OSI alternative to IP.
IP--非OSIネットワーク・プロトコル、インターネットで手広く使用されるインターネットプロトコル。 CLNPはIPへのOSI代替手段です。
IP-MESSAGE - An IP-message carries information generated by and
transferred between Interpersonal Messaging (IPM) User Agents
(UAs). An IP-message contains a Heading and a Body.
IP-MESSAGE--IP-メッセージは(UAs)が生成されて、Interpersonal Messaging(IPM)ユーザエージェントの間に移された情報を運びます。 IP-メッセージはHeadingとBodyを含んでいます。
IPM - See INTERPERSONAL MESSAGING.
IPM--個人間のメッセージングを見てください。
IPM-STATUS-REPORT - The pieces of information generated by an
Interpersonal Messaging (IPM) User Agent Entity (UAE) and
transferred to another IPM UAE, either to be used by that UAE or to
be conveyed to the user.
IPM-STATUS-REPORT--情報の断片は、別のIPM UAE、そのUAEによって使用されたか、またはユーザまで運ばれるべきどちらかに、Interpersonal Messaging(IPM)ユーザエージェントEntity(UAE)で生成して、移されました。
IPMS - See INTERPERSONAL MESSAGING SYSTEM.
IPMS--個人間のメッセージシステムを見てください。
ISO - An international standards making organization which, among other
things, develops OSI standards.
ISO--OSIを特に開発する組織を規格にする世界規格。
MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities
managed by an Administration or organization that includes at least
one Message Transfer Agent (MTA).
MANAGEMENT DOMAIN--Message Handling System(MHS)実体のセットは少なくとも1人のMessage Transferエージェント(MTA)を含んでいる政権か組織で管理されました。
MD - See MANAGEMENT DOMAIN.
MD--管理ドメインを見てください。
MESSAGE - In the context of Message Handling Systems (MHSs), the unit of
information transferred by the Message Transfer System (MTS). It
consists of an envelope and a content.
MESSAGE--Message Handling Systems(MHSs)の文脈では、Message Transfer System(MTS)によって情報のユニットは移されました。 それは封筒と内容から成ります。
MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which
is comprised of an Administrative Management Domain (ADMD), a
country name, and a set of user attributes.
MESSAGE HANDLING ADDRESS--Administrative Management Domain(ADMD)から成るOriginator/受取人(O/R)アドレス、国の名、および1セットのユーザ属性。
MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message
Transfer System (MTS).
MESSAGE HANDLING SYSTEM--Userエージェントのセット(UAs)とMessage Transfer System(MTS)。
MESSAGE TRANSFER AGENT - The functional component that, together with
the other Message Transfer Agents (MTAs), constitutes the Message
Transfer System (MTS). The MTAs provide message transfer service
MESSAGE TRANSFER AGENT--他のMessage Transferエージェント(MTAs)と共にMessage Transfer System(MTS)を構成する機能部品。 MTAsはメッセージ転送サービスを提供します。
ESCC X.500/X.400 Task Force [Page 44] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[44ページ]RFC1330X.500とX.400プラン
elements by: (1) interacting with originating User Agents (UAs)
via the submission dialogue, (2) relaying messages to other MTAs
based upon recipient designations, and (3) interacting with
recipient UAs via the delivery dialogue.
以下による要素 (1) (2) 服従対話で起因するUserエージェント(UAs)と対話して、他のMTAsにメッセージをリレーすると、受取人UAsとの相互作用は配送対話で受取人名称、および(3)に基づきました。
MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE)
is an entity, located in an MTA, that is responsible for
controlling the Message Transfer Layer (MTL). It controls the
operation of the protocol to other peer entities in the MTL.
MESSAGE TRANSFER AGENT ENTITY--Message TransferエージェントEntity(MTAE)はMTAに位置するMessage Transfer Layer(MTL)を制御するのに原因となる実体です。 それはMTLで他の同輩実体にプロトコルの操作を制御します。
MESSAGE TRANSFER LAYER - The Message Transfer Layer (MTL) is a layer in
the Application layer that provides Message Transfer System (MTS)
service elements. These services are provided by means of the
services of the layer below plus the functionality of the entities
in the layer, namely the Message Transfer Agent Entities (MTAEs)
and the Submission and Delivery Entities (SDEs).
MESSAGE TRANSFER LAYER--Message Transfer Layer(MTL)はMessage Transfer System(MTS)にサービス要素を供給するApplication層の層です。 以下での層のサービス、すなわち、層、Message TransferエージェントEntitiesの実体の機能性(MTAEs)、Submission、およびDelivery Entities(SDEs)によってこれらのサービスを提供します。
MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the
protocol which defines the relaying of messages between Message
Transfer Agents (MTAs) and other interactions necessary to provide
Message Transfer layer (MTL) services.
MESSAGE TRANSFER PROTOCOL--Message Transferプロトコル(P1)はMessage Transferエージェントの間のメッセージ(MTAs)と層(MTL)のサービスをMessage Transferに供給するのに必要な他の相互作用のリレーを定義するプロトコルです。
MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of
optional service elements provided by the Message Transfer System
(MTS).
MESSAGE TRANSFER SERVICE--Message Transfer ServiceはMessage Transfer System(MTS)によって提供された任意のサービス要素のセットです。
MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the
collection of Message Transfer Agents (MTAs), which provide the
Message Transfer Service elements.
MESSAGE TRANSFER SYSTEM--Message Transfer System(MTS)はMessage Transferエージェント(MTAs)の収集です。(そのエージェントは、Message Transfer Service要素を提供します)。
MHS - See MESSAGE HANDLING SYSTEM.
MHS--メッセージハンドリングシステムを見てください。
MTA - See MESSAGE TRANSFER AGENT.
MTA--メッセージ転送エージェントを見てください。
MTAE - See MESSAGE TRANSFER AGENT ENTITY.
MTAE--メッセージ転送エージェント実体を見てください。
MTL - See MESSAGE TRANSFER LAYER.
MTL--メッセージ転送が層にされるのを見てください。
MTS - See MESSAGE TRANSFER SYSTEM.
MTS--メッセージ転送システムを見てください。
MULTICASTING - Multicasting is a mode of interaction which may
optionally be used by a Directory System Agent (DSA) which cannot
perform an operation itself. The DSA multicasts the operation
(i.e. it invokes the operation of several other DSAs (in series or
in parallel) and passes an appropriate outcome to the original
requestor).
MULTICASTING--マルチキャスティングは操作自体を実行できないディレクトリSystemエージェント(DSA)によって任意に使用されるかもしれない相互作用のモードです。 DSAマルチキャスト、操作(すなわち、それは、他の数個のDSAs(連続的にか平行である)の操作を呼び出して、適切な結果をオリジナルの要請者に渡します)。
NAME - A name is a construct that singles out a particular object from
NAME--名前は事項からのシングルスが反対する構造物です。
ESCC X.500/X.400 Task Force [Page 45] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[45ページ]RFC1330X.500とX.400プラン
all other objects. A name must be unambiguous (i.e. denote just
one object); however, it need not be unique (i.e. be the only name
which unambiguously denotes the object).
他のすべてのオブジェクト。 名前は明白であるに違いありません(すなわち、ちょうど1個のオブジェクトを指示してください)。 しかしながら、それはユニークである必要はありません(すなわち、明白にオブジェクトを指示する唯一の名前になってください)。
NIST - The national institute of standards, a government organization
which develops, endorses, and promulgates standards for use by the
U.S. government.
NIST--規格の国家の研究所(発展する政府機関)は、米国政府による使用の規格を是認して、公表します。
O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS.
O/Rアドレス--創始者/受取人アドレスを見てください。
O/R NAME - See ORIGINATOR/RECIPIENT NAME.
O/R名--創始者/受取人名を見てください。
OBJECT (OF INTEREST) - Anything in some "world", generally the world of
telecommunications and information processing or some part thereof,
which is identifiable (i.e. can be named), and which it is of
interest to hold information on in the Directory Information Base
(DIB).
OBJECT(OF INTEREST)--それのいくつかの「世界」か一般にテレコミュニケーションの世界と情報処理か何らかの部分(DIB)の何でも。そこでは、身元保証可能であり(すなわち、命名できます)、それはディレクトリInformation基地の中で保持情報におもしろいです。
OIW - The OSI Implementors workshop. OIW is one of three regional
workshops (OIW, EWOS, AOW), which specifies implementation
agreements for base OSI standards. OIW's participants are mostly
from the Americas and the OIW is jointly sponsored by the IEEE
(Institute of Electrical and Electronic Engineers) and NIST.
OIW--OSI Implementorsワークショップ。 OIWは3つの地域ワークショップ(OIW、EWOS、AOW)のひとりです。(そのひとりはベースOSI規格のための実装協定を指定します)。 OIWの関係者はほとんどアメリカ大陸からいます、そして、OIWはIEEE(電気電子学会)とNISTによって共同で後援されます。
OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of
interconnecting different systems.
オープン・システム・インターコネクション--異系統とインタコネクトする能力について言及する用語。
ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that
submits to the Message Transfer System (MTS) a message to be
transferred.
ORIGINATING USER AGENT--Originating Userエージェント(UA)はMessage Transfer System(MTS)に移されるべきメッセージを提出するUAです。
ORIGINATOR - A user, a human being or computer process, from whom the
Message Handling System (MHS) accepts a message.
ORIGINATOR--ユーザ、人間またはコンピュータ(Message Handling System(MHS)はメッセージを受け入れる)が処理されます。
ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA)
that contains certain characteristics which help the Message
Transfer System (MTS) to locate the UA's point of attachment. An
Originator/Recipient (O/R) address is a type of O/R name.
ORIGINATOR/RECIPIENT ADDRESS--Message Transfer System(MTS)がUAの接着点の場所を見つけるのを助けるある特性を含むUserエージェント(UA)にとって、描写的である名前。 Originator/受取人(O/R)アドレスは一種のO/R名です。
ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is
the descriptive name for a User Agent (UA).
ORIGINATOR/RECIPIENT NAME--Originator/受取人Name(O/R Name)はUserエージェント(UA)にとって、描写的である名前です。
OSI - See OPEN SYSTEMS INTERCONNECTION.
OSI--開放型システム間相互接続を見てください。
PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN.
PRDMD--個人的なディレクトリ管理領域を見てください。
PRIMITIVE NAME - A name assigned by a naming authority. Primitive names
are components of descriptive names.
PRIMITIVE NAME--命名権威によって割り当てられた名前。 原始の名前は描写的である名前の成分です。
ESCC X.500/X.400 Task Force [Page 46] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[46ページ]RFC1330X.500とX.400プラン
PRIVATE DIRECTORY MANAGEMENT DOMAIN - A Private Directory Management
Domain (PRDMD) is a Directory Management Domain which is managed by
an organization other than an administration.
PRIVATE DIRECTORY MANAGEMENT DOMAIN--兵士のディレクトリManagement Domain(PRDMD)は管理以外の組織によって管理されるディレクトリManagement Domainです。
PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a
management domain managed by a company or non-commercial
organization.
PRIVATE MANAGEMENT DOMAIN--兵士のManagement Domain(PRMD)は会社によって経営された管理ドメインか非営利的な組織です。
PRMD - See PRIVATE MANAGEMENT DOMAIN.
PRMD--自営業ドメインを見てください。
RDN - See RELATIVE DISTINGUISHED NAME.
RDN--相対的な分類名を見てください。
RECIPIENT - A user, a human being or computer process, who receives a
message from the Message Handling System (MHS).
RECIPIENT--ユーザ、人間またはコンピュータ(Message Handling System(MHS)からメッセージを受け取る)が処理されます。
RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered
or that is specified for delivery.
RECIPIENT USER AGENT--メッセージが提供されるUserエージェント(UA)かそれが配送に指定されます。
REFERRAL - A referral is an outcome which can be returned by a Directory
System Agent (DSA) which cannot perform an operation itself, and
which identifies one or more other DSAs more able to perform the
operation.
REFERRAL--紹介は操作自体を実行できないディレクトリSystemエージェント(DSA)が返すことができて、操作をより実行できる他の1DSAsを特定する結果です。
RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a
set of attribute value assertions, each of which is true,
concerning the distinguished values of a particular entry.
RELATIVE DISTINGUISHED NAME--Relative Distinguished Name(RDN)は1セットの属性値主張です、特定のエントリーの顕著な値に関して。それはそれぞれ本当です。
RELAYING - The interaction by which one Message Transfer Agent (MTA)
transfers to another MTA the content of a message plus the relaying
envelope.
RELAYING--Message Transferエージェント(MTA)がメッセージの内容とリレー封筒を別のMTAに移す相互作用。
RELAYING ENVELOPE - The envelope which contains the information related
to the operation of the Message Transfer System (MTS) plus the
service elements requested by the originating User Agent (UA).
RELAYING ENVELOPE--情報を含む封筒はMessage Transfer Systemの操作(MTS)と起因しているUserエージェントによって要求されたサービス要素(UA)に関連しました。
RFC - Request for Comments. The RFC's are documents used to propose or
specify internet community standards.
RFC--コメントのために、要求します。 RFCのものはインターネット生活環境水準を提案するか、または指定するのに使用されるドキュメントです。
ROOT - The vertex that is not the final vertex of any arc is referred to
as the root vertex (or informally as the root) of the tree.
ROOT、--、どんなアークの最終的な頂点でない頂点も根の頂点と呼ばれる(非公式である、根) 木について。
SCHEMA - The Directory Schema is the set of rules and constraints
concerning the Directory Information Tree (DIT) structure, object
class definitions, attribute types, and syntaxes which characterize
the Directory Information base (DIB).
SCHEMA--ディレクトリSchemaは規則のセットとディレクトリ情報ベースを特徴付けるディレクトリ情報Tree(DIT)構造、オブジェクトクラス定義、属性タイプ、および構文(DIB)に関する規制です。
SDE - See SUBMISSION AND DELIVERY ENTITY.
SDE--服従と配送実体を見てください。
ESCC X.500/X.400 Task Force [Page 47] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[47ページ]RFC1330X.500とX.400プラン
SMTP - Simple Mail Transfer Protocol. An e-mail protocol frequently
used by the Internet community.
SMTP--簡単なメール転送プロトコル。 頻繁にインターネットコミュニティによって使用されるメールプロトコル。
SUBMISSION - The interaction by which an originating User Agent (UA)
transfers to a Message Transfer Agent (MTA) the contents of a
message plus the submission envelope.
SUBMISSION--起因しているUserエージェント(UA)がMessage Transferエージェント(MTA)にメッセージと服従封筒のコンテンツを移す相互作用。
SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity
(SDE) is an entity located in the Message Transfer Layer (MTL),
co-resident with a User Agent (UA) and not with a Message Transfer
Agent (MTA), and responsible for controlling the submission and
delivery interactions with a Message Transfer Agent Entity (MTAE).
SUBMISSION AND DELIVERY ENTITY--Submissionであり、Delivery Entity(SDE)はMessage Transfer Layerに位置する実体(MTL)と、エージェント(MTA)の、そして、服従を制御するのに責任があるMessage Transferではなく、Userエージェント(UA)と一緒にいるコレジデントとMessage TransferエージェントEntityとの配送相互作用(MTAE)です。
SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol
(P3) is the protocol which governs communication between a
Submission and Delivery Entity (SDE) and a Message Transfer Agent
Entity (MTAE).
SUBMISSION AND DELIVERY PROTOCOL--SubmissionとDeliveryプロトコル(P3)はSubmissionと、Delivery Entity(SDE)とMessage TransferエージェントEntity(MTAE)とのコミュニケーションを支配するプロトコルです。
SUBMISSION ENVELOPE - The envelope which contains the information the
Message Transfer System (MTS) requires to provide the requested
service elements.
SUBMISSION ENVELOPE--Message Transfer System(MTS)が要求されたサービス要素を提供するのを必要とする情報を含む封筒。
TCP - A non-OSI transport protocol, the Transmission Control Protocol,
used extensively in the Internet. TP4 is the OSI alternative to
TCP.
TCP--非OSIトランスポート・プロトコル、インターネットで手広く使用される通信制御プロトコル。 TP4はTCPへのOSI代替手段です。
TP0 - An OSI transport protocol specified by GOSIP and generally used
with connection-oriented networks.
TP0--GOSIPによって指定されて、一般に、接続指向のネットワークと共に使用されるOSIトランスポート・プロトコル。
TP4 - An OSI transport protocol specified by GOSIP and generally used
with connectionless networks such as CLNP.
TP4--OSIトランスポート・プロトコルは、GOSIPで指定して、一般に、コネクションレスなネットワークと共にCLNPとしてそのようなものを使用しました。
TREE - A tree is a set of points (vertices), and a set of directed lines
(arcs); each arc leads from a vertex V to a vertex V'. The
vertices V and V' are said to be the initial and final vertices of
an arc a from V to V'. In a tree, several different arcs may have
the same initial vertex, but not the same final vertex.
TREE--木は、1セットの先(頭頂)と、1セットの有向直線(アーク)です。 '各アークは頂点Vから頂点Vまで導きます'。 '頭頂VとV'はアークのVからV初期的、そして、最終的な頭頂であると言われています'。 木では、いくつかの異なったアークが同じ最終的な頂点ではなく、同じ初期の頂点を持っているかもしれません。
UA - See USER AGENT.
UA--ユーザエージェントを見てください。
UAE - See USER AGENT ENTITY.
UAE--ユーザエージェント実体を見てください。
UAL - See USER AGENT LAYER.
UAL--ユーザエージェント層を見てください。
USER - A person or computer application or process who makes use of a
Message Handling System (MHS).
USER--Message Handling System(MHS)を利用する人、コンピュータアプリケーションまたはプロセス。
USER AGENT - Typically, the User Agent (UA) is a set of computer
USER AGENT--Userエージェント(UA)は通常、コンピュータのセットです。
ESCC X.500/X.400 Task Force [Page 48] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[48ページ]RFC1330X.500とX.400プラン
processes (for example, an editor, a file system, a word processor)
that are used to create, inspect, and manage the storage of
messages. There is typically one user per User Agent (UA). During
message preparation, the originator communicates with his UA via an
input/output (I/O) device (for example, a keyboard, display,
printer, facsimile machine, and/or telephone). Also by means of
these devices, the UA communicates to its user messages received
from the Message Transfer System (MTS). To send and receive
messages, the UA interacts with the MTS via the submission and
delivery protocol.
メッセージのストレージを作成して、点検して、管理するのに使用されるプロセス(例えば、エディタ、ファイルシステム、ワードプロセッサ)。 Userエージェント(UA)あたり1人のユーザが通常います。 メッセージ準備の間、創始者は入力/出力(入出力)デバイス(例えば、キーボード、ディスプレイ、プリンタ、ファクシミリ装置、そして/または、電話)を通して彼のUAとコミュニケートします。 これらのデバイスによっても、UAはMessage Transfer System(MTS)から受け取られたユーザメッセージに交信します。 メッセージを送って、受け取るために、UAは服従と配送プロトコルでMTSと対話します。
USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User
Agent Layer (UAL) of the Application Layer that controls the
protocol associated with cooperating UAL services. It exchanges
control information with the Message Transfer Agent Entity (MTAE)
or the Submission and Delivery Entity (SDE) in the layer below.
The control information is the information the Message Transfer
layer (MTL) requires to create the appropriate envelope and thus
provide the desired message transfer service elements.
USER AGENT ENTITY--UserエージェントEntity(UAE)はUALが修理する協力に関連しているプロトコルを制御するApplication LayerのUserエージェントLayer(UAL)の実体です。 それは以下の層のMessage TransferエージェントEntity(MTAE)かSubmissionとDelivery Entity(SDE)と制御情報を交換します。 制御情報はMessage Transfer(MTL)層が適切な封筒を作成して、その結果、必要なメッセージ転送サービス要素を提供するのを必要とする情報です。
USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains
the User Agent Entities (UAEs).
USER AGENT LAYER--UserエージェントLayer(UAL)はUserエージェントEntities(UAEs)を含む層です。
X.25 - A packet switched network standard often used by public providers
and optional in GOSIP.
X.25--しばしばGOSIPでプロバイダーの、そして、任意の公衆によって使用されたパケット交換網規格。
Appendix A: Current Activities in X.500
付録A: X.500の現在の活動
NOTE: The following are edited excerpts from the IETF Directory Services Monthly reports as well as a few IETF scope documents. Effort has been taken to make sure this information is current as of late 1991. At the end of each section are lists of anonymous FTP and/or an e-mail address if more information is desired.
以下に注意してください。 ↓これはいくつかのIETF範囲ドキュメントと同様にIETFディレクトリサービスMonthlyレポートからの編集された抜粋です。 この情報が確実に1991年後半現在現在になるようにするために取り組みを取りました。 それぞれの終わりでは、詳しい情報が望まれているなら、セクションは、公開FTPのリスト、そして/または、Eメールアドレスです。
IETF DISI
(Directory Information Services Infrastructure Working Group)
IETF DISI(ディレクトリ情報サービスインフラストラクチャ作業部会)
The Directory Information Services (pilot) Infrastructure Working Group is chartered to facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards. It will facilitate this deployment by producing informational RFCs intended to serve as a Directory Services "Administrator's Guide". These RFCs will relate the current usage and scope of the X.500 standard and Directory Services in North America and the world, and will contain information on the procurement, installation, and operation of various implementations of the X.500 standard. As the various implementations of the X.500 standard work equally well over TCP/IP and CLNP, the DISI working group shall not mandate specific
ディレクトリ情報Services(パイロット)インフラストラクチャ作業部会は、X.500規格の実現に基づくディレクトリサービスのインターネットで展開を容易にするためにチャーターされます。 それは、ディレクトリサービス「管理者用ガイド」として機能することを意図する情報のRFCsを生産することによって、この展開を容易にするでしょう。 これらのRFCsは北アメリカと世界でX.500規格とディレクトリサービスの現在の用法と範囲を関係づけて、X.500規格の様々な実現の調達、インストール、および操作で情報を保管するでしょう。 X.500規格の様々な実現がTCP/IPとCLNPの上で等しくうまくいくとき、DISIワーキンググループは詳細を強制しないものとします。
ESCC X.500/X.400 Task Force [Page 49] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[49ページ]RFC1330X.500とX.400プラン
implementations or transport protocols.
実現かトランスポート・プロトコル。
DISI is an offshoot of the OSI Directory Services group, and, accordingly, is a combined effort of the OSI Integration Area and User Services Area of the IETF. The current OSIDS working group was chartered to smooth out technical differences in information storage schema and difficulties in the interoperability and coherence of various X.500 implementations. The DISI group is concerned solely with expanding the Directory Services infrastructure. As DISI will be providing information to facilitate the building of infrastructure with an eye towards truly operational status, DISI will need to form liaisons with COSINE, PARADISE, and perhaps the RARE WG3.
DISIはOSIディレクトリサービスグループの分枝であり、それに従って、IETFのOSI Integration AreaとUser Services Areaの協力です。 現在のOSIDSワーキンググループは、情報記憶図式の技術的な違いと様々なX.500実現の相互運用性と首尾一貫性における困難を取り除くためにチャーターされました。 DISIグループは唯一ディレクトリサービスインフラストラクチャを広げるのに関係があります。 DISIが本当に操作上の状態に目を向けてインフラストラクチャのビルを容易にするために情報を提供するとき、DISIは、COSINE、PARADISE、および恐らくRARE WG3との連絡を形成する必要があるでしょう。
As a final document, the DISI working group shall write a charter for a new working group concerned with user services, integration, maintenance and operations of Directory Services, the Operations and Infrastructure of Directory Services (OIDS) Group.
最終合意文書として、DISIワーキンググループは新しいワーキンググループディレクトリサービスのユーザサービス、統合、ディレクトリサービスの維持と操作、Operations、およびInfrastructureに関係がある(OIDS)グループのために特許を書くものとします。
One particular DISI document you may be interested in is a catalogue of the various X.500 implementations:
あなたが興味を持つかもしれない1通の特定のDISIドキュメントが様々なX.500実現に関するカタログです:
Title : Catalog of Available X.500 Implementations
Author(s) : R. Lang, R. Wright
Filename : rfc1292.txt
Pages : 103
タイトル: 手があいているX.500実現作者のカタログ: R。 ラング、R.職人ファイル名: rfc1292.txtページ: 103
This document is available on the ESnet Information Server in the [ANONYMOUS.RFCS] directory.
このドキュメントは[ANONYMOUS.RFCS]ディレクトリのESnet情報Serverで利用可能です。
Mailing list address:
General Discussion: disi@merit.edu
To Subscribe: disi-request@merit.edu
Anonymous FTP site address: (e-mail archive is here)
merit.edu
メーリングリストアドレス: 一般議論: 申し込む disi@merit.edu : disi-request@merit.edu アノニマス・エフテーピーサイトアドレス: (メールアーカイブがここにあります) merit.edu
IETF OSI-DS (OSI Directory Service Working Group)
IETFオウシ-DS(OSIディレクトリサービス作業部会)
The OSI-DS group works on issues relating to building an OSI Directory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered.
OSI-DSグループはインターネットでX.500とその展開を使用することでOSIディレクトリサービスを組み込むのに関係する問題に取り組みます。 このグループは直接操縦に関係がありませんが、焦点は開いているディレクトリの展開への前提条件が考えられるので必要である実用的で、技術的な仕事です。
The major goal of this WG is to provide the technical framework for a Directory Service infrastructure on the Internet. This infrastructure should be based on the OSI Directory (X.500). It is intended that this infrastructure can be used by many applications. Whilst this WG is not directly concerned with operation of services,
このWGの主要な目標はインターネットで技術的な枠組みをディレクトリサービスインフラストラクチャに提供することです。 このインフラストラクチャはOSIディレクトリ(X.500)に基づくべきです。 多くのアプリケーションでこのインフラストラクチャを使用できることを意図します。 このWGは直接サービスの操作に関係がありませんが
ESCC X.500/X.400 Task Force [Page 50] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[50ページ]RFC1330X.500とX.400プラン
close liaison is expected with those groups which do operate pilots and services.
緊密な連携はパイロットとサービスを手術するそれらのグループと共に予想されます。
Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC, North American Directory Forum.
連絡はRARE WG3、NIST、CCITT/ISO IEC、北米のディレクトリForumと共に確立されました。
X.500 (1984) / ISO 9594 does not have sufficient functionality for full deployment on the Internet. This group identifies areas where extensions are required.
X.500(1984)/ISO9594はインターネットに完全な展開のための十分な機能性を持っていません。 このグループは拡大が必要である領域を特定します。
It is a basic aim of the group to be aligned to appropriate base standards and functional standards. Any activity should be undertaken in the light of ongoing standardization activity. Areas which should be examined include:
ベース規格と機能標準を当てるために並べられるのは、グループの基本的な目的です。 どんな活動も進行中の標準化活動の見地から引き受けられるべきです。 調べられるべきである領域は:
o Replication
o 模写
o Knowledge Representation
o 知識表現
o Schema Management
o 図式管理
o Access Control
o アクセス管理
o Authentication
o 認証
o Distributed operations for partially connected DSAs
o 部分的に接続されたDSAsのための分配された操作
o Presentation Address Handling
o プレゼンテーションアドレス取り扱い
Mailing list address:
General Discussion: osi-ds@cs.ucl.ac.uk
To Subscribe: osi-ds-request@cs.ucl.ac.uk
Anonymous FTP site address: (all OSI-DS documents and e-mail archive
cs.ucl.ac.uk are here)
メーリングリストアドレス: 一般議論: 申し込む osi-ds@cs.ucl.ac.uk : osi-ds-request@cs.ucl.ac.uk アノニマス・エフテーピーサイトアドレス: (すべてのOSI-DSドキュメントとメールアーカイブcs.ucl.ac.ukがここにあります)
FOX (Field Operational X.500 Project)
フォックス(分野の操作上のX.500プロジェクト)
The FOX project is a DARPA funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NYSERnet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight.
FOXプロジェクトはDARPAがNREN/インターネットでの操作上のX.500展開の基礎を提供するための努力に資金を供給したということです。 この仕事がMerit、NYSERnet/PSI、SRI、およびISIで行われています。 ISIは元請であってプロジェクト見落としに責任があります。
There are two primary thrusts of the FOX project:
FOXプロジェクトの2つの第一の突き刺しがあります:
1. X.500 Infrastructure: It is important that multiple
interoperable platforms be available for deployment. FOX
plans to examine and test the interoperability of the QUIPU
and NIST-X.500 (Custos) implementations, and DNANS-X.500 if
1. X.500インフラストラクチャ: 複数の共同利用できるプラットホームが展開に利用可能であることは、重要です。 FOXはQUIPUとNIST-X.500(Custos)実現、およびDNANS-X.500の相互運用性を調べて、テストするのを計画しています。
ESCC X.500/X.400 Task Force [Page 51] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[51ページ]RFC1330X.500とX.400プラン
possible. In addition, FOX will explore X.500 interfaces to
conventional database systems (one target is Sybase), an
alternate OS platform (VM) for X.500 servers, and X-window
based user interfaces.
可能。 さらに、FOXは従来のデータベース・システムにX.500インタフェースを探検するでしょう(1個の目標がSybaseです)、X.500サーバのための(VM)交互のOSプラットホーム、そして、X windowはユーザインタフェースを基礎づけました。
2. X.500 Applications: A long-range goal is to facilitate the
use of X.500 for real Internet applications. FOX will first
focus on making network infrastructure information available
through X.500. This includes network and AS site contacts,
topology information, and the NIC WHOIS service.
2. X.500アプリケーション: 長期の目標はX.500の実際のインターネットアプリケーションの使用を容易にすることです。 FOXは、最初に、ネットワークインフラ情報をX.500を通して利用可能にするのは焦点を合わせるでしょう。 これはネットワーク、ASサイト接触、トポロジー情報、およびNIC WHOISサービスを含んでいます。
A centrally managed X.500 version will be the first phase of a WHOIS service. Providing an X.500 version of a well-known widely-used service should promote the use of X.500 by Internet users. In addition, this effort will provide experience in designing X.500 applications. However, the manageability of this scheme will be short-lived, so the next step will be a design for a distributed version of WHOIS.
中心で管理されたX.500バージョンはWHOISサービスの第1段階になるでしょう。 周知に広く使用されたサービスのX.500バージョンを提供すると、インターネットユーザによるX.500の使用は促進されるべきです。 さらに、この努力はX.500アプリケーションを設計する経験を提供するでしょう。 しかしながら、この計画の管理可能性が短命になるので、次のステップはWHOISの分配されたバージョンのためにデザインになるでしょう。
Finally, it is critical for Internet X.500 efforts to be aligned with directory service efforts that are ongoing in other communities. FOX participants are involved in, or are otherwise tracking these efforts, and information about FOX activities will be publicly available.
最終的に、他の共同体で進行中であることの電話番号案内の努力に並べられるためのインターネットX.500の努力には、それは重要です。 FOX関係者は、かかわって、そうでなければ、これらの努力を追跡しています、そして、FOX活動の情報は公的に利用可能になるでしょう。
NADF (North American Directory Forum)
NADF(北米のディレクトリフォーラム)
The North American Directory Forum (NADF) is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations.
北米のディレクトリForum(NADF)は申し出に提供するか、または計画されている組織の収集です、北アメリカでの公共のディレクトリサービス、CCITT X.500 Recommendationsに基づいて。
The NADF has produced a document, NADF-175, "A Naming Scheme for c=US", which has been issued as RFC-1255.
ドキュメント、NADF-175、「c=米国の命名計画」をNADFは生産しました。(それは、RFC-1255として発行されました)。
The NADF-175 document proposes the use of existing civil infrastructure for naming objects under c=US. This has the advantage of using existing registration authorities and not establishing any new ones (the document simply maps names assigned by existing authorities into different portions of the c=US DIT). The document is intended as the basis for X.500 names in the U.S. for the long- term; it is important that interested parties get a copy, review it, and return comments.
NADF-175ドキュメントは既存の民間インフラストラクチャのc=の下の物を米国と命名する使用を提案します。 これには、既存の登録局を使用して、どんな新しいものも確立しない利点(ドキュメント単に名前が既存の当局でcの異なった部分に割り当てた地図=US DIT)があります。 ドキュメントは米国のX.500名の基礎として長い期間に意図します。 利害関係者がコピーを手に入れて、それを見直して、コメントを返すのは、重要です。
A second output, which is still undergoing development, is NADF-128, a preliminary draft on "Mapping the DIT onto Multiple ADDMDs". This describes how the c=US portion of the DIT is mapped onto DSAs and what service-providers must minimally share in order to achieve a working public directory. The next revision of this document will
「複数のADDMDsにデイットを写像します」のときに2番目の出力(まだ開発を受けている)はNADF-128、予備草案です。 これは、DITのc=米国部分がどのようにDSAsに写像されるか、そして、どんなサービスプロバイダーが働く公共のディレクトリを達成するために最少量で共有しなければならないかを説明します。 このドキュメントの次の改正はそうするでしょう。
ESCC X.500/X.400 Task Force [Page 52] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[52ページ]RFC1330X.500とX.400プラン
likely be ASCII-ized and published as an informational RFC.
おそらくASCII化されて情報のRFCとして発行されてください。
NIST (National Institute of Standards and Technology)
NIST(米国商務省標準技術局)
NIST is involved in several X.500 activities: standards, pilot deployment, and development of an X.500 implementation, Custos. The objective is to see X.500 widely deployed and used in the U.S. Government. X.500 is expected to be in the next release of the U.S. Government OSI Profile (GOSIP). In the standards efforts, emphasis is on access control and replication; the other activities are described in some detail below.
NISTはいくつかのX.500活動にかかわります: X.500実現、Custosの規格、パイロット展開、および開発。 目的はX.500が米国政府に広く配備されて、使用されるのを見ることです。 X.500が米国政府OSI Profile(GOSIP)の次のリリースにいると予想されます。 規格の努力、強調はアクセス管理と模写で中です。 他の活動は以下の何らかの詳細に説明されます。
o NIST/GSA X.500 Pilot Deployment: NIST and GSA are
collaborating in the creation of a U.S. Government X.500 pilot
deployment. To date, two meetings have been held. At the
second, held on April 25th at NIST, significant progress was
made towards refining an initial draft schema developed by
NIST. A number of government agency requirements will be
included in the next schema revision. Once the schema is
defined, agencies will begin collecting data for loading into
the directory. Initially, NIST will offer to host agency data
on Custos DSAs running at NIST. Eventually, agencies are
expected to obtain and operate DSAs.
o NIST/GSA X.500は展開を操縦します: NISTとGSAは米国政府X.500パイロット展開の創造で共同しています。 これまで、2回の会合が行われました。 4月25日にNISTで開催された2番目では、重要な進歩は、NISTによって開発された初期の草稿図式を洗練しながら、向かわれました。多くの政府機関要件が次の図式改正に含まれるでしょう。 図式がいったん定義されると、政府機関はディレクトリにロードするための資料収集を始めるでしょう。 初めは、NISTは、NISTを走りながらCustos DSAsで政府機関データをホスティングすると申し出るでしょう。結局、政府機関は、DSAsを入手して、操作すると予想されます。
o CUSTOS: The NIST X.500 public-domain implementation, Custos,
is implemented on ISODE, although it otherwise bears no
relation to QUIPU. One of its more interesting features is that
the DBMS interface is SQL, and we provide a simple DBMS as part
of Custos to support the DSA. Information can be optionally
loaded into memory, and the memory usage is reasonably
efficient on a per-entry basis.
o CUSTOS: そうでなければ、QUIPUは関係ないのですが、NIST X.500公共の場実現(Custos)はISODEで実行されます。 よりおもしろい特徴の1つはDBMSインタフェースがSQLであり、私たちがDSAを支持するためにCustosの一部として簡単なDBMSを提供するということです。 任意に情報をメモリにロードできます、そして、メモリ使用量は1エントリーあたり1個のベースでかなり効率的です。
OIW (OSI Implementor's Workshop)
OIW(OSI作成者のワークショップ)
The OSI Implementor's Workshop (OIW) is an open public forum for technical issues, concerned with the timely development of implementation agreements based on emerging international OSI standards. The Workshop accepts as input the specifications of emerging standards for protocols, and produces as output agreements on the implementation and testing particulars of these protocols. This process is expected to expedite the development of OSI protocols and to promote interoperability of independently manufactured data communications equipment.
OSI ImplementorのWorkshop(OIW)は国際的なOSI規格として現れることに基づいて実現協定のタイムリーな開発に関する専門的な問題のための開いている公共のフォーラムです。 Workshopはプロトコルの規格として現れる仕様を入力するとき受け入れて、これらのプロトコルの実現とテスト子細の出力協定として生産します。 この過程は、OSIプロトコルの開発を速めて、独自に製造されているデータ通信装置の相互運用性を促進すると予想されます。
The Workshop organizes its work through Special Interest Groups (SIGs) that prepare technical documentation. The SIGs are encouraged to coordinate with standards organizations and user groups, and to seek widespread technical consensus on implementation agreements
Workshopは技術的なドキュメンテーションを準備する特別利益団体Groups(SIG)を通した仕事を組織化します。 SIGは、規格組織とユーザ・グループと共に調整して、実現協定に関する広範囲の技術的なコンセンサスを求めるよう奨励されます。
ESCC X.500/X.400 Task Force [Page 53] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[53ページ]RFC1330X.500とX.400プラン
through international discussions and liaison activities.
国際的な議論と連絡活動で。
The Directory SIG of the Workshop produces agreements on the implementation of Directory protocols based on ISO 9594 and CCITT X.500 Recommendations. There are three major areas that the SIG is working on for 1991: access control, replication, and distributed operations.
WorkshopのディレクトリSIGはISO9594とCCITT X.500 Recommendationsに基づくディレクトリプロトコルの実現の協定を作成します。 SIGが1991の間に働いている3つの主要な領域があります: コントロール、模写、および分配された操作にアクセスしてください。
Mailing list address:
General Discussion: dssig@nisc.sri.com
To Subscribe: dssig-request@nisc.sri.com
メーリングリストアドレス: 一般議論: 申し込む dssig@nisc.sri.com : dssig-request@nisc.sri.com
PARADISE Project
天国プロジェクト
The PARADISE project is based at the Department of Computer Science, University College London (UCL).
PARADISEプロジェクトはコンピュータScience、ユニバーシティ・カレッジロンドン(UCL)の部に拠点を置いています。
PARADISE is a sub-project of the broader COSINE project sponsored under the umbrella of EUREKA by eighteen participating countries and aimed at promoting OSI to the academic, industrial and governmental research and development organizations in Europe. The countries involved are those of the EC, EFTA plus Yugoslavia; that is: Austria, Belgium, Denmark, Finland, France, Germany, Greece, Holland, Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom, and Yugoslavia.
PARADISEは、より広いユーレカ計画のかさの下で18の参加国によって後援されて、アカデミックで、産業の、そして、政府の研究開発組織にOSIを促進するのがヨーロッパで目的とされたCOSINEプロジェクトのサブプロジェクトです。 かかわった国はEC、EFTA、およびユーゴスラビアのものです。 それは以下の通りです。 オーストリア、ベルギー、デンマーク、フィンランド、フランス、ドイツ、ギリシア、オランダ、アイルランド、イタリア、ルクセンブルク、ノルウェー、ポルトガル、スペイン、スウェーデン、スイス、イギリス、およびユーゴスラビア。
The partners funded by PARADISE besides UCL are:
UCL以外にPARADISEによって資金を供給されたパートナーは以下の通りです。
o The Networks Group at the University of London Computer Centre
(ULCC), which is a service-oriented organization providing a
range of facilities to the academic community in London and the
entry point into the UK for IXI, the COSINE international X.25
backbone;
o ロンドンとエントリーにおける学界にさまざまな施設を提供するサービス志向の組織であるロンドンコンピュータCentre(ULCC)大学のNetworks GroupはIXIのためのイギリスに指します、COSINEの国際的なX.25背骨。
o X-Tel Services Ltd, a software company based in Nottingham
which currently provides service support to the UK Academic
X.500 pilot; and
o X-Tel Services Ltd、現在イギリスのAcademic X.500パイロットにサービスサポートを提供するノッティンガムに拠点を置くソフトウェア会社。 そして
o PTT Telematic Systems from the Netherlands, which in turn has
subcontracted the Swiss and Finnish PTTs, and whose involvement
is to create a forum for discussion on X.500 among the European
carrier administrations.
o 順番にスイスの、そして、フィンランドのPTTを下請けして、X.500についての議論のためにヨーロッパのキャリヤー運営の中でフォーラムを作成するかかわり合いがことであるオランダからのPTT Telematic Systems。
The project also aims to have representation from all the participating countries, which in the majority of cases are the existing X.500 national pilots.
また、プロジェクトは、すべての参加国からの代理を持っていることを目指します(多くの場合既存のX.500国家のパイロットです)。
Of the 18 countries involved, at least 12 are registered in the White
18関係諸国では、少なくとも12はホワイトに登録されます。
ESCC X.500/X.400 Task Force [Page 54] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[54ページ]RFC1330X.500とX.400プラン
Pages Pilot Project. Most countries are using the QUIPU implementation developed at UCL. However, a French group has developed PIZARRO, which will form the basis of the emerging French pilot. In Italy, a Torino-based company Systems Wizards are using DirWiz, which is currently the sole representative from Italy in the tree.
ページのパイロットは突出します。 ほとんどの国がUCLで開発されたQUIPU実現を使用しています。 しかしながら、フランスのグループはピザロを開発しました。(ピザロは、現れているフランス人のパイロットの基礎を形成するでしょう)。 イタリアでは、トリノベースの会社のSystemsウィザーズがDirWizを使用しています。(現在、DirWizは木のイタリアからの総代理人です)。
Mailing list address:
helpdesk@paradise.ulcc.ac.uk
メーリングリストアドレス: helpdesk@paradise.ulcc.ac.uk
PSI White Pages Pilot Project
ψホワイトページ試験計画
The White Pages Pilot Project is the first production-quality field test of the OSI Directory (X.500). The pilot currently has a few hundred organizations (more each month) and is based on OSI TP4 over TCP/IP (RFC-1006).
ホワイトページPilot ProjectはOSIディレクトリ(X.500)の最初の生産品質実地試験です。 パイロットは、現在、数100の組織(むしろ毎月)を持って、TCP/IP(RFC-1006)の上でOSI TP4に基づいています。
Anonymous FTP site address: (Most X.500 pilot project software is
uu.psi.com here as well as more information)
アノニマス・エフテーピーサイトアドレス: (ほとんどのX.500試験計画ソフトウェアが詳しい情報と同様にここのuu.psi.comです)
ANSI ASC X3T5.4 (Directory Ad Hoc Group)
ANSI ASC X3T5.4(ディレクトリ専門家班)
The American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X3T5.4. This group reviews the Proposed Draft Amendments (PDAMs) for extensions to the International Consultative Committee for Telegraphy and Telephony (CCITT) X.500 Recommendations/International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 9594.
American National Standards Institut(ANSI)は規格委員会(ASC)のX3T5.4を信任しました。 このグループは拡大のために、TelegraphyとTelephony(CCITT)X.500 Recommendations/国際標準化機構(ISO)/国際電気標準化会議(IEC)9594のための国際Consultative CommitteeにProposed Draft米国憲法の修正条項(PDAMs)を見直します。
Appendix B: Current Activities in X.400
付録B: X.400の現在の活動
NOTE: The following are edited excerpts from the IETF X.400 Services Monthly reports as well as a few IETF scope documents. Effort has been taken to make sure this information is current as of February 1992. At the end of each section are lists of anonymous FTP and/or an e-mail address if more information is desired.
以下に注意してください。 ↓これはいくつかのIETF範囲ドキュメントと同様にIETF X.400 Services Monthlyレポートからの編集された抜粋です。 この情報が確実に1992年2月現在現在になるようにするために努力を取りました。 それぞれの終わりでは、詳しい情報が望まれているなら、セクションは、公開FTPのリスト、そして/または、Eメールアドレスです。
IETF OSIX400 (IETF OSI X.400 Working Group)
IETF OSIX400(IETF OSI X.400作業部会)
The IETF OSI X.400 Working Group is chartered to identify and provide solutions for problems encountered when operating X.400 in a dual protocol internet. This charter includes pure X.400 operational issues as well as X.400 <-> RFC 822 gateway (ala RFC 987) issues.
IETF OSI X.400作業部会は、二元的なプロトコルインターネットでX.400を操作するとき行きあたられる問題に解決法を特定して、提供するためにチャーターされます。 この特許はX.400<->RFC822ゲートウェイ(ala RFC987)問題と同様に純粋なX.400操作上の問題を含んでいます。
Mailing list address:
General Discussion: ietf-osi-x400@cs.wisc.edu
To Subscribe: ietf-osi-x400-request@cs.wisc.edu
メーリングリストアドレス: 一般議論: 申し込む ietf-osi-x400@cs.wisc.edu : ietf-osi-x400-request@cs.wisc.edu
ESCC X.500/X.400 Task Force [Page 55] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[55ページ]RFC1330X.500とX.400プラン
IETF X400OPS (IETF X.400 Operations Working Group)
IETF X400OPS(IETF X.400操作作業部会)
X.400 management domains are being deployed today on the Internet. There is a need for coordination of the various efforts to insure that they can interoperate and collectively provide an Internet-wide X.400 message transfer service connected to the existing Internet mail service. The overall goal of this group is to insure interoperability between Internet X.400 management domains and to the existing Internet mail service. The specific task of this group is to produce a document that specifies the requirements and conventions of operational Internet PRMDs.
X.400管理ドメインは今日、インターネットで配布されています。 様々な取り組みのコーディネートが共同利用して、既存のインターネット・メールサービスに関連づけられたインターネット全体のX.400メッセージ転送サービスはまとめて提供できるのを保障する必要があります。 このグループの全体的な目的はインターネットX.400管理ドメインの間と、そして、既存のインターネット・メールサービスに相互運用性を保障することです。 このグループの特定のタスクは操作上のインターネットPRMDsの要件とコンベンションを指定するドキュメントを製作することです。
Mailing list address:
General Discussion: ietf-osi-x400ops@pilot.cs.wisc.edu
To Subscribe: ietf-osi-x400ops-request@pilot.cs.wisc.edu
メーリングリストアドレス: 一般議論: 申し込む ietf-osi-x400ops@pilot.cs.wisc.edu : ietf-osi-x400ops-request@pilot.cs.wisc.edu
IETF MHS-DS (IETF Message Handling Services - Directory Services)
IETF MHS-DS(IETFメッセージ通信処理サービス--ディレクトリサービス)
The MHS-DS Group works on issues relating to Message Handling Service use of Directory Services. The Message Handling Services are primarily X.400, but issues relating to RFC 822 and RFC 822 interworking, in as far as use of the Directory is concerned, are in the scope of the Group. Directory Services means the services based on X.500 as specified by the OSI-DS group (RFCs 1274, 1275, 1276, 1277, 1278, 1297). The major aim of this group is to define a set of specifications to enable effective large scale deployment of X.400. While this Group is not directly concerned with piloting, the focus is practical, and implementations of this work by members of the Group is expected.
MHS-DS GroupはディレクトリサービスのMessage Handling Service使用に関係する問題に取り組みます。 Message Handling Servicesは主としてX.400ですが、ディレクトリの使用に関する限り、RFC822とRFC822の織り込むことに関連する問題がGroupの範囲にあります。 サービスが指定されるとしてのOSI-DSによるX.500に基礎づけたディレクトリサービス手段は(RFCs1274、1275、1276、1277、1278、1297)を分類します。 このグループの主要な目的はX.400の有効な大規模展開を可能にするために仕様一式を定義することです。 このGroupは直接操縦に関係がありませんが、焦点は実用的です、そして、Groupのメンバーによるこの仕事の実装は予想されます。
Mailing list address:
General Discussion: mhs-ds@mercury.udev.cdc.com
To Subscribe: mhs-ds-request@mercury.udev.cdc.com
Anonymous FTP site address: (e-mail archive is here)
mercury.udev.cdc.com
メーリングリストアドレス: 一般議論: 申し込む mhs-ds@mercury.udev.cdc.com : mhs-ds-request@mercury.udev.cdc.com アノニマス・エフテーピーサイトアドレス: (メールアーカイブがここにあります) mercury.udev.cdc.com
XNREN X.400 Pilot Project
XNREN X.400試験計画
The Internet X.400 Project at the University of Wisconsin is funded by NSF. We are working on two main areas:
ウィスコンシン大学のインターネットX.400 ProjectはNSFによって資金を供給されます。 私たちは2つの主な領域で働いています:
1. Supporting the operational use of X.400.
1. X.400の操作上の使用をサポートします。
2. Working with others to define organizational procedures
necessary to operate X.400 on a large scale in the Internet.
2. 大規模にインターネットでX.400を操作するのに必要な組織的な手順を定義するために他のものと共に働いています。
To support the use of X.400, we are operating a PRMD, assisting sites in running PP or the Wisconsin Argo X.400 software packages, and
そしてX.400の使用をサポートするために、私たちはPRMDを操作しています、実行しているPPかウィスコンシンアルゴー船X.400ソフトウェアパッケージにサイトを助けて。
ESCC X.500/X.400 Task Force [Page 56] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[56ページ]RFC1330X.500とX.400プラン
running an X.400 Message Transfer Agent (MTA) which is connected to U.S. and international MTAs using RFC1006/TCP/IP. Internet sites are invited to join our PRMD or establish X.400 connections with us. The organizational work is being done jointly by IETF working groups and RARE Working Group 1.
米国に接続されるX.400 Message Transferエージェント(MTA)とRFC1006/TCP/IPを使用する国際的なMTAsを実行します。 私たちのPRMDを接合するか、またはインターネット・サイトが私たちとのX.400接続を確立するよう誘われています。 IETFワーキンググループとRARE作業部会1は共同で組織的作業を完了しています。
Mailing list address:
General Discussion: x400-project-team@cs.wisc.edu
メーリングリストアドレス: 一般議論: x400-project-team@cs.wisc.edu
RARE WG1 (RARE Working Group 1 - Message Handling Systems)
まれなWG1(まれな作業部会1--メッセージハンドリングシステム)
RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1, Message Handling Systems, creates and promotes a European infrastructure for a message handling service within the European research community, with connections to the global environment. Membership of the Working Group is by nomination from the national networking organizations, together with a number of invited experts.
RARE(Reseaux Associesはla Recherche Europeenneを注ぐ)作業部会1(Message Handling Systems)は、ヨーロッパの研究団体の中のメッセージ通信処理サービスのためにヨーロッパのインフラストラクチャを作成して、促進します、地球環境との接続と共に。 作業部会の会員資格が多くの招待された専門家と共に国家のネットワーク組織からの指名でいます。
CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains)
CCITT SG-D MHS-Md(CCITT研究グループD、MHS管理ドメイン)
This group initially pursues the development of the rules for registering MHS management Domain names within the US. This group also pursues developing a set of voluntary agreements for North American operators of these management domains which will allow the US to uphold its Telecommunications treaty obligations while the industry maintains e-mail as an Information Processing service. The specific aspect of the treaty that is immediate concern to this group is that subscribers of MHS services in other countries, especially those countries who treat MHS as a Telecommunications service, must be able to reach MHS users in this country regardless of how their message enters the US and regardless of how many domains are involved in the transfer of the message to the intended recipient.
このグループは初めは、米国の中にMHS管理Domain名を登録するための規則の開発につきまといます。 また、このグループは、産業が情報Processingサービスとしてメールを維持している間に米国がTelecommunications条約義務を是認できるこれらの管理ドメインの北米のオペレータのための自発的な同意一式を開発しながら、つきまといます。 このグループへの目前の課題である条約の特定の局面は彼らのメッセージがどう米国に入るかにかかわらずいくつのドメインがメッセージの転送にかかわるかにかかわらず他国におけるMHSサービスの加入者(特にTelecommunicationsサービスとしてMHSを扱う国)がこの国でMHSユーザに意図している受取人に届くことができなければならないということです。
The US State Department presently considers MHS (e-mail) as an Information Processing service. Some other countries consider any MHS (e-mail) service to be a Telecommunications service and hence, CCITT treaty obligations apply.
米国国務省は、現在、MHS(メール)が情報Processingサービスであるとみなします。 外国は、どんなMHS(メール)サービスもTelecommunicationsサービスであると考えます、そして、したがって、CCITT条約義務は申請されます。
NIST/GSA Interagency X.400 Connectivity Project
NIST/GSA省庁X.400接続性プロジェクト
The goal of this project is to assist the members of the Federal Information Resource Management Policy Council (FIRMPoC) in establishing electronic mail connectivity based on X.400. The outcome of this project is to continue, as the National Institute of Standards and Technology (NIST) has done in the past, providing Federal agencies with assistance in establishing electronic mail connectivity. This project is sponsored by the General Services
このプロジェクトの目標はX.400に基づく電子メールの接続性を確立するのを連邦政府の情報源Management Policy Council(FIRMPoC)のメンバーを補助することです。 このプロジェクトの結果は続くことになっています、米国商務省標準技術局(NIST)が過去にしたように、電子メールの接続性を確立する際に連邦政府の機関に支援を提供して。 このプロジェクトは司令官のServicesによって後援されます。
ESCC X.500/X.400 Task Force [Page 57] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[57ページ]RFC1330X.500とX.400プラン
Administration (GSA).
政権(GSA)。
Appendix C: How to Obtain QUIPU, PP and ISODE
付録C: 結び縄文字、pp、およびISODEを入手する方法
ISODE/QUIPU 7.0
ISODE/結び縄文字7.0
This software supports the development of certain kinds of OSI protocols and applications. Here are the details:
このソフトウェアはある種類のOSIプロトコルとアプリケーションの開発をサポートします。 ここに、詳細があります:
o The ISODE is not proprietary, but it is not in the public
domain. This was necessary to include a "hold harmless"
clause in the release. The upshot of all this is that anyone
can get a copy of the release and do anything they want with
it, but no one takes any responsibility whatsoever for any
(mis)use.
o ISODEは独占ではありませんが、それは公共の場にありません。 これが、リリースに「保持無害な」節を含むのに必要でした。 このすべての結果がリリースのコピーを手に入れて、彼らがそれで欲しいことができますが、だれも全くどんな責任もいずれにも取らないということである、(誤、)、使用。
o The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V
systems, in addition to various other UNIX-like operating
systems. No kernel modifications are required.
o ISODEは故郷のバークレー(4.2、4.3)とAT&T System Vシステムで動きます、他の様々なUNIXのようなオペレーティングシステムに加えて。カーネル変更は全く必要ではありません。
o Current modules include:
o 現在のモジュールは:
- OSI transport service (TP0 on top of TCP, X.25 and CONS;
TP4 for SunLink OSI)
- OSI輸送サービス(TCP、X.25、およびコンズの上のTP0; SunLink OSIのためのTP4)
- OSI session, presentation, and association control services
- OSIセッション、プレゼンテーション、およびアソシエーション制御サービス
- ASN.1 abstract syntax/transfer notation tools, including:
- ASN.1抽象構文/転送記法ツール、含み:
1. Remote operations stub-generator (front-end for remote
operations)
1. リモート操作スタッブジェネレータ(リモート操作のためのフロントエンド)
2. Structure-generator (ASN.1 to C)
2. 構造ジェネレータ(CへのASN.1)
3. Element-parser (basic encoding rules)
3. 要素パーサ(基本的な符号化規則)
- OSI reliable transfer and remote operations services
- OSIの信頼できる転送とリモート操作サービス
- OSI directory services
- OSIディレクトリサービス
- OSI file transfer, access and management
- OSIファイル転送、アクセス、および管理
- FTAM/FTP gateway
- FTAM/FTPゲートウェイ
- OSI virtual terminal (basic class, TELNET profile)
- OSI仮想端末(基本的なクラス、TELNETプロフィール)
o ISODE 7.0 consists of final "IS" level implementations with the
exception of VT which is a DIS implementation. The ISODE also
o 不-実装であるバーモントを除いて、ISODE7.0は決勝が「ある」という平らな実装から成ります。 ISODEも
ESCC X.500/X.400 Task Force [Page 58] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[58ページ]RFC1330X.500とX.400プラン
contains implementations of the 1984 X.400 versions of ROS and
RTS.
1984年のROSとRTSのX.400バージョンの実装を含んでいます。
o Although the ISODE is not "supported" per se, it does have a
problem reporting address, Bug-ISODE@XTEL.CO.UK. Bug reports
(and fixes) are welcome by the way.
o ISODEはそういうものとして「サポートされません」が、それには、アドレス、 Bug-ISODE@XTEL.CO.UK を報告することにおける問題があります。 ところで、バグレポート(そして、フィックス)を歓迎します。
o The discussion group ISODE@NISC.SRI.COM is used as an open
forum on ISODE. Contact ISODE-Request@NISC.SRI.COM to be added
to this list.
o ディスカッション・グループ ISODE@NISC.SRI.COM はオープン・フォーラムとしてISODEで使用されます。 ISODE-Request@NISC.SRI.COM に連絡して、このリストに追加されてください。
o The primary documentation for this release consists of a five
volume User's Manual (approx. 1000 pages) and a set of UNIX
manual pages. The sources to the User's Manual are in LaTeX
format. In addition, there are a number of notes, papers, and
presentations included in the documentation set, again in
either LaTeX or SLiTeX format. If you do not have LaTeX, you
should probably get a hardcopy from one of the distribution
sites below.
o このリリースのためのプライマリドキュメンテーションはUserの5ボリュームManual(およそ1000ページ)とUNIXマニュアルページのセットから成ります。 LaTeX形式にはUserのManualへのソースがあります。 さらに、ドキュメンテーションセットに含まれていた多くの注意、書類、およびプレゼンテーションがあります、再びLaTeXかSLiTeX形式のどちらかで。 LaTeXを持っていないなら、あなたはたぶん下の分配サイトの1つからハードコピーを得るべきです。
ISODE/QUIPU Distribution Sites
ISODE/結び縄文字分配サイト
The FTP or FTAM distributions of ISODE-7.0 consists of 3 files. The source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z which is approximately 4.7MB in size.
ISODE-7.0のFTPかFTAM配が3個のファイルから成ります。 ソースと主なISODE-7.0分配がサイズにおいておよそ4.7MBであるファイルISODE-7.tar.Zにあります。
LaTeX source for the entire document set can be found in the ISODE- 7-doc.tar.Z file (3.5MB). A list of documents can be found in the doc/ directory of the source tree.
ISODE7-doc.tar.Zファイル(3.5MB)で全体の文献集合のためのLaTeXソースを見つけることができます。 ソース木のdoc/ディレクトリでドキュメントのリストを見つけることができます。
A Postscript version of the five volume manual can be found in the ISODE-7-ps.tar.Z file (4.3MB).
ISODE-7-ps.tar.Zファイル(4.3MB)で5ボリュームマニュアルの補遣版を見つけることができます。
If you can FTP to the Internet, then use anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the files in BINARY mode from the ISODE/ directory.
インターネット、その時までのFTPがあなたであるならuu.psi.comに公開FTPを使用できる、[136.161 .128 .3] ISODE/ディレクトリからBINARYモードによるファイルを取るために。
Additional PSI White Pages Pilot Software
追加ψホワイトページパイロットソフトウェア
The 'usconfig' program configures a DSA which understands some of the NADF naming rules. This software is primarily intended for creating directory hierarchies for DSAs from scratch. The add-on software is available via anonymous FTP from uu.psi.com in:
'usconfig'プログラムは規則を命名するいくらかのNADFを理解しているDSAを構成します。 このソフトウェアは、最初からDSAsのためのディレクトリ階層構造を作成するために主として意図します。 アドオンソフトは以下でuu.psi.comからの公開FTPで利用可能です。
wp/src/wpp-addon.tar.Z
wp/src/wpp-addon.tar.Z
Whether you choose to use 'usconfig' or not, please retrieve and install the addon, and follow the instructions therein. You might
'usconfig'を使用するのを選ぶか否かに関係なく、addonを検索して、インストールしてください、そして、そこに指示に従ってください。 あなたはそうするかもしれません。
ESCC X.500/X.400 Task Force [Page 59] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[59ページ]RFC1330X.500とX.400プラン
want to retrieve pilot-ps.tar.Z again also, as it contains an updated Administrator Guide.
また、アップデートされたAdministratorガイドを含むので、再びパイロット-ps.tar.Zを検索したいです。
Note that the wpp-addon.tar.Z file needs to be installed on top of the ISODE 7.0 distribution; it does not duplicate any of the ISODE 7.0, you need to retrieve and generate that too.
wpp-addon.tar.Zファイルが、ISODE7.0分配の上でインストールされる必要に注意してください。 それがISODE7.0のいずれもコピーしないで、あなたは、それをも検索して、生成する必要があります。
PP 6.0
pp6.0
PP is a Message Transfer Agent, intended for high volume message switching, protocol conversion, and format conversion. It is targeted for use in an operational environment, but is also be useful for investigating message related applications. Good management features are a major aspect of this system. PP supports the 1984 and 1988 versions of the CCITT X.400 / ISO 10021 services and protocols. Many existing RFC-822 based protocols are supported, along with RFC- 1148bis conversion to X.400. PP is an appropriate replacement for MMDF or Sendmail. This is the second public release of PP, and includes substantial changes based on feedback from using PP on many sites.
PPは高いボリュームメッセージ交換、プロトコル変換、およびフォーマット変換のために意図するMessage Transferエージェントです。 それは、運用環境における使用のために狙いますが、また、メッセージ関連出願を調査することの役に立つことです。 良い管理機能はこのシステムの主要な局面です。 PPはCCITT X.400 / ISO10021サービスとプロトコルの1984と1988バージョンをサポートします。 多くの既存のRFC-822ベースのプロトコルがRFC1148bis変換と共にX.400にサポートされます。 PPはMMDFかセンドメールへの適切な交換品です。 これは、PPの2番目の公共のリリースであり、多くのサイトのPPを使用するのからのフィードバックに基づく大きな変化を含んでいます。
o PP is not proprietary and can be used for any purpose. The only
restriction is that suing of the authors for any damage the
code may cause is not allowed.
o PPは独占でなく、どんな目的にも使用できます。 唯一の制限はコードがもたらすどんな損害でも作者について訴えるのが許されていないということです。
o PP runs on a range of UNIX and UNIX-like operating systems,
including SUNOS, Ultrix, and BSD. A full list of platforms on
which PP is know to run is included in the distribution.
o SUNOS、Ultrix、およびBSDを含んでいて、PPはさまざまなUNIXとUNIXのようなオペレーティングシステムで動きます。 PPが稼働するのを知ることであるプラットホームに関する完全リストは分配に含まれています。
o Current modules include:
o 現在のモジュールは:
- X.400 (1984) P1 protocol.
- X.400(1984)P1は議定書を作ります。
- X.400 (1988) P1 protocol.
- X.400(1988)P1は議定書を作ります。
- Simple mail transfer protocol (SMTP), conformant to host
requirements.
- SMTP(SMTP)、ホスト要件へのconformant。
- JNT mail (grey book) Protocol.
- JNTはプロトコルを郵送します(灰色の本)。
- UUCP mail transfer.
- UUCPは転送を郵送します。
- DECNET Mail-11 transfer
- DECNETメール-11転送
- Distribution list expansion and maintenance, using either a
file based mechanism or an X.500 directory.
- 発送先リスト拡張とメインテナンス、ファイルを使用すると、メカニズムかX.500ディレクトリが基づきました。
- RFC 822-based local delivery.
- RFCの822ベースの地方の配送。
ESCC X.500/X.400 Task Force [Page 60] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[60ページ]RFC1330X.500とX.400プラン
- Delivery time processing of messages.
- メッセージの納期処理。
- Conversion between X.400 and RFC-822 according to the latest
revision of RFC-1148, known as RFC-1148bis.
- RFC-1148bisとして知られているRFC-1148の最新の改正に従ったX.400とRFC-822の間の変換。
- Conversion support for reformatting body parts and headers.
- 身体の部分とヘッダーを再フォーマットする変換サポート。
- X-Window and line-based management console.
- Xウィンドウと系列ベースのマネージメントコンソール。
- Message Authorization checking.
- メッセージAuthorizationの照合。
- Reformatting support for "mail hub" operation.
- 「メール・ハブ」操作のサポートをReformattingします。
- X.500-based distribution list facility using the QUIPU
directory.
- QUIPUディレクトリを使用するX.500ベースの発送先リスト施設。
- FAX interworking
- FAXの織り込むこと
o No User Agents (UAs) are included with PP. However, procedural
access to the MTA is documented, to encourage others to write
or to port UAs. Several existing UAs, such as MH, may be used
with PP.
o Userエージェント(UAs)は全くPPと共に含まれていません。 しかしながら、MTAへの手続き上のアクセスは、他のものが書くか、またはUAsを移植するよう奨励するために記録されます。 MHなどの既存の数個のUAsがPPと共に使用されるかもしれません。
o It is expected that a Message Store to be used in conjunction
with PP (PPMS), and an associated X-Windows User Agent (XUA)
will be released on beta test in first quarter 92.
o エージェント(XUA)がそうするPP(PPMS)、および関連XウィンドウUserに関連して使用されるべきMessageストアが第1四半期92にベータテストでリリースされると予想されます。
o The core routing of PP 6.0 is table based. DNS is used by the
SMTP channel. The next version of PP will support Directory
Based routing, which may use X.500 or DNS.
o PP6.0のコアルーティングは基づくテーブルです。 DNSはSMTPチャンネルによって使用されます。 PPの次のバージョンは、ディレクトリBasedがルーティングであるとサポートするでしょう。(それは、X.500かDNSを使用するかもしれません)。
o PP 6.0 requires ISODE 7.0.
o PP6.0はISODE7.0を必要とします。
o X-Windows release X11R4 (or greater) is needed by some of the
management tools. PP can be operated without these tools.
o XウィンドウリリースX11R4と(よりすばらしい)、管理ツールのいくつかが必要です。 これらのツールなしでPPを操作できます。
o Although PP is not "supported" per se (but see later), it does
have a problem reporting address (bug reports (and fixes) are
welcome):
o PPはそういうものとして「サポートされません」が(後で見てください)、それには、アドレスを報告することにおける問題があります(バグレポート(そして、フィックス)を歓迎します):
RFC-822: PP-SUPPORT@CS.UCL.AC.UK
X.400: S=PP-Support; OU=CS; O=UCL;
PRMD=UK.AC; ADMD= ; C=GB;
RFC-822: PP-SUPPORT@CS.UCL.AC.UK X.400: Sはppサポートと等しいです。 OUはCsと等しいです。 O=UCL。 PRMD=UK.AC。 ADMD=。 CはGBと等しいです。
o The discussion group PP-PEOPLE@CS.UCL.AC.UK is used as an open
forum on PP; Contact PP-PEOPLE-REQUEST@CS.UCL.AC.UK to be added
to this list.
o ディスカッション・グループ PP-PEOPLE@CS.UCL.AC.UK はオープン・フォーラムとしてPPで使用されます。 PP-PEOPLE-REQUEST@CS.UCL.AC.UK に連絡して、このリストに追加されてください。
ESCC X.500/X.400 Task Force [Page 61] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[61ページ]RFC1330X.500とX.400プラン
o The primary documentation for this release consists of a three
and a half volume User's Manual (approx. 300 pages) and a set
of UNIX manual pages. The sources to the User's Manual are in
LaTeX format.
o このリリースのためのプライマリドキュメンテーションはUserのボリュームManual(およそ300ページ)の3.5とUNIXマニュアルページのセットから成ります。 LaTeX形式にはUserのManualへのソースがあります。
PP Distribution Sites
pp分配サイト
If you can FTP to the Internet from outside Europe, then use anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp- 6.tar.Z in binary mode from the ISODE/ directory. This file is the tar image after being run through the compress program and is approximately 3Mb in size.
ヨーロッパ、その時の外からのインターネットへのFTPがあなたであるならuu.psi.comに公開FTPを使用できる、[136.161 .128 .3] ISODE/ディレクトリからバイナリ・モードでファイルpp6.tar.Zを検索するために。 このファイルは、湿布プログラムで実行された後のタールイメージであり、サイズがおよそ3Mbです。
If you can FTP to the Internet from Europe, then use anonymous FTP to archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in binary mode from the network/ISODE/ directory. This file is the tar image after being run through the compress program and is approximately 3Mb in size.
ヨーロッパからのインターネットへのFTP、その時があなたであるならarchive.eu.netに公開FTPを使用できる、[192.16 .202 .1] ネットワーク/ISODE/ディレクトリからバイナリ・モードでファイルpp-6.tar.Zを検索するために。 このファイルは、湿布プログラムで実行された後のタールイメージであり、サイズがおよそ3Mbです。
ISODE/QUIPU and PP Platforms as of December 1991
1991年12月現在ISODE/結び縄文字とppプラットホーム
Machine OS ISODE PP Stacks Notes
====================================================================
CCUR 6000 RTU 5.0 7.0 Yes! TCP 1
--------------------------------------------------------------------
CCUR 6000 RTU 6.0 7.0 Yes! TCP 2
X25
CLNS
--------------------------------------------------------------------
CDC 4000 Series EP/IX 1.3.2 6.6+ TCP 3
EP/IX 1.4.1 CLNS
X25
--------------------------------------------------------------------
COMPAQ 386/25 SCO Unix 5.2 6.0 TCP
--------------------------------------------------------------------
COMPAQ 386 BSD 7.0 TCP 4
X25
--------------------------------------------------------------------
Convex C120 ConvexOS 8.1 7.0 TCP 5
--------------------------------------------------------------------
DEC Vax 2nd Berkeley Network rel 7.0 TCP
X25
--------------------------------------------------------------------
DEC DECnet-ULTRIX V5.0 7.0 TCP 6
CLNS
--------------------------------------------------------------------
DEC Ultrix 3.1D 7.0 5.2 TCP 7
Ultrix 4.0 X25
マシンOS ISODE ppは注意を積み重ねます。==================================================================== CCUR6000RTU5.0 7.0はい! TCP1-------------------------------------------------------------------- CCUR6000RTU6.0 7.0はい! TCP2X25 CLNS-------------------------------------------------------------------- CDC4000シリーズEP/IX1.3.2 6.6+TCP3EP/IX1.4.1CLNS X25-------------------------------------------------------------------- コンパック386/25SCO unix5.2 6.0TCP-------------------------------------------------------------------- コンパック386BSD7.0TCP4X25-------------------------------------------------------------------- 凸C120 ConvexOS8.1 7.0TCP5-------------------------------------------------------------------- 12月のバックス2番目のバークレーNetwork rel7.0TCP X25-------------------------------------------------------------------- 12月のDECnet-ULTRIX V5.0 7.0 TCP6CLNS-------------------------------------------------------------------- 12月のUltrix 3.1D7.0 5.2TCP7Ultrix4.0X25
ESCC X.500/X.400 Task Force [Page 62] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[62ページ]RFC1330X.500とX.400プラン
Ultrix 4.1
--------------------------------------------------------------------
DEC Ultrix 4.2 7.0 TCP
X25
CLNS
--------------------------------------------------------------------
DEC VMS v5.x 7.0 TCP
X25
--------------------------------------------------------------------
DG Avion DGUX 4.30 7.0 TCP 8
--------------------------------------------------------------------
Encore Multimax 3xx UMAX V 2.2h 6.0 TCP 9
Encore Multimax 5xx
--------------------------------------------------------------------
Encore NP1 UTX/32 3.1a 7.0 TCP 10
X25
--------------------------------------------------------------------
Encore PN6000 UTX/32 2.1b 6.0 TCP 9
Encore PN9000 X25
--------------------------------------------------------------------
HP/9000/3xx HP/UX 6.0 7.0 TCP 11
HP-UX 7.05 B
--------------------------------------------------------------------
HP/9000/8xx HP-UX 7.00 7.0 TCP 11
X25
--------------------------------------------------------------------
IBM 3090 AIX/370 1.2.1 7.0 TCP 12
--------------------------------------------------------------------
IBM PS/2 AIX 1.2.1 6.7 TCP 13
--------------------------------------------------------------------
IBM RS/6000 AIX 3.1 6.8 TCP
AIX 3.0
--------------------------------------------------------------------
ICL DRS/6000 7.0 5.2 TCP 14
--------------------------------------------------------------------
Macintosh A/UX 2.0.1 7.0 TCP
--------------------------------------------------------------------
Macintosh MacOS V6.x 6.0 TCP 15
--------------------------------------------------------------------
Mips 4-52 ATT-V3-0 7.0 5.2 TCP 16
--------------------------------------------------------------------
NeXT 7.0 5.2 TCP 17
--------------------------------------------------------------------
ORION/Clipper 6.8 TCP
--------------------------------------------------------------------
Olivetti LSX-3020 X/OS 2.1 6.7b 5.0 TCP 1
X25
--------------------------------------------------------------------
Ultrix4.1-------------------------------------------------------------------- 12月のUltrix4.2 7.0TCP X25 CLNS-------------------------------------------------------------------- 12月のVMS v5.x7.0TCP X25-------------------------------------------------------------------- DGエイヴォンDGUX4.30 7.0TCP8-------------------------------------------------------------------- アンコールMultimax 3xx UMAX V2.2h6.0TCP9アンコールMultimax 5xx-------------------------------------------------------------------- アンコールNP1 UTX/32 3.1a7.0TCP10X25-------------------------------------------------------------------- アンコールPN6000 UTX/32 2.1b6.0TCP9アンコールPN9000 X25-------------------------------------------------------------------- hp/9000/3xx hp/UX6.0 7.0TCP11hp-UX7.05B-------------------------------------------------------------------- hp/9000/8xx hp-UX7.00 7.0TCP11X25-------------------------------------------------------------------- IBM3090AIX/370 1.2.1 7.0TCP12-------------------------------------------------------------------- IBM PS/2AIX1.2.1 6.7TCP13-------------------------------------------------------------------- IBM RS/6000AIX3.1 6.8TCP AIX3.0-------------------------------------------------------------------- ICL DRS/6000 7.0 5.2TCP14-------------------------------------------------------------------- マッキントッシュは/UX2.0.1 7.0TCPです。-------------------------------------------------------------------- マッキントッシュMacOS V6.x6.0TCP15-------------------------------------------------------------------- Mips4-52ATT-V3-0 7.0 5.2TCP16-------------------------------------------------------------------- 次の7.0 5.2TCP17-------------------------------------------------------------------- オリオン/刈り取る人6.8TCP-------------------------------------------------------------------- オリベッティLSX-3020 X/OS2.1 6.7b5.0TCP1X25--------------------------------------------------------------------
ESCC X.500/X.400 Task Force [Page 63] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[63ページ]RFC1330X.500とX.400プラン
Pyramid 9800 OSx 5.1 (4.3BSD/SVR3.2) 7.0 5.2 TCP 18
Pyramid MIS
--------------------------------------------------------------------
SEQUENT DYNIX V3.0.18 7.0 TCP 8
--------------------------------------------------------------------
Sony News-1750 NEWS-OS 3.3 6.8 TCP
NEWS-OS 4.0c
--------------------------------------------------------------------
Sun4 SunOS 4.1 7.0 5.2 TCP
Sun3 SunOS 4.1.1 X25
SunOS 4.0.3c CONS
CLNS
--------------------------------------------------------------------
ピラミッド9800OSx5.1(4.3BSD/SVR3.2)7.0 5.2TCP18がピラミッド状になる、誤-------------------------------------------------------------------- 次のDYNIX V3.0.18 7.0TCP8-------------------------------------------------------------------- ソニーニュース-1750ニュースOS3.3 6.8TCPニュースOS4.0c-------------------------------------------------------------------- Sun4 SunOS4.1 7.0 5.2TCP Sun3 SunOS4.1.1X25 SunOS4.0.3のcコンズCLNS--------------------------------------------------------------------
Notes:
注意:
1. NOT SNMP or VT
1. SNMPでないバーモントでない
2. Little tested
2. 少ししか、テストしませんでした。
3. Official upper layer
3. 公式の上側の層
4. Prototype only!
4. 原型専用!
5. Planned port
5. 計画されたポート
6. Being worked on!
6. 働いていること!
7. 3.1D binaries compiled under 4.2
7. 3.1 D2種混合毒ガスは4.2未満をコンパイルしました。
8. Only QUIPU confirmed
8. 確認されたQUIPUだけ
9. Not QUIPU
9. 結び縄文字でない
10. Need "-Dregister=" in CONFIG.make
10. 「-、」 Dregister=コネCONFIG.makeでなければならない
11. Need bug-fix no. 5 from bug-ISODE@xtel.co.uk. not SNMP,VT or
FTAM-FTP gateway
11. bug-ISODE@xtel.co.uk SNMP、バーモントでないのからの必要性バグ修正No.5かFTAM-FTPゲートウェイ
12. No VT, QUIPU not tested
12. バーモントがない、テストされなかったQUIPU
13. Models 80 and 95
13. モデル80と95
14. NOT SNMP or VT,PP and X.25 requires patches available from
X-Tel
14. NOT SNMPかバーモントと、PPとX.25がX-Telから利用可能なパッチを必要とします。
15. Using MacTCP
15. MacTCPを使用します。
ESCC X.500/X.400 Task Force [Page 64] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[64ページ]RFC1330X.500とX.400プラン
16. Only QUIPU tested, built using BSD43 config
16. BSD43コンフィグを使用することで建てられて、テストされたQUIPUだけ
17. Need bug-fix no. 6 from bug-ISODE@xtel.co.uk
17. 必要性バグ修正No.6 bug-ISODE@xtel.co.uk から
18. Built using BSD config, no VT or SNMP
18. どんなBSDコンフィグ、バーモントもまたはSNMPも使用しないことで、建てられます。
The above tables do not refer to beta releases of ISODE and PP more recent than the public ISODE-7.0 or PP-5.2 releases. The above table is generated from reports sent to bug-ISODE and pp-support. There is no guarantee the information is correct.
上のテーブルは公共のISODE-7.0かPP-5.2リリースより最近のISODEとPPのベータリリースを示しません。 上のテーブルはバグ-ISODEに送られたレポートとppサポートから発生します。 情報が正しいという保証が全くありません。
Appendix D: Sample X.500 Input File and Restricted Character List
付録D: サンプルX.500はファイルを入力して、キャラクターリストを制限しました。
Below is a sample datafile that illustrates the format for providing data about persons at your site to be loaded into the ESnet DSA. Following the sample datafile is a detailed explanation of the format and content of the file. We have tried to be as flexible as possible in defining the format of the file, given the constraints imposed by an automated process. We would appreciate feedback on the format of the file and will try to accommodate any specific needs you may have to any extent that is reasonable.
以下に、ESnet DSAにロードされるためにあなたのサイトで人々に関するデータを提供するために形式を例証するサンプルdatafileがあります。 サンプルdatafileに続くのは、形式の詳説とファイルの中身です。 私たちはできるだけファイルの書式を定義するのにおいてフレキシブルになろうとしました、自動化された工程で課された規制を考えて。 ファイルの形式のフィードバックに感謝するでしょう、そして、私たちはあなたがどんな妥当な程度まで持っているどんな特定の必要性も収容しようとするでしょう。
# # Sample Data File for Bulk Loading X.500 Database # # delimiter character is "," 1 # field 1 is commonName 2 # field 2 is phone extension 3 # area code for all numbers is 510 4 # prefix for all numbers is 422 5 # field 3 is rfc822Mailbox 6 # field 4 is facsimileTelephoneNumber 7 # default facsimileTelephoneNumber is (510) 422-3333 8 # postalAddress for all entries is: 9 # National Energy Research Supercomputer Center 10 # P.O. Box 5509 11 # Livermore, California 94552 12 # Chris Anderson,1915,anderson@ws1.nersc.gov, 13 Lila Brown,5680,brownl@ws2.nersc.gov, 14 Bob Green,4474,, 15 Max Jones,4488,elvis@presley.nersc.gov,5104224444 16 Dave Smith,9818,smithd@ws3.nersc.gov, 17 Cathy White,4016,snow@white.nersc.gov, 18 <end-of-file>
# # 」 「Bulk Loading X.500 Database##デリミタキャラクタのためのサンプルData Fileはそうです」、1つの#分野1はcommonName2#分野2がすべての数のための電話拡大3#市外局番がすべての数のための510 4#接頭語が422 5#分野3がrfc822Mailbox6#分野4がfacsimileTelephoneNumber7#デフォルトfacsimileTelephoneNumberが(510) 422-3333 すべてのエントリーへの8#postalAddressがあるということであるということであるということであるということであるということであるということであるということです: 国家のエネルギー研究スーパーコンピュータセンター10#私書箱5509 11#9#リバーモア(カリフォルニア)の94552 12#クリス・アンダーソン、1915、 anderson@ws1.nersc.gov 、13ライラBrown、5680、 brownl@ws2.nersc.gov 、14ボブGreen、4474、15はジョーンズ、4488、 elvis@presley.nersc.gov 、5104224444 16デーヴ鍛冶屋、9818、 smithd@ws3.nersc.gov 、17キャシーWhite、4016、 snow@white.nersc.gov に最大限にします、18<ファイルの終り>。
Comment lines at the beginning of the file convey relevant formatting information.
ファイルの始めの注釈行は関連形式情報を伝えます。
ESCC X.500/X.400 Task Force [Page 65] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[65ページ]RFC1330X.500とX.400プラン
Following comment lines, each data line contains information about one person.
注釈行に続いて、各データラインは情報およそ1人を含みます。
Fields within a single data line are separated by a delimiter character. You specify the delimiter character you wish to use in the comment section; be sure to choose a delimiter which does not appear as a legitimate character in any field of a data line.
ただ一つのデータラインの中の野原はデリミタキャラクタによって分離されます。 あなたがコメント部で使用したいデリミタキャラクタを指定します。 正統のキャラクタとしてデータラインのどんな分野にも現れないデリミタを必ず選んでください。
You may provide all or part of the attribute types listed in the table in Section 2.5 (commonName is required). In the comment section, you must indicate which attribute types are contained in each field of a data line.
あなたがすべてを提供できますか、または属性タイプの一部がセクション2.5にテーブルに記載しました(commonNameが必要です)。 コメント部で、あなたは、どの属性タイプがデータラインの各分野に保管されているかを示さなければなりません。
Each data line must contain the same number of fields and the same order of fields (i.e. same order of attribute types). Two successive delimiters indicated a null value (eof is a considered a field delimiter).
各データラインは同じ数の分野と分野の同じ注文(すなわち、属性タイプの同じ注文)を含まなければなりません。 2つの連続したデリミタがヌル値を示しました(eofはフイールド・デリミタであると考えられたaです)。
The characters "=", "&", "$", and "#" are NEVER allowed in any attribute value.
キャラクタ「=」、“&"、「$」、および「#」はどんな属性値でも決して許容されていません。
Below is a discussion of relevant lines of the sample datafile.
以下に、サンプルdatafileの関連線の議論があります。
Line 1 The delimiter character is identified as a comma (,).
線1、デリミタキャラクタがコンマとして特定される、()
Line 2 Field # 1 is identified as containing the commonName
attribute.
線2Field#1はcommonName属性を含むとして特定されます。
Line 3 Field # 2 is identified as containing the telephoneNumber
attribute. The actual data value is a 4-digit
extension.
線3Field#2はtelephoneNumber属性を含むとして特定されます。 実際のデータ値は4ケタの拡大です。
Lines 4,5 Identify the area code and prefix which apply to all
4-digit extensions in the datafile. If your actual
data values already contain area code and/or prefix,
then there would be no need to indicate default values.
4、5Identifyを裏打ちする、datafileでのすべての4ケタの拡大に適用される市外局番と接頭語。 あなたの実際のデータ値が既に市外局番、そして/または、接頭語を含んでいるなら、デフォルト値を示す必要は全くないでしょう。
Line 6 Field # 3 is identified as containing the rfc822Mailbox
attribute.
線6Field#3はrfc822Mailbox属性を含むとして特定されます。
Line 7 Field # 4 is identified as containing the
facsimileTelephoneNumber attribute.
線7Field#4はfacsimileTelephoneNumber属性を含むとして特定されます。
Line 8 Identifies the default value for
facsimileTelephoneNumber. If field 4 is missing in a
data line, the default value will be applied.
デフォルトがfacsimileTelephoneNumberのために評価する8Identifiesを裏打ちしてください。 分野4がデータラインでなくなると、デフォルト値は適用されるでしょう。
Lines 9-12 Identify the value of the postalAddress attribute which
postalAddressの値が結果と考える線9-12Identify、どれ
ESCC X.500/X.400 Task Force [Page 66] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[66ページ]RFC1330X.500とX.400プラン
applies to all entries.
すべてのエントリーに適用します。
Line 13 commonName= Chris Anderson
surName= Anderson
telephoneNumber= 510-422-1915
rfc822MailBox= anderson@ws1.nersc.gov
facsimileTelephoneNumber= 510-422-3333
postalAddress= National Energy Research Supercomputer Center
P.O. Box 5509
Livermore, California 94552
5509年のリバーモア、国家のEnergy研究スーパーコンピュータセンターP.O. Box510-422-3333 線クリス・アンダーソン姓=アンダーソンtelephoneNumber=510-422-1915rfc822MailBox= anderson@ws1.nersc.gov 13commonName=facsimileTelephoneNumber=postalAddress=カリフォルニア 94552
Line 14 commonName= Lila Brown
surName= Brown
telephoneNumber= 510-422-5680
rfc822MailBox= brownl@ws2.nersc.gov
facsimileTelephoneNumber= 510-422-3333
postalAddress= National Energy Research Supercomputer Center
P.O. Box 5509
Livermore, California 94552
5509年のリバーモア、国家のEnergy研究スーパーコンピュータセンターP.O. Box510-422-3333 線ライラブラウン姓=ブラウンtelephoneNumber=510-422-5680rfc822MailBox= brownl@ws2.nersc.gov 14commonName=facsimileTelephoneNumber=postalAddress=カリフォルニア 94552
Line 15 commonName= Bob Green
surName= Green
telephoneNumber= 510-422-4474
rfc822MailBox=
facsimileTelephoneNumber= 510-422-3333
postalAddress= National Energy Research Supercomputer Center
P.O. Box 5509
Livermore, California 94552
5509年のリバーモア、国家のEnergy研究スーパーコンピュータセンターP.O. Box510-422-3333 510-422-4474 線ボブ・グリーン姓=グリーン15commonName=telephoneNumber=rfc822MailBox= facsimileTelephoneNumber=postalAddress=カリフォルニア 94552
Line 16 commonName= Max Jones
surName= Jones
telephoneNumber= 510-422-4488
rfc822MailBox= elvis@presley.nersc.gov
facsimileTelephoneNumber= 510-422-4444
postalAddress= National Energy Research Supercomputer Center
P.O. Box 5509
Livermore, California 94552
5509年のリバーモア、国家のEnergy研究スーパーコンピュータセンターP.O. Box510-422-4444 線ジョーンズtelephoneNumber=510-422-4488rfc822MailBox= elvis@presley.nersc.gov マックスジョーンズ16commonName=surName=facsimileTelephoneNumber=postalAddress=カリフォルニア 94552
Line 17 commonName= Dave Smith
surName= Smith
telephoneNumber= 510-422-9818
rfc822MailBox= smithd@ws3.nersc.gov
facsimileTelephoneNumber= 510-422-3333
postalAddress= National Energy Research Supercomputer Center
P.O. Box 5509
Livermore, California 94552
5509年のリバーモア、国家のEnergy研究スーパーコンピュータセンターP.O. Box510-422-3333 線デーヴスミス姓=スミスtelephoneNumber=510-422-9818rfc822MailBox= smithd@ws3.nersc.gov 17commonName=facsimileTelephoneNumber=postalAddress=カリフォルニア 94552
ESCC X.500/X.400 Task Force [Page 67] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[67ページ]RFC1330X.500とX.400プラン
Line 18 commonName= Cathy White
surName= White
telephoneNumber= 510-422-4016
rfc822MailBox= snow@white.nersc.gov
facsimileTelephoneNumber= 510-422-3333
postalAddress= National Energy Research Supercomputer Center
P.O. Box 5509
Livermore, California 94552
5509年のリバーモア、国家のEnergy研究スーパーコンピュータセンターP.O. Box白い線telephoneNumber=510-422-4016rfc822MailBox= snow@white.nersc.gov facsimileTelephoneNumberキャシーホワイト18commonName=surName==510-422-3333postalAddress=カリフォルニア 94552
Appendix E: ESnet Backbone Sites
付録E: ESnet背骨サイト
Government Agencies
政府機関
U.S. Department of Energy, Office of Energy Research (DOE) Germantown, Maryland USA
米国エネルギー省、エネルギー課研究(DOE)メリーランドジャーマンタウン(米国)
U.S. Department of Energy, San Francisco Office (SAN) Oakland, California USA
米国エネルギー省、サンフランシスコオフィス(SAN)カリフォルニアオークランド(米国)
National Laboratories
国家の研究所
NASA Ames Research Center (AMES, FIX-WEST) Mountain View, California USA
米航空宇宙局エイムズ研究所(エームズ、フィックス西)カリフォルニアマウンテンビュー(米国)
Argonne National Laboratory (ANL) Argonne, Illinois USA
アルゴンヌ国立研究所(ANL)アルゴンヌ、イリノイ米国
Brookhaven National Laboratory (BNL) Upton, New York USA
ブルックヘイブン国立研究所(BNL)ニューヨークアプトン(米国)
Continuous Electron Beam Accelerator Facility (CEBAF) Newport News, Virginia USA
連続した電子ビーム加速器施設(CEBAF)ヴァージニアニューポートニューズ(米国)
Fermi National Accelerator Laboratory (FNAL) Batavia, Illinois USA
フェルミ国立加速研究所(FNAL)イリノイバタビア(米国)
Lawrence Berkeley Laboratory (LBL) Berkeley, California USA
ローレンスバークレイ研究所(LBL)カリフォルニアバークレー(米国)
Lawrence Livermore National Laboratory (LLNL) Livermore, California USA
ローレンス・リバモア国立研究所(LLNL)カリフォルニアリバーモア(米国)
Los Alamos National Laboratory (LANL) Los Alamos, New Mexico USA
ロスアラモス国立研究所(LANL)ニューメキシコロスアラモス(米国)
Oak Ridge National Laboratory (ORNL) Oak Ridge, Tennessee USA
国立オークリッジ研究所(ORNL)テネシーオークリッジ(米国)
ESCC X.500/X.400 Task Force [Page 68] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[68ページ]RFC1330X.500とX.400プラン
Pacific Northwest Laboratory (PNL) Richland, Washington USA
パシフィックノースウェスト研究所(PNL)ワシントン・リッチランド(米国)
Princeton Plasma Physics Laboratory (PPPL) Princeton, New Jersey USA
プリンストンプラズマ物理研究所(PPPL)ニュージャージープリンストン(米国)
Sandia National Laboratory, Albuquerque (SNLA) Albuquerque, New Mexico USA
Sandiaの国家の研究所、(SNLA)アルバカーキ、アルバカーキニューメキシコ米国
Stanford Linear Accelerator Center (SLAC) Menlo Park, California USA
スタンフォード線型加速器センター(SLAC)カリフォルニアメンローパーク(米国)
Superconducting Super Collider (SSC) Dallas, Texas USA
超電導超大型粒子加速器(SSC)テキサスダラス(米国)
Universities
大学
California Institute of Technology (CIT) Pasadena, California USA
カリフォルニア工科大学(CIT)カリフォルニアパサディナ(米国)
Florida State University (FSU) Tallahassee, Florida USA
フロリダ州立大学(FSU)フロリダタラシー(米国)
Iowa State University (ISU) Ames, Iowa USA
アイオワ州立大学(ISU)のアイオワエームズ(米国)
Massachusetts Institute of Technology (MIT) Cambridge, Massachusetts USA
マサチューセッツ工科大学(MIT)マサチューセッツケンブリッジ(米国)
New York University (NYU) Upton, New York USA
ニューヨーク大学(NYU)ニューヨークアプトン(米国)
Oak Ridge Associated Universities (ORAU) Oak Ridge, Tennessee USA
オークリッジ関連大学(ORAU)テネシーオークリッジ(米国)
University of California, Los Angeles (UCLA) Westwood, California USA
カリフォルニア大学ロサンゼルス校(UCLA)カリフォルニアウエストウッド(米国)
University of Maryland (UMD, FIX-EAST) College Park, Maryland USA
メリーランド大学(UMD、フィックス東)メリーランドカレッジパーク(米国)
University of Texas, Austin (UTA) Austin, Texas USA
テキサス大、(UTA)オースチン、オースチンテキサス米国
Commercial Entities
商業実体
General Atomics (GA) San Diego, California USA
一般Atomics(ジョージア)カリフォルニアサンディエゴ(米国)
ESCC X.500/X.400 Task Force [Page 69] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[69ページ]RFC1330X.500とX.400プラン
Office of Science and Technology Information (OSTI) Oak Ridge, Tennessee USA
科学・技術課Information(OSTI)テネシーオークリッジ(米国)
Science Applications, Incorporated (SAIC) McLean, Virginia USA
科学応用、法人組織の(SAIC)マクリーン、ヴァージニア米国
Appendix F: Local Site Contacts for DOE Naming Authorities
付録F: ローカル・サイトはDOEのために命名当局に連絡します。
Below is a list of all Department of Energy GOSIP Site Authorities for OSI registration and addressing. This information was obtained from the DoE GOSIP On-Line Information System (DOE-GOIS), dated November 18, 1991.
以下に、OSI登録とアドレシングのためのすべてのエネルギー省GOSIP Site Authoritiesのリストがあります。 1991年11月18日付けのDoE GOSIP On-線情報システム(ドウ-ゴイス)からこの情報を得ました。
Marian F. Sotel Director, Information management Division U.S. Department of Energy DOE Field Office, Albuquerque
聖母マリア信仰者のF.Sotelディレクター、情報管理事業部米国エネルギー省DOE Fieldオフィス、アルバカーキ
Dennis Jensen Ames Laboratory 258H Development Ames, IA 50011-3020 (515) 294-7909
デニス・ジェンセン・エームズ・研究所の258H Developmentエームズ、アイオワ50011-3020(515)294-7909
Linda Winkler Argonne National Laboratory Argonne, IL 60439 (708) 972-7236
リンダ地上げ屋アルゴンヌ国立研究所アルゴンヌ、不-60439(708)972-7236
R. E. Kremer Manager, Resource Automation U.S. Department of Energy Bettis Atomic Power laboratory
Resource Automation米国エネルギー省ベティスAtomic Power実験室のR.E.クレーメルマネージャ
Gary Ragsdale Manager, Information Services U.S. Department of Energy Bonneville Power Administration 905 NE 11th Avenue Portland, OR 97232
ゲーリーラグズデールマネージャ、情報サービス第11米国エネルギー省ボンヌビル電力事業団905Ne Avenueポートランド、または97232
Wayne Larson Head of Data Communications Unit U.S. Department of Energy Bonneville Power Administration 905 NE 11th Avenue Portland, OR 97232
データ通信第11ユニット米国エネルギー省ボンヌビル電力事業団905Ne Avenueポートランド、または97232のウェインラーソンヘッド
ESCC X.500/X.400 Task Force [Page 70] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[70ページ]RFC1330X.500とX.400プラン
George Rabinowitz Head Distributed Computing Section Brookhaven National Laboratory Upton, New York 11973 (516) 282-7637
ジョージラビノウィッツヘッド分散コンピューティングセクションブルックヘイブン国立研究所アプトン(ニューヨーク)11973(516)282-7637
Donna A. Dyxin Communications Specialist U.S. Department of Energy DOE Field Office, Chicago 9800 South Cass Avenue Argonne, IL 60439
ドナA.Dyxinコミュニケーション専門家米国エネルギー省DOE出張所、9800年のシカゴの南キャスアベニューアルゴンヌ、不-60439
Elaine R. Liebrecht System Manager and Planning Supervisor EG&G Mound Applied Technologies P.O. Box 3000 Miamisburg, OH 45343-3000 (FTS) 774-3733 or (513) 865-3733
エレインR.リーブレヒトシステム・マネージャと計画監督EG&G土手応用技術私書箱3000マイアミズバーグ、おお、45343-3000(FTS)774-3733または(513)865-3733
Jeffrey J. Johnson Communications Supervisor EG&G Mound Applied Technologies P.O. Box 3000 Miamisburg, OH 45343-3000 (FTS) 774-4230 or (513) 865-4230
ジェフリーJ.ペニスコミュニケーションEG監督とG土手応用技術私書箱3000マイアミズバーグ、おお、45343-3000(FTS)774-4230または(513)865-4230
Paul P. Herr U.S. Department of Energy Energy Information Agency (202) 586-7318
ポールP.君米国エネルギー省エネルギー情報調査所(202)586-7318
William H. Foster U.S. Department of Energy Energy Information Agency (202) 586-6310
ウィリアムH.フォスター米国エネルギー省エネルギー情報調査所(202)586-6310
Mark O. Kaletka Data Communications Group Leader, Computing Div. Fermi National Accelerator Lab P.O. Box 500 Batavia, IL 60510 (708) 840-2965
Divを計算して、O.Kaletkaデータコミュニケーションがグループのリーダーであるとマークしてください。 フェルミ国家のアクセル研究室P.O. Box500バタビア、イリノイ60510(708)840-2965
David A. Mackler Grand Junction Project Office (FTS) 326-6412
デヴィッドA.Macklerグランドジャンクションプロジェクト・オフィス(FTS)326-6412
ESCC X.500/X.400 Task Force [Page 71] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[71ページ]RFC1330X.500とX.400プラン
Wayne L. Selfors Grand Junction Project Office (FTS) 326-6525
ウェインL.Selforsグランドジャンクションプロジェクト・オフィス(FTS)326-6525
Gerald F. Chappell Director, ITSO U.S. Department of Energy Headquarters Washington D.C., 20545 (FTS) 233-3685 or (301) 903-3685
20545(FTS)のジェラードF.チャッペルディレクター、ITSO米国エネルギー省本部ワシントンDC、233-3685または(301)903-3685
Joe Diel Supervisor, Biomathematics Group ITRI
ジョーDiel監督、生物数理学グループITRI
David H. Robinson Section Supervisor, Information Systems Allied-Signal Aerospace Company Kansas City Division P.O. Box 419159 Kansas City, MO 64141-6159 (FTS) 997-3690 or (816) 997-3690
デヴィッド・H.ロビンソンセクション監督、情報システムアライド・シグナル・エアロスペース会社カンザスシティー事業部私書箱419159カンザスシティー、MO64141-6159(FTS)997-3690または(816)997-3690
Robert M. Jensen Supervisory Engineer, Information Systems Allied-Signal Aerospace Company Kansas City Division P.O. Box 419159 Kansas City, MO 64141-6159 (FTS) 997-5538 or (816) 997-5538
ロバート・M.ジェンセン管理の技術者、情報システムアライド・シグナル・エアロスペース会社カンザスシティー事業部私書箱419159カンザスシティー、MO64141-6159(FTS)997-5538または(816)997-5538
Russell Wright Lawrence Berkeley Laboratories 1 Cyclotron Road Berkeley, CA 94720 (510) 486-6965
ラッセル・職人のローレンスのバークレー研究所1サイクロトロンRoadバークレー、カリフォルニア94720(510)486-6965
William A. Lokke Associate Director for Computation Lawrence Livermore National Lab (FTS) 532-9870 or (669) 422-9870
計算ローレンスリバーモア国家の研究室(FTS)532-9870か(669)422-9870へのウィリアムA.Lokke次長
Philip Wood/Glenn Michel Los Alamos National Laboratory Los Alamos, NM 87545 (FTS) 843-1845 or (FTS) 843-2598
フィリップ・木/グレン・ミシェル・ロスアラモス国立研究所ロスアラモス、87545(FTS)のニューメキシコ843-1845か(FTS)843-2598
ESCC X.500/X.400 Task Force [Page 72] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[72ページ]RFC1330X.500とX.400プラン
Robert Bruen MIT Laboratory for Nuclear Science Computer Facilities Manager Massachusetts Institute of Tech. Cambridge, MA
コンピューター施設マネージャマサチューセッツが設ける技術者の原子物理学のためのロバートBruen MIT研究所。 ケンブリッジ(MA)
Mark Cerullo Morgantown Energy Technology Center (FTS) 923-4345
マークCerulloモーガンタウンエネルギー技術センター(FTS)923-4345
Hank Latham NVRSN (FTS) 575-7646
ハンクレイサムNVRSN(FTS)575-7646
Bill Morrison Network Specialist Bechtel Petroleum Operations, Inc Naval Petroleum Reserves California P.O. Box 127 Tupman, CA 93276 (FTS) 797-6933 or (805) 763-6933
ビルのモリソンのネットワークスペシャリストBechtel石油操作、Incの海軍の石油は(805) 797-6933か763-6933に、カリフォルニア カリフォルニア私書箱127Tupman、93276(FTS)を予約します。
Mary Ann Jones DOE Field Office, Nevada
メアリアンジョーンズDOE出張所、ネバダ
Bill Freberg Computer Sciences Corporation DOE Field Office, Nevada
ビルFrebergコンピューターサイエンシズ社のDOE出張所、ネバダ
Roger Hardwick Project Director Roy F. Weston OCRWM 3885 S. Decatur Blvd. Las Vegas, NV 89103 (702) 873-6200
ロジャーハードウィックプロジェクト・ディレクタロイF.ウェストンOCRWM3885秒間ディケーターBlvd. ラスベガス、ネバダ89103(702)873-6200
John Gandi U.S. Department of Energy OCRWM 101 Convention Ctr Phase II Complex, Suite 202 Las Vegas, NV 89109 (702) 794-7954
ジョンGandi米国エネルギー省OCRWM101コンベンションCtrフェーズIIの敷地、スイート202ラスベガス(ネバダ)89109(702)794-7954
Benny Goodman U.S. Department of Energy OSTI
ベニーグッドマン米国エネルギー省OSTI
ESCC X.500/X.400 Task Force [Page 73] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[73ページ]RFC1330X.500とX.400プラン
Raymond F. Cook U.S. Department of Energy OSTI
レイモンドF.クック米国エネルギー省OSTI
D. M. Turnpin Martin Marietta Energy Systems, Inc Oak Ridge P.O. Box 2009 Oak Ridge, TN 37831-8227 (FTS) 626-8848 or (615) 576-8848
D.M.Turnpinマーチンマリエッタエネルギー・システム、Incオークリッジ私書箱2009オークリッジ、テネシー37831-8227(FTS)626-8848または(615)576-8848
T. E. Birchfield Supervisor, Electronic Informations Delivery Sect. Martin Marietta Energy Systems, Inc Oak Ridge P.O. Box 2008 Oak Ridge, TN 37831-6283 (FTS) 624-4635 or (615) 574-4635
電子情報配送セクトのT.E.Birchfield監督。 マーチンマリエッタエネルギー・システム、IncオークリッジP.O. Box2008オークリッジ、テネシー37831-6283(FTS)624-4635または(615)574-4635
Bobby Brumley TRESP Associates DOE Field Office, Oak Ridge
ボビーBrumley TRESPはDOE出張所、オークリッジを関連づけます。
Mike Letterman TRESP Associates DOE Field Office, Oak Ridge
マイク学生スポーツの優秀選手TRESPはDOE出張所、オークリッジを関連づけます。
S. Dean Carpenter Department Head, Communications Mason and Hanger Pantex Plant
S.ディーン大工部のヘッド、メイスンとハンガパンテックスが植えるコミュニケーション
Wayne C. Phillips Section Head, Internal Communications Mason and Hanger Pantex Plant
ウェインC.フィリップスセクションヘッド、メイスンとハンガパンテックスが植える内部のコミュニケーション
A. J. Lelekacs Sr. Networking Engineer General Electric Pinellas Plant P.O. Box 2908 Neutron Devices Department Largo, FL 34649-2908
A.J.Lelekacs Sr。 ネットワーク技術者ゼネラル・エレクトリック社ピネラス植物私書箱2908中性子装置部のラルゴ、フロリダ34649-2908
ESCC X.500/X.400 Task Force [Page 74] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[74ページ]RFC1330X.500とX.400プラン
Paul A. Funk Site Access Coordinator Princeton Plasma Physics Laboratory P.O. Box 451 Princeton, NJ 08543 (609) 243-3403
プリンストンプラズマ物理研究所P.O. Box451プリンストン、ポールA.ファンクサイトアクセスコーディネータニュージャージー08543(609)243-3403
John Murphy Branch Chief, Information and Communication Mgmt U.S. Department of Energy DOE Field Office, Richland P.O. Box 550 Richland, WA 99352 (FTS) 444-7543 or (509) 376-7543
ジョンマーフィー支店長か情報とコミュニケーション管理米国エネルギー省DOE出張所か、リッチランド私書箱550リッチランドか、ワシントン99352(FTS)444-7543か(509)376-7543
Mike Schmidt Telecom & Network Services IRM Westinghouse Hanford Company DOE Field Office, Richland P.O. Box 1970 Richland, WA 99352 (FTS) 444-7739 or (509) 376-7739
マイク・シュミットテレコムとネットワーク・サービスIRMウェスチングハウスハンフォード社のDOE出張所、リッチランド私書箱1970リッチランド、ワシントン99352(FTS)444-7739または(509)376-7739
Dwayne Ramsey Information Resources Management Division U.S. Department of Energy DOE Field Office, San Francisco (FTS) 536-4302
ドウェインラムゼイ情報資源管理課米国エネルギー省DOE出張所、サンフランシスコ(FTS)536-4302
W. F. Mason Central Computing Systems Manager Sandia National Laboratories - AL P.O. Box 5800 Albuquerque, NM 87185 (FTS) 845-8059 or (505) 845-8059
W.のF.の石工の中央のコンピューティング・システムマネージャサンディア国立研究所--私書箱5800アルバカーキ、87185(FTS)のALニューメキシコ845-8059か(505)845-8059
Harry R. Holden U.S. Department of Energy DOE Field Office, Savannah River P.O. Box A Aiken, SC 29802 (FTS) 239-1118 or (803) 725-1118
ハリーR.ホールデン米国エネルギー省DOE出張所、サヴァナ川私書箱エーケン(サウスカロライナ)29802(FTS)239-1118または(803)725-1118
ESCC X.500/X.400 Task Force [Page 75] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[75ページ]RFC1330X.500とX.400プラン
Reggie Peagler Network Security Officer Savannah River Site Building 773-51A Aiken, SC 29808 (FTS) 239-3418 or (803) 557-3418
773-51 エーケンを造るレジーPeaglerネットワークガードマンサヴァナ川サイト、Sc29808(FTS)239-3418または(803)557-3418
Wade A. Gaines Acting ADP Manager U.S. Department of Energy Southeastern Power Administration Samuel Elbert Building Elberton, GA 30635
ビルElberton、A.ゲーンズ芝居ADPマネージャ米国エネルギー省南西部電力管理事業団サミュエル・エルバートジョージア 30635を歩いて渡ってください。
Paul Richard Southwestern Power Administration (FTS) 745-7482
ポールリチャード南西地域電力管理事業団(FTS)745-7482
Dr. R. Les Cottrell Assistant Director, SLAC Computer Services Stanford Linear Accelerator Center P.O. Box 4349 Stanford, CA 94309
R.レス・コットレル博士の助監督、SLACコンピュータはカリフォルニア スタンフォード線型加速器センターP.O. Box4349スタンフォード、94309を修理します。
John Lucero Systems Analyst, Management Systems Westinghouse Electric Corporation Waste Isolation Pilot Plant P.O. Box 2078 Carlsbad, NM 88221 (FTS) 571-8459 or (505) 887-8459
ウェスティングハウス・エレクトリック核廃棄物隔離試験施設私書箱2078カールスバッド、Systemsニューメキシコ ジョンLucero Systems Analyst、管理88221(FTS)571-8459か(505)887-8459
Lawrence Bluhm Sr. Systems Analyst, Management Systems Westinghouse Electric Corporation Waste Isolation Pilot Plant P.O. Box 2078 Carlsbad, NM 88221 (FTS) 571-8459 or (505) 887-8459
ローレンスBluhm Sr。 ウェスティングハウス・エレクトリック核廃棄物隔離試験施設私書箱2078カールスバッド、マネージメントSystemsニューメキシコ システム分析者、88221(FTS)571-8459か(505)887-8459
Ben Sandoval Western Area Power Administration (FTS) 327-7470
ベンサンドバル西部地域電力事業団(FTS)327-7470
John Sewell Western Area Power Administration (FTS) 327-7407
ジョンシュウェル西部地域電力事業団(FTS)327-7407
ESCC X.500/X.400 Task Force [Page 76] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[76ページ]RFC1330X.500とX.400プラン
Appendix G: Recommended Reading
付録G: お勧めの読書
RFCs (Request For Comments)
RFCs(コメントを求める要求)
The following RFCs may be obtained from the ESnet Information Server. They are stored in the directory [ANONYMOUS.RFCS]. They may be retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy (ESNIC::, 41.174).
ESnet情報Serverから以下のRFCsを入手するかもしれません。ディレクトリ[ANONYMOUS.RFCS]に彼らを格納します。 それらが公開FTPで検索されるかもしれない、(128.55の.32のnic.es.net、.3)またはDECnetコピー、(ESNIC:、:、41.174)
RFC1328 X.400 1988 to 1984 downgrading. Hardcastle-Kille, S.E. 1992
May; 5 p. (Format: TXT=10006 bytes)
RFC1328 X.400 1988年から1984格下げ。 Hardcastle-Kille、1992年の東南5月。 5 p。 (形式: TXT=10006バイト)
RFC1327 Mapping Between X.400 (1988) /ISO 10021 and RFC 822.
Hardcastle-Kille, S.E. 1992 May; 113 p. (Format: TXT=228598 bytes)
X.400(1988)/ISO10021とRFC822の間のRFC1327マッピング。 Hardcastle-Kille、1992年の東南5月。 113 p。 (形式: TXT=228598バイト)
RFC1309 Technical overview of directory services using the X.500
protocol. Weider, C.; Reynolds, J.K.; Heker, S. 1992 March; 4 p.
(Format: TXT=35694 bytes)
X.500プロトコルを使用する電話番号案内のRFC1309 Technical概観。 ワイダー、C.。 レイノルズ、J.K.。 Heker、S.1992行進。 4 p。 (形式: TXT=35694バイト)
RFC1308 Executive Introduction to Directory Services Using the X.500
Protocol. Weider, C.; Reynolds, J.K. 1992 March; 4 p. (Format:
TXT=9392 bytes)
X.500プロトコルを使用するディレクトリサービスへのRFC1308幹部社員序論。 ワイダー、C.。 レイノルズ、J.K.1992行進。 4 p。 (形式: TXT=9392バイト)
RFC1295 North American Directory Forum. User bill of rights for
entries and listing in the public directory. 1992 January; 2 p.
(Format: TXT=3502 bytes)
RFC1295の北米のディレクトリフォーラム。 エントリーへのユーザ人民の基本的人権に関する宣言と公共のディレクトリのリスト。 1992年の1月。 2 p。 (形式: TXT=3502バイト)
RFC1292 Lang, R.; Wright, R. Catalog of Available X.500
Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes)
RFC1292ラング、R.。 ライト、利用可能なX.500実現のR.カタログ。 1991年の12月。 103 p。 (形式: TXT=129468バイト)
RFC1279 Hardcastle-Kille, S.E. X.500 and domains. 1991 November; 13
p. (Format: TXT=26669, PS=170029 bytes)
RFC1279 Hardcastle-Kille、S.E. X.500、およびドメイン。 1991年の11月。 13 p。 (形式: TXT=26669、PS=170029バイト)
RFC1278 Hardcastle-Kille, S.E. String encoding of presentation
address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes)
RFC1278 Hardcastle-Kille、プレゼンテーションアドレスの東南Stringコード化。 1991年の11月。 5 p。 (形式: TXT=10256、PS=128696バイト)
RFC1277 Hardcastle-Kille, S.E. Encoding network addresses to support
operations over non-OSI lower layers. 1991 November; 10 p.
(Format: TXT=22254, PS=176169 bytes)
RFC1277 Hardcastle-Kille、東南Encodingは非OSIの低級層の上の操作を支持するためにアドレスをネットワークでつなぎます。 1991年の11月。 10 p。 (形式: TXT=22254、PS=176169バイト)
RFC1276 Hardcastle-Kille, S.E. Replication and distributed operations
extensions to provide an Internet directory using X.500. 1991
November; 17 p. (Format: TXT=33731, PS=217170 bytes)
X.500を使用することでインターネットディレクトリを提供するRFC1276 Hardcastle-Kille、東南Replication、および分配された操作拡大。 1991年の11月。 17 p。 (形式: TXT=33731、PS=217170バイト)
RFC1275 Hardcastle-Kille, S.E. Replication requirements to provide an
Internet directory using X.500. 1991 November; 2 p. (Format:
TXT=4616, PS=83736 bytes)
RFC1275 Hardcastle-Kille、X.500を使用することでインターネットディレクトリを提供するという東南Replication要件。 1991年の11月。 2 p。 (形式: TXT=4616、PS=83736バイト)
ESCC X.500/X.400 Task Force [Page 77] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[77ページ]RFC1330X.500とX.400プラン
RFC1274 Kille, S.E.; Barker, P. COSINE and Internet X.500 schema. 1991
November; 60 p. (Format: TXT=92827 bytes)
RFC1274 Kille、東南。 バーカー、P. COSINE、およびインターネットX.500図式。 1991年の11月。 60 p。 (形式: TXT=92827バイト)
RFC1255 North American Directory Forum. Naming scheme for c=US. 1991
September; 25 p. (Format: TXT=53783 bytes) (Obsoletes RFC 1218)
RFC1255の北米のディレクトリフォーラム。 cの計画を命名するのは米国と等しいです。 1991年の9月。 25 p。 (形式: TXT=53783バイト) (RFC1218を時代遅れにします)
RFC1249 Howes, T.; Smith, M.; Beecher, B. DIXIE protocol
specification. 1991 August; 10 p. (Format: TXT=20693 bytes)
RFC1249ハウズ、T.。 スミス、M.。 ビーチャー、B.デキシープロトコル仕様。 1991年の8月。 10 p。 (形式: TXT=20693バイト)
RFC1202 Rose, M.T. Directory Assistance service. 1991 February; 11 p.
(Format: TXT=21645 bytes)
RFC1202ローズ、M.T.ディレクトリAssistanceサービス。 1991年の2月。 11 p。 (形式: TXT=21645バイト)
RFC1006 Rose, M.T.; Cass, D.E. ISO transport services on top of the
TCP: Version 3. 1987 May; 17 p. (Format: TXT=31935 bytes)
RFC1006ローズ、M.T.。 キャス、TCPの上のD. E. ISO輸送サービス: バージョン3。 1987はそうするかもしれません。 17 p。 (形式: TXT=31935バイト)
Non Published Working Notes
非発行された働く注意
"A String Representation of Distinguished Names", S.E. Hardcastle-Kille,
01/30/1992.
「分類名のストリング表現」、東南Hardcastle-Kille、01/30/1992。
The OSI Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in
ASN.1. When a distinguished name is communicated between to users
not using a directory protocol (e.g., in a mail message), there is
a need to have a user-oriented string representation of
distinguished name.
OSIディレクトリは主キーとしてディレクトリでエントリーに分類名を使用します。 顕著なNamesはASN.1でコード化されます。 分類名でディレクトリプロトコル(例えば、メール・メッセージの)を使用しないことでユーザに交信するとき、分類名の利用者志向ストリング表現を持つ必要があります。
"An Access Control Approach for Searching and Listing", S.E.
Hardcastle-Kille, T. Howes, 09/23/1991.
「探すのとリストのためのアクセス管理アプローチ」、東南Hardcastle-Kille、T.ハウズ、09/23/1991。
This memo defines an extended ACL (Access Control List) mechanism
for the OSI Directory. It is intended to meet strong operational
requirements to restrict searching and listing externally, while
allowing much more freedom within an organization. In particular,
this mechanism makes it possible to restrict searches to certain
sets of attributes, and to prevent "trawling": the disclosure of
large organizational data or structure information by repeated
searches or lists. This capability is necessary for organizations
that want to hide their internal structure, or to prevent dumping
of their entire database. This memo describes functionality
beyond, but compatible with, that expected in the 1992 X.500
standard.
このメモはOSIディレクトリのために拡張ACL(アクセスControl List)メカニズムを定義します。 組織の中のずっと多くの自由を許容している間、探して、外部的に記載しながら、それが制限する強い操作上の必要条件を満たすことを意図します。 特に、このメカニズムで検索をあるセットの属性に制限して、「引くこと」を防ぐのが可能になります: 繰り返された検索かリストによる大きい組織的なデータか構造情報の公開。 この能力がそれらの内部の構造を隠したいか、またはそれらの全体のデータベースをどさっと落とすのを防ぎたがっている組織に、必要です。 このメモは向こうの機能性について説明しますが、互換性があるので、それは1992年に標準でX.500を予想しました。
"Building an Internet Directory using X.500", S. Kille, 01/07/1991.
「X.500を使用することでインターネットディレクトリを築き上げます」、S.Kille、01/07/1991。
The IETF has established a Working Group on OSI Directory Services.
A major component of the initial work of this group is to establish
a technical framework for establishing a Directory Service on the
IETFはOSIディレクトリサービスのときに作業部会を設立しました。 このグループの初期の仕事の主要なコンポーネントはディレクトリサービスを確立するのに、オンな技術的な枠組みを確立することです。
ESCC X.500/X.400 Task Force [Page 78] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[78ページ]RFC1330X.500とX.400プラン
Internet, making use of the X.500 protocols and services. This
document summarizes the strategy established by the Working Group,
and describes a number of RFCs which will be written in order to
establish the technical framework.
X.500プロトコルとサービスを利用するインターネット。 このドキュメントは、作業部会によって確立された戦略をまとめて、技術的な枠組みを確立するために書かれている多くのRFCsについて説明します。
"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)",
S.E. Hardcastle-Kille, 07/09/1991.
「コサインとインターネットのためのディレクトリ要件は(OSI-DS18)を操縦する」東南Hardcastle-Kille、07/09/1991。
This document specifies operational requirements for DUAs and DSAs
in the Internet and COSINE communities. This document summarizes
conformance requirements. In most cases, technical detail is
handled by reference to other documents. This document refers to
core directory infrastructure. Each application using the directory
may impose additional requirements.
このドキュメントはインターネットとCOSINE共同体でDUAsとDSAsのための操作上の要件を指定します。 このドキュメントは順応要件をまとめます。 多くの場合、技術的な詳細は他のドキュメントの参照で扱われます。 このドキュメントはコアディレクトリインフラストラクチャを示します。 ディレクトリを使用する各アプリケーションは追加要件を課すかもしれません。
"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992.
「DSA命名」、東南Hardcastle-Kille、01/24/1992。
This document describes a few problems with DSA Naming as currently
deployed in pilot exercises, and suggests a new approach. This
approach is suggested for use in the Internet Directory Pilot,
which overcomes a number of existing problems, and is an important
component for the next stage in increase of scale.
このドキュメントは、DSA Namingに関するいくつかの問題が現在パイロット運動で配備されていると記述して、新しいアプローチを示します。 このアプローチは、多くの既存の問題を克服するインターネットディレクトリPilotにおける使用のために示されて、スケールの増加における次のステージへの重要なコンポーネントです。
"Handling QOS (Quality of service) in the Directory", S.E. Kille,
08/29/1991.
「ディレクトリにおける取り扱いQOS(サービスの質)」、東南Kille、08/29/1991。
This document describes a mechanism for specifying the Quality of
Service for DSA Operations and Data in the Internet Pilot Directory
Service "Building and internet directory using X.500".
このドキュメントは、インターネットPilotディレクトリサービス「ビルとインターネットディレクトリ使用X.500」でDSA OperationsとDataにServiceのQualityを指定するためにメカニズムについて説明します。
"Interim Directory Tree Structure for Network Infrastructure
Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991.
「ネットワークインフラ情報のための当座のディレクトリツリー構造」、クリス・ワイダーは06/14/1991にKnopper、ルース・ラングをマークします。
As work progresses on incorporating WHOIS and Network
Infrastructure information into X.500, we thought it would be
useful to document the current DIT structure for this information,
along with some thoughts on future expansion and organization of
this subtree of the DIT. The first section of this document
describes the current structure, the second section the possible
expansion of the structure.
WHOISとNetwork Infrastructure情報をX.500に組み入れるとき仕事が進歩をするので、私たちは、この情報のための現在のDIT構造を記録するのがDITのこの下位木の今後の拡大と組織に関するいくつかの考えと共に役に立つと思いました。 このドキュメントの最初のセクションは現在の構造について説明して、第2セクションは構造の可能な拡大です。
"Interim Schema for Network Infrastructure Information in X.500 New
name: Encoding Network Addresses to support operation ov", Chris
Weider, Mark Knopper, 06/14/1991.
「X.500 NewのNetwork Infrastructure情報のための当座のSchemaは以下を命名します」 「操作ovを支持するためにNetwork Addressesをコード化します」、クリス・ワイダー、マークKnopper、06/14/1991。
As the OSI Directory progresses into an operational structure which
is being increasingly used as a primary resource for Directory
Information, it was perceived that having the Internet Site
OSIディレクトリが操作上の構造にどれを進行するかので、ますますディレクトリ情報のための第一のリソースとして使用されていて、それがそんなに持っていると知覚されたということであることはインターネットSiteですか?
ESCC X.500/X.400 Task Force [Page 79] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[79ページ]RFC1330X.500とX.400プラン
Contacts and some limited network information in the Directory
would be immediately useful and would also provide the preliminary
framework for some distributed NIC functions. This paper describes
the interim schema used to contain this information.
接触とディレクトリにおける何らかの限られたネットワーク情報が、すぐに、役に立って、また、いくつかの分散NIC機能に予備の枠組みを提供するでしょう。 この論文はこの情報を含むのに使用される当座の図式について説明します。
"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille,
01/30/1992.
「ディレクトリのパイロットへの命名ガイドライン」、P.バーカー、東南Kille、01/30/1992。
Deployment of a Directory will benefit from following certain
guidelines. This document defines a number of naming guidelines.
Alignment to these guidelines will be recommended for national
pilots.
ディレクトリの展開は次のあるガイドラインの利益を得るでしょう。 このドキュメントは多くの命名ガイドラインを定義します。 これらのガイドラインへの整列は国家のパイロットのために推薦されるでしょう。
"OSI NSAP Address Format For Use In The Internet", R Colella, R Callon,
02/13/1991.
「インターネットでの使用のためのオウシNSAP Address Format」、R Colella、R Callon、02/13/1991。
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI, it is necessary to address network
layer entities and network service users. The basic principles of
OSI Network Layer addressing and Network Service Access Points
(NSAPs) are defined in Addendum 2 to the OSI Network service
definition. This document recommends a structure for the Domain
Specific Part of NSAP addresses for use in the Internet that is
consistent with these principles.
インターネットはOSIを含んでいるマルチプロトコル環境に近づいています。 OSIを支持するために、ネットワーク層実体とネットワークサービス利用者に演説するのが必要です。 OSI Network LayerアドレシングとNetwork Service Access Points(NSAPs)の基本原理はAddendum2でOSI Networkサービス定義と定義されます。 このドキュメントはこれらの原則と一致したインターネットでの使用のためのNSAPアドレスのDomain Specific Partのために構造を推薦します。
"Representing Public Archives in the Directory", Wengyik Yeong,
12/04/1991.
「ディレクトリにおける公共のアーカイブを表します」、Wengyik Yeong、12/04/1991。
The proliferation of publicly accessible archives in the Internet
has created an ever-widening gap between the fact of the existence
of such archives, and knowledge about the existence and contents of
these archives in the user community. Related to this problem is
the problem of also providing users with the necessary information
on the mechanisms available to retrieve such archives. In order
for the Internet user community to better avail themselves of this
class of resources, there is a need for these gaps in knowledge to
be bridged.
インターネットでの公的にアクセス可能なアーカイブの増殖はユーザーコミュニティでそのようなアーカイブの存在の事実と、これらのアーカイブの存在とコンテンツに関する知識の絶えず拡大する格差を作成しました。 この問題に関連されるのは、また、そのようなアーカイブを検索するために利用可能なメカニズムに関する必要事項をユーザに提供するという問題です。 インターネットユーザーコミュニティがこのクラスに関するリソースを自分たちによりよく利用するように、知識のこれらのギャップが橋を架けられる必要があります。
"Schema for Information Resource Description in X.500", Chris Weider,
06/14/1991.
「X.500の情報源記述のための図式」、クリス・ワイダー、06/14/1991。
The authors are interested in allowing distributed access and
updating for Information Resource Description information to users
of the Internet. This paper discusses the schema used to hold the
Information Resource Description information. The new attributes
are taken from the US-MARC fields, and subfields, with the mapping
described in the text.
作者は、インターネットのユーザに分配されたアクセスを許して、情報源記述のために情報をアップデートしたがっています。 この論文は情報源記述情報を保持するのに使用される図式について議論します。 米国-マーク分野、およびテキストでマッピングで説明された部分体から新しい属性を取ります。
ESCC X.500/X.400 Task Force [Page 80] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[80ページ]RFC1330X.500とX.400プラン
"Schema for NIC Profile Information in X.500", Chris Weider, Mark
Knopper, 06/14/1991.
「X.500のNICプロフィール情報のための図式」、クリス・ワイダーはKnopper、06/14/1991をマークします。
The authors of this document, in conjunction with the chairs of the
IETF Network Information Services Infrastructure (NISI) group,
would like to implement a Directory of Network Information Centers,
or NICs. This will enable NICs to find each other easily, will
allow users with access to a DSA to find out where NICs are, and
will in general facilitate the distribution of information about
the Internet and some of its infrastructure. This document
proposes a set of standard schema for this information.
IETF Network情報Services Infrastructure(NISI)グループの教授の職に関連して、このドキュメントの作者はNetwork情報のセンターズ、またはNICsのディレクトリを実行したがっています。 これは、NICsが容易に互いを見つけるのを可能にして、DSAへのアクセスのユーザが、NICsがどこにあるかを見つけるのを許容して、一般に、インターネットとインフラストラクチャのいくつかに関して情報の流通を容易にするでしょう。 このドキュメントはこの情報のために1セットの標準の図式を提案します。
"Using the OSI Directory to Achieve User Friendly Naming", S. Kille,
01/30/1992.
「ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用します」、S.Kille、01/30/1992。
The OSI Directory has user friendly naming as a goal. A simple
minded usage of the directory does not achieve this. Two aspects
not achieved are: 1) A user oriented notation and 2)
Guessability. This proposal sets out some conventions for
representing names in a friendly manner, and shows how this can be
used to achieve really friendly naming. This then leads to a
specification of a standard format for representing names, and to
procedures to resolve them. This leads to a specification which
allows directory names to be communicated between humans. The
format in this specification is identical to that defined in the
reference of "A String Representation of Distinguished Name", and
it is intended that these specifications are compatible.
OSIディレクトリには、目標としてユーザフレンドリーな命名があります。 ディレクトリの簡単な気にされた使用法はこれを実現しません。 獲得されなかった2つの局面は以下の通りです。 1) ユーザは記法と2を)適応させました。 Guessability。 この提案は、好意的な態度で名前を表すためにいくつかのコンベンションを出して、本当に好意的な命名を達成するのにどうこれを使用できるかを示しています。 そして、これは、それらを決議するために名前を表して、手順への標準書式の仕様に通じます。 これはディレクトリ名が人間の間で伝えられるのを許容する仕様に通じます。 この仕様による形式は「分類名のストリング表現」の参照で定義されたそれと同じです、そして、これらの仕様は互換性があることを意図します。
"Requirements for X.400 Management Domains (MDs) Operating in the Global
Research and Development X.400 Service", R. Hagens, 11/12/1991.
「X.400管理ドメイン(MDs)のためのグローバルな研究開発X.400サービスで作動する要件」、R.Hagens、11/12/1991。
This document specifies a set of minimal operational
requirements that must be implemented by all Management Domains
(MDs) in the Global R&D X.400 Service. This document defines
the core operational requirements; in some cases, technical
detail is handled by reference to other documents. The Global
R&D X.400 Service is defined as all organizations which meet the
requirements described in this document.
このドキュメントはGlobal研究開発X.400 ServiceですべてのManagement Domainsが実行しなければならない1セットの最小量の操作上の要件(MDs)を指定します。 このドキュメントはコアの操作上の要件を定義します。 いくつかの場合、技術的な詳細は他のドキュメントの参照で扱われます。 Global研究開発X.400 Serviceは本書では説明された必要条件を満たすすべての組織と定義されます。
"Routing Coordination for X.400 MHS Services within a
Multiprotocol/Multinetwork Environment", U. Eppenberger,
10/25/1992.
「Multiprotocol/Multinetwork環境の中のX.400 MHSサービスのためのルート設定コーディネート」、U.Eppenberger、10/25/1992。
The X.400 addresses do start to appear on business cards. The
different MHS service providers are not well interconnected and
coordinated which makes it a very hard job for the MHS managers to
know where to route all the new addresses. A big number of X.400
implementations support different lower layer stacks. Taking into
X.400アドレスは名刺の上に載り始めます。 異なったMHSサービスプロバイダーは、よくインタコネクトされて、調整されません(MHSマネージャが、すべての新しいアドレスをどこに発送するかを知るようにそれを非常に困難な仕事にします)。 大きい数のX.400実現が異なった下層スタックを支えます。 魅力的
ESCC X.500/X.400 Task Force [Page 81] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[81ページ]RFC1330X.500とX.400プラン
account the variety of existing large transport networks, there is
now the chance of implementing a worldwide message handling service
using the same electronic mail standard and therefore without the
need of gateways with service reduction and without the restriction
to a single common transport network. This document proposes how
messages can travel over different networks by using multi stack
MTAs as relays. Document formats and coordination procedures bridge
the gap until an X.500 directory service is ready to store the
needed connectivity and routing information.
既存の大きい転送ネットワークのバラエティーを説明してください、ただ一つの一般的な転送ネットワークに現在、同じ電子メール規格を使用することで世界的なメッセージ通信処理サービスを実行するという見込みがあって、したがって、サービス減少があるゲートウェイの必要性なしで制限なしで。 このドキュメントはメッセージが異なったネットワークの上をリレーとしてマルチスタックMTAsを使用することによってどう移動できるかを提案します。 X.500電話番号案内が必要な接続性とルーティング情報を格納する準備ができるまで、ドキュメント・フォーマットと協力手順は間隙を塞ぎます。
International Standards Documents
世界規格ドキュメント
International Consultative Committee for Telephone and Telegraph. Open
Systems Interconnection - The Directory. X.500 Series
Recommendations. December, 1988.
電信電話のための国際諮問委員会。 オープン・システム・インターコネクション--ディレクトリ。 X.500シリーズ勧告。 1988年12月。
(also published as)
(また、発行されます)
ISO/IEC. Information Technology - Open Systems Interconnection - The
Directory. International Standard 9594. 1989.
ISO/IEC。 情報技術--オープン・システム・インターコネクション--ディレクトリ。 国際規格9594。 1989.
International Consultative Committee for Telephone and Telegraph. Data
Communication Networks - Message Handling Systems. X.400 Series
Recommendations. Geneva 1985.
電信電話のための国際諮問委員会。 データ通信ネットワーク--メッセージハンドリングシステムX.400シリーズ推薦。 ジュネーブ1985。
International Consultative Committee for Telephone and Telegraph. Data
Communication Networks - Message Handling Systems. X.400 Series
Recommendations. Melbourne, 1988.
電信電話のための国際諮問委員会。 データ通信ネットワーク--メッセージハンドリングシステムX.400シリーズ推薦。 メルボルン、1988。
NIST Documents
(National Institute of Standards and Technology Documents)
NISTドキュメント(米国商務省標準技術局ドキュメント)
The following documents can be retrieved from the ESnet Information Server in directory [ANONYMOUS.NIST].
ディレクトリ[ANONYMOUS.NIST]のESnet情報Serverから以下のドキュメントを検索できます。
Government Open Systems Interconnection Profile (GOSIP) Version 1,
National Institute of Standards and Technology, Federal Information
Processing Standards Publication #146, August, 1988.
政府オープンシステムインタコネクトは(GOSIP)バージョン1の輪郭を描きます、米国商務省標準技術局、連邦政府の情報処理規格公表#146、1988年8月。
Government Open Systems Interconnection Profile (GOSIP) Version 2,
National Institute of Standards and Technology, October, 1990.
政府オープンシステムインタコネクトは1990年10月に(GOSIP)バージョン2、米国商務省標準技術局の輪郭を描きます。
DOE Documents
DOEドキュメント
The following documents prepared by the DOE GOSIP Migration Working Group can be retrieved from the ESnet Information Server in directory [ANONYMOUS.DOE-GOSIP].
ディレクトリ[ANONYMOUS.DOE-GOSIP]のESnet情報ServerからドウGOSIP Migration作業部会によって準備された以下のドキュメントは検索できます。
ESCC X.500/X.400 Task Force [Page 82] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[82ページ]RFC1330X.500とX.400プラン
U.S. Department of Energy. Government Open Systems Interconnection
Profile. Transition Strategy. DOE GOSIP Document # GW-ST-008.
November, 1990.
米国エネルギー省。 政府開放型システム間相互接続プロフィール。 変遷戦略。 ドウGOSIPが#、を記録する、GW、008番目 1990年11月。
U.S. Department of Energy. Government Open Systems Interconnection
Profile. Transition Plan. DOE GOSIP Document # GW_PN_005.
November, 1990.
米国エネルギー省。 政府開放型システム間相互接続プロフィール。 変遷プラン。 ドウGOSIPは#GW_PN_005を記録します。 1990年11月。
U.S. Department of Energy. Government Open Systems Interconnection
Profile. Procedures and Guidelines. DOE GOSIP Document # GW-PR-
007. April, 1991.
米国エネルギー省。 政府開放型システム間相互接続プロフィール。 手順とガイドライン。 ドウGOSIPは#GW PR-007を記録します。 1991年4月。
IETF Working Groups
IETFワーキンググループ
Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been working in in X.400 and X.500. Minutes of meetings, descriptions of the working groups' charters and goals, information about mailing lists, and other pertinent documents can be retrieved from the ESnet Information Server in the directories [ANONYMOUS.IETF.OSIDS], [ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS].
IETFワーキンググループ、OSI X.400、OSI-DS、およびMHS-DSがX.400とX.500で働いている3。 ディレクトリのESnet情報Server[ANONYMOUS.IETF.OSIDS]、[ANONYMOUS.IETF.OSIX400]、および[ANONYMOUS.IETF.MHSMS]からミーティングの議事録、ワーキンググループの特許の記述、目標、メーリングリストの情報、および他の関連書類を検索できます。
Others
他のもの
Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO
Development Environment: User's Manual, 1991. ISODE Documentation
Set.
ジュリアン・P.アニアンズとコリン・J.ロビンス、マーシャルT.は上昇しました。 ISO開発環境: ユーザマニュアル、1991。 ISODEドキュメンテーションはセットしました。
Marshall T. Rose and Wengyik Yeong. PSI White Pages Pilot Project:
Administrator's Guide, 1991. ISODE Documentation Set.
マーシャル・T.ローズとWengyik Yeong。 ホワイトページが操縦するpsiは突出しています: 管理者用ガイド、1991。 ISODEドキュメンテーションはセットしました。
Marshall T. Rose. The Open Book: A Practical Perspective on Open
Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3.
マーシャルT.は上昇しました。 ざっくばらんな人: オープン・システム・インターコネクションの実用的な見解。 新米のホール、1990。 ISBN0-13-643016-3。
Marshall T. Rose. The Little Black Book: Mail Bonding with OSI
Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5.
マーシャルT.は上昇しました。 小さい黒い本: OSIディレクトリサービスとの接着を郵送してください。 新米のホール、1991。 ISBN0-13-683219-5。
Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory. Performance
Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation.
1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET-
DOC]QUIPU-PERF.PS
アラン・ターナーとポールGjefle、Pacficノースウェスト研究所。 オウシX.500(結び縄文字)ディレクトリサービスImplmentationの機能解析。 1992. ディレクトリ[ANONYMOUS.ESNET DOC]QUIPU-PERF.PSのnic.es.netでは、利用可能です。
Appendix H: Task Force Member Information
付録H: 特別委員会メンバー情報
Bob Aiken
U.S. Department of Energy, Office of Energy Research, Scientific
Computing Staff (now with National Science Foundation)
Email: raiken@nsf.gov
ボブエネルギー省、エーケン米国エネルギー課Research、科学計算スタッフ(現在、科学基金がある)メール: raiken@nsf.gov
ESCC X.500/X.400 Task Force [Page 83] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[83ページ]RFC1330X.500とX.400プラン
Joe Carlson
Lawrence Livermore National Laboratory
Livermore, California USA
Email: carlson@lll-winken.llnl.gov
ジョーカールソンローレンス・リバモア国立研究所カリフォルニアリバーモア(米国)はメールされます: carlson@lll-winken.llnl.gov
Les Cottrell
Stanford Linear Accelerator Center
Menlo Park, California USA
Email: cottrell@slacvm.slac.stanford.edu
レス・コットレル・スタンフォード線型加速器センターカリフォルニアメンローパーク(米国)はメールされます: cottrell@slacvm.slac.stanford.edu
Tim Doody
Fermi National Accelerator Laboratory
Batavia, Illinois USA
Email: doody@fndcd.fnal.gov
ティム・ドゥーディ・フェルミ国立加速研究所イリノイバタビア(米国)はメールされます: doody@fndcd.fnal.gov
Tony Genovese (Contributing Author)
Lawrence Livermore National Laboratory
Livermore, California USA
Email: genovese@es.net
トニーGenovese(作者を寄付する)ローレンス・リバモア国立研究所カリフォルニアリバーモア(米国)はメールされます: genovese@es.net
Arlene Getchell (Contributing Author)
Lawrence Livermore National Laboratory
Livermore, California USA
Email: getchell@es.net
アーリン・ゲッチェル(作者を寄付する)ローレンス・リバモア国立研究所カリフォルニアリバーモア(米国)はメールされます: getchell@es.net
Charles Granieri
Stanford Linear Accelerator Center
Menlo Park, California USA
Email: cxg@slacvm.slac.stanford.edu
チャールズ・Granieriスタンフォード線型加速器センターカリフォルニアメンローパーク(米国)はメールされます: cxg@slacvm.slac.stanford.edu
Kipp Kippenhan (Contributing Author)
Fermi National Accelerator Laboratory
Batavia, Illinois USA
Email: kippenhan@fnal.fnal.gov
キップKippenhan(作者を寄付する)フェルミ国立加速研究所イリノイバタビア(米国)はメールされます: kippenhan@fnal.fnal.gov
Connie Logg
Stanford Linear Accelerator Center
Menlo Park, California USA
Email: cal@slacvm.slac.stanford.edu
コニー・Loggスタンフォード線型加速器センターカリフォルニアメンローパーク(米国)はメールされます: cal@slacvm.slac.stanford.edu
Glenn Michel
Los Alamos National Laboratory
Los Alamos, New Mexico USA
Email: gym@lanl.gov
グレン・ミシェル・ロスアラモス国立研究所ニューメキシコロスアラモス(米国)はメールされます: gym@lanl.gov
Peter Mierswa
Digital Equipment Corporation USA
ピーターMierswa DEC米国
ESCC X.500/X.400 Task Force [Page 84] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[84ページ]RFC1330X.500とX.400プラン
Jean-Noel Moyne
Lawrence Berkeley Laboratory
Berkeley, California USA
Email: jnmoyne@lbl.gov
ジーン-クリスマスのMoyneローレンスバークレイ研究所カリフォルニアバークレー(米国)はメールされます: jnmoyne@lbl.gov
Kevin Oberman (Contributing Author)
Lawrence Livermore National Laboratory
Livermore, California USA
Email: oberman@icdc.llnl.gov
ケビンOberman(作者を寄付する)ローレンス・リバモア国立研究所カリフォルニアリバーモア(米国)はメールされます: oberman@icdc.llnl.gov
Dave Oran
Digital Equipment Corporation USA
デーヴオランディジタルイクイップメント社米国
Bob Segrest
Digital Equipment Corporation USA
ボブSegrest DEC米国
Tim Streater
Stanford Linear Accelerator Center
Menlo Park, California USA
Email: streater@slacvm.slac.stanford.edu
ティム・Streaterスタンフォード線型加速器センターカリフォルニアメンローパーク(米国)はメールされます: streater@slacvm.slac.stanford.edu
Allen Sturtevant (Chair, Contributing Author, Document Editor)
Lawrence Livermore National Laboratory
Livermore, California USA
Email: sturtevant@es.net
アレン・スタートバント(作者、ドキュメントエディタを寄付する議長)ローレンス・リバモア国立研究所カリフォルニアリバーモア(米国)はメールされます: sturtevant@es.net
Mike Sullenberger
Stanford Linear Accelerator Center
Menlo Park, California USA
Email: mls@scsw5.slac.stanford.edu
マイク・Sullenbergerスタンフォード線型加速器センターカリフォルニアメンローパーク(米国)はメールされます: mls@scsw5.slac.stanford.edu
Alan Turner (Contributing Author)
Pacific Northwest Laboratory
Richland, Washington USA
Email: ae_turner@pnl.gov
アラン・ターナー(作者を寄付する)・パシフィックノースウェスト研究所ワシントン・リッチランド(米国)はメールされます: ae_turner@pnl.gov
Linda Winkler (Contributing Author)
Argonne National Laboratory
Argonne, Illinois USA
Email: b32357@anlvm.ctd.anl.gov
リンダ・ウィンクラー(作者を寄付する)アルゴンヌ国立研究所Argonne、イリノイ米国メール: b32357@anlvm.ctd.anl.gov
Russ Wright (Contributing Author)
Lawrence Berkeley Laboratory
Berkeley, California USA
Email: wright@lbl.gov
ラス職人(作者を寄付する)ローレンスバークレイ研究所カリフォルニアバークレー(米国)はメールします: wright@lbl.gov
ESCC X.500/X.400 Task Force [Page 85] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[85ページ]RFC1330X.500とX.400プラン
Security Considerations
セキュリティ問題
Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this memo.
セクション2.5.1と2.7で安全保障問題について議論します。.5 この.1のメモ。
Authors' Addresses
作者のアドレス
Allen Sturtevant Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551
アレンスタートバントローレンス・リバモア国立研究所P.O. Box5509。 L-561リバーモア、カリフォルニア 94551
Phone: +1 510-422-8266 Email: sturtevant@es.net
以下に電話をしてください。 +1 510-422-8266 メールしてください: sturtevant@es.net
Tony Genovese Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551
トニーGenoveseローレンス・リバモア国立研究所P.O. Box5509。 L-561リバーモア、カリフォルニア 94551
Phone: +1 510-423-2471 Email: genovese@es.net
以下に電話をしてください。 +1 510-423-2471 メールしてください: genovese@es.net
Arlene Getchell Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551
アーリンゲッチェルローレンス・リバモア国立研究所P.O. Box5509。 L-561リバーモア、カリフォルニア 94551
Phone: +1 510-423-6349 Email: getchell@es.net
以下に電話をしてください。 +1 510-423-6349 メールしてください: getchell@es.net
H. A. Kippenhan Jr. Fermi National Accelerator Laboratory Wilson Hall 6W, MS-234 P.O. Box 500 Batavia, IL 60150
H.A.Kippenhan Jr.フェルミ国立加速研究所ウィルソンホール6W、MS-234P.O. Box500バタビア不-60150
Phone: +1 708-840-8068 Email: kippenhan@fnal.fnal.gov
以下に電話をしてください。 +1 708-840-8068 メールしてください: kippenhan@fnal.fnal.gov
ESCC X.500/X.400 Task Force [Page 86] RFC 1330 X.500 and X.400 Plans for ESnet May 1992
ESnet1992年5月のためのESCC X.500/X.400特別委員会[86ページ]RFC1330X.500とX.400プラン
Kevin Oberman Lawrence Livermore National Laboratory P.O. Box 5509; L-156 Livermore, CA 94551
ケビンObermanローレンス・リバモア国立研究所P.O. Box5509。 L-156リバーモア、カリフォルニア 94551
Phone: +1 510-422-6955 Email: oberman1@llnl.gov
以下に電話をしてください。 +1 510-422-6955 メールしてください: oberman1@llnl.gov
Alan Turner Pacific Northwest Laboratory P.O. Box 999; K7-57 Richland, WA 99352
アランターナーパシフィックノースウェスト研究所P.O. Box999。 K7-57リッチランド、ワシントン 99352
Phone: +1 509-375-6670 Email: ae_turner@pnl.gov
以下に電話をしてください。 +1 509-375-6670 メールしてください: ae_turner@pnl.gov
Linda Winkler Argonne National Laboratory 9700 South Cass Avenue Building 221 B251 Argonne, IL 60439
リンダ地上げ屋アルゴンヌ国立研究所9700の南キャスアベニュービル221B251アルゴンヌ、不-60439
Phone: +1 708-252-7236 Email: lwinkler@anl.gov
以下に電話をしてください。 +1 708-252-7236 メールしてください: lwinkler@anl.gov
Russ Wright Lawrence Berkeley Laboratory 1 Cyclotron Road MS 50B-2258 Berkeley, CA 94720
ラス・職人ローレンスバークレイ研究所1サイクロトロン道路MS50B-2258バークレー、カリフォルニア 94720
Phone: +1 510-486-6965 Email: wright@lbl.gov
以下に電話をしてください。 +1 510-486-6965 メールしてください: wright@lbl.gov
ESCC X.500/X.400 Task Force [Page 87]
ESCC X.500/X.400特別委員会[87ページ]
一覧
スポンサーリンク
