RFC1802 日本語訳

Network Working Group                                      H. Alvestrand
Request for Comments: 1802                                       UNINETT
Category: Informational                                        K. Jordan
                                                    Control Data Systems
                                                             S. Langlois
                                                   Electricite de France
                                                            J. Romaguera
                                                              NetConsult
                                                               June 1995

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 1802年のUNINETTカテゴリ: 情報のK.のS.ラングロイフランス電気学会J.Romaguera NetConsultジョーダンControlデータシステムズ1995年6月

                     Introducing Project Long Bud:
      Internet Pilot Project for the Deployment of X.500 Directory
                Information in Support of X.400 Routing

長い間プロジェクトを紹介して、芽生えてください: X.400ルート設定を支持したX.500ディレクトリ情報の展開のためのインターネット試験計画

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   The Internet X.400 community (i.e., GO-MHS) currently lacks a
   distributed mechanism providing dynamic updating and management of
   message routing information.  The IETF MHS-DS Working Group has
   specified an approach for X.400 Message Handling Systems to perform
   message routing using OSI Directory Services.  The MHS-DS approach
   has been successfully tested in a number of local environments.

インターネットX.400共同体(すなわち、GO-MHS)は現在、メッセージルーティング情報のダイナミックなアップデートと管理を提供する分配されたメカニズムを欠いています。 X.400 Message Handling Systemsがメッセージルーティングを実行するように、IETF MHS-DS作業部会はOSIディレクトリサービスを使用することでアプローチを指定しました。 MHS-DSアプローチは多くの地方の環境で首尾よくテストされました。

   This memo describes a proposed Internet Pilot Project that seeks to
   prove the MHS-DS approach on a larger scale.  The results of this
   pilot will then be used to draw up recommendations for a global
   deployment.

このメモは、より大きいスケールでMHS-DSがアプローチであると立証しようとする提案されたインターネットPilot Projectについて説明します。 そして、このパイロットの結果は、グローバルな展開のための推薦を作成するのに使用されるでしょう。

1. Background

1. バックグラウンド

   The 1988 edition of X.400 introduces, among other extensions or
   revisions, the concept of O/R Names which assumes the existence of a
   widely available Directory Service.  This Directory Service is needed
   to support several MHS operations (support for names to identify
   senders and receivers of messages in a user-friendly fashion, support
   for distribution lists, authentication of MHS components, description
   of MHS components capabilities...).

1988年のX.400の版は他の拡大か改正の中で広く利用可能なディレクトリサービスの存在を仮定するO/R Namesの概念を紹介します。 このディレクトリサービスが、いくつかのMHS操作を支持するのに必要です(送付者を特定する名前とユーザフレンドリーなファッションによるメッセージの受信機、発送先リストのサポート、MHSの認証のためにコンポーネントを支えてください、MHSコンポーネント能力の…記述)。

   The prime advantage of Directory Names, as perceived by many users,
   was to release users from the remembering of complex O/R Addresses
   for their correspondents.

多くのユーザによって知覚されるディレクトリNamesの主要な利点は彼らの通信員のために複雑なO/R Addressesを覚えているのからユーザを釈放することでした。

Alvestrand, et al            Informational                      [Page 1]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[1ページ]RFC1802Introducing Project Longバッド1995年6月

   In the MHS infrastructure, as compared to other protocols, a name by
   itself does not contain enough information to allow the Message
   Transfer Agents (MTAs) to route a message to the User Agent (UA)
   servicing this name.  The routing process is based on information
   provided by different MHS Management Domains, whether they are public
   or private.

MHSインフラストラクチャでは、他のプロトコルと比べて、それ自体で名前はこの名前を修理しながらMessage Transferエージェント(MTAs)がUserエージェント(UA)にメッセージを発送するのを許容できるくらいの情報を含んでいません。 ルーティングの過程は彼らが公共であるか、または個人的であることにかかわらず異なったMHS Management Domainsによって提供された情報に基づいています。

   An MHS community combines several administrative MHS domains among
   which agreements for cooperative routing exist:  the GO-MHS community
   is the set of MTA's taking care of X.400 mail operations on the
   Internet [RFC 1649].

MHS共同体は協力的なルーティングのための協定が存在するいくつかの管理MHSドメインを結合します: GO-MHS共同体はMTAがインターネット[RFC1649]でX.400メール操作の世話をするセットです。

   In the absence of a distributed Directory Service, an interim
   technique has been developed within the GO-MHS community to collect
   and advertise routing information.  This resulted in an experimental
   IETF protocol [RFC 1465].

分配されたディレクトリサービスがないとき、当座の技術は、ルーティング情報を集めて、広告を出すためにGO-MHS共同体の中で見いだされました。 これは実験IETFプロトコル[RFC1465]をもたらしました。

2. Rationale

2. 原理

   A number of routing problems are preventing the present Internet
   X.400 service from expanding its number of participating message
   transfer agents to a global scale.  The two most critical problems
   are:

多くのルーティング問題が、現在のインターネットX.400サービスが参加メッセージ転送エージェントの番号をグローバルなスケールに広くするのを防いでいます。 2つの最も批判的な問題は以下の通りです。

      * The present mechanism of centrally maintained and advertized
        MTA routing tables has been optimized as far as possible.
        Increasing the number of directly connected MTAs increases also
        the workload on the MHS managers.  The current solution does
        not scale.  Routing must be a fully dynamic and distributed
        process.

* 中心で維持されていて、advertized MTA経路指定テーブルの現在のメカニズムはできるだけ最適化されました。 また、直接接続されたMTAsについて数を増やすのはMHSマネージャの上のワークロードを増加させます。 現在の解決策は比例しません。 ルート設定は完全にダイナミックで分散している過程であるに違いありません。

      * Manual propagation and installation of routing tables do not
        guarantee consistency of routing information (even in a loose
        fashion) when it is accessed by different MTAs scattered across
        the globe.

* 経路指定テーブルの手動の伝播とインストールは、それがいつ異なったMTAsによってアクセスされるかという情報(ゆるいファッションさえによる)が地球沿うところに散在したのをルーティングの一貫性に保証しません。

   It is commonly accepted that a distributed mechanism providing for
   dynamic updating and management of X.400 routing information is
   highly desirable.  The focus of the project is to establish X.500-
   based support of X.400 routing, at a very large scale.

一般的に、X.400ルーティング情報のダイナミックなアップデートと管理に備える分配されたメカニズムが非常に望ましいと受け入れます。 プロジェクトの焦点は非常に大きいスケールでX.400ルーティングのX.500のベースのサポートを確立することになっています。

3. Benefits

3. 利益

   Using the Directory as a dynamic means of information storage and
   advertisement will guarantee participants in Project Long Bud that
   their updated data are globally available to the community.  As a
   direct consequence of the above, a participating MHS manager will be
   released from configuring connections to the other participants.

情報記憶と広告のダイナミックな手段としてディレクトリを使用するのは、Project Longバッドで彼らのアップデートされたデータが共同体にグローバルに利用可能であることを関係者に保証するでしょう。 上記の直接の結果として、参加しているMHSマネージャは接続を構成するのから他の関係者に釈放されるでしょう。

Alvestrand, et al            Informational                      [Page 2]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[2ページ]RFC1802Introducing Project Longバッド1995年6月

   Directory-capable MTAs will be able to discover more optimal and more
   direct routes to X.400 destinations than are practical today.  This
   will enable faster delivery of messages.

ディレクトリできるMTAsはX.400の目的地への今日実用的であるよりさらに最適の、そして、ダイレクトなルートを発見できるでしょう。 これはメッセージの、より速い配送を可能にするでしょう。

   The infrastructure reliability will be improved:  the information
   stored in the Directory will allow automatic use of backup
   connections in case of remote MTA or network problems.  X.400 mail
   managers in the GO-MHS Community should then be released from the
   need to know the complexity of the whole mail routing infrastructure.
   Providing a dynamic routing infrastructure will eliminate
   inconsistencies introduced by unsynchronized static tables and
   improve quality of service.

インフラストラクチャの信頼性は改良されるでしょう: ディレクトリに格納された情報はリモートMTAかネットワーク問題の場合にバックアップ接続の自動使用を許すでしょう。次に、GO-MHS CommunityのX.400メールマネージャは全体のメールルーティングインフラストラクチャの複雑さを知る必要性から釈放されるべきです。 ダイナミックルーティングインフラストラクチャを提供すると、非連動している静的なテーブルによって導入された矛盾が排除されて、サービスの質は改良されるでしょう。

   Furthermore, besides the robustness and the optimization of the new
   routing infrastructure, the Long Bud approach should bring to the
   participating organizations better control over how they establish
   and maintain their interconnection with the GO-MHS community.

その上、新しいルーティングインフラストラクチャの丈夫さと最適化以外に、彼らがどうGO-MHS共同体がある自分達のインタコネクトを確立して、維持するかの上でバッドアプローチが参加にもたらすべきであるLongは制御するほうがよいです。

   Participants will share in building an X.400 network which can expand
   to a very large scale.  They will develop experience using a global
   messaging architecture which scales well and requires minimal
   administrative overhead.  They will be able to discuss experience
   with the MHS-DS experts and architects in the ongoing standards
   development cycle.

関係者は、非常に大きいスケールに広がることができるX.400ネットワークを造りながら、分担するでしょう。 彼らは最小量の管理オーバーヘッドをよくスケーリングして、必要とするグローバルなメッセージング構造を使用するという経験を開発するでしょう。 彼らは進行中の規格開発サイクルにMHS-DS専門家と建築家の経験について議論できるでしょう。

4. Definition of project LONG BUD

4. プロジェクトLONG BUDの定義

   The Long Bud pilot wishes to demonstrate that the X.500 Directory is
   able to provide a global-scale service to messaging applications.

Longバッドパイロットは、X.500ディレクトリがメッセージングアプリケーションに対するグローバルなスケールサービスを提供できるのを示したがっています。

   Although MHS-DS provides ways to use private routing trees, Long Bud
   will focus on the Open Community Routing Tree as used by the GO-MHS
   community.

MHS-DSは個人的なルーティング木を使用する方法を提供しますが、GO-MHS共同体によって使用されるようにLongバッドはオープンCommunityルート設定Treeに焦点を合わせるでしょう。

4.1 Project Goals

4.1 プロジェクト目標

   Project Long Bud has the following goals:

プロジェクトLongバッドには、以下の目標があります:

   * Gather pilot experience of the defined framework for X.500
     support of MTA routing, as defined by the IETF MHS-DS Working
     Group [Kille 94].

* MTAルーティングのX.500サポートのために定義された枠組みのパイロット経験を集めてください、IETF MHS-DS作業部会[Kille94]によって定義されるように。

   * Actively investigate migration of the existing operational
     X.400 service from a routing method based upon distribution of
     centrally maintained static tables, as specified in [RFC 1465],
     to a method based instead upon X.500:

* 静的なテーブルであることが支持された中心の分配に基づくルーティング方式から既存に操作上のX.400サービスの移動を活発に調査してください、[RFC1465]で指定されるように、代わりにX.500に基づく方法に:

Alvestrand, et al            Informational                      [Page 3]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[3ページ]RFC1802Introducing Project Longバッド1995年6月

       -- Deploy X.400 MTAs which are directly capable of reading
          routing information from the X.500 Directory, in
          compliance with the specifications of the MHS-DS Working
          Group.  This type of MTA is called a directory-capable
          MTA.

-- X.500ディレクトリからルーティング情報を直接読むことができるX.400 MTAsを配備してください、MHS-DS作業部会の仕様に従って。 MTAのこのタイプはディレクトリできるMTAと呼ばれます。

       -- Deploy tools which read routing information from the X.500
          Directory and use it to generate static routing tables for
          MTAs which are not directory-capable.

-- X.500ディレクトリからルーティング情報を読んで、ディレクトリできないMTAsのためにスタティックルーティングテーブルを発生させるのにそれを使用するツールを配備してください。

   * specify a set of minimal operational requirements needed before
     X.500-based routing of X.400 messages can be widely deployed.

* 広くX.400メッセージのX.500ベースのルーティングを配備できる前に必要である1セットの最小量の操作上の要件を指定してください。

4.2 Phasing

4.2 フェーズ

   The first phase of Project Long Bud consists in deploying a small
   number of directory-capable MTAs operated by members of the MHS-DS
   Working Group and GO-MHS community.  These MTAs must be capable of
   using information in the X.500 directory to route messages to all
   other members of the project as well as to the existing GO-MHS
   community.  As of this writing, an initial set of MTAs is already
   operational.

Project Longバッドの第1段階は、MHS-DS作業部会とGO-MHS共同体のメンバーによって操作されたディレクトリできるMTAsの少ない数を配備しながら、存します。 これらのMTAsは、既存のGO-MHS共同体に関してまた、プロジェクトの他のすべてのメンバーにメッセージを発送するのにX.500ディレクトリの情報を使用できなければなりません。 この書くこと現在、MTAsの1人の始発が既に操作上です。

   At the end of this phase, the following goals should be achieved:

このフェーズの終わりでは、以下の目標は達成されるべきです:

   * The X.500 DIT must be populated with enough routing information
     to allow the participating MTAs to route reliably messages to
     each other and to the existing GO-MHS community.

* 参加しているMTAsが互いと、そして、既存のGO-MHS共同体にメッセージを確かに発送するのを許容できるくらいのルーティング情報でX.500 DITに居住しなければなりません。

   * The X.500 DSAs holding the routing information must operate at
     a quality of service that is acceptable for an operational
     X.400 service.

* ルーティング情報を保持するX.500 DSAsは操作上のX.400サービスにおいて、許容できるサービスの質で作動しなければなりません。

   As a prerequisite, a sufficient number of MTA managers must be
   willing to participate in Project Long Bud for the first set of
   results to be significant.  Support for a protocol stack conforming
   to [RFC 1006] is mandatory.  All MTAs participating in the Long Bud
   pilot need to register in the Open Tree and must be prepared to
   accept connections from anyone.

前提条件として、十分な数のMTAマネージャが、結果の第一セットが重要であるようにProject Longバッドに参加しても構わないと思っているに違いありません。 [RFC1006]に一致しているプロトコル・スタックのサポートは義務的です。 Longバッドパイロットに参加するすべてのMTAsをオープンTreeに登録するのが必要であり、だれからも接続を受け入れるように準備しなければなりません。

   Note that in the first phase, default routes will be established in
   the DIT such that messages addressed to destinations outside of the
   Long Bud community will be routed to designated MTAs in the GO-MHS
   community.  This will allow for full connectivity between the Long
   Bud community and the GO-MHS community which are related, but
   distinct communities.  Interworking between these two must be
   established and coordinated.

第1段階では、デフォルトルートがDITに確立されるのでメッセージがLongバッド社会の外部を目的地に記述したというメモはGO-MHS共同体の指定されたMTAsに発送されるでしょう。 これは関連しますが、異なった共同体であるLongバッド社会とGO-MHS共同体の間の完全な接続性を考慮するでしょう。 これらの2の間の織り込むことを設立されて、調整しなければなりません。

Alvestrand, et al            Informational                      [Page 4]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[4ページ]RFC1802Introducing Project Longバッド1995年6月

   In the second phase of Project Long Bud, a greater number of MTAs
   should be added to the experiment.  Cooperation with non directory-
   capable communities must be addressed.

Project Longバッドの2番目のフェーズでは、MTAsの、より大きい数は実験に追加されるべきです。 非ディレクトリにできる共同体との協力を記述しなければなりません。

4.3 General Approach

4.3 一般的方法

   No large scale resources have been committed to this project.  Yet,
   expedient deployment is desirable.  Therefore, the pilot project
   needs to be focused and relatively short-lived.  The general approach
   for satisfying these requirements includes:

大規模リソースは全くこのプロジェクトに心がけていません。 しかし、好都合な展開は望ましいです。 したがって、試験計画は、集中していて比較的短命である必要があります。 これらの要件を満たすための一般的方法は:

   * Use as many existing MHS-DS tools as possible.  Also, continue
     to track the progress of tools being developed by project
     members and facilitate their deployment as soon as they are
     ready.

* できるだけ多くの既存のMHS-DSツールを使用してください。 また、プロジェクトメンバーによって開発されるツールの進歩を追跡して、彼らが準備ができているとすぐに、彼らの展開を容易にし続けてください。

   * Coordinate efforts with existing GO-MHS community service.

* 既存のGO-MHSボランティア活動で努力を調整してください。

   * Establish a core infrastructure:  4 DSAs (two in the United
     States and two in Europe) are set up to serve MHS-DS
     information.

* コアインフラストラクチャを確立してください: 4DSAs(合衆国の2とヨーロッパの2)がサーブMHS-DS情報まで用意ができています。

   * Wherever it is technically feasable, DSA managers will
     establish bilateral agreements with one (or more) of the core
     DSAs in order to duplicate their routing information.  For
     example, the core DSAs support the replication protocol
     specified in [RFC 1275] as a duplication technique.

* DSA、どこでも、それが技術的にfeasableであるところでは、マネージャが、彼らのルーティング情報をコピーするためにコアDSAsの1つ(さらに)と共に二国間条約を確立するでしょう。 例えば、コアDSAsは複製のテクニックとして[RFC1275]で指定された模写プロトコルをサポートします。

   * the Long Bud pilot needs to cooperate actively with DANTE
     NameFlow (the continuation of the PARADISE Pilot) and other
     directory providers in order to promote stability and
     consistency of informations.

* Longバッドパイロットは、情報の安定性と一貫性を促進するために活発にダンテNameFlow(PARADISE Pilotの継続)と他のディレクトリプロバイダーに協力する必要があります。

4.4 Tools Needed

4.4 必要であるツール

   To facilitate widespread deployment of MHS-DS routing technology and
   to foster interworking between directory-capable MTAs and MTAs which
   are not directory-capable, tools providing the following
   functionalities need to be developed:

MHS-DSルーティング技術の広範囲の展開を容易にして、ディレクトリできるMTAsとディレクトリできないMTAsの間の織り込むことを伸ばすために、以下の機能性を提供するツールは、開発される必要があります:

   populate the Directory with routing information:  such a tool must
        accept routing information specified in the standard syntax
        used by the GO-MHS community (see [RFC 1465]) as input, and it
        will load or update entries which convey the same information
        in the X.500 Directory.

ルーティング情報でディレクトリに居住してください: そのようなツールが入力されるようにGO-MHS共同体([RFC1465]を見る)によって使用された標準の構文で指定されたルーティング情報を受け入れなければならなくて、それは、X.500ディレクトリにおける同じ情報を伝えるエントリーを、ロードするか、またはアップデートするでしょう。

Alvestrand, et al            Informational                      [Page 5]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[5ページ]RFC1802Introducing Project Longバッド1995年6月

   downloading of routing information from the Directory:  in order to
        provide a migration path for organizations not using
        directory-capable MTAs, a tool is needed which will read X.400
        routing information from the X.500 Directory and generate
        static routing information from it.  The syntax of the static
        information generated will conform to the syntax defined by the
        GO-MHS community, so that "classical" MTAs run as they
        currently do.

ディレクトリからルーティング情報をダウンロードします: ディレクトリできるMTAsを使用しないことで移行パスを組織に提供するために、ルーティング情報をX.500ディレクトリからX.400に読み込んで、それから静的ルーティング情報を発生させるツールが、必要です。 発生する静的な情報の構文はGO-MHS共同体(彼らが現在するのとそんなに同じくらい「同じくらい古典的な」MTAs走行)によって定義された構文に従うでしょう。

   displaying route taken by a message between two end-points:  this
        tool should accept two parameters as input:  the X.500
        distinguished name of an MTA, and an X.400 O/R name.  It will
        display the possible routes which may be taken in order to
        deliver a message from the specified MTA to the specified X.400
        destination.  This tool looks very much the same as the
        traceroute facility used at the IP level.

メッセージによって2つのエンドポイントの間に取られた表示ルート: このツールは入力されるように2つのパラメタを受け入れるはずです: MTAのX.500分類名、およびX.400O/R名。 それは指定されたMTAから指定されたX.400の目的地まで伝言をもたらすために取られるかもしれない可能なルートを表示するでしょう。 このツールはIPレベルに使用されるトレースルート施設とたいへん同じに見えます。

   These tools must use standard protocols to access the Directory (such
   as DAP [CCITT 88] or LDAP [RFC 1487]).  Portability is encouraged.

これらのツールは、ディレクトリ(DAP[CCITT88]かLDAP[RFC1487]などの)にアクセスするのに標準プロトコルを使用しなければなりません。 携帯性は奨励されます。

   A note on quality

品質に関する注

   Pilot use of this Directory information depends heavily on data
   quality and availability.  Although the administration of DSA
   availability and global Directory data accuracy are not in the scope
   of Long Bud, care must be taken that Directory resources used by Long
   Bud participants are administrated well.

このディレクトリ情報のパイロット使用は大いにデータの品質と有用性に依存します。 DSAの管理ですが、有用性とグローバルなディレクトリデータ精度がLongバッドの範囲になくて、注意は取って、Longバッド関係者によるそのディレクトリ運用資金がよく管理されるということであるに違いありません。

   If they have the technical ability to do so, Long Bud participants
   are encouraged to replicate routing information in their Directory to
   improve data availability.

彼らにそうする技術的な能力があるなら、Longバッド関係者がデータの有効性を改良するために彼らのディレクトリにおけるルーティング情報を模写するよう奨励されます。

   Directory data used by the pilot must be accurate:  solutions to this
   problem will be recommanded as the project matures.

パイロットによって使用されたディレクトリデータは正確でなければなりません: プロジェクトが熟すとき、この問題の解決は再指図されるでしょう。

5. Participation Guide

5. 参加ガイド

   The existing operational X.400 service, the GO-MHS service, uses the
   following method to distribute and manage X.400 routing information:
   A group of MTAs is organized into a routing community.  The community
   keeps its routing information up to date by assigning to each MTA
   manager the responsibility of determining the routing information for
   his/her MTA, formalizing this routing information in the syntax
   defined by the community and sending the result to the GO-MHS
   coordination service.  Once the information has been validated
   against the other data provided by all managers in the community, the
   coordination service will advertise it to the whole community.  Each
   manager will then have to update his/her MTA configuration with the

既存の操作上のX.400サービス(GO-MHSサービス)はX.400ルーティング情報を分配して、管理する以下の方法を使用します: MTAsのグループはルーティング共同体へまとめられます。 共同体はその人のMTAのためのルーティング情報を決定する責任をそれぞれのMTAマネージャに割り当てることによって、ルーティング情報が時代について行かせます、共同体によって定義された構文でこのルーティング情報を正式にして、GO-MHSコーディネートサービスに結果を送って。 コーディネートサービスが共同体のすべてのマネージャで共同体全体にそれの広告を出すなら、一度、情報は他のデータに対して有効にされたことがあります。 そして、各マネージャはその人のMTA構成をアップデートしなければならないでしょう。

Alvestrand, et al            Informational                      [Page 6]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[6ページ]RFC1802Introducing Project Longバッド1995年6月

   verified information.

情報について確かめました。

   The purpose of Project Long Bud is to allow a manager to operate an
   MTA without having to perform ANY manual steps when another MTA
   manager adds new or changes existing routing information.  This will
   facilitate efficient, dynamic, and manageable interconnection of very
   large communities of MTAs.  It will allow the Internet X.400
   community to overcome the limitations in scalability which it is
   currently encountering.

Project Longバッドの目的はマネージャが別のMTAマネージャが新しい状態で加えるときのどんな手動のステップか情報を発送しながら存在する変化も実行する必要はなくてMTAを操作するのを許容することです。 これはMTAsの非常に大きい共同体の効率的で、ダイナミックで、処理しやすいインタコネクトを容易にするでしょう。 それで、インターネットX.400共同体はそれが現在遭遇しているスケーラビリティにおける限界を克服できるでしょう。

5.1 Prerequisites for participation

5.1 参加のための前提条件

   The prerequisites for joining Project Long Bud are:

Project Longバッドに加わるための前提条件は以下の通りです。

   Step 1:  Participants in the pilot must have a good knowledge of
            the IETF MHS-DS Working Group activities and documents:

ステップ1: パイロットの関係者には、IETF MHS-DS作業部会の活動とドキュメントに関する良い知識がなければなりません:

          1. Participants must join the MHS-DS distribution list:

1. 関係者はMHS-DS発送先リストに加わらなければなりません:

                   RFC-822:  mhs-ds@mercury.udev.cdc.com

RFC-822: mhs-ds@mercury.udev.cdc.com

                     X.400:  PN=mhs-ds; OU=mercury; OU=OSS;
                             OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US

X.400: PN=mhs-ds。 OUは水銀と等しいです。 OUはオッスと等しいです。 OU=ARH。 O=CPG。 PはCDCと等しいです。 A=ATTMail。 Cは米国と等しいです。

             Requests to join the MHS-DS distribution list may be sent
             to the following email address:

MHS-DS発送先リストを接合するという要求を以下のEメールアドレスに送るかもしれません:

                  RFC-822:  mhs-ds-request@mercury.udev.cdc.com

RFC-822: mhs-ds-request@mercury.udev.cdc.com

                    X.400:  PN=mhs-ds-request; OU=mercury; OU=OSS;
                            OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US

X.400: PN=mhs-ds-要求。 OUは水銀と等しいです。 OUはオッスと等しいです。 OU=ARH。 O=CPG。 PはCDCと等しいです。 A=ATTMail。 Cは米国と等しいです。

          2. Participants must retrieve and become familiar with all
             relevant tools and documents stored on the Project Long
             Bud anonymous FTP server

2. 関係者は、検索しなければならなくて、Project Longバッド公開FTPサーバに収納されるすべての関連道具とドキュメントになじみ深くなります。

                           Host name:  ftp.css.cdc.com

ホスト名: ftp.css.cdc.com

                           Directory:  pub/mhs-ds/long-bud

ディレクトリ: 長いパブ/mhs-ds/芽

             In particular, openly available software related to Long
             Bud activities will be kept up-to-date at this location.

特に、Longバッド活動に関連するオープンに利用可能なソフトウェアはこの位置で最新に保たれるでしょう。

Alvestrand, et al            Informational                      [Page 7]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[7ページ]RFC1802Introducing Project Longバッド1995年6月

          3. If not already done, participants must do one of the
             following:

3. 既にしないなら、関係者は以下の1つをしなければなりません:

               * Upgrade their X.400 and X.500 software such that it
                 supports the MHS-DS specifications as in [Kille 94].

* [Kille94]のようにMHS-DS仕様を支持するように、それらのX.400とX.500ソフトウェアをアップグレードさせてください。

               * Use the tools which extract MHS-DS information from
                 the directory and generate whatever local
                 configuration files are necessary to allow local MTA's
                 to use the information.  This should be done
                 frequently (at least once per day).

* 地方のMTAのものが情報を使用するのを許容するためにディレクトリからMHS-DS情報を抜粋して、どんな必要なローカルの構成ファイルも発生させるツールを使用してください。 (1日あたり少なくとも一度)頻繁にこれをするべきです。

   Step 2:  Participants must register required entries in the
            Directory so that their MTA(s) is (are) known to the
            Directory.

ステップ2: 関係者がディレクトリにおける必要なエントリーを登録しなければならないので、それらのMTA(s)はディレクトリに知られています(あります)。

          1. Arrange with the appropriate DSA Manager (who can be a
             local manager if the DSA is run by the participating
             organization, or a manager who is in charge of running the
             organization's DSA) to create an entry for the local
             MTA(s) involved in the pilot.  At this stage, only
             connection information is required.

1. 適切なDSAマネージャ(参加組織、または組織のDSAを走らせるのを担当しているマネージャがDSAを走らせるなら、地元のマネージャであるかもしれない)と共にパイロットにかかわる地方のMTA(s)のためにエントリーを作成するように手配してください。 現在のところ、接続情報だけが必要です。

          2. Check, test and verify the connection information with at
             least one other participant.  The mhs-ds distribution list
             should be used for announcing the new registration and
             asking volunteers for testing.

2. チェックしてください、そして、テストしてください、そして、他の少なくとも1人の関係者がいる接続情報について確かめてください。 mhs-ds発送先リストは、新規登録を発表して、ボランティアにテストを求めるのに使用されるべきです。

          3. Participants must establish sensible default X.400 routes
             to existing GO-MHS destinations for which X.500-based
             routing information will not exist initially.

3. 関係者はX.500ベースのルーティング情報が初めは存在しない既存のGO-MHSの目的地に実際的なデフォルト値X.400ルートを確立しなければなりません。

   Step 3:  Participants can then enter their routing information in
            the Directory.

ステップ3: そして、関係者は彼らのルーティング情報をディレクトリに入力できます。

          1. Before any routing is entered in the DIT, participants
             must check with the GO-MHS Coordination Service that the
             routes they want to register can be properly handled by
             the GO-MHS community (contact information is
             mailflow@mailflow.dante.net).  It is crucial for the Pilot
             that any routing information entered in the Directory is
             kept carefully accurate if the experiment is to be
             meaningful.  Participants may also consider the need for
             mapping rules (see [RFC 1465] for details).

1. どんなルーティングもDITに入れられる前に、関係者は、GO-MHS共同体が適切に、それらが登録したがっているルートを扱うことができる(問い合わせ先は mailflow@mailflow.dante.net である)とGO-MHS Coordination Serviceに問い合わせなければなりません。 Pilotにおいて、ディレクトリに入力されたどんなルーティング情報も実験が重要であることであるなら慎重に正確に保たれるのは、重要です。 また、関係者は配置規則の必要性を考えるかもしれません(詳細に関して[RFC1465]を見てください)。

          2. Once the above step is validated by the GO-MHS
             Coordination Service, participants must record routing
             information for their MTA(s) in the Internet X.500

2. 上のステップがGO-MHS Coordination Serviceによっていったん有効にされると、関係者はインターネットX.500の彼らのMTA(s)のためのルーティング情報を記録しなければなりません。

Alvestrand, et al            Informational                      [Page 8]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[8ページ]RFC1802Introducing Project Longバッド1995年6月

             directory service.  This requires that a participant does
             the following:

電話番号案内。 これは、関係者が以下をするのを必要とします:

               * Arrange with the appropriate DSA Manager (who can be
                 either a local manager if the DSA is run by the
                 participating organization or a manager which is in
                 charge of running the organization's DSA) to enter
                 X.400 routing information in a routing tree held by
                 the participating organization.  This routing tree
                 should contain all necessary information for the local
                 mail domain.

* 適切なDSAマネージャ(参加組織かマネージャがDSAを走らせるなら、(組織のDSAを走らせることを担当してあります)地元のマネージャであるかもしれない)と共に参加組織によって保持されたルーティング木にX.400ルーティング情報を入力するように手配してください。 このルーティング木は地方のメール・ドメインのためのすべての必要事項を含むはずです。

               * Check, test and verify the registered routing
                 information with at least one other participant.  The
                 mhs-ds distribution list should be used for announcing
                 the new registration and asking volunteers for
                 testing.

* チェックしてください、そして、テストしてください、そして、他の少なくとも1人の関係者がいる登録されたルーティング情報について確かめてください。 mhs-ds発送先リストは、新規登録を発表して、ボランティアにテストを求めるのに使用されるべきです。

          3. If a participant adds new nonleaf entries to the Open
             Community Routing Tree, then s/he must find at least one
             other participant who will maintain a slave copy of the
             children of the nonleaf entry.  Send email to the mhs-ds
             distribution list in order to find a partner who is
             willing to do this.

3. 関係者がオープンCommunityルート設定Treeに新しい「非-葉」のエントリーを加えるなら、その人は「非-葉」のエントリーの子供の奴隷コピーを維持する他の少なくとも1人の関係者を見つけなければなりません。 これをしても構わないと思っているパートナーを見つけるためにmhs-ds発送先リストにメールを送ってください。

          4. If a participant adds new nonleaf ADMD or PRMD entries to
             the directory, then s/he must contact the managers of the
             Long Bud core DSA's and arrange to provide slave copies of
             the children of the ADMD and/or PRMD entries to all of the
             core DSA's.  Send email to the mhs-ds distribution list in
             order to contact the core DSA managers.

4. 関係者が新しいnonleaf ADMDかPRMDエントリーをディレクトリに追加するなら、その人は、LongバッドコアDSAのマネージャに連絡して、コアDSAのすべてへのADMD、そして/または、PRMDエントリーの子供のコピーを奴隷に提供するように手配しなければなりません。 コアDSAマネージャに連絡するためにmhs-ds発送先リストにメールを送ってください。

          5. Once the above testing is completed, send email to the
             mhs-ds distribution list announcing the establishment of
             new X.500-based routes.

5. 上のテストがいったん完了している後、新しいX.500ベースのルートの確立を発表するmhs-ds発送先リストにメールを送ってください。

6. Notes on side effects

6. 副作用に関する注

   The Long Bud Pilot Project, with its specific scope, is investigating
   a new direction in X.500 service usage.  This should facilitate and
   expedite the global deployment of X.500 on the Internet.

特定の範囲で、LongバッドPilot ProjectはX.500サービス用法に関する新傾向を調査しています。 これは、インターネットにおけるX.500のグローバルな展開を容易にして、速めるべきです。

   Once the routing infrastructure illustrated by the Long Bud
   experiment is in place, the routing process will be able to take into
   account additional information to improve quality of service
   (minimizing messages conversions, enforcing various security policies
   established by MHS domains, taking advantage of recipients's
   capabilities stored in the Directory, ...).  While the Open Tree

Longバッド実験で例証されたルーティングインフラストラクチャが適所にいったんあると、ルーティングの過程は、サービスの質(ディレクトリ、…に格納された受取人sの能力を利用して、MHSドメインによって確立された様々な安全保障政策を実施して、メッセージ変換を最小にする)を改良するために追加情報を考慮に入れることができるでしょう。 開いている木をゆったり過ごしてください。

Alvestrand, et al            Informational                      [Page 9]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[9ページ]RFC1802Introducing Project Longバッド1995年6月

   provides global connectivity, multiple private routing trees allow
   the use of various routing trees.

グローバルな接続性、木が様々なルーティング木の使用を許す複数の個人的なルーティングを提供します。

7. Acknowledgements

7. 承認

   The authors would like to thank Urs Eppenberger (SWITCH) and Allan
   Cargille (University of Wisconsin) for their constructive comments on
   earlier drafts of this document.

作者はこのドキュメントの以前の草稿の彼らの建設的なコメントについてウルスEppenberger(SWITCH)とアランCargille(ウィスコンシン大学)に感謝したがっています。

References

参照

   [CCITT 88]          International Telegraph and Telephone
                       Consultative Committee. X.500 Recommendations
                       series. December 1988.

[CCITT88] 国際電信電話諮問委員会。 X.500推薦シリーズ。 1988年12月。

   [RFC 1649]          Hagens, R., and A. Hansen, "Operational
                       Requirements for X.400 Management Domains in the
                       GO-MHS Community", RFC 1649, ANS, UNINETT,
                       July 1994.

[RFC1649] Hagens、R.、およびA.ハンセン、「碁-MHS共同体のX.400管理ドメインのための操作上の要件」、RFC1649、ANS、UNINETT(1994年7月)。

   [Kille 94]          Kille, S., "MHS Use of the X.500 Directory to
                       Support MHS Routing", RFC 1801, ISODE Consortium,
                       June 1995.

[Kille94] Kille、S.、「MHSルート設定を支持するX.500ディレクトリのMHS使用」、RFC1801、ISODE共同体、1995年6月。

   [RFC 1006]          Rose, M., and D. Cass, "ISO Transport Service on
                       top of the TCP Version: 3", STD 35, RFC 1006,
                       Northrop Research and Technology Center,
                       May 1987.

[RFC1006] ローズ、M.、およびD.キャス、「TCPバージョンの上のISO Transport Service:」 3インチ(STD35、RFC1006、ノースロップの研究、および技術センター)は、1987がそうするかもしれません。

   [RFC 1275]          Hardcastle-Kille, S., "Replication Requirements
                       to provide an Internet Directory using X.500",
                       RFC 1275, University College London,
                       November 1991.

[RFC1275] Hardcastle-Kille、S.、「インターネットディレクトリを提供するX.500を使用する模写Requirements」、RFC1275、ユニバーシティ・カレッジロンドン1991年11月。

   [RFC 1465]          Eppenberger, U., "Routing Coordination for X.400
                       MHS Services Within a Multi Protocol / Multi
                       Network Environment Table Format V3 for Static
                       Routing", RFC 1465, SWITCH, May 1993.

[RFC1465] Eppenberger、U.、「スタティックルーティングのためのマルチプロトコル/マルチネットワーク環境テーブル形式V3の中のX.400 MHSサービスのためのルート設定コーディネート」、RFC1465は切り替わります、1993年5月。

   [RFC 1487]          Yeong, W., Howes, T., and S. Kille, "X.500
                       Lightweight Directory Access Protocol",
                       RFC 1487, Performance Systems International,
                       University of Michigan, ISODE Consortium,
                       July 1993.

[RFC1487] YeongとW.とハウズ、T.とS.Kille、「X.500ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1487、国際言語運用機構、ミシガン大学、ISODE共同体、1993年7月。

Alvestrand, et al            Informational                     [Page 10]

RFC 1802              Introducing Project Long Bud             June 1995

Alvestrand、他Informational[10ページ]RFC1802Introducing Project Longバッド1995年6月

8. Security Considerations

8. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Authors' Addresses

作者のアドレス

   Harald T. Alvestrand
   UNINETT
   P.O. box 6883 Elgeseter
   N-7002 Trondheim, Norway

ハラルドT.Alvestrand UNINETT P.O. box6883Elgeseter N-7002トロンヘイム(ノルウェー)

   Phone:  +47-73-59-70-94
   EMail:  Harald.T.Alvestrand@uninett.no

以下に電話をしてください。 +47-73-59-70-94はメールされます: Harald.T.Alvestrand@uninett.no

   Kevin E. Jordan
   Control Data Systems, Inc.
   4201 Lexington Avenue North
   Arden Hills, MN 55126, USA

ケビンE.ジョーダンコントロールデータシステムズInc.4201レキシントンアベニュー北部アーデンの森丘、ミネソタ 55126、米国

   Phone:  +1-612-482-6835
   EMail:  Kevin.E.Jordan@cdc.com

以下に電話をしてください。 +1-612-482-6835 メールしてください: Kevin.E.Jordan@cdc.com

   Sylvain Langlois
   Electricite de France
   Direction des Etudes et Recherches
   1, avenue du General de Gaulle
   92141 Clamart Cedex, France

シルバンラングロイフランス電気学会Direction desエチュードet Recherches1、大通りduシャルル・ド・ゴール92141クラマールCedex司令官、フランス

   Phone:  +33-1-47-65-44-02
   EMail:  Sylvain.Langlois@der.edf.fr

以下に電話をしてください。 +33-1-47-65 44-02のメール: Sylvain.Langlois@der.edf.fr

   James A. Romaguera
   NetConsult AG
   Morgenstrasse 129 3018 Bern, Switzerland

ジェームスA.Romaguera NetConsult株式会社Morgenstrasse129 3018ベルン(スイス)

   Phone:  +41-31-9984141
   EMail:  Romaguera@NetConsult.ch
   X.400:  S=Romaguera;O=NetConsult;P=switch;A=arcom;C=ch

以下に電話をしてください。 +41-31-9984141はメールされます: Romaguera@NetConsult.ch X.400: S=Romaguera; O=NetConsult; P=スイッチ; A=arcom; Cはchと等しいです。

Alvestrand, et al            Informational                     [Page 11]

Alvestrand、他のInformational[11ページ]