RFC1465 日本語訳
1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for StaticRouting. D. Eppenberger. May 1993. (Format: TXT=66833 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group U. Eppenberger
Request for Comments: 1465 SWITCH
May 1993
Eppenbergerがコメントのために要求するワーキンググループU.をネットワークでつないでください: 1465は1993年5月に切り替わります。
Routing Coordination for X.400 MHS Services
Within a Multi Protocol / Multi Network Environment
Table Format V3 for Static Routing
スタティックルーティングのためのマルチプロトコル/マルチネットワーク環境テーブル形式V3の中のX.400 MHSサービスのためのルート設定コーディネート
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
1. Introduction
1. 序論
The usage of the X.400 Message Handling System (MHS) is growing rapidly, especially in the commercial world but much interest can also be found in the academic and research community. New networks and new addresses come into use each and every day. The underlying technology for different X.400 networks can vary depending on the transport network and the X.400 MHS implementations used. As a large number of X.400 implementations now support multiple stacks, this offers the chance of implementing a world wide 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, however, leads to several problems for the MHS manager, two of which are:
X.400 Message Handling System(MHS)の使用法が世界的に特にコマーシャルに急速に生えていますが、また、アカデミック、そして、研究共同体で大きな関心を見つけることができます。 新しいネットワークと新しいアドレスはその日その日に使用に入ります。 転送ネットワークと実装が使用したX.400 MHSによって、異なったX.400ネットワークのための基本的な技術は異なることができます。 多くのX.400実装が現在複数のスタックを支えるとき、これは、ただ一つの一般的な転送ネットワークに世界的なメッセージハンドリングがサービスであると同じ電子メール規格を使用することで実装するという機会を提供して、サービス減少があるゲートウェイの必要性なしでしたがって、制限なしで支えます。 しかしながら、これはMHSマネージャのための2つのそれはことです:いくつかの問題を引き起こします。
- Where do I route new X.400 addresses and
- そして私が新しいX.400アドレスをどこに発送するか。
- How do I connect to a MHS domain that uses an underlying
technology that I do not support.
- 私はどのように私がサポートしない基本的な技術を使用するMHSドメインに接続しますか?
This document proposes short term solutions to these problems. It proposes a strategy for maintaining and distributing routing information and shows 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. The format has been designed to allow the information to be stored in an X.500 directory service while managers without directory service access may still use a table based approach.
このドキュメントはこれらの問題に短期間ソリューションを提案します。それは、ルーティング情報を保守して、分配するために戦略を提案して、リレーとしてマルチスタックMTAsを使用することによって、メッセージが異なったネットワークの上をどう移動できるかを示しています。 X.500ディレクトリサービスが必要な接続性とルーティング情報を保存する準備ができるまで、ドキュメント・フォーマットと協力手順は間隙を塞ぎます。 形式は、ディレクトリサービスアクセスのないマネージャがまだテーブルのベースのアプローチを使用しているかもしれない間、X.500ディレクトリサービスに格納される情報を許容するように設計されています。
The routing structure proposed can be applied to a global MHS service
構造が提案したルーティングをグローバルなMHSサービスに適用できます。
Eppenberger [Page 1] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[1ページ]RFC1465
but may also be used at a national level or even within an organisation.
しかし、また、全国レベルにおいて、または、機構の中でさえ使用されるかもしれません。
Many experts from IETF X.400-Operations Group and RARE Working Group 1 on Message Handling Systems have read drafts of this document and contributed ideas and solutions. I would especially like to thank Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and Paul-Andre Pays.
Message Handling Systemsの上のIETF X.400-運用群とRARE作業部会1からの多くの専門家が、このドキュメントの草稿を読んで、考えとソリューションを寄付しました。 ハラルドAlvestrand、エリックHuizer、マルコKaittola、アランCargille、およびポール-アンドレPaysに特に感謝申し上げます。
This is the third version of a table format. The first one was in use within COSINE-MHS for about two years. A second version with major enhancements was then proposed which has been in use for the past year. The third version will probably be the last one before it will be possible to switch to dynamic, directory service based routing.
これはテーブル形式の第3バージョンです。 最初のものはおよそ2年間COSINE-MHSの中で使用中でした。 そして、主要な増進がある第2の昨年使用中であるバージョンは提案されました。 ダイナミックで、ディレクトリサービスに基づいているルーティングに切り替わるのが可能になる前に第3バージョンはたぶん最後のものになるでしょう。
2. Terminology
2. 用語
MHS community
MHS共同体
One or more MHS domains form an MHS community. Mail exchange
between these MHS domains is defined by the coordination
procedures within this document. Examples of such communities are
the Global Open MHS service GO-MHS and the COSINE-MHS service.
1つ以上のMHSドメインがMHS共同体を形成します。 これらのMHSドメインの間のメール交換はこのドキュメントの中に協力手順で定義されます。 そのような共同体に関する例は、GlobalオープンMHSサービスGO-MHSとCOSINE-MHSサービスです。
MHS domain
MHSドメイン
One or more MHS subtrees form an MHS domain. This is a purely
administrative grouping of MHS subtrees. It is helpful, if
someone is responsible for several MHS subtrees, to refer to an
MHS domain instead of listing all the subtrees.
1つ以上のMHS下位木がMHSドメインを形成します。 これはMHS下位木の純粋に管理の組分けです。 それは役立っています、だれかがすべての下位木を記載することの代わりにMHSドメインについて言及するためにいくつかのMHS下位木に責任があるなら。
MHS subtree
MHS下位木
An MHS subtree consists of the total of the mailboxes addressable
within a subtree of the X.400 OR address space.
MHS下位木はX.400 ORアドレス空間の下位木の中でアドレス可能なメールボックスの合計から成ります。
Example: O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
例: ○ = 切り替わってください。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。
MHS domain of SWITCH in Switzerland, consisting of all
mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
address.
O=SWITCHと共にすべてのメールボックスから成るスイスのSWITCHのMHSドメイン。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 ORアドレスで。
RELAY-MTA
リレー-MTA
An X.400 MTA serving one or several MHS domains. Note that the
term WEP -Well Known Entry Point- has been used since the early
X.400ies (1987/88) until now, giving the wrong impression of a
1つに役立つX.400 MTAかいくつかのMHSドメイン。 前のX.400ies(1987/88)以来用語WEP井戸Known Entry Pointが現在まで使用されていることに注意してください、aの間違った印象を与えて
Eppenberger [Page 2] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[2ページ]RFC1465
single entry point (and therefore a single point of failure).
This document proposes to use the term RELAY-MTA, reflecting more
clearly the functionality of the MTA.
単一のエントリー・ポイント(そして、したがって、失敗の1ポイント)。 より明確にMTAの機能性を反映して、このドキュメントは、RELAY-MTAという用語を使用するよう提案します。
COSINE-MHS
コサイン-MHS
The COSINE-MHS community is mainly formed by European X.400
service providers from the academic and research area, each of
which is a member of RARE. The COSINE-MHS community is used in
the annex as an example for the usage of this document in a
multinational environment.
COSINE-MHS共同体はヨーロッパのX.400サービスプロバイダーによってアカデミック、そして、研究部門から主に形成されます。それはそれぞれRAREのメンバーです。 COSINE-MHS共同体は多国籍の環境におけるこのドキュメントの使用法に例として別館で使用されます。
3. Requirements
3. 要件
X.400 MTAs can communicate using different transport and network protocol stacks. For this document the stacks used in a WAN environment need to be considered:
X.400 MTAsは、異なった輸送とネットワークプロトコル・スタックを使用することで交信できます。 このドキュメントのために、WAN環境で使用されるスタックは、考えられる必要があります:
Stack 1 Stack 2 Stack 3 Stack 4
スタック1スタック2スタック3スタック4
Transport Layer 4 TP0 TP4 RFC1006 TP0
Networkservice 1-3 X.25 CLNS TCP/IP CONS
トランスポート層4TP0 TP4 RFC1006 TP0 Networkservice1-3X.25 CLNS TCP/IPまやかし
A common protocol stack is not the only requirement to enable communication between two MTAs. The networks to which the MTAs belong need to be interconnected. Some well known networks are listed together with the stacks they use.
一般的なプロトコル・スタックは2MTAsのコミュニケーションを可能にするという唯一の要件ではありません。 MTAsが属するネットワークは、インタコネクトされる必要があります。 よく知られているネットワークの中にはそれらが使用するスタックと共に記載されているものもあります。
Network Stack Abbreviation
ネットワークスタック略語
Public Switched Packet Data Networks 1 Public-X.25
International X.25 Infrastructure EMPB 1,4 EMPB-X.25
US and European connectionless pilot 2 Int-CLNS
Internet 2,3 Internet
公共のSwitched Packet Data Networks1のPublic-X.25の国際X.25 Infrastructure EMPB1、4EMPB-X.25 USとヨーロッパのコネクションレスなパイロット2Int-CLNSインターネット2、3インターネット
Note that several stacks may be supported over a single network. However communication between MTAs is only possible if the MTAs share at least a common stack AND a common network.
数個のスタックがただ一つのネットワークの上で支えられるかもしれないことに注意してください。 しかしながら、MTAsが少なくとも一般的なスタックと一般的なネットワークを共有する場合にだけ、MTAsのコミュニケーションは可能です。
Unlike SMTP/TCP/IP systems, there is no directory service available which would allow an MTA to look up the next MTA to which it should submit a message. Routing within X.400 will continue to be table based until a solution using X.500 directory services is available.
SMTP/TCP/IPシステムと異なって、MTAがそれがメッセージを提出するべきである次のMTAを見上げることができる利用可能などんなディレクトリサービスもありません。 X.400の中のルート設定はずっとテーブルの上に置くことのようにX.500ディレクトリサービスを使用するソリューションが利用可能になるまで基づくなるだろうこと。
Furthermore it is not generally allowed to connect to any MTA even on the same network without being registered on the destination MTA. These restrictions require a large coordination effort and carefully configured and updated systems.
その上、一般に、目的地MTAに登録されないで、それは同じネットワークさえのどんなMTAにも接続できません。 これらの制限は大きいコーディネート取り組みと慎重に構成されて、アップデートされたシステムを必要とします。
Eppenberger [Page 3] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[3ページ]RFC1465
4. Outline of the proposal
4. 提案のアウトライン
This proposal offers a solution for describing information about X.400 message routing within an MHS community in RELAY-MTA and DOMAIN documents. Basic information on the MHS community is documented in the corresponding COMMUNITY document. All contact persons and RELAY-MTA administrators can be found in PERSON documents. A future X.500 based solution may need extended information to overcome still unsolved problems like optimal routing or traffic optimization for messages with multiple recipients. The information collected for the intermediate solution however is very basic. All established coordination procedures will help and even speed up the future introduction of an X.500 based solution.
この提案は、RELAY-MTAとDOMAINドキュメントのMHS共同体の中でX.400メッセージルーティングの情報について説明するために解決法を提案します。 MHS共同体に関する基本情報は対応するCOMMUNITYドキュメントに記録されます。 PERSONドキュメントですべての連絡窓口とRELAY-MTA管理者を見つけることができます。 将来のX.500ベースのソリューションは、複数の受取人がいるメッセージのための最適ルーティングやトラフィック最適化のようなまだ未解決の問題を克服するために拡張情報を必要とするかもしれません。 しかしながら、中間的ソリューションのために集められた情報は非常に基本です。 すべての確立した協力手順が、助けて、X.500のベースのソリューションの今後の導入を早くさえするでしょう。
4.1 The COMMUNITY document
4.1 COMMUNITYドキュメント
For each MHS community there exists one single COMMUNITY document containing basic information. First the contact information for the central coordination point can be found together with the addresses for the file server where all the documents are stored. It also lists network names and stacks to be used in the RELAY-MTA and DOMAIN documents. An MHS community must agree on its own set of mandatory and optional networks and stacks.
それぞれのMHS共同体に、基本情報を含む1通のただ一つのCOMMUNITYドキュメントが存在しています。 まず最初に、ファイルサーバーのためのすべてのドキュメントが保存されるアドレスと共に主要なコーディネートポイント単位で問い合わせ先を見つけることができます。 それは、また、ネットワーク名を記載して、RELAY-MTAとDOMAINドキュメントで使用されるために積み重ねられます。 MHS共同体はそれ自身の義務的で任意のネットワークとスタックのセットに同意しなければなりません。
4.2 The RELAY-MTA document
4.2 RELAY-MTAドキュメント
Every MHS domain in the community may designate one or more MTAs as RELAY-MTAs. These RELAY-MTAs accept incoming connections from the RELAY-MTAs of the other MHS domains and in return are allowed to send messages to these RELAY-MTAs. A RELAY-MTA is documented with all the necessary connection information in the corresponding RELAY-MTA document.
共同体のあらゆるMHSドメインがRELAY-MTAsとして1MTAsを指定するかもしれません。 これらのRELAY-MTAsは他のMHSドメインのRELAY-MTAsから接続要求を受け入れて、代わりにこれらのRELAY-MTAsにメッセージを送ることができます。 すべての必要な接続情報が対応するRELAY-MTAドキュメントにある状態で、RELAY-MTAは記録されます。
4.3 The DOMAIN document
4.3 DOMAINドキュメント
An MHS domain has a responsible person who sets up the routing entries for the domain in the DOMAIN document. The primary RELAY- MTAs listed in the DOMAIN document as serving this MHS domain must, TOGETHER, offer at least connectivity to all networks and stacks listed as mandatory in the COMMUNITY document. Optional RELAY-MTAs may be added, generally with higher priority, to allow more precise routing.
MHSドメインには、DOMAINドキュメントのドメインのためのルーティングエントリーをセットアップする責任者がいます。 このMHSドメインに役立つのが記載されていなければならないようにDOMAINドキュメントに記載されたプライマリRELAY- MTAs(TOGETHER)はCOMMUNITYドキュメントで義務的であるとして記載されたすべてのネットワークとスタックに少なくとも接続性を提供します。 一般に、任意のRELAY-MTAsは、より高い優先度で加えられて、より正確なルーティングを許すかもしれません。
An MHS domain may also decide not to operate a RELAY-MTA. It will then only need agreements with one or more RELAY-MTAs from other MHS services which will relay for this domain. The domain itself, however, must either create its own DOMAIN document or document its MHS subtrees jointly with another MHS domain.
また、MHSドメインは、RELAY-MTAを操作しないと決めるかもしれません。 それは1RELAY-MTAsと共に次に、協定を必要とするだけであるためにこのドメインのためのリレーを望んでいる他のMHSサービスから望んでいます。 しかしながら、ドメイン自体は、それ自身のDOMAINドキュメントを作成しなければならないか、または別のMHSドメインと一緒にMHS下位木を記録しなければなりません。
Eppenberger [Page 4] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[4ページ]RFC1465
The structure of the DOMAIN document is very straightforward. It starts off with one or more MHS subtrees, each on its own line. After the domains follows a line indicating the responsible person for the MHS subtrees mentioned. Finally the responsible RELAY-MTA(s) are listed with appropriate priorities.
DOMAINドキュメントの構造は非常に簡単です。 それはそれぞれ1つ以上のMHS下位木と、それ自身の系列の上で始められます。 ドメインの、あとに下位木が言及したMHSのために責任者を示す系列について行っています。 最終的に責任があるRELAY-MTA(s)は適切なプライオリティで記載されています。
4.4 The PERSON document
4.4 PERSONドキュメント
All administrators and responsible persons are documented in PERSON documents. The RELAY-MTA and DOMAIN documents contain just keys pointing to a PERSON document. If such a person can already be found in an X.500 directory service, then the key consists of a Distinguished Name, else the key is just its OR address.
すべての管理者と責任者はPERSONドキュメントに記録されます。 RELAY-MTAとDOMAINドキュメントはまさしくPERSONドキュメントを示すキーを含んでいます。 X.500ディレクトリサービスで既にそのような人を見つけることができるなら、キーはDistinguished Nameから成って、ほかに、キーはただそのORアドレスです。
4.5 Coordination
4.5 コーディネート
This approach requires an identified coordination point. It is up to the MHS community to decide on the level of coordination and support to be provided and on the funding mechanisms for such activities. Basic information can be found in the COMMUNITY document. The following list of support activities is considered mandatory for an operational service:
このアプローチは特定されたコーディネートポイントを必要とします。 そのような活動のために提供されるコーディネートとサポートのレベルの上と、そして、資金調達メカニズムの上で決めるのは、MHS共同体次第です。 COMMUNITYドキュメントで基本情報を見つけることができます。 サポート活動の以下のリストは操作上のサービスに義務的であると考えられます:
- New RELAY-MTAs joining the service are tested and support is
given to create the RELAY-MTA document.
- サービスに参加する新しいRELAY-MTAsをテストします、そして、RELAY-MTAドキュメントを作成するためにサポートを与えます。
- New MHS domains joining the MHS community get assistance to set
up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s) and to
create DOMAIN documents.
- MHS共同体に加わる新しいMHSドメインは、RELAY-MTA(s)をセットアップする、そして/または、適切なRELAY-MTA(s)を見つけて、DOMAINドキュメントを作成するために支援を得ます。
- Updated documents are announced to the RELAY-MTA managers and
responsible persons for the DOMAIN documents unless automatic
distribution is used.
- 自動分配が使用されていない場合、アップデートされたドキュメントはDOMAINドキュメントのためにRELAY-MTAマネージャと責任者に発表されます。
- All the RELAY-MTA, DOMAIN and PERSON documents are made
available on a file server together with the COMMUNITY document.
The file server must at least be reachable via email. MHS
communities with a big number of documents may consider
additional access methods like ftp and FTAM.
- すべてのRELAY-MTA、DOMAIN、およびPERSONドキュメントをCOMMUNITYドキュメントと共にファイルサーバーで利用可能にします。 ファイルサーバーはメールで少なくとも届いていなければなりません。 大きい数のドキュメントがあるMHS共同体は、追加アクセスがftpとFTAMのようにメソッドであると考えるかもしれません。
- Tools should be made available to manage routing tables for the
X.400 software used on the RELAY-MTAs or to fill in and check
the documents. The format of the documents has specifically
been chosen to enable the use of automated tools.
- ツールをドキュメントにRELAY-MTAsで使用されるX.400ソフトウェアのために経路指定テーブルを管理するか、記入して、またはチェックするために利用可能にするべきです。 ドキュメントの形式は、自動化されたツールの使用を可能にするために明確に選ばれました。
The RELAY-MTA managers must be aware that a large number of RELAY- MTAs in an MHS community may require significant operational resources to keep the local routing tables up-to-date and to
そしてRELAY-MTAマネージャがMHS共同体の多くのRELAY- MTAsが地方の経路指定テーブルを最新に保つために重要な操作上のリソースを必要とするかもしれないのを意識しているに違いない。
Eppenberger [Page 5] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[5ページ]RFC1465
constantly monitor the correct functioning of the connections. On the other hand more than one RELAY-MTA with a good connectivity to an MHS domain improves the overall robustness of the domain and thus the QOS.
絶えず接続の正しい機能をモニターしてください。 他方では、MHSドメインへの良い接続性がある1RELAY-MTAがドメインの総合的な丈夫さとその結果QOSを改良します。
MHS communities may decide on additional mandatory requirements for the operation of a RELAY-MTA. These may include a hot line, echo services, exchange of statistics, response time to problem reports, uptime of the RELAY-MTA, etc. This will ensure a certain quality of service for the end users.
MHS共同体はRELAY-MTAの操作のための追加義務的な要件を決めるかもしれません。 これらはホットライン、エコーサービス、統計の交換、問題報告書への応答時間、RELAY-MTAの動作可能時間などを含むかもしれません。 これはエンドユーザのためにあるサービスの質を確実にするでしょう。
4.6 Routing
4.6 ルート設定
The proposal addresses MHS communities spanning several organisations. But it may also be used to manage routing within a single organisation or even a global MHS community.
提案は、MHSがいくつかの機構にかかる共同体であると扱います。 しかし、また、それは、単純組織かグローバルなMHS共同体の中でさえルーティングを管理するのに使用されるかもしれません。
Two kinds of mail relays are defined, the primary RELAY-MTAs and the secondary RELAY-MTAs. A primary or secondary RELAY-MTA must allow incoming connections from all other primary and secondary RELAY-MTAs with a common stack. Primary RELAY-MTAs must be able to connect to all other primary RELAY-MTAs which share a common stack. A secondary RELAY-MTA must connect to at least one primary RELAY-MTA.
2種類のメール中継が定義されて、予備選挙は、RELAY-MTAsとセカンダリRELAY-MTAsです。 プライマリの、または、セカンダリのRELAY-MTAは一般的なスタックで他のすべてのプライマリの、そして、セカンダリのRELAY-MTAsから接続要求を許容しなければなりません。 プライマリRELAY-MTAsは一般的なスタックを共有する他のすべてのプライマリRELAY-MTAsに接続できなければなりません。 セカンダリRELAY-MTAは少なくとも1プライマリRELAY-MTAに接続しなければなりません。
Each MHS community must define update procedures for the routing based on the documentation. Automated update has to be studied carefully.
それぞれのMHS共同体はドキュメンテーションに基づくルーティングのためにアップデート手順を定義しなければなりません。 自動化されたアップデートは慎重に研究されなければなりません。
An MHS community should also define procedures for new RELAY-MTAs and MHS domains joining the service. Since the usage of X.400 is growing rapidly a flexible but well coordinated way of integrating new members into an MHS community is needed. The proposed documentation format supports this by allowing primary and secondary RELAY-MTAs. All RELAY-MTAs accept incoming connections from each other. Sending messages can be done by using the primary RELAY-MTAs only. This allows new RELAY-MTAs to join the community as secondary and to get primary status when traffic flow increases. Secondary RELAY-MTAs may also require a longer testing period.
また、MHS共同体はサービスに参加する新しいRELAY-MTAsとMHSドメインと手順を定義するべきです。 X.400の使用法が急速に成長しているので、新しいメンバーをMHS共同体と統合するフレキシブルな、しかし、よく調整された方法が必要です。 提案されたドキュメンテーション形式は、プライマリの、そして、セカンダリのRELAY-MTAsを許容することによって、これをサポートします。 すべてのRELAY-MTAsが互いから接続要求を受け入れます。 プライマリRELAY-MTAsだけを使用することによって、送付メッセージができます。 これで、新しいRELAY-MTAsはセカンダリとして共同体に加わって、交通の流れが増加するとき、プライマリ状態を得ます。 また、セカンダリRELAY-MTAsは、より長いテストの期間を必要とするかもしれません。
5. The documents
5. ドキュメント
The definition is given in BNF-like syntax. The following conventions are used:
BNFのような構文で定義を与えます。 以下のコンベンションは使用されています:
| means choice
| 手段選択
\ is used for continuation of a definition over several lines
\はいくつかの系列の上の定義の継続に使用されます。
Eppenberger [Page 6] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[6ページ]RFC1465
[] means optional
[]手段任意です。
{} means repeated one or more times
手段は1回以上繰り返されました。
() is used to group choices
()は選択を分類するのにおいて使用されています。
\" is used for double quotes in a text string
「\」はテキスト文字列の二重引用符に使用されます。
<CR> is a Carriage Return and means that the next section starts
on its own line.
<CR>は、Carriage Returnであり、次のセクションがそれ自身の系列を始めることを意味します。
The definition is complete only to a certain level of detail. Below this level, all expressions are to be replaced with text strings. Expressions without more detailed definition are marked with single quotes '. The format and semantics should be clear from the names of the expressions and the comments given.
定義はあるレベルの詳細だけに完全です。 このレベルの下では、すべての式はテキスト文字列に取り替えることです。 'より詳細な定義のない式はシングル・クォーテション・マークでマークされます'。 形式と意味論は式の名前と与えられたコメントによって明確であるはずです。
Wherever the BNF definition requires a single blank, multiple blanks may be used to increase the readability. Please note that for some field values the number of spaces is significant.
BNF定義がどこで単一の空白を必要としても、複数の空白が、読み易さを高めるために費やされるかもしれません。 何らかの分野が空間の数を評価するので、それは重要です。
Lines exceeding 80 characters should be wrapped at any convenient blank except at blanks which are significant. The line is continued with at least one leading blank.
80のキャラクタを超えている線は重要な空白以外のどんな便利な空白にも包装されるべきです。 線は少なくとも1つの主な空白で続けられています。
Comments may be placed anywhere in the document but only on separate lines and without splitting wrapped lines. Such a comment line must either start with a '#' sign followed by white space and the comment or consist of a single '#' on a single line.
別々の線だけと包装された線を分けないで、コメントはどこでも置かれるかもしれません。 そのような注釈行は、余白とコメントがあとに続いた'#'サインから始まらなければならないか、または単線の単一の'#'から成らなければなりません。
The documents must follow the case of the strings defined in BNF. Note that some values, especially connection parameters like TSEL or MTA password are case dependant too.
ドキュメントはBNFで定義されたストリングのケースに続かなければなりません。 いくつかの値であり、また、特にTSELやMTAパスワードのような接続パラメタがケース扶養家族であることに注意してください。
The BNF definitions are ordered top-down. See Appendix B for an alphabetically sorted list.
トップダウンはBNF定義に注文されます。 アルファベット順に、分類されたリストに関してAppendix Bを見てください。
A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and PERSON documents belong together. The detailed definitions can be found in the following chapters.
1セットの1通のCOMMUNITYドキュメント、数個RELAY-MTA、DOMAIN、およびPERSONドキュメントはグループを成します。 以下の章で詳細な定義を見つけることができます。
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-MTA-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }
コーディネートを発送する<X.400がセット>を記録します:、:= \<共同体ドキュメント>\<リレーMTA-ドキュメント>、\<ドメインドキュメント>、\<人ドキュメント>。
Eppenberger [Page 7] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[7ページ]RFC1465
5.1 Common Definitions
5.1 一般的な定義
<DirectoryName> ::= 'Distinguished Name'
The string representation of a Distinguished Name is
defined in the RFCxxxx. If a Distinguished Name is
used as a key in the documents, then the information
can be fetched from the directory instead of checking
the appropriate document. But as long as not all
managers in the same community have directory access,
the same information must also be present in a
document. Note that Distinguished Names in the context
of the routing documents are just used as key strings
to point to other documents.
<DirectoryName>:、:= '顕著なName、'Distinguished Nameのストリング表現はRFCxxxxで定義されます。 Distinguished Nameがキーとしてドキュメントで使用されるなら、適切なドキュメントをチェックすることの代わりにディレクトリから情報をとって来ることができます。 しかし、また、同じ共同体のすべてのマネージャにディレクトリアクセスがあるというわけではない限り、同じ情報もドキュメントに存在していなければなりません。 ルーティングドキュメントの文脈のDistinguished Namesが他のドキュメントを示すのに主要なストリングとしてただ使用されることに注意してください。
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) <CR>
The 'community name' is a string identifying the MHS
community to be used in the first line of all
documents.
<共同体識別子>:、:= 「共同体:」 「すべてのドキュメントの最初の線に使用されるためにMHS共同体を特定する\('共同体名'| <DirectoryName>)<CR>存在という'共同体名'aストリング。」
<UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )
A unique key is needed to identify the RELAY-MTA. In
addition to the MTA name itself, it is proposed to use
OR address attributes of the management domain where
the RELAY-MTA resides. ADMD and PRMD fields are both
optional and may be used to guarantee uniqueness of the
key. The values used are irrelevant. Even non-
printable characters like @ or ! are acceptable. The
result is not an address but a key string. A
Distinguished Name may be used instead.
<UniqueRELAY-MTAkey>:、:= 「[「Pは」 'PRMDname'と等しい」;、「]、\、[「」 ='ADMDname'」;、「]、\「」 <C=国名略号>」 ; 「\「MTAname=」'MTAname') | <DirectoryName>、)、」 ユニークキーが、RELAY-MTAを特定するのに必要です。 MTA名自体に加えて、それは、RELAY-MTAが住んでいる管理ドメインのORアドレス属性を使用するために提案されます。 ADMDとPRMD分野は、ともに任意であり、キーのユニークさを保証するのに使用されるかもしれません。 使用される値は無関係です。 または、非印刷可能なキャラクタさえ@が好きである、許容できます。 結果はアドレスではなく、主要なストリングです。 Distinguished Nameは代わりに使用されるかもしれません。
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
A unique key is necessary to make the links from the
documents where a responsible person or an
administrator is needed, to the PERSON documents. It
is either the OR address of the person or a
Distinguished Name (if the person is already registered
in the directory).
<UniquePersonKey>:、:= (<X.400は>を記述します| <DirectoryName>) ユニークキーが責任者か管理者が必要であるドキュメントからリンクを作るのに必要です、PERSONドキュメントに。 それは、人のORアドレスかDistinguished Name(人がディレクトリに既に登録されるなら)のどちらかです。
<Country-Code> ::= 'Two Character Country Code ISO-3166'
<国名略号>:、:= '2キャラクター国名略号ISO-3166'
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
It has been used consequently all over the document.
This explains also the syntax of the
<X.400は>を記述します:、:= 'ORアドレス、ISO10021-2Annex F'Itはその結果ドキュメント全体にわたって使用されました。 また、これで、構文がわかります。
Eppenberger [Page 8] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[8ページ]RFC1465
<UniqueRELAY-MTAkey> and the <MHS-subtree>. Examples:
S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
G=john; I=w; S=doe; P=org; A=rel400; C=aq;
<UniqueRELAY-MTAkey>と<MHS-下位木>。 例: Sはユーザと等しいです。 O=org株式会社。 OU1=sect1。 P=org。 A=rel400。 Cはaqと等しいです。 DDA: RFC-822=we(a)sell.it。 Pはインターネットと等しいです。 =。 Cはxxと等しいです。 G=john。 I=w。 S=doe。 P=org。 A=rel400。 Cはaqと等しいです。
<EMail> ::= "Address: " <X.400 address> <CR>
<メール>:、:= 「以下を記述してください」 「<X.400アドレス><CR>」
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<telリストがない>:、:= <tel-番号>。; [「」、<tel-番号>、]
<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}
This syntax follows the attribute syntax of the X.500
directory based on CCITT E.123.
<tel-番号>:、:= 「+」 <int-pref>、「「<国家の数の>\[「x」<拡張子>]、この構文がCCITT E.123に基づくX.500ディレクトリの属性構文に従う、」
<int-pref> ::= 'international prefix'
<int-pref>:、:= '国際的な接頭語'
<national number> ::= 'national telephone number'
A national number may be written with spaces and
hyphens to group the figures.
<の国家の番号>:、:= '国家の電話番号'A国家の番号は空間とハイフンで書かれていて、数字を分類するかもしれません。
<extension> ::= 'local extension'
<拡張子>:、:= '地方の拡大'
<Phone> ::= "Phone: " <tel-no-list> <CR>
One or more phone numbers
<電話>:、:= 「以下に電話をしてください」 「<telリストがない><CR>Oneか、より多くの電話番号」
<Fax> ::= "Fax: " <tel-no-list> <CR>
One or more FAX numbers
<ファックス>:、:= 「Fax:」 「<telリストがない><CR>Oneか、より多くのFAX番号」
<Mail> ::= "Mail: " 'postal address information' <CR>
The items of the postal address are separated by ' /'
wherever the next item goes onto the next line for a
printed address label. If the document is for an
international community, the address should include the
person's country.
Example:
Mail: SWITCH Head Office / Urs Eppenberger /
Limmatquai 138 / CH-8001 Zurich / Switzerland
results in the following mailing label:
SWITCH Head Office
Urs Eppenberger
Limmatquai 138
CH-8001 Zurich
Switzerland
<メール>:、:= 「以下を郵送してください」 「郵便の宛先の商品が'/'によってどこでも、次の商品が印刷されたアドレスラベルに次の線に行くところに切り離されるという'郵便の宛先情報'<CR>。」 ドキュメントが国際社会のためのものであるなら、アドレスは人の国を含むべきです。 例: 以下を郵送してください。 SWITCH Headオフィス/ウルス・Eppenberger / Limmatquai138 / CH-8001チューリッヒ/スイスは以下の郵送ラベルをもたらします: スイッチ本社ウルスEppenberger Limmatquai138CH-8001チューリッヒスイス
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>
The <Update-info> contains also the format identifier.
<アップデートインフォメーション>:、:= 「以下をアップデートしてください」 形式はV3と等しいです。 'yymmdd'\」という「日付=」。 「START=」は<アップデートインフォメーション>が含む\[「; =を終わらせてください」という'yymmdd']<CR>を'yymmddします'。形式IDも。
Eppenberger [Page 9] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[9ページ]RFC1465
The date of the last update of a document is given in
the form 'yymmdd'.
A start date must be set. A document can be published
this way before the information in it is valid. (This
is especially useful in absence of automated tools.
RELAY-MTA managers get more time to prepare their
systems.)
An end date is used to set an expiration date for the
document.
フォーム'yymmdd'でドキュメントのアップデートの日付を与えます。 スタート日を設定しなければなりません。 それの情報が有効になる前にこのようにドキュメントを発表できます。 (これは自動化されたツールの欠如で特に役に立ちます。 RELAY-MTAマネージャは彼らのシステムを準備するより多くの時間を得ます。) 終了日は、有効期限をドキュメントに決めるのに使用されます。
<P-address> ::= 'String encoded Presentation Address'
The format of this string follows RFC1278, A string
encoding of Presentation Address and RFC1277, Encoding
Network Addresses to support operation over non-OSI
layers. See chapter 5.2 about the usage of macros in a
Presentation Address.
<P-アドレス>:、:= このストリングの形式がRFC1278、五弦コード化に続く'ストリングのコード化されたPresentation Address'Presentation AddressとRFC1277(非OSI層の上の操作を支持するEncoding Network Addresses)。 マクロの用法に関してPresentation Addressの第5.2章を見てください。
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
The service type consists of a string with three parts
concatenated with a "/": Network-name/Network-
service/Transport-Protocol.
<サービスタイプ>:、:= サービスタイプの「<は」 /」 \<ネットワーク・サービス>と>をネットワークで命名する」/」 \<トランスポート・プロトコル>が3つの部品がa」/で連結されるストリングから成る、」、: ネットワーク名/ネットワークサービス/トランスポート・プロトコル。
<Network-name> ::= 'Name of a network'
The network-name string identifies a network. A well
known key word should be chosen. (No '/' character is
allowed.)
Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
WIN, Janet,
<ネットワーク名>:、:= ''ネットワーク名が結ぶネットワークの名前はネットワークを特定します。 よく知られているキーワードは選ばれるべきです。 '('/'キャラクタは全く許容されていません。) 例: ジャネット、公共のX.25(インターネット、EMPB-X.25、Int-CLNS)は勝ちます。
<Network-service> ::= 'Name of a network service'
Examples: X.25, CONS, CLNS, TCP
<ネットワーク・サービス>:、:= 'ネットワークサービス'Examplesという名前: X.25、コンズ、CLNS、TCP
<Transport-Protocol> ::= 'Name of a transport protocol'
Examples: TP0, TP2, TP4, RFC1006
<トランスポート・プロトコル>:、:= '輸送プロトコル'Examplesという名前: TP0、TP2、TP4、RFC1006
Since network and stack information forms one string,
it identifies in an easy way a connection possibility
between two RELAY-MTAs. The COMMUNITY document defines
the strings to be used in the RELAY-MTA and DOMAIN
documents. Some examples:
Internet/TCP/RFC1006
Public-X.25/X.25/TP0
RARE-IXI/CONS/TP0
RARE-CLNS/CLNS/TP4
(It is probably important to mention here that this
string has nothing to do with the format of a
ネットワークとスタック情報が1個のストリングを形成するので、それは簡単な方法で2RELAY-MTAsの間の接続の可能性を特定します。 COMMUNITYドキュメントは、RELAY-MTAとDOMAINドキュメントで使用されるためにストリングを定義します。 いくつかの例: インターネット/TCP/RFC1006 Public-X.25/X.25/TP0 RARE-IXI/コンズ/TP0 RARE-CLNS/CLNS/TP4、(このストリングがaの形式と関係ないとここに言及するのはたぶん重要です。
Eppenberger [Page 10] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[10ページ]RFC1465
presentation address as defined by Steve Hardcastle-
Kille in RFC1278. The problem of networks using the
same address structure (X.121 DTEs, 4 Byte Internet
addresses) but not being connected is not addressed in
RFC1278 but solved by using the proposed service
identifier above in addition to the presentation
address. As long as there are network islands, there
is no other way than the addition of an 'island'-
identifier.
RFC1278でスティーブHardcastle- Killeによって定義されるプレゼンテーションアドレス。 同じアドレス構造(X.121 DTEs、Byteインターネットが記述する4)を使用しますが、接続されないネットワークの問題は、プレゼンテーションアドレスに加えてRFC1278に記述されませんが、上で提案されたサービス識別子を使用することによって、解決されています。 ネットワーク島がある限り、他の道は全く'島'の添加ほどありません--識別子。
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
<MHS-下位木>:、:= 等しい..組織..名前..等しい..等しい..等しい..等しい..等しい 「「\「C=」<国名略号>」」。
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone> <CR>
<操作>:、:= 「届く:、」 「「「-」 <は>を調節する」<時間>、」、;、\<の時間帯の><CR>。
<time> ::= 'hh:mm'
<時間>:、:= 'hh: mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
The operation information is needed to know the time
someone is reachable. This information is important
for communities spanning several time zones.
'hhmm' is a four digit value, the first two digits
indicate hours, the second two digits indicate minutes.
Use "UTC+" for time zones east of Greenwich. A simple
formula helps to calculate the current time at the
remote place:
local-time - local-displacement + remote-displacement =
remote-time
18:00 - (UTC + 0100) + (UTC - 0800) = 09:00
The <Time-zone> entry may be followed by a comment line
indicating when Daylight Saving Time is in effect.
This is especially reasonable for MHS communities
spanning continents on the northern and southern
hemisphere.
<の時間帯の>:、:= (「UTC+」| "UTC") だれかが届いている時代に知る操作情報が必要である'hhmm'。 いくつかの時間帯にわたる共同体に、この情報は重要です。 'hhmm'は最初の2ケタが、時間2番目の2ケタが分間示すのを示す4ケタ価値です。 グリニッジの時間帯の東に「UTC+」を使用してください。 簡単な公式は、遠い所で現在の時間について計算するのを助けます: 現地時間--サマータイムがいつ有効であるかを示す注釈行は+ 18:00〜(UTC+0100)(UTC--0800)=09:00まで、<が>エントリーをTime区分するリモートリモート地方の置換え+置換え=時のあとに続くかもしれません。 北で大陸にかかるMHS共同体と南半球に、これは特に妥当です。
5.2 The COMMUNITY document
5.2 COMMUNITYドキュメント
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>
The first line of the COMMUNITY document specifies the
<共同体ドキュメント>:、:= COMMUNITYドキュメントの最初の線が指定する<共同体識別子>\<Update-インフォメーション>\<COMMUNITY-文書本体>。
Eppenberger [Page 11] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[11ページ]RFC1465
<Community-Identifier> to be used in the header of all
other documents belonging to the same community. It is
recommended to add a few comment lines to describe the
members of this MHS community.
同じ共同体に属しながら他のすべてのドキュメントのヘッダーで使用されるべき<共同体識別子>。 このMHS共同体のメンバーについて説明するためにいくつかの注釈行を加えるのはお勧めです。
<COMMUNITY-document-body> ::= <Coordination> \
[{<Macro-definition>}] \
{<Connections>}
<共同体文書本体>:、:= <コーディネート>\[<マクロ定義>]\<コネクションズ>。
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <Operation> <File-server>
Set of contact information for the coordination point
<コーディネート>:、:= コーディネートポイント単位で問い合わせ先の<EMail><電話><FAX>\<メール><Operation><File-サーバ>Set
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>}]
All documents must be available at least to the
managers of the MHS domains and the RELAY-MTAs through
an email server. If FTAM and FTP are also available,
the generation of automated update tools is much
easier.
It is suggested to have a single server. If there is
only one, knowing a single X.400 OR address will allow
you to reach the server. However for FTP and FTAM more
system addresses may be possible depending on the
number of available network connections (or service
types as they are called in this document).
<ファイルサーバー>:、:= 少なくともMHSドメインとRELAY-MTAsのマネージャにとって、すべてが記録する<Eメールサーバ>[<FTPサーバ>]\[<FTAM-サーバ>]はEメールサーバを通して利用可能であるに違いありません。また、FTAMとFTPも利用可能であるなら、自動化されたアップデートツールの世代ははるかに簡単です。 それは、ただ一つのサーバを持つために提案されます。1つしかないと、ただ一つのX.400 ORアドレスを知っているのは、あなたがサーバに達するのを許容するでしょう。しかしながら、FTPとFTAMに関して、手があいているネットワーク接続の数によって、より多くのシステムアドレスが可能であるかもしれません(彼らが本書では呼ばれるようにタイプにサービスを提供してください)。
<email-server> ::= "Mail-server: "<X.400 address> <CR>
The email address of the file server.
<Eメールサーバ>:、:= 「メールサーバ:」 「<X.400が><CR>を記述する、ファイルサーバーのEメールアドレス、」
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
In addition to the domain name of the server, an
account name and a password is given. In most cases
this will probably be something like "anonymous" and
"guest".
Some servers request the RFC822 address of the user.
This is documented by using the string 'user@domain' as
password entry. The meaning is not to use
'user@domain' literally as password while accessing the
server (even if this would generally work too since the
software often just checks the presence of an @ sign,)
but to use ones own RFC822 email address.
<FTPサーバ>:、:= 「FTPサーバ:」 「'ドメイン名'」。 「サーバ、アカウント名、およびパスワードのドメイン名への\'アカウント名'[「;」'パスワード']<CR>In追加を与えます。」 多くの場合、これはたぶん「匿名」と「客」に似るでしょう。 いくつかのサーバがユーザのRFC822アドレスを要求します。 これは、パスワードエントリーとしてストリング' user@domain 'を使用することによって、記録されます。 意味がサーバにアクセスしている間、文字通りパスワードとして' user@domain 'を使用しない(これが以来一般にまた、働いても、ソフトウェアはしばしばただ@サインの存在をチェックします)ことですが、ものを使用するには、RFC822Eメールアドレスを所有してください。
<FTAM-server> ::= "FTAM-server: " <P-address> "; "\
'account-name' ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
The account name is often case sensitive. Some FTAM
<FTAM-サーバ>:、:= 「FTAM-サーバ:」 「<P-アドレス>」。 「\'アカウント名'[「;」'パスワード']\、[「;、X.500、」 <DirectoryName>] アカウントが命名する<CR>がしばしば大文字と小文字を区別している、」 いくらかのFTAM
Eppenberger [Page 12] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[12ページ]RFC1465
servers offer anonymous access with the account-name
ANON. Documenting an FTAM server with a Distinguished
Name is only allowed if the server is registered in the
directory.
サーバはアカウント名ANONとの匿名のアクセスを提供します。 サーバがディレクトリに登録される場合にだけ、Distinguished Nameと共にFTAMサーバを記録するのは許容されています。
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
Presentation addresses without the usage of macros are
generally unreadable. RFC1278 suggests a few macros.
All macros which are allowed in a community must be
defined in the COMMUNITY document. It is recommended
to use the proposed macros in RFC1278 and add new ones
if necessary:
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Janet-X25(80) TELEX+00728722+X.25(80)+02+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
<マクロ定義>:、:= 「マクロ:」 「'一般に、'」 「\'マクロ価値'<CR>Presentationがマクロの用法なしで記述するマクロ名は読みにくいです。」 RFC1278はいくつかのマクロを勧めます。 COMMUNITYドキュメントで共同体に許容されているすべてのマクロを定義しなければなりません。 RFC1278で提案されたマクロを使用して、必要なら、新しいものを加えるのはお勧めです: マクロ: Int-X25(80)は+00728722+X.25(80)+01+マクロをテレックスで送信します: ジャネット-X25(80)は+00728722+X.25(80)+02+マクロをテレックスで送信します: インターネット-RFC-1006テレックス+00728722+RFC-1006+03+
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
Note that at least one mandatory service type is
needed.
<コネクションズ>:、:= その少なくとも1つの義務的なサービスが必要であることを\[<の任意のサービス>]が、注意するタイプする<の義務的なサービス>。
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<の義務的なサービス>:、:= 「義務的なサービス:」 「\<サービスタイプ><CR>」
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
<の任意のサービス>:、:= 「任意のサービス:」 「\<サービスタイプ><CR>」
5.3 The RELAY-MTA document
5.3 RELAY-MTAドキュメント
<RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-MTA-document-Identifier> \
<RELAY-MTA-document-body>
A RELAY-MTA document contains the full description of a
single RELAY-MTA. Only one community is allowed.
Since some of the information is community dependent,
it would not be easily possible to have a single
RELAY-MTA document used in different communities.
<リレーMTA-ドキュメント>:、:= >\<Update-インフォメーション>\<RELAY-MTA-ドキュメント識別子>\<RELAY-MTA-文書本体>A RELAY-MTAが記録する<共同体識別子は独身のRELAY-MTAの余すところのない解説を含んでいます。 1つの共同体だけが許容されています。 情報のいくつかが共同体に依存しているので、異なった共同体でただ一つのRELAY-MTAドキュメントを使用させるのは容易に可能でないでしょう。
<RELAY-MTA-document-Identifier> ::= \
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
<リレーMTA-ドキュメント識別子>:、:= \、「リレー-MTA:」 「<UniqueRELAY-MTAkey><CR>」
<RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info>
<リレーMTA-文書本体>:、:= <状態><接続インフォメーション>\<コンタクトインフォメーション>。
<Status> ::= "Status: " ("primary" | "secondary") <CR>
This defines if the RELAY-MTA has 'primary' or
<状態>:、:= 「状態:」 または、「(「予備選挙」| 「2番目」) <CR>Thisは、RELAY-MTAで'予備選挙があるかどうかを定義する'、」
Eppenberger [Page 13] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[13ページ]RFC1465
'secondary' status. See section 4.3 and 6 for more
information.
'二次'の状態。 詳しい情報に関してセクション4.3と6を見てください。
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]
More than one set of connection information may be
present for RELAY-MTAs supporting several networks and
protocol stacks.
<接続インフォメーション>:、:= 1セットの接続情報がいくつかのネットワークをサポートするRELAY-MTAsのために存在していて、議定書を作るかもしれないより\[<エコー・サーバー>]多くの\[<システム>]\[<局所領域>]が積み重ねる<パスワード><RTS>\<の呼ばれた接続><呼んでいる接続>。
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
If the keyword none is present, then no password is
sent with the MTAname when this MTA initiates an RTS
connection or responds to an incoming connection.
Password: none
<パスワード>:、:= 「パスワード:」 キーワードはなにもにそうです。「「\(「」 | 「なにも」という秘密| \は「=\を評価」」という'パスワード'「\」」)<CR>If、プレゼント、次に、このMTAがRTS接続を開始するか、または接続要求に応じるMTAnameと共にパスワードを全く送りません。 パスワード: なし
If the keyword secret is present, then the connection
needs a password which is not made publicly available.
(For example, a community might keep a list of the
passwords at the central coordination point. The list
would then be faxed to the RELAY-MTA managers.)
Password: secret
キーワード秘密が存在しているなら、接続は公的に利用可能にされないパスワードを必要とします。 (例えば、共同体は主要なコーディネートポイントにパスワードのリストを保つかもしれません。 そして、ファックスでRELAY-MTAマネージャにリストを送るでしょう。) パスワード: 秘密
A password must be documented using the
value="password" notation. The double quotes around
the password are needed, consider the case of a single
blank as a password.
Password: value=" "
Password: value="nume-n-ine"
「パスワード」値=記法を使用することでパスワードを記録しなければなりません。 パスワードの周りの二重引用符が必要であり、単一の空白に関するケースがパスワードであるとみなしてください。 パスワード: 「=を評価してください」、「パスワード:」 値は"nume-n-ine"と等しいです。
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<RTS>:、:= <対話モード>、\[<チェックポイントサイズ><ウィンドウサイズ>]
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR>
<対話モード>:、:= 「RTS対話モード:」 「\(「トワ族」| 「モノローグ」)<CR>」
<checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR>
<チェックポイントサイズ>:、:= 「RTSチェックポイントサイズ:」 「\'チェックポイントサイズ'<CR>」
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<ウィンドウサイズ>:、:= 「RTS-ウィンドウサイズ:」 「\'ウィンドウサイズ'<CR>」
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<の呼ばれた接続>:、:= 「着呼アドレス:」 「\<サービスタイプ>」。 " \
Eppenberger [Page 14] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[14ページ]RFC1465
<P-address> "; " <MTS> \
["; " <Service-priority>] <CR>
「<P-アドレス>」。 「<MTS>\[「;」<サービス優先権>]<CR>」
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
MTS-T: mts-transfer
MTS-TP: mts-transfer-protocol
MTS-TP-84: mts-transfer-protocol-1984
See ISO 10021-6, Section 3, chapter 11.1 for more
details on this matter. X.400(84) systems only support
mts-transfer-protocol-1984.
<MTS>:、:= "MTS-T"| "MTS-TP"| 「MTS-TP-84インチのMTS-T:」 mts-転送MTS-TP: mts転送プロトコルMTS-TP-84: mts転送プロトコル1984See ISO10021-6、セクション3、この件に関するその他の詳細のための第11.1章。 X.400(84)システムはmts転送プロトコル1984をサポートするだけです。
<Service-priority> ::= 'Integer 0..99'
The lowest Integer corresponds to the highest priority
as in DNS. It is possible to set different priorities
for each service type. This may be chosen, for
example, to distribute the load amongst different
networks according to their available bandwidth.
<サービス優先権>:、:= '整数0'。'99'最も低いIntegerはDNSのように最優先に対応しています。 それぞれのサービスタイプに異なったプライオリティを設定するのは可能です。 これは、例えばそれらの利用可能な帯域幅に従って異なったネットワークに負荷を分配するために選ばれるかもしれません。
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>
Since called and calling network addresses may differ
in certain configurations and some X.400 systems do
validation on calling network addresses, it is
important to have this information in the RELAY-MTA
document. (Note: a calling X.121 address might change
if the X.25 switch is reconfigured. This will stop a
RELAY-MTA from connecting to other RELAY-MTAs using
address validation without having changed anything at
the higher layers!)
<の呼んでいる接続>:、:= 「以下を呼んで記述してください」 「\<サービスタイプ>」。 「ネットワーク・アドレスと呼ばれて、呼ぶ\<P-アドレス><CR>Sinceはある構成において異なるかもしれません、そして、ネットワーク・アドレスと呼ぶときいくつかのX.400システムが合法化します、そして、RELAY-MTAドキュメントのこの情報を持っているのは重要です。」 (以下に注意してください。 呼んでいるX.121アドレスは、X.25スイッチが再構成されるかどうかを変えるかもしれません。 これは、より高い層で何も変えていなくてアドレス合法化を使用することで接続から他のRELAY-MTAsにRELAY-MTAを止めるでしょう!)
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
It is optional to provide HW/SW information.
Experience, however, has shown that a number of
communication problems were more easily identified and
solved with this information present and up-to-date.
<システム>:、:= 「システム:」 「HWは」 'コンピュータタイプ'と等しいです」。 「\「OS=」'オペレーティングシステム'」。 「\「SW=」提供するのが任意である'MHSソフトウェア'<CR>HW/SW情報。」 しかしながら、経験は多くの意思疎通の問題が、より容易に特定されて、この情報が現在であって最新の状態で解決されたのを示しました。
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
This is a useful but optional extension to the
documentation.
The <MHS-subtree> is local to the RELAY-MTA. The <MHS-
subtree> attributes might be used together with
S=nosuchuser; to do connectivity and availability
tests.
<局所領域>:、:= 「LocalDomain:」 「<MHS-下位木><CR>Thisはドキュメンテーションへの役に立ちますが、任意の拡大です。」 <MHS-下位木>はRELAY-MTAに地方です。 >が結果と考える<MHS-下位木はS=nosuchuserと共に使用されるかもしれません。 接続性と有用性をするのはテストされます。
Eppenberger [Page 15] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[15ページ]RFC1465
<echo-server> ::= "EchoServer: " <X.400 address> <CR>
Some of the RELAY-MTAs might offer an echo server
functionality. It does make sense to document this in
the RELAY-MTA document for test purpose. This field is
optional.
<エコー・サーバー>:、:= 「EchoServer:」 「RELAY-MTAsの<X.400アドレス><CR>Someはエコー・サーバーの機能性を提供するかもしれません。」 それはテストのためのRELAY-MTAドキュメントにこれを記録する意味を目的にします。 この分野は任意です。
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
The contact details for the RELAY-MTA administrator can
be found in the appropriate PERSON document. It is
possible to document a whole team using a distribution
list if this is desired. It is generally better to
document one or more 'real' persons.
<コンタクトインフォメーション>:、:= 適切なPERSONドキュメントで「管理者:」 接触がRELAY-MTA管理者のために詳述する<UniquePersonKey><CR>を見つけることができます。 これが望まれているなら発送先リストを使用するチーム全体を記録するのは可能です。 一般に、それはドキュメント1か、より'本当'の人々により良いです。
5.4 The DOMAIN document
5.4 DOMAINドキュメント
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
<ドメインドキュメント>:、:= <共同体識別子>\<アップデートインフォメーション>\<ドメイン文書本体>。
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
<ドメイン文書本体>:、:= <責任がある<ドメインエントリー>、>\<リレー>。
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
Note that it is not allowed to have equal <Domain-
entry> lines in different DOMAIN documents belonging to
the same MHS community. A Domain-entry line can only
appear in one DOMAIN document.
<ドメインエントリー>:、:= 「ドメイン:」 「それが持つことができない<ORに合っている><MHS-下位木><CR>Noteは>が同じMHS共同体のもの異なったDOMAINドキュメントで裏打ちする<Domain-エントリーと等しいです。」 Domain-エントリー線は1通のDOMAINドキュメントに現れることができるだけです。
<OR-matching> ::= ( "* " | "= " )
This qualifier defines how the following OR address
attributes should be handled for the routing algorithm.
If a '*' is present, a destination address of a message
is matched by the "Domain:" entry if at least the OR
address attributes in the "Domain:" entry are equal to
the destination address.
If a "=" is present, a destination address of a message
is matched by the "Domain:" entry if there are exactly
the same OR attributes in the destination address as in
the "Domain:" entry. (This restriction works for OU4,
OU3, OU2, OU1, O, P, A and C only.)
Example:
a) Domain: * P=switch; A=arcom; C=ch;
b) Domain: = P=switch; A=arcom; C=ch;
The address S=eppenberger; P=switch; A=arcom; C=ch;
matches both cases, a) and b).
The address S=eppenberger; O=unibe; P=switch; A=arcom;
C=ch; matches only case a).
<OR合っている>:、:= ( "* " | "= " ) この資格を与える人は以下のORアドレス属性がルーティング・アルゴリズムのためにどう扱われるべきであるかを定義します。 '*'が存在しているなら、メッセージの送付先アドレスによって合わせられている、「ドメイン:」 エントリーが少なくともORであるなら中に属性を記述する、「ドメイン:」 エントリーは送付先アドレスと等しいです。 「=」が存在しているなら、メッセージの送付先アドレスによって合わせられている、「ドメイン:」 そこであるならエントリーが同じくらい中の送付先アドレスのまさに同じOR属性である、「ドメイン:」 エントリー。 (この制限はOU4、OU3、OU2、OU1、O、P、A、およびCだけに効き目があります。) 例: a) ドメイン: * Pはスイッチと等しいです。 A=arcom。 Cはchと等しいです。 b) ドメイン: = Pはスイッチと等しいです。 A=arcom。 Cはchと等しいです。 アドレスS=eppenberger。 Pはスイッチと等しいです。 A=arcom。 Cはchと等しいです。 マッチ両方のケース、a)とb)。 アドレスS=eppenberger。 O=unibe。 Pはスイッチと等しいです。 A=arcom。 Cはchと等しいです。 マッチはa)をケースに入れるだけです。
Eppenberger [Page 16] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[16ページ]RFC1465
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
This is the person responsible for the listed domains.
His task is to get the agreement of the relaying
RELAY-MTAs and keep the DOMAIN document up-to-date.
This person is the only one authorized to make changes
to this document. Note that multiple administrators
may be listed.
<の責任がある>:、:= 「管理者:」 <UniquePersonKey><CR>、記載されたドメインに責任がある人。 彼のタスクは、リレーの協定にRELAY-MTAsを手に入れて、DOMAINドキュメントを最新に保管することです。 この人はこのドキュメントへの変更を行うのが認可された唯一のものです。 複数の管理者が記載されているかもしれないことに注意してください。
<Relay> ::= "Relay: " \
( 'UniqueRELAY-MTAkey' | \
"Internet-SMTP" ) "; " \
<RELAY-MTA-Priority> <CR>
The priority is used to define the sequence in which
different RELAY-MTAs may be tried in case of failure.
A lower integer corresponds to a higher priority as in
DNS. Priorities 0..49 are used to indicate backup
RELAY-MTAs. Priorities 50..99 are used for RELAY-MTAs
not acting as backup but as relay service provider for
a network service type not supported by the main
RELAY-MTA.
The keyword "Internet-SMTP" is a placeholder for an
RFC1327 gateway connected to Internet. The RELAY-MTA
manager selects a gateway of his choice.
<リレー>:、:= 「以下をリレーしてください」 「\('UniqueRELAY-MTAkey'| \「インターネット-SMTP」)」。 「\<RELAY-MTA、-優先権が使用されている優先権><CR>が失敗の場合に異なったRELAY-MTAsが試みられるかもしれない系列を定義する、」 下側の整数はDNSのように、より高い優先度に対応しています。 プライオリティ0。49は、バックアップRELAY-MTAsを示すのに使用されます。 プライオリティ50。99はバックアップとして機能するのではなく、主なRELAY-MTAによって支持されなかったネットワーク・サービスタイプのためのリレーサービスプロバイダーとして機能するRELAY-MTAsに使用されます。 キーワード「インターネット-SMTP」はインターネットに接続されたRFC1327ゲートウェイへのプレースホルダです。 RELAY-MTAマネージャは彼の選択のゲートウェイを選択します。
<RELAY-MTA-Priority> ::= <Integer 0..99>
<リレーMTA-優先権>:、:= <整数0。99 >。
5.5 The PERSON document
5.5 PERSONドキュメント
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<人ドキュメント>:、:= <共同体識別子>\<アップデートインフォメーション>\<人ドキュメント識別子>\<人文書本体>。
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<人ドキュメント識別子>:、:= 「キー:」 「<UniquePersonKey><CR>」
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> <Fax> <Mail> <Operation>
<人文書本体>:、:= <は\<電話><ファックス><が><操作>に郵送する<RFC822>と><メール>を命名します。
<Name> ::= "Name: " 'name of person' <CR>
The name of the person is given. The issue of the
character set problem is not addressed in this
document. Especially international communities should
restrict themselves to IA5 or ASCII.
<名前>:、:= 「以下を命名してください」 「人の名前が与えられている'人の名前'<CR>。」 文字の組問題の問題は本書では記述されません。 特に国際社会は自分たちをIA5かASCIIに制限するべきです。
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
This is the RFC-822 address of the person. It is often
a big help to know the RFC822 address of someone, for
example if the X.400 system is not reachable. This is
<RFC822>:、:= 「RFC822:」 「<RFC-822アドレスの><CR>Thisは人のRFC-822アドレスです。」 しばしばだれかのRFC822アドレスを知るのは、大きい助けです、例えば、X.400システムが届かないなら。 これはそうです。
Eppenberger [Page 17] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[17ページ]RFC1465
also the reason why it is possible to provide multiple
OR and RFC822 addresses. The first one is considered
the primary one.
複数のORとRFC822にアドレスを供給するのが可能である理由も。 最初のものは第一のものであると考えられます。
6. Routing rules
6. ルート設定規則
All the users within the MHS community have the right to send messages to each other. The general agreement is that the RELAY-MTA infrastructure is used according to the following routing rules. More direct connections based on bilateral agreements are fully accepted.
MHS共同体の中のすべてのユーザには、メッセージを互いに送る権利があります。 一般協定は以下のルーティング規則に従ってRELAY-MTAインフラストラクチャが使用されるということです。 二国間条約に基づくよりダイレクトな接続を完全に受け入れます。
A primary or secondary RELAY-MTA must allow incoming connections from all other primary and secondary RELAY-MTAs with a common stack. Primary RELAY-MTAs must be able to connect to all other primary RELAY-MTAs which share a common stack. A secondary RELAY-MTA must connect to at least one primary RELAY-MTA.
第一の、または、二次のRELAY-MTAは一般的なスタックで他のすべての第一の、そして、二次のRELAY-MTAsから接続要求を許容しなければなりません。 第一のRELAY-MTAsは一般的なスタックを共有する他のすべての第一のRELAY-MTAsに接続できなければなりません。 二次RELAY-MTAは少なくとも1第一のRELAY-MTAに接続しなければなりません。
A message arriving at a RELAY-MTA must either be sent to the next RELAY-MTA based on the DOMAIN documents of the MHS community or it is sent to an MTA closer to the destination based on local routing decisions. The following algorithm must be used when forwarding a message to the next RELAY-MTA:
MHS共同体のDOMAINドキュメントに基づく次のRELAY-MTAにRELAY-MTAに到着するメッセージを送らなければならない、さもなければ、ローカルのルーティング決定に基づく目的地の、より近くでそれをMTAに送ります。 次のRELAY-MTAにメッセージを転送するとき、以下のアルゴリズムを使用しなければなりません:
1) Select the relevant DOMAIN document by searching for a match of
the Recipient address in the message with the entries in the
document.
1) ドキュメントのメッセージのエントリーがあるRecipientアドレスのマッチを捜し求めることによって、関連DOMAINドキュメントを選択してください。
If your own RELAY-MTA appears in this list, this indicates one of
the following:
あなた自身のRELAY-MTAがこのリストに現れるなら、これは以下の1つを示します:
- You offered relay services for another RELAY-MTA with higher
priority. Continue with step 2 to decide on the next RELAY-MTA.
- あなたは、より高い優先度がある別のRELAY-MTAのためにリレーサービスを提供しました。 ステップ2で、次のRELAY-MTAを決め続けてください。
- Your RELAY-MTA is the final destination according the DOMAIN
document of your community. You need to forward the message to
the final destination according local routing information.
- あなたのRELAY-MTAはあなたの共同体のDOMAINドキュメント最終的な目的地です。 あなたは、ローカルのルーティング情報最終的な目的地にメッセージを転送する必要があります。
2) From the list of RELAY-MTAs select those that have at least one
common network service type with your own RELAY-MTA.
2) RELAY-MTAsのリストから、少なくとも1つの一般的なネットワーク・サービスタイプがあなた自身のRELAY-MTAと共にあるものを選択してください。
3) Now delete all secondary RELAY-MTAs from the list where no
direct connection is desired. For remaining RELAY-MTAs in the
list no difference is made anymore between primary and secondary
status.
3) 今度は、どんなダイレクト接続も望まれていないリストからすべての二次RELAY-MTAsを削除してください。 リストにRELAY-MTAsのままで残っているのにおいて、違いは全くそれ以上第一の、そして、二次の状態の間で作られません。
4) Select from this reduced set of RELAY-MTAs the one with the
highest RELAY-MTA-priority. If there is more than one RELAY-MTA
4) RELAY-MTAsのこの減少しているセットから、最も高いRELAY-MTA-優先度があるものを選択してください。 1RELAY-MTAがあれば
Eppenberger [Page 18] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[18ページ]RFC1465
having the same priority, then select a RELAY-MTA of your choice.
If your own RELAY-MTA appears in that list, then you are not
allowed to send to a RELAY-MTA with lower or equal priority.
同じ優先権を持っていて、そして、選択のRELAY-MTAを選択してください。 あなた自身のRELAY-MTAがそのリストに現れるなら、あなたは下側の、または、等しい優先度と共にRELAY-MTAに発信できません。
5) If there are no service-priorities set in the corresponding
RELAY-MTA document indicating which service type to use, you are
free to choose the service type for connecting to the RELAY-MTA.
However, if there are specific priorities set then select the
service type with the highest priority.
5) どのサービスタイプを使用したらよいかを示す対応するRELAY-MTAドキュメントに設定されたサービスプライオリティが全くなければ、あなたは自由にRELAY-MTAに接続するためのサービスタイプを選ぶことができます。 しかしながら、特定のプライオリティセットがあれば、最優先でサービスタイプを選んでください。
6) If the connection fails then try other service types in the
sequence of descending priority.
6) 接続が失敗するなら、下る優先権の系列で他のサービスタイプを裁いてください。
7) If no connection works for the selected RELAY-MTA, then check
in the list for the one with the same priority, if possible, or
else select one with the next lower priority. If there is another
RELAY-MTA with a RELAY-MTA-priority between 0..49, then select it
and proceed at step 5. Without another RELAY-MTA to try the
currently selected RELAY-MTA will be retried.
7) どんな接続も選択されたRELAY-MTAに勤めないなら、できれば、同じ優先権でもののためのリストを預けるか、または次の低優先度で1つを選択してください。 0の間には、RELAY-MTA-優先がある状態で別のRELAY-MTAがあれば。49 次に、それを選択してください、そして、ステップ5で続いてください。 別のRELAY-MTAがなければ、現在選択されたRELAY-MTAを試みるのは再試行されるでしょう。
6.1 How to use RELAY-MTA-priorities
6.1 RELAY-MTA-プライオリティを使用する方法
An example helps to explain the usage of RELAY-MTA-priorities. Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory service types in the community REMOTEmail. The MHS domain P=REMOTE; A=ARCOM; C=CH; operates MTA-B, only connected to public X.25. A second RELAY-MTA which is connected to both, Internet and public X.25 is needed to offer relay services. A connection using Internet is considered cheap in this example. Both service types are available at MTA-A. Since MTA-B is the only RELAY-MTA responsible for relaying messages to P=REMOTE; A=ARCOM; C=CH; to the final destination it must have the highest priority.
例は、RELAY-MTA-プライオリティの用法を説明するのを助けます。 インターネット/TCP/RFC1006とPublic-X.25/X.25/TP0はサービスが共同体REMOTEmailをタイプするのが義務的です。 MHSドメインP=REMOTE。 A=ARCOM。 CはCHと等しいです。 公共のX.25に接続されただけであるMTA-Bを操作します。 両方、インターネット、および公共のX.25に接続される第2のRELAY-MTAが、リレーサービスを提供するのに必要です。 インターネットを使用している接続はこの例で安いと考えられます。 両方のサービスタイプはMTA-Aに手があいています。 以来、MTA-BはP=REMOTEにメッセージをリレーするのに責任がある唯一のRELAY-MTAです。 A=ARCOM。 CはCHと等しいです。 最終的な目的地に、それは最優先を持たなければなりません。
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 20
RELAY-MTA: P=MTA-C; A=ARCOM; C=CH;MTAname=MTA-C; 80
共同体: REMOTEmailドメイン: * P=リモート。 A=ARCOM。 CはCHと等しいです。 リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-B 20リレー-MTA: P=MTA-C。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-C 80
__________________________
+-------+ X.25 +-------+ ( )
| MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (__________________________)
\ /
TCP/IP \ /X.25
+-------+
| MTA-C |
+-------+
__________________________ +-------+ X.25+-------+ ( ) | MTA-A+-------------+ MTA-B+(Pはリモートな; A=ARCOM;C=CHと等しい;) +-------+ +-------+ (__________________________)\/TCP/IP\/X.25+-------+ | MTA-C| +-------+
Eppenberger [Page 19] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[19ページ]RFC1465
If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH; then the rules of chapter 6 are evaluated:
MTA-Aが、P=REMOTEであるときに伝言を伝える必要があるなら。 A=ARCOM。 CはCHと等しいです。 次に、第6章の規則は評価されます:
1. MTA-B and MTA-C are possible destinations
1. MTA-BとMTA-Cは可能な目的地です。
2. MTA-B and MTA-C are reachable from MTA-A
2. MTA-BとMTA-CはMTA-Aから届いています。
3. MTA-B is a primary RELAY-MTA (not relevant in this example)
3. MTA-Bは第一のRELAY-MTAです。(この例で関連しない)です。
4. MTA-B has the highest priority.
4. MTA-Bには、最優先があります。
5. MTA-B doesn't have specific service type lines documented.
MTA-A chooses public X.25, since it is the only possibility
to connect to MTA-B.
5. MTA-Bは特定のサービスタイプ台詞を記録させません。 MTA-Aは、それがMTA-Bに接続する唯一の可能性であるので、公共のX.25を選びます。
6. No other service types are available if the connection
fails.
6. 接続が失敗するなら、他のどんなサービスタイプも手があいていません。
7. MTA-C has a priority of 80, it is not a backup RELAY-MTA.
MTA-A must spool the message and try to connect directly to
MTA-B.
7. MTA-Cには、80の優先があって、それはバックアップRELAY-MTAではありません。 MTA-絶対に必要なものは、メッセージをスプールして、直接MTA-Bに接続しようとします。
The organisation running MTA-A could save money by sending messages for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C. Since the connection between MTA-C and the destination MTA-B is also expensive, the organisation running MTA-C would have to pay for external relay traffic. Setting a lower priority for MTA-C forces the other RELAY- MTAs with public X.25 connectivity to take their share of the cost.
機構走行MTA-AはMHSドメインP=REMOTEへのメッセージを送ることによって、お金を貯めることができるでしょう。 A=ARCOM。 CはCHと等しいです。 MTA-Cを通して。 また、MTA-Cと目的地MTA-Bとの関係も高価であるので、MTA-Cを走らせる機構は外部のリレー交通の代価を払わなければならないでしょう。 MTA-Cに低優先度を設定するので、公共のX.25の接続性がある他のRELAY- MTAsはやむを得ず彼らの費用のシェアを取ります。
Note that forcing other RELAY-MTAs to use a specific stack should be avoided wherever possible by offering RELAY-MTAs with equal priority for all mandatory network services. This can be an important financial issue for MHS communities spanning several organisations, it is not relevant in general for an MHS community within a single organisation.
他のRELAY-MTAsに特定のスタックを使用させるのがどこでも、RELAY-MTAsを提供することによって等しい優先権ですべての義務的なネットワーク・サービスには可能であるところで避けられるべきであることに注意してください。 これがいくつかの機構にかかるMHS共同体に、重要な財政的な問題であるかもしれない、一般に、MHS共同体において、それは単純組織の中で関連していません。
6.2 How to use RELAY-MTA-priorities for backup RELAY-MTAS
6.2 バックアップRELAY-MTASにRELAY-MTA-プライオリティを使用する方法
Two RELAY-MTAs offer real backup connectivity for the MHS domain P=REMOTE; A=ARCOM; C=CH;. It is therefore possible to set RELAY-MTA priorities in the range of 0..49 for both RELAY-MTAs. MTA-B will be the preferred one since it has the higher priority. If the connection to MTA-B fails, a sending RELAY-MTA may immediately try to connect to MTA-C.
2RELAY-MTAsがMHSドメインP=REMOTEのために本当のバックアップの接続性を提供します。 A=ARCOM。 CはCHと等しいです; したがって、0の範囲にRELAY-MTAプライオリティをはめ込むのは可能です。49 両方のRELAY-MTAsのために。 それには、より高い優先度があるので、MTA-Bは都合のよい方でしょう。 MTA-Bとの接続が失敗するなら、送付RELAY-MTAはすぐに、MTA-Cに接続しようとするかもしれません。
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
共同体: REMOTEmailドメイン: * P=リモート。 A=ARCOM。 CはCHと等しいです。 リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-B 10
Eppenberger [Page 20] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[20ページ]RFC1465
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-C 30
__________________________
+-------+ +-------+ ( )
| MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (__________________________)
\ /
\ +-------+
-----------+ MTA-C |
+-------+
__________________________ +-------+ +-------+ ( ) | MTA-A+-------------+ MTA-B+(Pはリモートな; A=ARCOM;C=CHと等しい;) +-------+ +-------+ (__________________________) \ / \ +-------+ -----------+ MTA-C| +-------+
6.3 Load Sharing
6.3負荷分割法
It is possible to set equal priorities to do some sort of load sharing. However, most implementations are not able to do random selection of RELAY-MTAs with equal priorities but have a fixed configuration. If load sharing is really needed then it is suggested to split up the MHS domain into several MHS subtrees and document them separately with a set of RELAY-MTAs with different priorities.
プライオリティは、ある種の負荷分割法をするためにセットと等しいですそれが可能である。 しかしながら、ほとんどの実現は、等しいプライオリティがあるRELAY-MTAsのランダム・セレクションをしますが、固定構成を持つことができません。 負荷分割法が本当に必要であるなら、それは、MHSドメインをいくつかのMHS下位木に分けて、別々に異なったプライオリティがあるRELAY-MTAsの1セットでそれらを記録するために示されます。
An example is provided for illustration of the first possibility with equal RELAY-MTA-priorities:
等しいRELAY-MTA-プライオリティと共に最初の可能性のイラストに例を提供します:
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
_ __________________________
) +-------+ ( )
)--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (__________________________)
) /
) +-------+/
)--+ MTA-C |
_) +-------+
共同体: REMOTEmailドメイン: * P=リモート。 A=ARCOM。 CはCHと等しいです。 リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-B 10リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-C 10 _ __________________________ ) +-------+ ( ) )、--+ MTA-B+--(P=リモート。 A=ARCOM。 CはCHと等しいです。 ) ) +-------+ (__________________________) ) / ) +-------+、/)、--、+ MTA-C| _) +-------+
And here is an example where the MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
DOMAIN document: Note that in this example both RELAY-MTAs serve
as backup RELAY-MTAs.
そして、ここに、MHSドメインCがCH; ADMD=ARCOM; PRMD=REMOTEと等しい例があります; ○ = 大きいOrgはそれ自身のDOMAINドキュメントで記録されます: この例では、両方のRELAY-MTAsがバックアップRELAY-MTAsとして機能することに注意してください。
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
共同体: REMOTEmailドメイン: * P=リモート。 A=ARCOM。 CはCHと等しいです。 リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-B 10リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-C 30
Community: REMOTEmail
Domain: * O=Big-Org; P=REMOTE; A=ARCOM; C=CH;
共同体: REMOTEmailドメイン: * Oは大きいOrgと等しいです。 P=リモート。 A=ARCOM。 CはCHと等しいです。
Eppenberger [Page 21] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[21ページ]RFC1465
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 30
_ __________________________
) +-------+ ( )
)--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (__________________________)
) \/
) /\ _____________________________________
) +-------+ ( )
)--+ MTA-C |--( O=Big-Org; P=REMOTE; A=ARCOM; C=CH; )
_) +-------+ (_____________________________________)
リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-C 10リレー-MTA: P=リモート。 A=ARCOM。 CはCHと等しいです; MTAname=MTA-B 30 _ __________________________ ) +-------+ ( ) )、--+ MTA-B+--(P=リモート。 A=ARCOM。 CはCHと等しいです。 ) ) +-------+ (__________________________) ) \/ ) /\ _____________________________________ ) +-------+ ( ) )、--、+ MTA-C|--(Oは大きいOrgと等しいです; Pはリモートな; A=ARCOM;C=CHと等しいです;) _) +-------+ (_____________________________________)
7. Open issues
7. 未解決の問題
Currently there are about 35 RELAY-MTAs within the COSINE-MHS service. A rough guess is that a network with about 60 RELAY-MTAs is still manageable provided there are automated tools for MTA configuration. If there are more MTAs applying for RELAY-MTA status in an MHS community, then either an X.500 based solution should be ready or a core set of about 30 well operated super-RELAY-MTAs should form a backbone, documented within a specific MHS community.
現在、COSINE-MHSサービスの中におよそ35RELAY-MTAsがあります。 荒い推測はMTA構成のための自動化されたツールがあればおよそ60RELAY-MTAsとのネットワークがまだ処理しやすいということです。 MHS共同体でRELAY-MTA状態に申し込むより多くのMTAsがあれば、X.500のベースの解決策が準備ができるべきですか、またはおよそ30上手に操作された超RELAY-MTAsの1人の巻き癖が特定のMHS共同体の中に記録された背骨を形成するべきです。
Since the RELAY-MTA document contains information about the supported X.400 version (84 or 88), it is possible for an X.400(88) system to select with higher priority an (88)RELAY-MTA. The rules in chapter 6 could be modified to select X.400(88) systems first if the sending RELAY-MTA is an (88) system itself. The issue of how to establish an X.400(88) RELAY-MTA infrastructure within an MHS community is for further study.
RELAY-MTAドキュメントが支持されたX.400バージョン(84か88)の情報を含んでいるので、X.400(88)システムが、より高い優先度で(88)RELAY-MTAを選択するのは、可能です。 第6章の規則は、最初に、発信しているRELAY-MTAが(88)システム自体であるならX.400(88)システムを選択するように変更されるかもしれません。 さらなる研究にはMHS共同体の中でどうX.400(88) RELAY-MTAインフラストラクチャを確立するかに関する問題があります。
Eppenberger [Page 22] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[22ページ]RFC1465
Appendix A: Document examples for the COSINE-MHS community
付録A: COSINE-MHS共同体のためのドキュメントの例
Instead of creating artificial documents to show an example document set, this appendix contains extracts from a real operational X.400 service. The research and development community in Europe has used X.400 for several years. This proposal was initially written to address this community only and solve the urgent routing and coordination problems. Contributions from different experts have made it more flexible and therefore hopefully useful for other MHS communities.
例の文献集合を見せているために人工のドキュメントを作成することの代わりに、この付録は全く操作上のX.400サービスからの抽出を含んでいます。 ヨーロッパの研究開発共同体は数年間X.400を使用しています。 この提案は、初めは、この共同体だけに演説して、緊急のルーティングと協調問題を解決するために書かれました。異なった専門家からの貢献で、よりフレキシブルであって、したがって、願わくはそれの他のMHS共同体の役に立ちました。
Appendix A1: The COMMUNITY document
付録A1: COMMUNITYドキュメント
Community: COSINE-MHS
# The COSINE-MHS service is a MHS community formed by the European
# academic and research networks with additional contacts in all
# other continents.
#
# The coordination is done by the COSINE-MHS project team.
#
Update: FORMAT=V3; DATE=921218; START=930201
#
Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
#
Phone: +41 1-262-31-43
Fax: +41 1-261-81-88
#
Mail: SWITCH Head Office /
MHS Coordination Service /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+1
#
Mail-server: S=mhs-server; O=switch; OU1=nic;
P=SWITCH; A=ARCOM; C=CH;
FTP-server: nic.switch.ch; cosine; user@domain
#
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
Macro: IXI TELEX+00728722+X.25(80)+06+
#
Mandatory-Service: Public-X.25/X.25/TP0
# The public X.25 network. X.25 is supported in most X.400
# applications and mandatory in X.400 anyhow.
#
Mandatory-Service: Internet/TCP/RFC1006
共同体: COSINE-MHSが調整するCOSINE-MHS#は追加接触が他のすべての#大陸にある状態でアカデミック、そして、研究のヨーロッパの#ネットワークによって形成されたMHS共同体です。 # # COSINE-MHSプロジェクト・チームはコーディネートを完了しています。 # 以下をアップデートしてください。 形式はV3と等しいです。 921218と=の日付を入れてください。 =930201#アドレスを始めてください: Sはプロジェクト・チームと等しいです。 ○ = 切り替わってください。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 # 以下に電話をしてください。 +41 1-262-31-43Fax: +41 1-261-81-88 #以下を郵送してください。 スイッチ本社/MHSコーディネートサービス/Limmatquai138 / CH-8001チューリッヒ/スイス#届く: 09:00-12:00; 14:00-17:30; UTC+1#メールサーバ: S=mhs-サーバ。 ○ = 切り替わってください。 OU1=nic。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 FTPサーバ: nic.switch.ch。 コサイン。 user@domain #マクロ: Int-X25(80)は+00728722+X.25(80)+01+マクロをテレックスで送信します: インターネット-RFC-1006は+00728722+RFC-1006+03+マクロをテレックスで送信します: IXIはX.25(80)+06+#義務的な+00728722+サービスをテレックスで送信します: 公共のX.25がネットワークでつなぐ公共のX.25/X.25/TP0#。 X.25はとにかくほとんどのX.400#アプリケーションで支持されていてX.400で義務的です。 # 義務的なサービス: インターネット/TCP/RFC1006
Eppenberger [Page 23] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[23ページ]RFC1465
# The Internet, standing for the global TCP/IP network of the # research and development community # RFC1006 is considered a solution to ease migration to OSI. It will # be replaced by TP4/CLNS as soon as a reliable service is # available. # Optional-Service: Int-CLNS/CLNS/TP4 # The RARE Connectionless pilot service. Current participants are # NORDUnet, SURFnet, CERN, NSFnet and SWITCH. # Optional-Service: EMPB-X.25/X.25/TP0 # The International X.25 Infrastructure covering most countries in # Europe. The absence of volume tariffs make it a preferred choice.
# インターネット、#研究開発共同体#RFC1006のグローバルなTCP/IPネットワークを表すのは、移動をOSIに緩和するために解決策であると考えられます。 それは取り替えるでしょう。#信頼できるサービスが#利用可能であるとすぐに、TP4/CLNSに取り替えてください。 # 任意のサービス: Int-CLNS/CLNS/TP4#RARE Connectionlessはサービスを操縦します。 現在の関係者は、#NORDUnetと、SURFnetと、CERNと、NSFnetとSWITCHです。 # 任意のサービス: #ヨーロッパのほとんどの国を覆うEMPB-X.25/X.25/TP0#の国際X.25 Infrastructure。 ボリューム関税の欠如はそれを都合のよい選択にします。
Appendix A2: Example of a RELAY-MTA document
付録A2: RELAY-MTAドキュメントに関する例
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
#
RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch
#
Status: primary
#
Password: none
RTS-dialog-mode: MONOLOGUE
#
Called-address: Public-X.25/X.25/TP0;
"591"/Int-X25(80)=22847971014520+CUDF+03010100;
MTS-TP-84
Calling-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014520;
#
Called-address: Internet/TCP/RFC1006;
"591"/Internet-RFC-1006=chx400.switch.ch;
MTS-TP-84
Calling-address: Internet/TCP/RFC1006;
Internet-RFC-1006=chx400.switch.ch
#
Called-address: EMPB-X.25/X.25/TP0;
"591"/IXI=20432840100520+CUDF+03010100;
MTS-TP-84
Calling-address: EMPB-X.25/X.25/TP0;
IXI=20432840100520;
#
Calling-address: Int-CLNS/CLNS/TP4;
"591"/NS+39756F11111111010000014560AA00040005E100;
MTS-TP-84
共同体: コサイン-MHS#アップデート: 形式はV3と等しいです。 921218と=の日付を入れてください。 =930201#リレー-MTAを始動してください: Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 MTAname=chx400.switch.ch#状態: 予備選挙#Password: なにも、RTS対話モード: モノローグ#着呼アドレス: 公共のX.25/X.25/TP0。 「591」/Int-X25(80)=22847971014520+CUDF+03010100。 MTS-TP-84呼びアドレス: 公共のX.25/X.25/TP0。 Int-X25(80)=22847971014520。 # 着呼アドレス: インターネット/TCP/RFC1006。 インターネット「591」/RFC-1006=chx400.switch.ch。 MTS-TP-84呼びアドレス: インターネット/TCP/RFC1006。 インターネット-RFC-1006=chx400.switch.ch#着呼アドレス: EMPB-X.25/X.25/TP0。 「591」/IXI=20432840100520+CUDF+03010100。 MTS-TP-84呼びアドレス: EMPB-X.25/X.25/TP0。 IXI=20432840100520。 # 呼びアドレス: Int-CLNS/CLNS/TP4。 「591」/ナノ秒+39756F11111111010000014560AA00040005E100。 MTS-TP-84
Eppenberger [Page 24] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[24ページ]RFC1465
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
# For X.400(88) over CLNS
#
Calling-address: Int-CLNS/CLNS/TP4;
"592"/NS+39756F11111111010000014560AA00040005E100;
MTS-T
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
System: HW=SUN 4/690MP; OS=SunOS 4.1.1; SW=PP-6.0
#
LocalDomain: O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
EchoServer: S=echo; O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
Administrator: CN=Felix Kugler, O=SWITCH, C=CH
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
着呼アドレス: CLNS#呼びアドレスの上のX.400(88)のためのDCC+756+x11111111010000014560AA00040005E100##: Int-CLNS/CLNS/TP4。 「592」/ナノ秒+39756F11111111010000014560AA00040005E100。 MTS-T着呼アドレス: DCC+756+x11111111010000014560AA00040005E100#システム: HWは太陽4/690MPと等しいです。 SunOS4.1OS=.1。 SWはpp-6.0#LocalDomainと等しいです: ○ = 切り替わってください。 OU1=chx400。 Pはスイッチと等しいです。 A=arcom。 Cはchと等しいです。 # EchoServer: Sはエコーと等しいです。 ○ = 切り替わってください。 OU1=chx400。 Pはスイッチと等しいです。 A=arcom。 Cはchと等しいです。 # 管理者: C=CH管理者、フェリクス・CN=クーグラー、O=は切り替わります: ○ = CNはクリストフ・グラフと等しく、切り替わってください、そして、CはCHと等しいです。
Appendix A3: Example of a DOMAIN document
付録A3: DOMAINドキュメントに関する例
Community: COSINE-MHS # Update: FORMAT=V3; DATE=921218; START=930201 ## Domain: * P=SWITCH; A=ARCOM; C=CH; Domain: * P=SANDOZ; A=ARCOM; C=CH; Domain: * P=ABB; A=ARCOM; C=CH; Domain: * P=UBS; A=ARCOM; C=CH; Domain: * P=ISREC; A=ARCOM; C=CH; Domain: * P=ALCATEL; A=ARCOM; C=CH; Domain: * P=ITU; A=ARCOM; C=CH; Domain: * P=OSILABMAIL; A=ARCOM; C=CH; Domain: * P=WHO; A=ARCOM; C=CH; Domain: * P=CERN; A=ARCOM; C=CH; Domain: * P=CERBERUS; A=ARCOM; C=CH; # Administrator: CN=Christoph Graf, O=SWITCH, C=CH Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; C=CH; # RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 0 # RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 10
共同体: コサイン-MHS#アップデート: 形式はV3と等しいです。 921218と=の日付を入れてください。 =930201##ドメインを始めてください: * Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 ドメイン: * Pはサンドと等しいです。 A=ARCOM。 CはCHと等しいです。 ドメイン: * P=ABB。 A=ARCOM。 CはCHと等しいです。 ドメイン: * Pはオブスと等しいです。 A=ARCOM。 CはCHと等しいです。 ドメイン: * P=ISREC。 A=ARCOM。 CはCHと等しいです。 ドメイン: * Pはアルカテルと等しいです。 A=ARCOM。 CはCHと等しいです。 ドメイン: * PはITUと等しいです。 A=ARCOM。 CはCHと等しいです。 ドメイン: * P=OSILABMAIL。 A=ARCOM。 CはCHと等しいです。 ドメイン: * PはWHOと等しいです。 A=ARCOM。 CはCHと等しいです。 ドメイン: * P=CERN。 A=ARCOM。 CはCHと等しいです。 ドメイン: * Pはケルベロスと等しいです。 A=ARCOM。 CはCHと等しいです。 # 管理者: C=CH管理者、クリストフ・CN=グラフ、O=は切り替わります: Sは郵便局長と等しいです。 ○ = 切り替わってください。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 # リレー-MTA: Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 MTAname=chx400.switch.ch。 0 #リレー-MTA: Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 MTAname=vms.switch。 10
Appendix A4: Example of a PERSON document
付録A4: PERSONドキュメントに関する例
Community: COSINE-MHS # Update: FORMAT=V3; DATE=921218; START=930201
共同体: コサイン-MHS#アップデート: 形式はV3と等しいです。 921218と=の日付を入れてください。 =930201を始めてください。
Eppenberger [Page 25] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[25ページ]RFC1465
#
Key: CN=Christoph Graf, O=SWITCH, C=CH
#
Name: Christoph Graf
#
Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
RFC822: Graf@switch.ch
#
Phone: +41 1 2565454
Fax: +41 1 2618133
#
Mail: SWITCH Head Office /
Christoph Graf /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+0100
# キー: C=CH#は、クリストフ・CN=グラフ、O=が切り替わると命名します: クリストフグラフ#Address: Sはグラフと等しいです。 ○ = 切り替わってください。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。 RFC822: Graf@switch.ch #電話: +41 1 2565454Fax: +41 1つの2618133#メール: スイッチ本社/クリストフグラフ/Limmatquai138 / CH-8001チューリッヒ/スイス#届く: 09:00-12:00; 14:00-17:30; UTC+0100
Eppenberger [Page 26] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[26ページ]RFC1465
Appendix B: BNF Definitions
付録B: BNF定義
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<P-address> "; " <MTS> \
["; " <Service-priority>] <CR>
<の呼ばれた接続>:、:= 「着呼アドレス:」 「\<サービスタイプ>」。 「\<P-アドレス>」。 「<MTS>\[「;」<サービス優先権>]<CR>」
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>
<の呼んでいる接続>:、:= 「以下を呼んで記述してください」 「\<サービスタイプ>」。 「\<P-アドレス><CR>」
<checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR>
<チェックポイントサイズ>:、:= 「RTSチェックポイントサイズ:」 「\'チェックポイントサイズ'<CR>」
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>
<共同体ドキュメント>:、:= <共同体識別子>\<アップデートインフォメーション>\<共同体文書本体>。
<COMMUNITY-document-body> ::= <Coordination> \
[{<Macro-definition>}] \
{<Connections>}
<共同体文書本体>:、:= <コーディネート>\[<マクロ定義>]\<コネクションズ>。
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) <CR>
<共同体識別子>:、:= 「共同体:」 「\('共同体名'| <DirectoryName>)<CR>」
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]
<接続インフォメーション>:、:= <パスワード><RTS>\<の呼ばれた接続><呼んでいる接続>、\[<システム>]\[<局所領域>]\[<エコー・サーバー>]
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
<コネクションズ>:、:= <の義務的なサービス>、\[<の任意のサービス>]
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
<コンタクトインフォメーション>:、:= 「管理者:」 <UniquePersonKey><CR>。
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <Operation> <File-server>
<コーディネート>:、:= <メール><電話><ファックス>\<は><操作><ファイルサーバー>に郵送します。
<Country-Code> ::= 'Two Character Country Code ISO-3166'
<国名略号>:、:= '2キャラクター国名略号ISO-3166'
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR>
<対話モード>:、:= 「RTS対話モード:」 「\(「トワ族」| 「モノローグ」)<CR>」
<DirectoryName> ::= 'Distinguished Name'
<DirectoryName>:、:= '分類名'
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<ドメインドキュメント>:、:= <共同体識別子>\<アップデートインフォメーション>、\
Eppenberger [Page 27] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[27ページ]RFC1465
<DOMAIN-document-body>
<ドメイン文書本体>。
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
<ドメイン文書本体>:、:= <責任がある<ドメインエントリー>、>\<リレー>。
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
<ドメインエントリー>:、:= 「ドメイン:」 「><MHS-下位木><CR>にOR合っている<」
<echo-server> ::= "EchoServer: " <X.400 address> <CR>
<エコー・サーバー>:、:= 「EchoServer:」 「<X.400アドレス><CR>」
<EMail> ::= "Address: " <X.400 address> <CR>
<メール>:、:= 「以下を記述してください」 「<X.400アドレス><CR>」
<email-server> ::= "Mail-server: "<X.400 address> <CR>
<Eメールサーバ>:、:= 「メールサーバ:」 「<X.400アドレス><CR>」
<extension> ::= 'local extension'
<拡張子>:、:= '地方の拡大'
<Fax> ::= "Fax: " <tel-no-list> <CR>
<ファックス>:、:= 「Fax:」 「<telリストがない><CR>」
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>]}
<ファイルサーバー>:、:= <Eメールサーバ>[<FTPサーバ>]\、[<FTAM-サーバ>]
<FTAM-server> ::= "FTAM-server: " <P-address> "; "\
'account-name' ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
<FTAM-サーバ>:、:= 「FTAM-サーバ:」 「<P-アドレス>」。 「\'アカウント名'[「;」'パスワード']\、[「;、X.500、」 <DirectoryName>] <CR>、」
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
<FTPサーバ>:、:= 「FTPサーバ:」 「'ドメイン名'」。 「\'アカウント名'[「;」'パスワード']<CR>」
<int-pref> ::= 'international prefix'
<int-pref>:、:= '国際的な接頭語'
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
<局所領域>:、:= 「LocalDomain:」 「<MHS-下位木><CR>」
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
<マクロ定義>:、:= 「マクロ:」 「'マクロ名'」「\'マクロ価値の'<CR>」
<Mail> ::= "Mail: " 'postal address information' <CR>
<メール>:、:= 「以下を郵送してください」 「'郵便の宛先情報'<CR>」
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<の義務的なサービス>:、:= 「義務的なサービス:」 「\<サービスタイプ><CR>」
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
<MHS-下位木>:、:= 等しい..組織..名前..等しい..等しい..等しい..等しい..等しい 「「\「C=」<国名略号>」」。
Eppenberger [Page 28] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[28ページ]RFC1465
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
<MTS>:、:= "MTS-T"| "MTS-TP"| 「MTS-TP-84インチ」
<Name> ::= "Name: " 'name of person' <CR>
<名前>:、:= 「以下を命名してください」 「'人の名前'<CR>」
<national number> ::= 'national telephone number'
<の国家の番号>:、:= '国家の電話番号'
<Network-name> ::= 'Name of a network'
<ネットワーク名>:、:= 'ネットワークの名前'
<Network-service> ::= 'Name of a network service'
<ネットワーク・サービス>:、:= 'ネットワーク・サービスの名前'
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone> <CR>
<操作>:、:= 「届く:、」 「「「-」 <は>を調節する」<時間>、」、;、\<の時間帯の><CR>。
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
<の任意のサービス>:、:= 「任意のサービス:」 「\<サービスタイプ><CR>」
<OR-matching> ::= ( "* " | "= " )
<OR合っている>:、:= ( "* " | "= " )
<P-address> ::= 'String encoded Presentation Address'
<P-アドレス>:、:= 'ストリングのコード化されたPresentation Address'
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
<パスワード>:、:= 「パスワード:」 「「\(「」 | 「なにも」という秘密| \は「=\を評価」」という'パスワード'「\」」)<CR>。
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<人ドキュメント>:、:= <共同体識別子>\<アップデートインフォメーション>\<人ドキュメント識別子>\<人文書本体>。
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<人ドキュメント識別子>:、:= 「キー:」 「<UniquePersonKey><CR>」
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<人文書本体>:、:= <が><メール>を<RFC822>と命名する、\
<Phone> ::= "Phone: " <tel-no-list> <CR>
<電話>:、:= 「以下に電話をしてください」 「<telリストがない><CR>」
<Relay> ::= "Relay: " \
'UniqueRELAY-MTAkey' "; " \
<RELAY-MTA-Priority> <CR>
<リレー>:、:= 「以下をリレーしてください」 「\'UniqueRELAY-MTAkey'」。 「\<リレーMTA-優先権><CR>」
<RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-MTA-document-Identifier> \
<RELAY-MTA-document-body>
<リレーMTA-ドキュメント>:、:= <共同体識別子>\<アップデートインフォメーション>\<リレーMTA-ドキュメント識別子>\<リレーMTA-文書本体>。
<RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info>
<リレーMTA-文書本体>:、:= <状態><接続インフォメーション>\<コンタクトインフォメーション>。
<RELAY-MTA-document-Identifier> ::= \
<リレーMTA-ドキュメント識別子>:、:= \
Eppenberger [Page 29] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[29ページ]RFC1465
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
「リレー-MTA:」 「<UniqueRELAY-MTAkey><CR>」
<RELAY-MTA-Priority> ::= <Integer 0..99>
<リレーMTA-優先権>:、:= <整数0。99 >。
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
<の責任がある>:、:= 「管理者:」 <UniquePersonKey><CR>。
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
<RFC822>:、:= 「RFC822:」 「<RFC-822アドレスの><CR>」
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<RTS>:、:= <対話モード>、\[<チェックポイントサイズ><ウィンドウサイズ>]
<Service-priority> ::= 'Integer 0..99'
<サービス優先権>:、:= '整数0'。99'
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
<サービスタイプ>:、:= 「<は」 /」 \<ネットワーク・サービス>と>をネットワークで命名する」/」 \<トランスポート・プロトコル>。
<Status> ::= "Status: " ("primary" | "secondary") <CR>
<状態>:、:= 「状態:」 「(「予備選挙」| 「二次」)<CR>」
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
<システム>:、:= 「システム:」 「HWは」 'コンピュータタイプ'と等しいです」。 「\「OS=」'オペレーティングシステム'」。 「\「SW=」'MHSソフトウェア'<CR>」
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<telリストがない>:、:= <tel-番号>。; [「」、<tel-番号>、]
<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}
<tel-番号>:、:= 「+」 <int-pref>、「「<国家の数の>\[「x」<拡張子>]、」
<time> ::= 'hh:mm'
<時間>:、:= 'hh: mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
<の時間帯の>:、:= (「UTC+」| "UTC") 'hhmm'
<Transport-Protocol> ::= 'Name of a transport protocol'
<トランスポート・プロトコル>:、:= 'トランスポート・プロトコルの名前'
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
<UniquePersonKey>:、:= (<X.400は>を記述します| <DirectoryName>)
<UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )
<UniqueRELAY-MTAkey>:、:= 「[「Pは」 'PRMDname'と等しい」;、「]、\、[「」 ='ADMDname'」;、「]、\「」 <C=国名略号>」 ; 「\「MTAname=」'MTAname') | <DirectoryName>、)、」
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>
<アップデートインフォメーション>:、:= 「以下をアップデートしてください」 形式はV3と等しいです。 'yymmdd'\」という「日付=」。 「始め=」'yymmdd'\[「; =を終わらせてください」という'yymmdd']<CR>。
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<ウィンドウサイズ>:、:= 「RTS-ウィンドウサイズ:」 「\'ウィンドウサイズ'<CR>」
Eppenberger [Page 30] RFC 1465 Routing Coordination for X.400 Services May 1993
サービス1993年5月にX.400のためにコーディネートを発送するEppenberger[30ページ]RFC1465
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
<X.400は>を記述します:、:= 'ORアドレス、ISO10021-2Annex F'
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-MTA-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }
コーディネートを発送する<X.400がセット>を記録します:、:= \<共同体ドキュメント>\<リレーMTA-ドキュメント>、\<ドメインドキュメント>、\<人ドキュメント>。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Urs Eppenberger SWITCH Head Office Limmatquai 138 CH-8001 Zurich Switzerland
ウルスEppenbergerスイッチ本社Limmatquai138CH-8001チューリッヒスイス
Phone: +41 1 261 8112 Fax: +41 1 261 8133
以下に電話をしてください。 +41 1 261 8112Fax: +41 1 261 8133
EMail: Eppenberger@switch.ch
S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
メール: Eppenberger@switch.ch S=Eppenberger。 ○ = 切り替わってください。 Pはスイッチと等しいです。 A=ARCOM。 CはCHと等しいです。
Comments to the document may also be sent to the distribution list wg-msg@rare.nl of the RARE Working Group on Mail and Messaging.
また、メールとMessagingの上のRARE作業部会の発送先リスト wg-msg@rare.nl にドキュメントへのコメントを送るかもしれません。
Eppenberger [Page 31]
Eppenberger[31ページ]
一覧
スポンサーリンク
