RFC1801 日本語訳
1801 MHS use of the X.500 Directory to support MHS Routing. S. Kille. June 1995. (Format: TXT=156462 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kille Request for Comments: 1801 ISODE Consortium Category: Experimental June 1995
Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1801年のISODE共同体カテゴリ: 実験的な1995年6月
X.400-MHS use of the X.500 Directory to support X.400-MHS Routing
X.400-MHSルート設定を支持するX.500ディレクトリのX.400-MHS使用
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Table of Contents
目次
1 Introduction 3
2 Goals 3
3 Approach 5
4 Direct vs Indirect Connection 6
5 X.400 and RFC 822 8
6 Objects 9
7 Communities 10
8 Routing Trees 11
8.1 Routing Tree Definition . . . . . . . 12
8.2 The Open Community Routing Tree . . . . . 12
8.3 Routing Tree Location . . . . . . . 13
8.4 Example Routing Trees . . . . . . . 13
8.5 Use of Routing Trees to look up Information . . 13
9 Routing Tree Selection 14
9.1 Routing Tree Order . . . . . . . . 14
9.2 Example use of Routing Trees . . . . . . 15
9.2.1 Fully Open Organisation . . . . . 15
9.2.2 Open Organisation with Fallback . . . 15
9.2.3 Minimal-routing MTA . . . . . . 16
9.2.4 Organisation with Firewall . . . . . 16
9.2.5 Well Known Entry Points . . . . . 16
9.2.6 ADMD using the Open Community for Advertising 16
9.2.7 ADMD/PRMD gateway . . . . . . . 17
10 Routing Information 17
10.1 Multiple routing trees . . . . . . . 20
10.2 MTA Choice . . . . . . . . . . 22
10.3 Routing Filters . . . . . . . . . 25
10.4 Indirect Connectivity . . . . . . . 26
11 Local Addresses (UAs) 27
11.1 Searching for Local Users . . . . . . 30
12 Direct Lookup 30
13 Alternate Routes 30
1 序論3 2Goals3 3Approach5 4Direct対Indirect Connection6 5X.400とルート設定Trees. . . . . . 15 9.2の情報. . 13 9ルート設定Tree Selection14 9.1ルート設定Tree Order. . . . . . . . 14 9.2Example使用を見上げるルート設定TreesのRFC822 8 6Objects9 7のCommunities10 8ルート設定Trees11 8.1ルート設定Tree Definition. . . . . . . 12 8.2オープンCommunityルート設定Tree. . . . . 12 8.3ルート設定Tree Location. . . . . . . 13 8.4Exampleルート設定Trees.138.5Use; 1つの完全に開いている機構. . . . . 15 9.2.2が機構を開く、後退. . . 15 9.2.3最小量のルーティングMTAと共に、ファイアウォール. . . . . 16 9.2.5のよく知られているエントリーとの.169.2.4機構が広告に疎生群落を使用することで.6ADMDを.169.2に指す、16、9; 2.7 ADMD/PRMDゲートウェイ.17 10経路情報17 10.1Multipleルーティング木. . . . . . . 20 10.2のMTA Choice. . . . . . . . . . 22 10.3ルート設定Filters. . . . . . . . . 25 10.4Indirect Connectivity. . . . . . . 26 11Local Addrローカルユーザー. . . . . . 30 12Direct Lookup30 13Alternate Routes30のためのesses(UAs)27 11.1Searching
Kille Experimental [Page 1] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[1ページ]RFC1801X.400-MHSルート設定
13.1 Finding Alternate Routes . . . . . . . 30
13.2 Sharing routing information . . . . . . 31
14 Looking up Information in the Directory 31
15 Naming MTAs 33
15.1 Naming 1984 MTAs . . . . . . . . . 35
16 Attributes Associated with the MTA 35
17 Bilateral Agreements 36
18 MTA Selection 38
18.1 Dealing with protocol mismatches . . . . . 38
18.2 Supported Protocols . . . . . . . . 39
18.3 MTA Capability Restrictions . . . . . . 39
18.4 Subtree Capability Restrictions . . . . . 40
19 MTA Pulling Messages 41
20 Security and Policy 42
20.1 Finding the Name of the Calling MTA . . . . 42
20.2 Authentication . . . . . . . . . 42
20.3 Authentication Information . . . . . . 44
21 Policy and Authorisation 46
21.1 Simple MTA Policy . . . . . . . . 46
21.2 Complex MTA Policy . . . . . . . . 47
22 Delivery 49
22.1 Redirects . . . . . . . . . . 49
22.2 Underspecified O/R Addresses . . . . . . 50
22.3 Non Delivery . . . . . . . . . . 51
22.4 Bad Addresses . . . . . . . . . 51
23 Submission 53
23.1 Normal Derivation . . . . . . . . 53
23.2 Roles and Groups . . . . . . . . . 53
24 Access Units 54
25 The Overall Routing Algorithm 54
26 Performance 55
27 Acknowledgements 55
28 References 56
29 Security Considerations 57
30 Author's Address 58
A Object Identifier Assignment 59
B Community Identifier Assignments 60
C Protocol Identifier Assignments 60
D ASN.1 Summary 61
E Regular Expression Syntax 71
List of Figures
1 Location of Routing Trees . . . . . . 12
2 Routing Tree Use Definition . . . . . . 14
3 Routing Information at a Node . . . . . 17
4 Indirect Access . . . . . . . . . 25
5 UA Attributes . . . . . . . . . 27
6 MTA Definitions . . . . . . . . . 33
7 MTA Bilateral Table Entry . . . . . . 36
13.1 MTA35 17Bilateral Agreements36 18MTA Selection38 18と共にAlternate Routes. . . . . . . 30 13.2Sharingルーティング情報が.31 14Lookingであることがディレクトリ31 15Naming MTAs33 15.1Naming1984MTAs.35 16Attributes Associatedの情報にわかります; 1 プロトコルに対処すると、.38 18.2のSupportedプロトコル. . . . . . . . 39 18.3MTA Capability Restrictions. . . . . . 39 18.4Subtree Capability Restrictions. . . . . 40 19MTA Pulling Messages41 20SecurityとPolicy42 20はミスマッチします; 1 呼ぶMTA. . . . 42 20.2認証. . . . . . . . . 42 20.3認証情報. . . . . . 44 21方針と認可46 21.1の簡単なMTA方針. . . . . . . . 46 21.2の複雑なMTA方針. . . . . . . . 47 22配送49 22.1の名前が非配送.51 22.4に悪い状態で.49 22.2のUnderspecified O/Rアドレス. . . . . . 50 22.3を転送するのがわかるのが.51 23に服従53 23.1の通常の派生を記述します… . . . . . アルゴリズム54 26パフォーマンス55 27承認55 28参照56 29セキュリティ問題を発送して、57 30作者のものは58を記述します。53 23.2の役割、総合的を.53 24アクセスユニット54 25分類する、物の識別子課題59B共同体識別子課題60Cプロトコル識別子課題60D ASN; 1 数字1ルート設定木. . . . . . 12 2のルート設定木の位置の概要61E正規表現構文71リストはノード. . . . . 17 4の間接アクセス. . . . . . . . . 25 5UA属性. . . . . . . . . 27 6MTA定義. . . . . . . . . 33 7のMTAの双方のテーブル項目. . . . . . 36で定義. . . . . . 14 3経路情報を使用します。
Kille Experimental [Page 2] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[2ページ]RFC1801X.400-MHSルート設定
8 Bilateral Table Attribute . . . . . . 37
9 Supported MTS Extensions . . . . . . . 39
10 Subtree Capability Restriction . . . . . 40
11 Pulling Messages . . . . . . . . . 41
12 Authentication Requirements . . . . . . 43
13 MTA Authentication Parameters . . . . . 45
14 Simple MTA Policy Specification . . . . . 46
15 Redirect Definition . . . . . . . . 48
16 Non Delivery Information . . . . . . . 50
17 Bad Address Pointers . . . . . . . . 52
18 Access Unit Attributes . . . . . . . 53
19 Object Identifier Assignment . . . . . . 59
20 Transport Community Object Identifier Assignments 60
21 Protocol Object Identifier Assignments . . . 61
22 ASN.1 Summary . . . . . . . . . 61
8 双方のテーブル属性. . . . . . 37 9は、メッセージ. . . . . . . . . 41 12の認証要件. . . . . . 43 13MTA認証パラメタ. . . . . 45 14の簡単なMTA方針仕様. . . . . 46 15の再直接の定義を引きながら、MTS拡張子. . . . . . . 39 10下位木能力制限. . . . . 40 11をサポートしました; .48 16 非配送情報. . . . . . . 50 17の悪いアドレス・ポインタ. . . . . . . . 52 18アクセスユニット属性. . . . . . . 53 19物の識別子課題. . . . . . 59 20輸送共同体物の識別子課題60 21プロトコル物の識別子課題. . . 61 22ASN.1概要. . . . . . . . . 61
1. Introduction
1. 序論
MHS Routing is the problem of controlling the path of a message as it traverses one or more MTAs to reach its destination recipients. Routing starts with a recipient O/R Address, and parameters associated with the message to be routed. It is assumed that this is known a priori, or is derived at submission time as described in Section 23.
MHSルート設定は目的地受取人に届くように1MTAsを横断するのでメッセージの経路を制御するという問題です。 ルート設定は受取人O/R Address、および発送されるべきメッセージに関連しているパラメタから始まります。 セクション23で説明されるようにこれが先験的に知られているか、または服従時に引き出されると思われます。
The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. There are a number of things which need to be considered to determine this. These are discussed in the subsequent sections. A description of the overall routing process is given in Section 25.
ルーティングによる主要な問題はAddressをO/RからMTA(次のホップ)に写像することです。 これは何らかの意味で目的地UAに「より近い」MTAになるでしょう。 直接受取人UAにメッセージを渡すことができるまで繰り返してこれをします。 これを決定すると考えられる必要がある多くのものがあります。 その後のセクションでこれらについて議論します。 セクション25で総合的なルーティングの過程の記述を与えます。
2. Goals
2. 目標
Application level routing for MHS is a complex procedure, with many requirements. The following goals for the solution are set:
MHSのためのアプリケーションレベルルーティングは多くの要件がある複雑な手順です。 解決策の以下の目標は設定されます:
o Straightforward to manage. Non-trivial configuration of routing
for current message handling systems is a black art, often
involving gathering and processing many tables, and editing
complex configuration files. Many problems are solved in a very
ad hoc manner. Managing routing for MHS is the most serious
headache for most mail system managers.
o 管理するために、簡単です。 現在のメッセージハンドリングシステムのためのルーティングの重要な構成は魔術です、しばしば多くのテーブルを集めて、処理して、複雑な構成ファイルを編集することを伴って。 多くの問題が非常に臨時の方法で解決されています。 MHSのためにルーティングを管理するのは、ほとんどのメールシステム・マネージャにとって、最も重大な頭痛です。
o Economic, both in terms of network and computational resources.
o ネットワークとコンピュータのリソースでは、経済です。
Kille Experimental [Page 3] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[3ページ]RFC1801X.400-MHSルート設定
o Robust. Errors and out of date information shall cause minimal
and localised damage.
o 強健。 誤りと時代遅れの情報は最小量の、そして、局限された損害をもたらすものとします。
o Deal with link failures. There needs to be some ability to choose
alternative routes. In general, it is desirable that the routing
approach be redundant.
o リンクの故障に対処してください。 代替のルートを選ぶ何らかの能力があるのが必要です。 一般に、ルーティングアプローチが余分であることは、望ましいです。
o Load sharing. Information on routes shall allow "equal" routes
to be specified, and thus facilitate load sharing.
o 負荷分割法。 ルートに関する情報は、「等しい」ルートが指定されるのを許容して、その結果、負荷分割法を容易にするものとします。
o Support format and protocol conversion
o サポート形式とプロトコル変換
o Dynamic and automatic. There shall be no need for manual
propagation of tables or administrator intervention.
o ダイナミックであって、自動です。 テーブルか管理者介入の手動の伝播の必要は全くないでしょう。
o Policy robust. It shall not allow specification of policies which
cause undesirable routing effects.
o 方針強健です。 それは望ましくないルーティング効果を引き起こす方針の仕様を許容しないものとします。
o Reasonably straightforward to implement.
o 実行するために合理的に簡単です。
o Deal with X.400, RFC 822, and their interaction.
o X.400、RFC822、およびそれらの相互作用に対処してください。
o Extensible to other mail architectures
o 他のメール構造に広げることができます。
o Recognise existing RFC 822 routing, and coexist smoothly.
o 既存のRFC822ルーティングを認識してください、そして、スムーズに共存してください。
o Improve RFC 822 routing capabilities. This is particularly
important for RFC 822 sites not in the SMTP Internet.
o RFC822ルーティング能力を改良してください。 SMTPインターネットでないところのRFC822サイトには、これは特に重要です。
o Deal correctly with different X.400 protocols (P1, P3, P7), and
with 1984, 1988 and 1992 versions.
o 正しく、バージョンは異なったX.400プロトコル(P1、P3、P7)、1984、1988、および1992を取扱います。
o Support X.400 operation over multiple protocol stacks (TCP/IP,
CONS, CLNS) and in different communities.
o 複数のプロトコル・スタック(TCP/IP、コンズ、CLNS)の上と、そして、異なった共同体でX.400操作を支持してください。
o Messages shall be routed consistently. Alternate routing
strategies, which might introduce unexpected delay, shall be used
with care (e.g., routing through a protocol converter due to
unavailability of an MTA).
o メッセージは一貫して発送されるものとします。 迂回中継戦略(不測の遅延を導入するかもしれない)は慎重(例えば、MTAの使用不能によるプロトコルコンバータを通したルーティング)に使用されるものとします。
o Delay between message submission and delivery shall be minimised.
This has indirect impact on the routing approaches used.
o メッセージ提案と配送の間の遅れは最小となるものとします。 これで、ルーティングアプローチへの間接的な影響を使用します。
o Interact sensibly with ADMD services.
o 分別よくADMDサービスと対話してください。
o Be global in scope
o 範囲でグローバルであってください。
Kille Experimental [Page 4] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[4ページ]RFC1801X.400-MHSルート設定
o Routing strategy shall deal with a scale of order of magnitude
1,000,000 -- 100,000,000 MTAs.
o ルート設定戦略は桁1,000,000 -- 100,000,000MTAsのスケールに対処するものとします。
o Routing strategy shall deal with of order 1,000,000 -- 100,000,000
Organisations.
o 戦略が対処するものとするオーダー1,000,000 -- 100,000,000Organisationsのルート設定。
o Information about alterations in topology shall propagate rapidly
to sites affected by the change.
o トポロジーでの変更に関する情報は急速に変化で影響を受けるサイトに伝播されるものとします。
o Removal, examination, or destruction of messages by third parties
shall be difficult. This is hard to quantify, but "difficult"
shall be comparable to the effort needed to break system security
on a typical MTA system.
o 第三者によるメッセージの取り外し、試験、または破壊が難しくなるでしょう。 これは定量化しにくいのですが、「難しいこと」は典型的なMTAシステムの上でシステムセキュリティを壊すのに必要である努力に匹敵するようになるでしょう。
o As with current Research Networks, it is recognised that
prevention of forged mail will not always be possible. However,
this shall be as hard as can be afforded.
o 現在のResearch Networksのように、偽造メールの防止がいつも可能になるというわけではないと認められます。 しかしながら、これは都合することができるのと同じくらい困難でしょう。
o Sufficient tracing and logging shall be available to track down
security violations and faults.
o 十分なたどるのと伐採は、安全の侵害と欠点を捜し出すために利用可能になるでしょう。
o Optimisation of routing messages with multiple recipients, in
cases where this involves selection of preferred single recipient
routes.
o これが都合のよいただ一つの受取人ルートの品揃えにかかわる場合における複数の受取人とのルーティング・メッセージの最適化。
The following are not initial goals:
↓これは当初の目標ではありません:
o Advanced optimisation of routing messages with multiple
recipients, noting dependencies between the recipients to find
routes which would not have been chosen for any of the single
recipients.
o 独身の受取人のいずれにも選ばれていないルートを見つけるために受取人の間の依存に注意して、複数の受取人とのルーティング・メッセージの最適化を進めました。
o Dynamic load balancing. The approach does not give a means to
determine load. However, information on alternate routes is
provided, which is the static information needed for load
balancing.
o ダイナミック・ロードバランスをとること。 アプローチは負荷を決定する手段を与えません。 しかしながら、代替経路の情報(ロードバランシングに必要である静的な情報である)を提供します。
3. Approach
3. アプローチ
A broad problem statement, and a survey of earlier approaches to the problem is given in the COSINE Study on MHS Topology and Routing [8]. The interim (table-based) approach suggested in this study, whilst not being followed in detail, broadly reflects what the research X.400 (GO-MHS) community is doing. The evolving specification of the RARE table format is defined in [5]. This document specifies the envisaged longer term approach.
広い問題声明、および、より早いことの問題へのアプローチがMHS Topologyとルート設定[8]のときにCOSINE Studyで与えられる調査。 当座(テーブルベースの)のアプローチはこの研究に示されました、続かれないのが研究X.400(GO-MHS)共同体がしていることを詳細に、そして、広く反映しますが。 RAREテーブル形式の発展仕様は[5]で定義されます。 このドキュメントはアプローチという考えられたより長い期間を指定します。
Kille Experimental [Page 5] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[5ページ]RFC1801X.400-MHSルート設定
Some documents have made useful contributions to this work:
いくつかのドキュメントがこの仕事への有益な貢献をしました:
o A paper by the editor on MHS use of directory, which laid out the
broad approach of mapping the O/R Address space on to the DIT [7].
o エディタのそばのO/R AddressスペースをDIT[7]に写像する広いアプローチを広げたディレクトリのMHS使用に関する論文。
o Initial ISO Standardisation work on MHS use of Directory for
routing [19]. Subsequent ISO work in this area has drawn from
earlier drafts of this specification.
o 初期のISO Standardisationはディレクトリのルーティング[19]のMHS使用に取り組みます。 この領域でのその後のISO仕事はこの仕様の以前の草稿から描いてあります。
o The work of the VERDI Project [3].
o ヴェディProject[3]の仕事。
o Work by Kevin Jordan of CDC [6].
o CDC[6]のケビン・ジョーダンで、働いてください。
o The routing approach of ACSNet [4, 17] paper. This gives useful
ideas on incremental routing, and replicating routing data.
o ACSNet[4、17]紙のルーティングアプローチ。 これは増加のルーティングと、ルーティングデータを模写することに関する役に立つ考えを与えます。
o A lot of work on network routing is becoming increasingly
relevant. As the MHS routing problem increases in size, and
network routing increases in sophistication (e.g., policy based
routing), the two areas have increasing amounts in common. For
example, see [2].
o ネットワークルーティングに対する多くの仕事がますます関連するようになっています。 MHSルーティング問題が大きくなって、ネットワークルーティングが洗練を増やすのに従って(例えば、方針はルーティングを基礎づけました)、2つの領域が増加する量が共通です。 例えば、[2]を見てください。
4. Direct vs Indirect Connection
4. 間接的な接続に対してダイレクトです。
Two extreme approaches to routing connectivity are:
ルーティングの接続性への2つの極端なアプローチは以下の通りです。
1. High connectivity between MTAs. An example of this is the way
the Domain Name Server system is used on the DARPA/NSF Internet.
Essentially, all MTAs are fully interconnected.
1. MTAsの間の高い接続性。 この例はDomain Name ServerシステムがDARPA/NSFインターネットで使用される方法です。 本質的には、すべてのMTAsが完全にインタコネクトされます。
2. Low connectivity between MTAs. An example of this is the UUCP
network.
2. MTAsの間の少ない接続性。 この例はUUCPネットワークです。
In general an intermediate approach is desirable. Too sparse a connectivity is inefficient, and leads to undue delays. However, full connectivity is not desirable, for the reasons discussed below. A number of general issues related to relaying are now considered. The reasons for avoiding relaying are clear. These include.
一般に、中間的アプローチは望ましいです。 まばら過ぎる接続性は、効率が悪く、不当な遅延につながります。 しかしながら、完全な接続性は以下で議論した理由で望ましくはありません。 リレーに関連する多くの一般答弁が現在、考えられます。 リレーするのを避ける理由は明確です。 これらは含んでいます。
o Efficiency. If there is an open network, it is desirable that it
be used.
o 効率。 オープンネットワークがあれば、それが使用されるのは、望ましいです。
o Extra hops introduce delay, and increase the (very small)
possibility of message loss. As a basic principle, hop count
shall be minimised.
o 余分なホップは、遅れを導入して、メッセージの損失の(非常に小さい)の可能性を増加させます。 基本原理として、ホップカウントは最小となるものとします。
o Busy relays or Well Known Entry points can introduce high delay
and lead to single point of failure.
o 忙しいリレーかWell Known Entryポイントが失敗の単一のポイントに高い遅れとリードを紹介できます。
Kille Experimental [Page 6] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[6ページ]RFC1801X.400-MHSルート設定
o If there is only one hop, it is straightforward for the user to
monitor progress of messages submitted. If a message is delayed,
the user can take appropriate action.
o あれば、ワンバウンドであるだけであり、ユーザにとって、提出されたメッセージの進歩をモニターするのは簡単です。 メッセージが遅らせられるなら、ユーザは適切な行動を取ることができます。
o Many users like the security of direct transmission. It is an
argument often given very strongly for use of SMTP.
o 多くのユーザが直線伝動のセキュリティが好きです。 それはSMTPの使用のためにしばしば非常に強く与えられた議論です。
Despite these very powerful arguments, there are a number of reasons why some level of relaying is desirable:
これらの非常に強力な議論にもかかわらず、何らかのレベルのリレーが望ましい多くの理由があります:
o Charge optimisation. If there is an expensive network/link to be
traversed, it may make sense to restrict its usage to a small
number of MTAs. This would allow for optimisation with respect to
the charging policy of this link.
o 最適化を請求してください。 横断されるために高価なネットワーク/リンクがあれば、それは用法をMTAsの少ない数に制限する意味になるかもしれません。 これはこのリンクの充電方針に関して最適化を考慮するでしょう。
o Copy optimisation. If a message is being sent to two remote MTAs
which are close together, it is usually optimal to send the
message to one of the MTAs (for both recipients), and let it pass
a copy to the other MTA.
o 最適化をコピーしてください。 近くに一緒にある2リモートMTAsにメッセージを送るなら、通常、MTAs(両方の受取人のための)の1つにメッセージを送って、もう片方のMTAにコピーを渡させるのは、最適です。
o To access an intermediate MTA for some value added service. In
particular for:
o 何らかの付加価値が付いたサービスのために中間的MTAにアクセスするために。 特定なように:
-- Message Format Conversion
-- メッセージ・フォーマット変換
-- Distribution List expansion
-- 分配List拡大
o Dealing with different protocols. The store and forward approach
allows for straightforward conversion. Relevant cases include:
o 異なったプロトコルに対処します。 店と前進のアプローチは簡単な変換を考慮します。 関連ケースは:
-- Provision of X.400 over different OSI Stacks (e.g.,
Connectionless Network Service).
-- 異なったOSI Stacks(例えば、Connectionless Network Service)の上のX.400の設備。
-- Use of a different version of X.400.
-- X.400の異なった見解の使用。
-- Interaction with non-X.400 mail services
-- 非X.400メールサービスとの相互作用
o To compensate for inadequate directory services: If tables are
maintained in an ad hoc manner, the manual effort to gain full
connectivity is too high.
o 不十分な電話番号案内を補うために: テーブルが臨時の方法で維持されるなら、完全な接続性を獲得するための手動労力は高過ぎます。
o To hide complexity of structure. If an organisation has many
MTAs, it may still be advantageous to advertise a single entry
point to the outside world. It will be more efficient to have an
extra hop, than to (widely) distribute the information required to
connect directly. This will also encourage stability, as
organisations need to change internal structure much more
frequently than their external entry points. For many
o 構造の複雑さを隠すために。 機構に多くのMTAsがあるなら、1エントリー・ポイントの外の世界に広告を出すのはまだ有利であるかもしれません。 余分なホップを持っているのは(広く)直接接続するのに必要である情報を分配するより効率的でしょう。 また、機構が、それらの外部のエントリー・ポイントよりはるかに頻繁に内部の構造を変える必要があるとき、これは安定性を奨励するでしょう。 多くのために
Kille Experimental [Page 7] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[7ページ]RFC1801X.400-MHSルート設定
organisations, establishing such firewalls is high priority.
機構であり、そのようなファイアウォールを確立するのは、高い優先度です。
o To handle authorisation, charging and security issues. In
general, it is desirable to deal with user oriented authorisation
at the application level. This is essential when MHS specific
parameters shall be taken into consideration. It may well be
beneficial for organisations to have a single MTA providing access
to the external world, which can apply a uniform access policy
(e.g., as to which people are allowed access). This would be
particularly true in a multi-vendor environment, where different
systems would otherwise have to enforce the same policy --- using
different vendor-specific mechanisms.
o 認可、請求、および安全保障問題を扱うために。 一般に、ユーザに対応するのがアプリケーションレベルで認可を適応させたのは、望ましいです。 MHSの特定のパラメタが考慮に入れられるものとするとき、これは不可欠です。 機構が独身のMTAに外界へのアクセスを提供させるのは、たぶん有益でしょう。外界は一定のアクセス方針(例えばアクセスが人々に許されている)を適用できます。 これはマルチベンダ環境で特に本当でしょう。そうでなければ、異系統はそこで同じ方針を実施しなければならないでしょう。--- 異なった業者特有のメカニズムを使用します。
In summary there are strong reasons for an intermediate approach. This will be achieved by providing mechanisms for both direct and indirect connectivity. The manager of a configuration will then be able to make appropriate choices for the environment.
概要には、中間的アプローチの強い理由があります。 これは、ダイレクトものと同様に間接的な接続性にメカニズムを提供することによって、達成されるでしょう。 構成のマネージャはその時、環境のための適当な選択をすることができるでしょう。
Two models of managing large scale routing have evolved:
大きいスケールルーティングを管理する2つのモデルが発展しました:
1. Use of a global directory/database. This is the approach
proposed here.
1. グローバルなディレクトリ/データベースの使用。 これはここで提案されたアプローチです。
2. Use of a routing table in each MTA, which is managed either by a
management protocol or by directory. This is coupled with means
to exchange routing information between MTAs. This approach is
more analogous to how network level routing is commonly performed.
It has good characteristics in terms of managing links and
dealing with link related policy. However, it assumes limited
connectivity and does not adapt well to a network environment
with high connectivity available.
2. 各MTAにおける経路指定テーブルの使用。(MTAは管理プロトコルかディレクトリによって管理されます)。 これはMTAsの間でルーティング情報を交換する手段に結びつけられます。 このアプローチはルーティングがネットワークどれくらい平らであるか一般的に実行されていた状態で、より類似しています。 それには、リンクを管理することに関して良い特性があります、そして、リンクに対処すると、方針は関係づけられました。 しかしながら、それは、限られた接続性を仮定して、高い接続性が利用可能な状態でネットワーク環境によく順応しません。
5. X.400 and RFC 822
5. X.400とRFC822
This document defines mechanisms for X.400 message routing. It is important that this can be integrated with RFC 822 based routing, as many MTAs will work in both communities. This routing document is written with this problem in mind, and some work to verify this has been done. support for RFC 822 routing using the same basic infrastructure is defined in a companion document [13]. In addition support for X.400/RFC 822 gatewaying is needed, to support interaction. Directory based mechanisms for this are defined in [16]. The advantages of the approach defined by this set of specifications are:
このドキュメントはX.400メッセージルーティングのためにメカニズムを定義します。 多くのMTAsが両方の共同体で働きながら掘るベースのRFC822とこれを統合できるのは重要です。 念頭にこの問題でこのルーティングドキュメントを書きます、そして、これについて確かめるいくらかの仕事をしました。仲間ドキュメント[13]で同じ基本的なインフラストラクチャを使用するRFC822ルーティングのサポートを定義します。 さらに、X.400/RFC822gatewayingのサポートが金属・担体相互作用に必要です。 これのためのディレクトリに基づいているメカニズムは[16]で定義されます。 このセットの仕様で定義されたアプローチの利点は以下の通りです。
o Uniform management for sites which wish to support both protocols.
o 両方のプロトコルをサポートしたがっているサイトのための一元管理。
o Simpler management for gateways.
o ゲートウェイのための、より簡単な管理。
Kille Experimental [Page 8] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[8ページ]RFC1801X.400-MHSルート設定
o Improved routing services for RFC 822 only sites.
o 改良されたルーティングはRFC822のためにサイトだけを修理します。
For sites which are only X.400 or only RFC 822, the mechanisms associated with gatewaying or with the other form of addressing are not needed.
X.400だけかRFC822であるにすぎないサイトにおいて、gatewayingかもう片方のフォームのアドレシングに関連しているメカニズムは必要ではありません。
6. Objects
6. 物
It is useful to start with a manager's perspective. Here is the set of object classes used in this specification. It is important that all information entered relates to something which is being managed. If this is achieved, configuration decisions are much more likely to be correct. In the examples, distinguished names are written using the String Syntax for Distinguished Names [11]. The list of objects used in this specification is:
マネージャの見解から始まるのは役に立ちます。 ここに、この仕様で使用される物のクラスのセットがあります。 情報が入ったすべてが管理されている何かに関連するのは、重要です。 これが達成されるなら、構成決定ははるかに正しい傾向があります。 例に、分類名は、Distinguished Names[11]にString Syntaxを使用することで書かれています。 この仕様で使用される物のリストは以下の通りです。
User An entry representing a single human user. This will typically
be named in an organisational context. For example:
独身の人間のユーザの代理をするユーザAnエントリー。 これはorganisational文脈で通常命名されるでしょう。 例えば:
CN=Edgar Smythe,
O=Zydeco Services, C=GB
CNはエドガー・スマイス、O=Zydecoサービスと等しく、CはGBと等しいです。
This entry would have associated information, such as telephone
number, postal address, and mailbox.
このエントリーは電話番号や、郵便の宛先や、メールボックスなどの情報を関連づけたでしょう。
MTA A Message Transfer Agent. In general, the binding between
machines and MTAs will be complex. Often a small number of MTAs
will be used to support many machines, by use of local approaches
such as shared filestores. MTAs may support multiple protocols,
and will identify separate addressing information for each
protocol.
To achieve support for multiple protocols, an MTA is modelled as
an Application Process, which is named in the directory. Each MTA
will have one or more associated Application Entities. Each
Application Entity is named as a child of the Application Process,
using a common name which conveniently identifies the Application
Entity relative to the Application Process. Each Application
Entity supports a single protocol, although different Application
Entities may support the same protocol. Where an MTA only
supports one protocol or where the addressing information for all
of the protocols supported have different attributes to represent
addressing information (e.g., P1(88) and SMTP) the Application
Entity(ies) may be represented by the single Application Process
entry.
MTA Aメッセージ転送エージェント。 一般に、マシンとMTAsの間の結合は複雑になるでしょう。 しばしば、MTAsの少ない数は多くのマシンを支えるのに使用されるでしょう、共有されたfilestoresなどの地方のアプローチの使用で。 MTAsは複数のプロトコルをサポートするかもしれなくて、各プロトコルのための別々のアドレス指定情報を特定するでしょう。 複数のプロトコルのサポートを達成するために、MTAはApplication Processとしてモデル化されます。(Application Processはディレクトリで命名されます)。 各MTAには、1関連Application Entitiesがあるでしょう。 各Application EntityはApplication Processの子供として命名されます、便利にApplication Processに比例してApplication Entityを特定する一般名を使用して。 異なったApplication Entitiesは同じプロトコルをサポートするかもしれませんが、各Application Entityはただ一つのプロトコルをサポートします。 MTAが1つのプロトコルしかサポートしないか、またはサポートされたプロトコルのすべてには情報(例えば、P1(88)とSMTP)Application Entity(ies)を記述する表す異なった属性があるのでアドレス指定情報が単一のApplication Processエントリーで表されるかもしれないところで。
User Agent (Mailbox) This defines the User Agent (UA) to which mail
may be delivered. This will define the account with which the UA
is associated, and may also point to the user(s) associated with
これがUserエージェント(UA)を定義するそれのメールが配達されるかもしれないユーザエージェント(メールボックス)。 UAがどれで関連していて、また、(s)が関連づけたユーザを示すかもしれないかでこれはアカウントを定義するでしょう。
Kille Experimental [Page 9] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[9ページ]RFC1801X.400-MHSルート設定
the UA. It will identify which MTAs are able to access the UA.
(In the formal X.400 model, there will be a single MTA delivering
to a UA. In many practical configurations, multiple MTAs can
deliver to a single UA. This will increase robustness, and is
desirable.)
UA。 それは、どのMTAsがUAにアクセスできるかを特定するでしょう。 (礼儀正しいX.400モデルには、UAに配送する独身のMTAがあるでしょう。 多くの実用的な構成では、複数のMTAsが独身のUAに配送できます。 これは、丈夫さを増加させて、望ましいです。)
Role Some organisational function. For example:
役割のSome organisationalは機能します。 例えば:
CN=System Manager, OU=Sales,
O=Zydeco Services, C=GB
CNはシステム・マネージャ、OU=販売O=Zydecoサービス、C=GBと等しいです。
The associated entry would indicate the occupant of the role.
関連エントリーは役割の占有者を示すでしょう。
Distribution Lists There would be an entry representing the
distribution list, with information about the list, the manger,
and members of the list.
分配Lists Thereはリスト、飼葉桶の情報で発送先リストを表すエントリーと、リストのメンバーでしょう。
7. Communities
7. 共同体
There are two basic types of agreement in which an MTA may participate in order to facilitate routing:
MTAが掘るのを容易にするために参加するかもしれない協定の2人の基本型がいます:
Bilateral Agreements An agreement between a pair of MTAs to route
certain types of traffic. This MTA pair agreement usually
reflects some form of special agreement and in general bilateral
information shall be held for the link at both ends. In some
cases, this information shall be private.
あるタイプの交通を発送する1組のMTAsの間の双方のAgreements An協定。 通常、このMTA組協定は何らかの形式の特別な協定を反映します、そして、一般に、双方の情報は両端のリンクとして保持されるものとします。 いくつかの場合、この情報は個人的になるでしょう。
Open Agreements An agreement between a collection of MTAs to behave
in a cooperative fashion to route traffic. This may be viewed as
a general bilateral agreement.
交通を発送するために協力的なファッションで振る舞うMTAsの収集の間のAgreements An協定を開いてください。 これは一般的な二国間条約として見なされるかもしれません。
It is important to ensure that there are sufficient agreements in place for all messages to be routed. This will usually be done by having agreements which correspond to the addressing hierarchy. For X.400, this is the model where a PRMD connects to an ADMD, and the ADMD provides the inter PRMD connectivity, by the ability to route to all other ADMDs. Other agreements may be added to this hierarchy, in order to improve the efficiency of routing. In general, there may be valid addresses, which cannot be routed to, either for connectivity or policy reasons.
十分な協定がすべての発送されるべきメッセージのために適所にあるのを保証するのは重要です。 通常、アドレシング階層構造に対応する協定を持っていることによって、これをするでしょう。 X.400に関しては、これはPRMDがADMDに接続して、ADMDが間のPRMDの接続性を供給するモデルです、他のすべてのADMDsに発送する能力で。 他の協定は、ルーティングの効率を高めるためにこの階層構造に追加されるかもしれません。 一般に、有効なアドレスがあるかもしれません。(接続性か方針理由でアドレスを掘ることができません)。
We model these two types of agreements as communities. A community is a scope in which an MTA advertises its services and learns about other services. Each MTA will:
私たちは共同体としてこれらの2つのタイプの協定をモデル化します。 共同体はMTAがサービスの広告を出して、他のサービスに関して学ぶ範囲です。 各MTAはそうするでしょう:
1. Register its services in one or more communities.
1. 1つ以上の共同体にサービスを登録してください。
Kille Experimental [Page 10] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[10ページ]RFC1801X.400-MHSルート設定
2. Look up services in one or more communities.
2. 1つ以上の共同体でサービスを見上げてください。
In most cases an MTA will deal with a very small number of communities --- very often one only. There are a number of different types of community.
多くの場合、MTAは非常に少ない数の共同体と取り引きするでしょう。--- 頻繁である、1専用。 多くの異なったタイプの共同体があります。
The open community This is a public/global scope. It reflects
routing information which is made available to any MTA which
wishes to use it.
疎生群落Thisは公共の、または、グローバルな範囲です。 それはそれを使用したがっているどんなMTAも入手するルーティング情報を反映します。
The local community This is the scope of a single MTA. It reflects
routing information private to the MTA. It will contain an MTA's
view of the set of bilateral agreements in which it participates,
and routing information private and local to the MTA.
地方の共同体Thisは独身のMTAの範囲です。 それはMTAに個人的なルーティング情報を反映します。 それはMTAのそれが関与する二国間条約のセットの視点、およびMTAへの個人的でローカルのルーティング情報を含むでしょう。
Hierarchical communities A hierarchical community is a subtree of the
O/R Address tree. For example, it might be a management domain,
an organisation, or an organisational unit. This sort of
community will allow for firewalls to be established. A community
can have complex internal structure, and register a small subset
of that in the open community.
階層的な共同体A階層的な共同体はO/R Address木の下位木です。 例えば、それは、管理ドメイン、機構、またはorganisationalユニットであるかもしれません。 この種類の共同体は、ファイアウォールが確立されるのを許容するでしょう。 共同体は、疎生群落に複雑な内部の構造を持って、その小さい部分集合を登録できます。
Closed communities A closed community is a set of MTAs which agrees
to route amongst themselves. Examples of this might be ADMDs
within a country, or a set of PRMDs representing the same
organisation in multiple countries.
閉じている共同体A閉じた共同体は自分たちの中で発送する同意するMTAsの1セットです。 この例は、国の中のADMDs、または複数の国で同じ機構を代表するPRMDsの1セットであるかもしれません。
Formally, a community indicates the scope over which a service is advertised. In practice, it will tend to reflect the scope of services offered. It does not make sense to offer a public service, and only advertise it locally. Public advertising of a private service makes more sense, and this is shown below. In general, having a community offer services corresponding to the scope in which they are advertised will lead to routing efficiency. Examples of how communities can be used to implement a range of routing policies are given in Section 9.2.
正式に、共同体はサービスが広告に掲載されている範囲の示します。 実際には、それは、提供されたサービスの範囲を反映する傾向があるでしょう。 それは、社会奉仕を提供する意味になって、局所的にそれの広告を出すだけではありません。 密葬の公共広告は、より多く理解できます、そして、これは以下に示されます。 一般に、共同体にそれらが広告に掲載されている範囲の対応するサービスを提供させるのが効率を発送するのに通じるでしょう。 さまざまなルーティング政策を実施するのにどう共同体を使用できるかに関する例はセクション9.2で出されます。
8. Routing Trees
8. ルート設定木
Communities are a useful abstract definition of the routing approach taken by this specification. Each community is represented in the directory as a routing tree. There will be many routing trees instantiated in the directory. Typically, an MTA will only be registered in and make use of a small number of routing trees. In most cases, it will register in and use the same set of routing trees.
共同体はこの仕様で取られたルーティングアプローチの役に立つ抽象的な定義です。 各共同体はルーティング木としてディレクトリで代表されます。 ディレクトリに例示された多くのルーティング木があるでしょう。 MTAは少ない数のルーティング木を、登録されて、通常、利用になるだけでしょう。 多くの場合、それは、同じセットのルーティング木を登録して、使用するでしょう。
Kille Experimental [Page 11] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[11ページ]RFC1801X.400-MHSルート設定
8.1 Routing Tree Definition
8.1 ルート設定木の定義
Each community has a model of the O/R address space. Within a community, there is a general model of what to do with a given O/R Address. This is structured hierarchically, according to the O/R address hierarchy. A community can register different possible actions, depending on the depth of match. This might include identifying the MTA associated with a UA which is matched fully, and providing a default route for an O/R address where there is no match in the community --- and all intermediate forms. The name structure of a routing tree follows the O/R address hierarchy, which is specified in a separate document [15]. Where there is any routing action associated with a node in a routing tree, the node is of object class routingInformation, as defined in Section 10.
各共同体には、O/Rアドレス空間のモデルがあります。 共同体の中に、与えられたO/R Addressを処理するために、何に関する一般的なモデルがあるか。 O/Rアドレス階層構造に従って、これは階層的で構造化されます。 マッチの深さによって、共同体は異なった可能な動作を登録できます。 これは、完全に合わせられているUAに関連しているMTAを特定して、マッチが全く共同体にないO/Rアドレスにデフォルトルートを提供するのを含むかもしれません。--- そして、すべての中間介在物が形成されます。ルーティング木の名前構造はO/Rアドレス階層構造に従います。(それは、別々のドキュメント[15]で指定されます)。 ノードに関連しているどんなルーティング動作もルーティング木にあるところでは、ノードは物のクラスroutingInformationのものです、セクション10で定義されるように。
8.2 The Open Community Routing Tree
8.2 疎生群落ルート設定木
The routing tree of the open community starts at the root of the DIT. This routing tree also serves the special function of instantiating the global O/R Address space in the Directory. Thus, if a UA wishes to publish information to the world, this hierarchy allows it to do so.
疎生群落のルーティング木はDITの根で始まります。 また、このルーティング木はディレクトリにおけるグローバルなO/R Addressスペースを例示する特別な機能を果たします。 したがって、UAが情報を世界に発表したいなら、この階層構造で、それはそうします。
The O/R Address hierarchy is a registered tree, which may be instantiated in the directory. Names at all points in the tree are valid, and there is no requirement that the namespace is instantiated by the owner of the name. For example, a PRMD may make an entry in the DIT, even if the ADMD above it does not. In this case, there will be a "skeletal" entry for the ADMD, which is used to hang the PRMD entry in place. The skeletal entry contains the minimum number of entries which are needed for it to exist in the DIT (Object Class and Attribute information needed for the relative distinguished name). This entry may be placed there solely to support the subordinate entry, as its existence is inferred by the subordinate entry. Only the owner of the entry may place information into it. An analogous situation in current operational practice is to make DIT entries for Countries and US States.
O/R Address階層構造は登録された木です。(その木はディレクトリに例示されるかもしれません)。 木のすべてのポイントの名前は妥当です、そして、名前空間が名前の所有者によって例示されるという要件が全くありません。 例えば、それの上のADMDが記帳しないでも、PRMDはDITに記帳するかもしれません。 この場合、「骨格」のエントリーがADMDのためにあるでしょう。(ADMDは、PRMDエントリーを適所に掛けるのに使用されます)。 骨格のエントリーはDIT(情報が相対的な分類名に必要とした物のClassとAttribute)に存在するのに必要であるエントリーの最小の数を含んでいます。 このエントリーは唯一下位のエントリーを支持するためにそこに置かれるかもしれません、存在が下位のエントリーで推論されるとき。 エントリーの所有者だけが情報をそれに置くかもしれません。 現在の操作上の実際には類似の状況はCountriesのためのDITエントリーと米国Statesを作ることです。
---------------------------------------------------------------------
---------------------------------------------------------------------
routingTreeRoot OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation|subtree}
ID oc-routing-tree-root}
routingTreeRootは以下を物で分類します:= SUBCLASS OF、routingInformation| 下位木、ID ocルーティング木の根
Figure 1: Location of Routing Trees
図1: ルート設定木の位置
---------------------------------------------------------------------
---------------------------------------------------------------------
Kille Experimental [Page 12] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[12ページ]RFC1801X.400-MHSルート設定
8.3 Routing Tree Location
8.3 ルート設定木の位置
All routing trees follow the same O/R address hierarchy. Routing trees other than the open community routing tree are rooted at arbitrary parts of the DIT. These routing trees are instantiated using the subtree mechanism defined in the companion document "Representing Tables and Subtrees in the Directory" [15]. A routing tree is identified by the point at which it is rooted. An MTA will use a list of routing trees, as determined by the mechanism described in Section 9. Routing trees may be located in either the organisational or O/R address structured part of the DIT. All routing trees, other than the open community routing tree, are rooted by an entry of object class routingTreeRoot, as defined in Figure 1.
すべてのルーティング木が同じO/Rアドレス階層構造に従います。 疎生群落ルーティング木以外のルート設定木はDITの任意の部分に根づきます。 これらのルーティング木による下位木メカニズムが仲間で定義した例示された使用が「ディレクトリでテーブルと下位木を表します」[15]を記録するということです。 ルーティング木はそれが根づいているポイントによって特定されます。 MTAはセクション9で説明されたメカニズムで決定するようにルーティング木のリストを使用するでしょう。 ルート設定木がorganisationalに位置したかもしれませんか、またはO/RアドレスはDITの一部を構造化しました。 疎生群落ルーティング木以外のすべてのルーティング木が物のクラスroutingTreeRootのエントリーで根づきます、図1で定義されるように。
8.4 Example Routing Trees
8.4 例のルート設定木
Consider routing trees with entries for O/R Address:
O/R Addressのためにエントリーで木を発送すると考えてください:
P=ABC; A=XYZMail; C=GB;
P=ABC。 A=XYZMail。 CはGBと等しいです。
In the open community routing tree, this would have a distinguished name of:
疎生群落ルーティング木では、これは以下の分類名を持っているでしょう。
PRMD=ABC, ADMD=XYZMail, C=GB
PRMD=ABC、ADMD=XYZMail、CはGBと等しいです。
Consider a routing tree which is private to:
以下のことと個人的なルーティング木は考えてください。
O=Zydeco Services, C=GB
O=Zydecoサービス、CはGBと等しいです。
They might choose to label a routing tree root "Zydeco Routing Tree", which would lead to a routing tree root of:
彼らは、以下のルーティング木の根に通じるだろうルーティング木の根の「Zydecoルート設定木」をラベルするのを選ぶかもしれません。
CN=Zydeco Routing Tree, O=Zydeco Services, C=GB
CN=Zydecoルート設定木、O=Zydecoサービス、CはGBと等しいです。
The O/R address in question would be stored in this routing tree as:
問題のO/Rアドレスは以下としてこのルーティング木に格納されるでしょう。
PRMD=ABC, ADMD=XYZMail
C=GB, CN=Zydeco Routing Tree,
O=Zydeco Services, C=GB
PRMD=ABC、ADMD=XYZMail CはGB、O=Zydecoが修理するCN=Zydecoルート設定木と等しく、CはGBと等しいです。
8.5 Use of Routing Trees to look up Information
8.5 ルート設定Treesの情報に見せる使用
Lookup of an O/R address in a routing tree is done as follows:
ルーティング木のO/Rアドレスのルックアップは以下の通り完了しています:
1. Map the O/R address onto the O/R address hierarchy described in
[15] in order to generate a Distinguished Name.
1. Distinguished Nameを発生させるように[15]で説明されたO/Rアドレス階層構造にO/Rアドレスを写像してください。
Kille Experimental [Page 13] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[13ページ]RFC1801X.400-MHSルート設定
2. Append this to the Distinguished Name of the routing tree, and
then look up the whole name.
2. ルーティング木のDistinguished Nameにこれを追加してください、そして、次に、全部の名前を調べてください。
3. Handling of errors will depend on the application of the lookup,
and is discussed later.
3. 誤りの取り扱いについて、ルックアップのアプリケーションによって、後で議論します。
Note that it is valid to look up a null O/R Address, as the routing tree root may contain default routing information for the routing tree. This is held in the root entry of the routing tree, which is a subclass of routingInformation. The open community routing tree does not have a default.
ヌルO/R Addressを見上げるのが有効であることに注意してください、ルーティング木の根がルーティング木のためのデフォルトルーティング情報を含むとき。 これはルーティング木の根のエントリーに保持されます。(それは、routingInformationのサブクラスです)。 疎生群落ルーティング木には、デフォルトがありません。
Routing trees may have aliases into other routing trees. This will typically be done to optimise lookups from the first routing tree which a given MTA uses. Lookup needs to take account of this.
ルート設定木は他のルーティング木に別名を持っているかもしれません。 与えられたMTAが使用する最初のルーティング木からルックアップを最適化するために通常これをするでしょう。 ルックアップは、これを考慮に入れる必要があります。
9. Routing Tree Selection
9. ルート設定木の選択
The list of routing trees which a given MTA uses will be represented in the directory. This uses the attribute defined in Figure 2.
与えられたMTAが使用するルーティング木のリストはディレクトリに表されるでしょう。 これは図2で定義された属性を使用します。
---------------------------------------------------------------------
---------------------------------------------------------------------
routingTreeList ATTRIBUTE ::= {
WITH SYNTAX RoutingTreeList
SINGLE VALUE
ID at-routing-tree-list}
routingTreeListは以下を結果と考えます:= ルーティング木に記載されたWITH SYNTAX RoutingTreeList SINGLE VALUE ID
RoutingTreeList ::= SEQUENCE OF RoutingTreeName
RoutingTreeList:、:= RoutingTreeNameの系列
RoutingTreeName ::= DistinguishedName
RoutingTreeName:、:= DistinguishedName
Figure 2: Routing Tree Use Definition
図2: 木を発送して、定義を使用してください。
---------------------------------------------------------------------
---------------------------------------------------------------------
This attribute defines the routing trees used by an MTA, and the order in which they are used. Holding these in the directory eases configuration management. It also enables an MTA to calculate the routing choice of any other MTA which follows this specification, provided that none of its routing trees have access restrictions. This will facilitate debugging routing problems.
この属性は木がMTAで使用したルーティング、およびそれらが使用されている注文を定義します。 ディレクトリにこれらを保持すると、構成管理は緩和されます。 また、それは、MTAがこの仕様に従ういかなる他のMTAのルーティング選択についても計算するのを可能にします、ルーティング木のいずれにもアクセス制限がなければ。 これは、ルーティング問題をデバッグするのを容易にするでしょう。
9.1 Routing Tree Order
9.1 ルート設定木の命令
The order in which routing trees are used will be critical to the operation of this algorithm. A common approach will be:
ルーティング木が使用されているオーダーはこのアルゴリズムの操作に重要になるでしょう。 一般的なアプローチは以下の通りになるでしょう。
Kille Experimental [Page 14] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[14ページ]RFC1801X.400-MHSルート設定
1. Access one or more shared private routing trees to access private
routing information.
1. より多くのアクセス1は、個人的なルーティング情報にアクセスするために個人的なルーティング木を共有しました。
2. Utilise the open routing tree.
2. 開いているルーティング木を利用してください。
3. Fall back to a default route from one of the private routing
trees.
3. 個人的なルーティング木の1つからデフォルトルートへ後ろへ下がってください。
Initially, the open routing tree will be very sparse, and there will be little routing information in ADMD level nodes. Access to many services will only be via ADMD services, which in turn will only be accessible via private links. For most MTAs, the fallback routing will be important, in order to gain access to an MTA which has the right private connections configured.
初めは、開いているルーティング木は非常にまばらになるでしょう、そして、ADMDの平らなノードにはルーティング情報がほとんどないでしょう。 多くのサービスへのアクセスがADMDサービスであるだけでしょう。(サービスは個人的なリンクを通して順番にアクセスしやすくなるだけでしょう)。 後退ルーティングはほとんどのMTAsに関しては、重要になるでしょう、正しい個人的な接続を構成させるMTAへのアクセスを得るために。
In general, for a site, UAs will be registered in one routing tree only, in order to avoid duplication. They may be placed into other routing trees by use of aliases, in order to gain performance. For some sites, Users and UAs with a 1:1 mapping will be mapped onto single entries by use of aliases.
一般に、サイトにおいて、UAsは、重複を避けるために1本のルーティング木だけに登録されるでしょう。 それらは、性能を獲得するために別名の使用で他のルーティング木に置かれるかもしれません。 いくつかのサイトにおいて、1:1マッピングがあるUsersとUAsは単一のエントリーに別名の使用で写像されるでしょう。
9.2 Example use of Routing Trees
9.2 ルート設定Treesの例の使用
Some examples of how this structure might be used are now given. Many other combinations are possible to suit organisational requirements.
この構造がどう使用されるかもしれないかに関するいくつかの例が現在、出されます。 他の多くの組み合わせがorganisational要件に合うのにおいて可能です。
9.2.1 Fully Open Organisation
9.2.1 完全に開いている機構
The simplest usage is to place all routing information in the open community routing tree. An organisation will simply establish O/R addresses for all of its UAs in the open community tree, each registering its supporting MTA. This will give access to all systems accessible from this open community.
最も簡単な用法はすべてのルーティング情報を疎生群落ルーティング木に置くことです。 機構は単にUAsのすべてのためのO/Rアドレスを疎生群落木に確立するでしょう、MTAを支持するのをそれぞれ登録して。 これはすべてのシステムへのアクセスをこの疎生群落からアクセスしやすく与えるでしょう。
9.2.2 Open Organisation with Fallback
9.2.2 後退との開いている機構
In practice, some MTAs and MDs will not be directly reachable from the open community (e.g., ADMDs with a strong model of bilateral agreements). These services will only be available to users/communities with appropriate agreements in place. Therefore it will be useful to have a second (local) routing tree, containing only the name of the fallback MTA at its root. In many cases, this fallback would be to an ADMD connection.
実際には、いくつかのMTAsとMDsは疎生群落(例えば、二国間条約の強いモデルがあるADMDs)から直接届かないでしょう。 適切な協定が適所にあった状態で、これらのサービスは単にユーザ/共同体に利用可能になるでしょう。 したがって、第2の(地方)のルーティング木を持っているのは役に立ちます、根に後退MTAという名前だけを含んでいて。 多くの場合、ADMD接続にはこの後退があるでしょう。
Thus, open routing will be tried first, and if this fails the message will be routed to a single selected MTA.
したがって、開いているルーティングは最初に試みられるでしょう、そして、これが失敗すると、メッセージは独身の選択されたMTAに発送されるでしょう。
Kille Experimental [Page 15] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[15ページ]RFC1801X.400-MHSルート設定
9.2.3 Minimal-routing MTA
9.2.3 最小量のルーティングMTA
The simplest approach to routing for an MTA is to deliver messages to associated users, and send everything else to another MTA (possibly with backup).
MTAのためのルーティングへの最も簡単なアプローチは別のMTA(ことによるとバックアップがある)にユーザを関連づけて、他の何もかもを送るメッセージを送ることです。
An organisation using MTAs with this approach will register its users as for the fully open organisation. A single routing tree will be established, with the name of the organisation being aliased into the open community routing tree. Thus the MTA will correctly identify local users, but use a fallback mechanism for all other addresses.
このアプローチがあるMTAsを使用する機構は完全に開いている機構のようにユーザを登録するでしょう。 単一のルーティング木は設立されるでしょう、機構の名前が疎生群落ルーティング木にaliasedされている状態で。 したがって、MTAは正しく地元のユーザを特定するでしょうが、他のすべてのアドレスに後退メカニズムを使用してください。
9.2.4 Organisation with Firewall
9.2.4 ファイアウォールとの機構
An organisation can establish an organisation community to build a firewall, with the overall organisation being registered in the open community. This is an important structure, which it is important to support cleanly.
機構はファイアウォールを建設するために機構共同体を確立できます、総合的な機構が疎生群落に登録されている状態で。 これは重要な構造です。(清潔に支持するのはその構造が重要です)。
o Some MTAs are registered in the open community routing tree to
give access into the organisation. This will include the O/R tree
down to the organisational level. Full O/R Address verification
will not take place externally.
o いくつかのMTAsが、アクセスを機構に与えるために疎生群落ルーティング木に登録されます。 これはO/R木をorganisationalレベルまで含むでしょう。 完全なO/R Address検証は外部的に行われないでしょう。
o All users are registered in a private (organisational) routing
tree.
o すべてのユーザが個人的な(organisational)ルーティング木に登録されます。
o All MTAs in the organisation are registered in the organisation's
private routing tree, and access information in the organisation's
community. This gives full internal connectivity.
o 機構におけるすべてのMTAsが機構の共同体に機構の個人的なルーティング木、およびアクセス情報に登録されます。 これは完全な内部の接続性を与えます。
o Some MTAs in the organisation access the open community routing
tree. These MTAs take traffic from the organisation to the
outside world. These will often be the same MTAs that are
externally advertised.
o 機構におけるいくつかのMTAsが疎生群落ルーティング木にアクセスします。 これらのMTAsは機構から外の世界までの交通を取ります。 これらはしばしば外部的に広告に掲載されているMTAsになるでしょう同じの。
9.2.5 Well Known Entry Points
9.2.5 よく知られているエントリー・ポイント
Well known entry points will be used to provide access to countries and MDs which are oriented to private links. A private routing tree will be established, which indicates these links. This tree would be shared by the well known entry points.
よく知られているエントリー・ポイントは、個人的なリンクに向けられる国とMDsへのアクセスを提供するのに使用されるでしょう。 個人的なルーティング木(これらのリンクを示す)は設立されるでしょう。 この木はよく知られているエントリー・ポイントによって共有されるでしょう。
9.2.6 ADMD using the Open Community for Advertising
9.2.6 広告に疎生群落を使用するADMD
An ADMD uses the open community for advertising. It advertises its existence and also restrictive policy. This will be useful for:
ADMDは広告に疎生群落を使用します。 それは存在と引締政策も広告を出します。 これは以下の役に立ちます。
Kille Experimental [Page 16] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[16ページ]RFC1801X.400-MHSルート設定
o Address validation
o アドレス合法化
o Advertising the mechanism for a bilateral link to be established
o 双方のリンクが証明されるためにメカニズムの広告を出します。
9.2.7 ADMD/PRMD gateway
9.2.7 ADMD/PRMDゲートウェイ
An MTA provides a gateway from a PRMD to an ADMD. It is important to note that many X.400 MDs will not use the directory. This is quite legitimate. This technique can be used to register access into such communities from those that use the directory.
MTAはPRMDからADMDへのゲートウェイを提供します。 多くのX.400 MDsがディレクトリを使用しないことに注意するのは重要です。 これはかなり正統です。 ディレクトリを使用するものからそのような共同体にアクセスを登録するのにこのテクニックを使用できます。
o The MTA registers the ADMD in its local community (private link)
o MTAは地方の共同体にADMDを登録します。(個人的なリンク)
o The MTA registers itself in the PRMD's community to give access to
the ADMD.
o MTAは、ADMDへのアクセスを与えるためにPRMDの共同体にそれ自体を登録します。
10. Routing Information
10. 経路情報
Routing trees are defined in the previous section, and are used as a framework to hold routing information. Each node, other than a skeletal one, in a routing tree has information associated with it, which is defined by the object class routingInformation in Figure 3. This structure is fundamental to the operation of this specification, and it is recommended that it be studied with care.
ルート設定木は、前項で定義されて、ルーティング情報を保持するのに枠組みとして使用されます。 骨格のもの以外の各ノードはルーティング木にそれに関連している情報を持っています。(それは、図3で物のクラスroutingInformationによって定義されます)。 この構造はこの仕様の操作に基本的です、そして、それが慎重に研究されるのは、お勧めです。
---------------------------------------------------------------------
---------------------------------------------------------------------
routingInformation OBJECT-CLASS ::= {
SUBCLASS OF top
KIND auxiliary
MAY CONTAIN {
subtreeInformation|
routingFilter|
routingFailureAction|
mTAInfo|
accessMD| 10
nonDeliveryInfo|
badAddressSearchPoint|
badAddressSearchAttributes}
ID oc-routing-information}
-- No naming attributes as this is not a
-- structural object class
routingInformationは以下を物で分類します:= SUBCLASS OFがKINDの補助のMAY CONTAINを上回っている、subtreeInformation|routingFilter|routingFailureAction|mTAInfo|accessMD| 10nonDeliveryInfo| badAddressSearchPoint| badAddressSearchAttributes、ID ocルーティング情報、--これがaでないので、属性を命名しません--構造的な物クラス
subtreeInformation ATTRIBUTE ::= { 20
WITH SYNTAX SubtreeInfo
SINGLE VALUE
subtreeInformationは以下を結果と考えます:= 構文のSubtreeInfoのただ一つの価値がある20
Kille Experimental [Page 17] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[17ページ]RFC1801X.400-MHSルート設定
ID at-subtree-information}
ID、下位木情報
SubtreeInfo ::= ENUMERATED {
all-children-present(0),
not-all-children-present(1) }
SubtreeInfo:、:= 列挙されます。オール(0)を子供と同じくらい提示して、オール(1)は子供ほど提示しません。
routingFilter ATTRIBUTE ::= { 30
WITH SYNTAX RoutingFilter
ID at-routing-filter}
routingFilterは以下を結果と考えます:= 30WITH SYNTAX RoutingFilter ID、ルーティングフィルタ
RoutingFilter ::= SEQUENCE{
attribute-type OBJECT-IDENTIFIER,
weight RouteWeight,
dda-key String OPTIONAL,
regex-match IA5String OPTIONAL,
node DistinguishedName } 40
RoutingFilter:、:= SEQUENCEがOBJECT-IDENTIFIER、重さのRouteWeight、dda主要なString OPTIONAL、regex-マッチIA5String OPTIONAL、ノードDistinguishedNameを属性でタイプする、40
String ::= CHOICE {PrintableString, TeletexString}
以下を結んでください:= 選択PrintableString、TeletexString
routingFailureAction ATTRIBUTE ::= {
WITH SYNTAX RoutingFailureAction
SINGLE VALUE
ID at-routing-failure-action}
routingFailureActionは以下を結果と考えます:= WITH SYNTAX RoutingFailureAction SINGLE VALUE ID、ルーティング失敗動作
RoutingFailureAction ::= ENUMERATED {
next-level(0), 50
next-tree-only(1),
next-tree-first(2),
stop(3) }
RoutingFailureAction:、:= 列挙されます。次のレベル(0)、次の木-最初の(2)である50次の木だけの(1)は(3)を止めます。
mTAInfo ATTRIBUTE ::= {
WITH SYNTAX MTAInfo
ID at-mta-info}
mTAInfoは以下を結果と考えます:= WITH SYNTAX MTAInfo ID、mtaインフォメーション
MTAInfo ::= SEQUENCE { 60
name DistinguishedName,
weight [1] RouteWeight DEFAULT preferred-access,
mta-attributes [2] SET OF Attribute OPTIONAL,
ae-info SEQUENCE OF SEQUENCE {
aEQualifier PrintableString,
ae-weight RouteWeight DEFAULT preferred-access,
ae-attributes SET OF Attribute OPTIONAL} OPTIONAL
}
MTAInfo:、:= 系列60はDistinguishedName、重さ[1]のRouteWeight DEFAULTの都合のよいアクセスであって、mta属性の[2]SET OF Attribute OPTIONAL、ae-インフォメーションのSEQUENCE OF SEQUENCEのaEQualifier PrintableStringの、そして、ae重さのRouteWeight DEFAULT都合のよいアクセスであって、ae属性のSET OF Attribute OPTIONALをOPTIONALと命名します。
RouteWeight ::= INTEGER {endpoint(0), 70
RouteWeight:、:= 整数、終点(0)、70
Kille Experimental [Page 18] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[18ページ]RFC1801X.400-MHSルート設定
preferred-access(5),
backup(10)} (0..20)
都合のよいアクセス(5)、バックアップ(10) (0..20)
Figure 3: Routing Information at a Node
図3: ノードの経路情報
---------------------------------------------------------------------
---------------------------------------------------------------------
For example, information might be associated with the (PRMD) node:
例えば、情報は(PRMD)ノードに関連しているかもしれません:
PRMD=ABC, ADMD=XYZMail, C=GB
PRMD=ABC、ADMD=XYZMail、CはGBと等しいです。
If this node was in the open community routing tree, then the information represents information published by the owner of the PRMD relating to public access to that PRMD. If this node was present in another routing tree, it would represent information published by the owner of the routing tree about access information to the referenced PRMD. The attributes associated with a routingInformation node provide the following information:
このノードが疎生群落ルーティング木にあったなら、情報はそのPRMDにパブリックアクセスに関連するPRMDの所有者によって発表された情報を表します。 このノードが別のルーティング木に存在しているなら、それはアクセス情報に関してルーティング木の所有者によって参照をつけられたPRMDに発表された情報を表すでしょうに。 routingInformationノードに関連している属性は以下の情報を提供します:
Implicit That the node corresponds to a partial or entire valid O/R
address. This is implicit in the existence of the entry.
内在しているThat、ノードは部分的であるか全体の有効なO/Rアドレスに対応します。 これはエントリーの存在に暗黙です。
Object Class If the node is a UA. This will be true if the node is of
object class routedUA. This is described further in Section 11.
If it is not of this object class, it is an intermediate node in
the O/R Address hierarchy.
Class Ifが反対する、ノードはUAです。 これはノードが物のクラスroutedUAのものであるなら本当になるでしょう。 これはセクション11で、より詳しく説明されます。 この物のクラスのものでないなら、それはO/R Address階層構造の中間的ノードです。
routingFilter A set of routing filters, defined by the routingFilter
attribute. This attribute provides for routing on information in
the unmatched part of the O/R Address. This is described in
Section 10.3.
routingFilter属性によって定義されたルーティングフィルタのroutingFilter Aセット。 この属性はO/R Addressの優れた部分の情報にルーティングに備えます。 これはセクション10.3で説明されます。
subtreeInformation Whether or not the node is authoritative for the
level below is specified by the subtreeInformation attribute. If
it is authoritative, indicated by the value all-children-present,
this will give the basis for (permanently) rejecting invalid O/R
Addresses. The attribute is encoded as enumerated, as it may be
later possible to add partial authority (e.g., for certain
attribute types). If this attribute is missing, the node is
assumed to be non-authoritative (not-all-children-present).
The value all-children-present simply means that all of the child
entries are present, and that this can be used to determine
invalid addresses. There are no implications about the presence
of routing information. Thus it is possible to verify an entire
address, but only to route on one of the higher level components.
以下のレベルがsubtreeInformation属性によって指定されるので、ノードではなく、subtreeInformation Whetherが正式です。 出席しているオール子供、それが正式であるなら、値によって示されて、これは無効のO/R Addressesを拒絶しながら、(永久に)の基礎を与えるでしょう。 属性は列挙されるようにコード化されます、部分的な権威(例えば、確信している属性タイプのための)を加えるのにおいて可能な状態で、より遅いときに。 この属性がなくなるなら、ノードが非正式であると(出席しているオール子供でない)思われます。 値のオール子供プレゼントは、子供エントリーのすべてが出席していて、無効のアドレスを決定するのにこれは使用できることを単に意味します。 ルーティング情報の存在に関する含意が全くありません。 したがって、全体のアドレスについて確かめますが、より高い平らなコンポーネントの1つのルートだけに可能であるのは可能です。
For example, consider the node:
例えば、ノードを考えてください:
Kille Experimental [Page 19] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[19ページ]RFC1801X.400-MHSルート設定
MHS-O=Zydeco, PRMD=ABC, ADMD=XYZMail, C=GB
MHS-O=Zydeco、PRMD=ABC、ADMD=XYZMail、CはGBと等しいです。
An organisation which has a bilateral agreement with this
organisation has this entry in its routing tree, with no children
entries. This is marked as non-authoritative. There is a second
routing tree maintained by Zydeco, which contains all of the
children of this node, and is marked as authoritative. When
considering an O/R Address
この機構との二国間条約を持っている機構はルーティング木にこのエントリーを持っています、子供エントリーなしで。 これは非正式であるとしてマークされます。 このノードの子供を皆、含んで、正式であるとしてマークされるZydecoによって維持された2番目のルーティング木があります。 O/R Addressを考えます。
MHS-G=Random + MHS-S=Unknown, MHS-O=Zydeco,
PRMD=ABC, ADMD=XYZMail, C=GB
MHS-Gは未知の無作為の+MHS-S=、MHS-O=Zydeco、PRMD=ABC ADMD=XYZMail、C=GBと等しいです。
only the second, authoritative, routing tree can be used to
determine that this address is invalid. In practice, the manager
configuring the non-authoritative tree, will be able to select
whether an MTA using this tree will proceed to full verification,
or route based on the partially verified information.
このアドレスが無効であることを決定するために木を発送する正式の秒しか費やすことができません。 習慣、非正式の木を構成するマネージャでは、この木を使用するMTAが完全な検証、または部分的に確かめられた情報に基づくルートに続くかどうかを選択できるでしょう。
mTAInfo A list of MTAs and associated information defined by the
mTAInfo attribute. This information is discussed further in
Sections 15 and 18. This information is the key information
associated with the node. When a node is matched in a lookup, it
indicates the validity of the route, and a set of MTAs to connect
to. Selection of MTAs is discussed in Sections 18 and
Section 10.2.
mTAInfo属性によって定義されたMTAsと関連情報のmTAInfo Aリスト。 セクション15と18で、より詳しくこの情報について議論します。 この情報はノードに関連している主要な情報です。 それは、接続するためにノードがいつルックアップで合わせられているかをルートの正当性、およびMTAsの1セットを示します。 セクション18とセクション10.2でMTAsの品揃えについて議論します。
routingFailureAction An action to be taken if none of the MTAs can be
used directly (or if there are no MTAs present) is defined by the
routingFailureAction attribute. Use of this attribute and
multiple routing trees is described in Section 10.1.
直接MTAsのどれかを使用できないなら(どんな存在しているMTAsもなければ)、取られるべきroutingFailureAction An動作はroutingFailureAction属性によって定義されます。 この属性と複数のルーティング木の使用はセクション10.1で説明されます。
accessMD The accessMD attribute is discussed in Section 10.4. This
attribute is used to indicate MDs which provide indirect access
to the part of the tree that is being routed to.
accessMD、セクション10.4でaccessMD属性について議論します。 この属性は、それが発送されている木の部分への間接アクセスを提供するMDsを示すのに使用されます。
badAddressSearchPoint/badAddressSearchAttributes The
badAddressSearchPoint and badAddressSearchAttributes are
discussed in Section 17. This attribute is for when an address
has been rejected, and allows information on alternative addresses
to be found.
セクション17でbadAddressSearchPoint/badAddressSearchAttributesのbadAddressSearchPointとbadAddressSearchAttributesについて議論します。 探したら、この属性はアドレスが拒絶されて、代替アドレスの情報を許容する時の間、あります。
10.1 Multiple routing trees
10.1 複数のルーティング木
A routing decision will usually be made on the basis of information contained within multiple routing trees. This section describes the algorithms relating to use of multiple routing trees. Issues relating to the use of X.500 and handling of errors is discussed in Section 14. The routing decision works by examining a series of
複数のルーティング木の中に含まれた情報に基づいて通常ルーティング決定をするでしょう。 このセクションは複数のルーティング木の使用に関連するアルゴリズムを説明します。 セクション14でX.500の使用と誤りの取り扱いに関連する問題について議論します。 決定がシリーズを調べることによって働いているルーティング
Kille Experimental [Page 20] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[20ページ]RFC1801X.400-MHSルート設定
entries (nodes) in one or more routing trees. This information is summarised in Figure 3. Each entry may contain information on possible next-hop MTAs. When an entry is found which enables the message to be routed, one of the routing options determined at this point is selected, and a routing decision is made. It is possible that further entries may be examined, in order to determine other routing options. This sort of heuristic is not discussed here.
1本以上のルーティング木のエントリー(ノード)。 図3でこの情報について略言します。 各エントリーは可能な次のホップMTAsの情報を含むかもしれません。 エントリーを見つけるとき、(発送されるべきメッセージを可能にします)ここに決定しているルーティングオプションの1つを選択します、そして、ルーティング決定をします。 一層のエントリーが他のルーティングオプションを決定するために調べられるのは、可能です。 ここでこの種類のヒューリスティックについて議論しません。
When a single routing tree is used, the longest possible match based on the O/R address to be routed to is found. This entry, and then each of its parents in turn is considered, ending with the routing tree root node (except in the case of the open routing tree, which does not have such a node). When multiple routing trees are considered, the basic approach is to treat them in a defined order. This is supplemented by a mechanism whereby if a matched node cannot be used directly, the routing algorithm will have the choice to move up a level in the current routing tree, or to move on to the next routing tree with an option to move back to the first tree later. This option to move back is to allow for the common case where a tree is used to specify two things:
単一のルーティング木が使用されているとき、発送されるO/Rアドレスに基づく可能な限り長いマッチは見つけられます。 このエントリー、および次にその両親の各人は順番に考えられます、ルーティング木の根のノード(そのようなノードを持っていない開いているルーティング木に関するケースを除いた)で終わって。 複数のルーティング木が考えられるとき、基本的なアプローチは定義されたオーダーでそれらを扱うことです。 これは直接取り組んでいるノードを使用できないなら、ルーティング・アルゴリズムが後で最初の木に戻らせるオプションで次のルーティング木にオンに現在のルーティング木をレベルを動くか、または動かす選択を持っているメカニズムによって補われます。 戻らせるこのオプションは木が2つのものを指定するのに使用されるよくある例を考慮することです:
1. Routing information private to the MTA (e.g., local UAs or routing
info for bilateral links).
1. MTA(双方のリンクのための例えば、地方のUAsかルーティングインフォメーション)に個人的な情報を発送します。
2. Default routing information for the case where other routing has
failed.
2. 他のルーティングが失敗したところにケースのための情報を発送して、デフォルトとしてください。
The actions allow for a tree to be followed, for the private information, then for other trees to be used, and finally to fall back to the default situation. For very complex configurations it might be necessary to split this into two trees. The options defined by routingFailureAction, to be used when the information in the entry does not enable a direct route, are:
動作は、木がそして、他の使用されるべき木のための個人情報と最終的にデフォルト状況への落下まで続かれるのを許容します。 非常に複雑な構成に、これを2本の木に分けるのが必要であるかもしれません。 エントリーにおける情報が直航路を可能にしないとき、使用されるためにroutingFailureActionによって定義されたオプションは以下の通りです。
next-level Move up a level in the current routing tree. This is the
action implied if the attribute is omitted. This will usually be
the best action in the open community routing tree.
現在のルーティング木のレベルへの次のレベルMove。 これは属性が省略されるなら含意された動作です。 通常、これは疎生群落ルーティング木で最も良い動作でしょう。
next-tree-only Move to the next tree, and do no further processing on
the current tree. This will be useful optimisation for a routing
tree where it is known that there is no useful additional routing
information higher in the routing tree.
次の木だけのMove、次は木に登られて、これ以上現在の木で処理をしないでください。 これはルーティング木のためのどんなルーティング木では、より高い役に立つ追加ルーティング情報もないのが知られているところの役に立つ最適化でしょう。
next-tree-first Move to the next tree, and then default back to the
next level in this tree when all processing is completed on
subsequent trees. This will be useful for an MTA to operate in
the sequence:
次の木への最初に次に木に登っているMove、およびそして、すべての処理がその後の木で終了しているこの木の次のレベルへのデフォルト。 MTAが系列で作動するように、これは役に立ちます:
Kille Experimental [Page 21] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[21ページ]RFC1801X.400-MHSルート設定
1. Check for optimised private routes
1. 最適化された個人的なルートがないかどうかチェックしてください。
2. Try other available information
2. 他の入手可能な情報を試みてください。
3. Fall back to a local default route
3. ローカルのデフォルトルートへ後ろへ下がってください。
stop This address is unroutable. No processing shall be done in any
trees.
停止Thisアドレスは非発送可能です。 どんな木でも処理しないものとすること。
For the root entry of a routing tree, the default action and next- level are interpreted as next-tree-only.
ルーティング木の根のエントリーにおいて、デフォルト動作と次のレベルは次の木だけとして解釈されます。
10.2 MTA Choice
10.2 MTA選択
This section considers how the choice between alternate MTAs is made. First, it is useful to consider the conditions why an MTA is entered into a node of the routing tree:
このセクションは、どのように代替のMTAsの選択をするかを考えます。 まず最初に、MTAがルーティング木の節に入れられる状態を考えるのは役に立ちます:
o The manager for the node of the tree shall place it there. This
is a formality, but critical in terms of overall authority.
o 木の節のためのマネージャはそれをそこに置くものとします。 これは、形式的な手続きにもかかわらず、総合的な権威で重要です。
o The MTA manager shall agree to it being placed there. For a well
operated MTA, the access policy of the MTA will be set to enforce
this.
o MTAマネージャは、そこに置かれながら、それに同意するものとします。 上手に操作されたMTAにおいて、MTAのアクセス方針がこれを実施するように設定されるでしょう。
o The MTA will in general (for some class of message) be prepared
to route to any valid O/R address in the subtree implied by the
address. The only exception to this is where the MTA will route
to a subset of the tree which cannot easily be expressed by
making entries at the level below. An example might be an MTA
prepared to route to all of the subtree, with certain explicit
exceptions.
o 一般に、MTAはあらゆる有効なO/Rにアドレスによって含意された下位木におけるアドレスを発送するように準備されるでしょう(何らかのクラスに関するメッセージのために)。 これへの唯一の例外はMTAが木の部分集合にどれを発送するかで以下のレベルでエントリーをすることによって容易に言い表すことができないということです。 例はある下位木のすべてに明白な例外を発送するように準備されたMTAであるかもしれません。
Information on each MTA is stored in an mTAInfo attribute, which is defined in Figure 3. This attribute contains:
各MTAに関する情報はmTAInfo属性で保存されます。(それは、図3で定義されます)。 この属性は以下を含んでいます。
name The Distinguished Name of the MTA (Application Process)
MTAのDistinguished Nameを命名してください。(アプリケーション・プロセス)
weight A weighting factor (Route Weight) which gives a basis to
choose between different MTAs. This is described in Section 10.2.
異なったMTAsを選ぶ基礎を与えるA重み係数(ルートWeight)に重みを加えてください。 これはセクション10.2で説明されます。
mta-attributes Attributes from the MTA's entry. Information on the
MTA will always be stored in the MTA's entry. The MTA is
represented here as a structure, which enables some of this entry
information to be represented in the routing node. This is
effectively a maintained cache, and can lead to considerable
performance optimisation. For example if ten MTAs were
represented at a node, another MTA making a routing decision might
MTAのエントリーからのmta-属性Attributes。 MTAに関する情報はMTAのエントリーにいつも保存されるでしょう。 MTAは構造としてここに表されます。(それは、ルーティングノードのこのエントリー表現する情報のいくつかを可能にします)。 これは、事実上維持されたキャッシュであり、かなりの性能最適化に通じることができます。 例えば、10MTAsがノードに表されるなら、ルーティング決定をする別のMTAは表されるでしょうに。
Kille Experimental [Page 22] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[22ページ]RFC1801X.400-MHSルート設定
need to make ten directory reads in order to obtain the
information needed. If any attributes are present here, all of
the attributes needed to make a routing decision shall be
included, and also all attributes at the Application Entity level.
10ディレクトリを作る必要性は、必要である情報を得るために読みます。 何か属性がここに存在していると、ルーティング決定をするのに必要である属性のすべてが含むようになって、Application Entityのすべての属性も平らです。
ae-info Where an MTA supports a single protocol only, or the
protocols it supports have address information that can be
represented in non-conflicting attributes, then the MTA may be
represented as an application process only. In this case, the
ae-info structure which gives information on associated
application entities may be omitted, as the MTA is represented by
a single application entity which has the same name as the
application process. In other cases, the names of all application
entities shall be included. A weight is associated with each
application entity to allow the MTA to indicate a preference
between its application entities.
MTAがただ一つのプロトコルだけ、またはそれがサポートするプロトコルをサポートするae-インフォメーションWhereは非闘争属性で表すことができるアドレス情報を持って、次に、MTAはアプリケーション・プロセスだけとして表されるかもしれません。 この場合、関連するアプリケーション実体で知らせるae-インフォメーション構造は省略されるかもしれません、MTAがアプリケーション・プロセスと同じ名前を持っているただ一つのアプリケーション実体によって表されるように。 他の場合では、すべてのアプリケーション実体の名前は含まれているものとします。 重りは、MTAがアプリケーション実体の間の優先を示すのを許容するためにそれぞれのアプリケーション実体に関連づけられます。
The structure of information within ae-info is as follows:
ae-インフォメーションの中の情報の構造は以下の通りです:
ae-qualifier A printable string (e.g., "x400-88"), which is the
value of the common name of the relative distinguished name of the
application entity. This can be used with the application process
name to derive the application entity title.
ae-資格を与える人のA印刷可能なストリング、(例えば、「x400-88インチ)、アプリケーション実体の相対的な分類名の一般名の値がどれであるか、」 アプリケーション実体タイトルを引き出すのにアプリケーション・プロセス名と共にこれを使用できます。
ae-weight A weighting factor (Route Weight) which gives a basis to
choose between different Application Entities (not between
different MTAs). This is described below.
異なったApplication Entities(異なったMTAsの間の)を選ぶ基礎を与えるae-重さのA重み係数(ルートWeight)。 これは以下で説明されます。
ae-attributes Attributes from the AEs entry.
AEsエントリーからのae-属性Attributes。
Information in the mta-attributes and ae-info is present as a performance optimisation, so that routing choices can be made with a much smaller number of directory operations. Using this information, whose presence is optional, is equivalent to looking up the information in the MTA. If this information is present, it shall be maintained to be the same as that information stored in the MTA entry. Despite this maintenence requirement, use of this performance optimisation data is optional, and the information may always be looked up from the MTA entry.
mta-属性とae-インフォメーションの情報は性能最適化として存在しています、はるかに少ない数のディレクトリ操作でルーティング選択をすることができるように。 この情報を使用するのはMTAの情報を調べるのに同等です。(情報の存在は任意です)。 この情報が存在しているなら、それはMTAエントリーに保存されたその情報と同じであると主張されるものとします。 このmaintenence要件にもかかわらず、この性能最適化データの使用は任意です、そして、情報はMTAエントリーからいつも調べられるかもしれません。
Note: It has been suggested that substantial performance optimisation
will be achieved by caching, and that the performance gained
from maintaining these attributes does not justify the effort
of maintaining the entries. If this is borne out by
operational experience, this will be reflected in future
versions of this specification.
以下に注意してください。 かなりの性能最適化がキャッシュすることによって実現されて、これらの属性を維持しながら得られる性能がエントリーを維持する取り組みを正当化しないことが提案されました。 運用経験で支持されると、これはこの仕様の将来のバージョンに反映されるでしょう。
Kille Experimental [Page 23] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[23ページ]RFC1801X.400-MHSルート設定
Route weighting is a mechanism to distinguish between different route choices. A routing weight may be associated with the MTA in the context of a routing tree entry. This is because routing weight will always be context dependent. This will allow machines which have other functions to be used as backup MTAs. The Route Weight is an integer in range 0--20. The lower the value, the better the choice of MTA. Where the weight is equal, and no other factors apply, the choice between the MTAs shall be random to facilitate load balancing. If the MTA itself is in the list, it shall only route to an MTA of lower weight. The exact values will be chosen by the manager of the relevant part of the routing tree. For guidance, three fixed points are given:
ルートの重さは異なったルート選択の間で区別するメカニズムです。 ルーティング重りはルーティング木のエントリーの文脈のMTAに関連しているかもしれません。 これはルーティングの重さがいつも文脈に依存するようになるからです。 これは、他の機能を持っているマシンがバックアップMTAsとして使用されるのを許容するでしょう。 Route Weightは範囲0--20の整数です。 値が低ければ低いほど、MTAの選択は、より良いです。 重さが等しく、他の要素が全く適用されないところでは、MTAsの選択は、ロードバランシングを容易にするために無作為になるでしょう。 MTA自身がリストにある場合にだけ、それはあるでしょう。下側の重さのMTAへのルート。 正確な値はルーティング木の関連部分のマネージャによって選ばれるでしょう。 指導において、3つの定点を与えます:
o 0. For an MTA which can deliver directly to the entire subtree
implied by the position in the routing tree.
o 0. 直接ルーティング木の位置のそばで暗示している全体の下位木を配達できるMTAのために。
o 5. For an MTA which is preferred for this point in the subtree.
o 5. これのために好まれるMTAに関しては、下位木では、指してください。
o 10. For a backup MTA.
o 10. バックアップMTAのために。
When an organisation registers in multiple routing trees, the route weight used is dependent on the context of the subtree. In general it is not possible to compare weights between subtrees. In some cases, use of route weighting can be used to divert traffic away from expensive links.
機構が複数のルーティング木に登録されるとき、重さが使用したルートは下位木の文脈に依存しています。 一般に、下位木の間の重りを比較するのは可能ではありません。 いくつかの場合、高価なリンクから遠くにトラフィックを紛らすのにルートの重さの使用を使用できます。
Attributes present in an MTA Entry are defined in various parts of this specification. A summary and pointers to these sections is given in Section 16.
MTA Entryの現在の属性はこの仕様の様々な部分で定義されます。 セクション16でこれらのセクションへの概要と指針をします。
Attributes that are available in the MTA entry and will be needed for making a routing choice are:
特選していた状態でMTAエントリーで利用可能であり、ルーティングを作るのに必要である属性は以下の通りです。
protocolInformation
protocolInformation
applicationContext
applicationContext
mhs-deliverable-content-length
mhs提出物のコンテンツの長さ
responderAuthenticationRequirements
responderAuthenticationRequirements
initiatorAuthenticationRequirements
initiatorAuthenticationRequirements
responderPullingAuthenticationRequirements
responderPullingAuthenticationRequirements
initiatorPullingAuthenticationRequirements
initiatorPullingAuthenticationRequirements
initiatorP1Mode
initiatorP1Mode
Kille Experimental [Page 24] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[24ページ]RFC1801X.400-MHSルート設定
responderP1Mode
responderP1Mode
polledMTAs Current MTA shall be in list if message is to be pulled.
polledMTAs Current MTAがメッセージが引かれることであるならリストにあるものとします。
mTAsAllowedToPoll
mTAsAllowedToPoll
supportedMTSExtensions
supportedMTSExtensions
If any MTA attributes are present in the mTAInfo attribute, all of the attributes that may affect routing choice shall be present. Other attributes may be present. A full list of MTA attributes, with summaries of their descriptions are given in Section 16, with a formal definition in Figure 6.
何かMTA属性がmTAInfo属性で存在していると、ルーティング選択に影響するかもしれない属性のすべてが出席するでしょう。 他の属性は存在しているかもしれません。 MTA属性に関する完全リスト、彼らの記述の概要と共に、セクション16における当然のことがあります、図6への公式の定義で。
10.3 Routing Filters
10.3 ルート設定フィルタ
This attribute provides for routing on information in the unmatched part of the O/R Address, including:
この属性はO/R Addressの優れた部分、包含における情報にルーティングに備えます:
o Routing on the basis of an O/R Address component type
o O/R Addressコンポーネント型に基づいたルート設定
o Routing on the basis of a substring match of an O/R address
component. This might be used to route X121 addressed faxes to
an appropriate MTA.
o O/Rアドレス構成要素のサブストリングマッチに基づいて、掘ります。 これは、ファックスであると扱われたX121を適切なMTAに発送するのに使用されるかもしれません。
When present, the procedures of analysing the routing filters shall be followed before other actions. The routing filter overrides mTAInfo and accessMD attributes, which means that the routing filter must be considered first. Only in the event that no routing filters match shall the mTAInfo and accessMD attributes be considered. The components of the routingFilter attribute are:
存在しているとき、ルーティングフィルタを分析する手順は他の動作の前に従われるものとします。 ルーティングフィルタはmTAInfoとaccessMD属性をくつがえします(最初にルーティングフィルタを考えなければならないことを意味します)。 ルーティングフィルタが全く合っていない場合にだけ、mTAInfoとaccessMD属性は考えられるものとします。 routingFilter属性のコンポーネントは以下の通りです。
---------------------------------------------------------------------
---------------------------------------------------------------------
attribute-type This gives the attribute type to be matched, and is
selected from the attribute types which have not been matched to
identify the routing entry. The filter applies to this attribute
type. If there is no regular expression present (as defined
below), the filter is true if the attribute is present. The
value is the object identifier of the X.500 attribute type
(e.g., at-prmd-name).
属性タイプThisは合わせられるために属性タイプに与えて、ルーティングエントリーを特定するために合わせられていない属性タイプから選択されます。 フィルタはこの属性タイプに適用されます。 属性が存在していて、どんな存在している正規表現もなければ(以下で定義されるように)、フィルタは本当です。 値はX.500属性タイプ(例えば、prmd-名前における)のオブジェクト識別子です。
weight This gives the weight of the filter, which is encoded as a
Route Weight, with lower values indicating higher priority. If
multiple filters match, the weight of each matched filter is used
to select between them. If the weight is the same, then a random
choice shall be made.
重さのThisはRoute Weightとしてコード化されるフィルタの重さを与えます、下側の値が、より高い優先度を示していて。 複数のフィルタが合っているなら、それぞれの照合フィルタの重さはそれらの間で選択するのにおいて使用されています。 重さが同じであるなら、無作為の選択をするものとします。
Kille Experimental [Page 25] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[25ページ]RFC1801X.400-MHSルート設定
dda-key If the attribute is domain defined, then this parameter may
be used to identify the key.
Ifをdda合わせてください。定義されて、属性がドメインである、次に、このパラメタはキーを特定するのが使用されてもよいです。
accessMD ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-access-md}
accessMDは以下を結果と考えます:= SUBTYPE OF distinguishedName ID、アクセスMd
Figure 4: Indirect Access
図4: 間接アクセス
---------------------------------------------------------------------
---------------------------------------------------------------------
regex-match This string is used to give a regular expression match on
the attribute value. The syntax for regular expressions is
defined in Appendix E.
regex-マッチThisストリングは、属性値で正規表現マッチを与えるのに使用されます。 正規表現のための構文はAppendix Eで定義されます。
node This distinguished name specifies the entry which holds routing
information for the filter. It shall be an entry with object
class routingInformation, which can be used to determine the MTA
or MTA choice. All of the attributes from this entry should be
used, as if they had been directly returned from the current entry
(i.e., the procedure recurses). The current entry does not set
defaults.
ノードThis分類名はフィルタのためのルーティング情報を保持するエントリーを指定します。 それは、オブジェクトのクラスroutingInformationとのエントリーかMTA選択になるでしょう。(MTAを決定するのにroutingInformationを使用できます)。 このエントリーからの属性のすべてが使用されるべきです、まるで現在のエントリー(すなわち、手順「再-呪い」)からそれらを直接返したかのように。 現在のエントリーはデフォルトを設定しません。
An example of use of routing filters is now given, showing how to route on X121 address to a fax gateway in Germany. Consider the routing point.
ルーティングフィルタで役に立つ例は現在出されます、X121アドレスのルートへのその方法をドイツのファックスゲートウェイに示して。 ルーティングポイントを考えてください。
PRMD=ABC, ADMD=XYZMail, C=GB
PRMD=ABC、ADMD=XYZMail、CはGBと等しいです。
The entry associated would have two routing filters:
関連づけられたエントリーは2個のルーティングフィルタを持っているでしょう:
1. One with type x121 and no regular expression, to route a default
fax gateway.
1. デフォルトがファックスでゲートウェイを送るルートへのタイプx121にもかかわらず、正規表現がない1。
2. One with type x121 and a regular expression ^9262 to route all
German faxes to a fax gateway located in Germany with which there
is a bilateral agreement. This would have a lower weight, so that
it would be selected over the default fax gateway.
2. すべてのドイツのファックスをファックスゲートウェイに発送するタイプx121がある1と通常の式^9262は二国間条約があるドイツで場所を見つけられました。 これには、下側の重りが、それがデフォルトファックスゲートウェイの上で選択されるように、あるでしょう。
10.4 Indirect Connectivity
10.4 間接的な接続性
In some cases a part of the O/R Address space will be accessed indirectly. For example, an ADMD without access from the open community might have an agreement with another MD to provide this access. This is achieved by use of the accessMD attribute defined in Figure 4. If this attribute is found, the routing algorithm shall read the entry pointed to by this distinguished name. It shall be an
いくつかの場合、O/R Addressスペースの一部が間接的にアクセスされるでしょう。 例えば、疎生群落からのアクセスのないADMDには、このアクセサリーを提供するために、協定が別のMDと共にあるかもしれません。 これは図4で定義されたaccessMD属性の使用で達成されます。 この属性が見つけられるなら、ルーティング・アルゴリズムはこの分類名によって示されたエントリーを読むものとします。 それはそうでしょう。
Kille Experimental [Page 26] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[26ページ]RFC1801X.400-MHSルート設定
entry with object class routingInformation, which can be used to determine the MTA or MTA choice and route according to the information retrieve to this access MD. All of the attributes from this entry should be used, as if they had been directly returned from the current entry (i.e., the procedure recurses). The current entry does not set defaults.
オブジェクトのクラスroutingInformationとのエントリー、情報に従ったMTAを決定するのにどれを使用できるか、そして、MTA選択とルートがこのアクセスにMDを検索します。 このエントリーからの属性のすべてが使用されるべきです、まるで現在のエントリー(すなわち、手順「再-呪い」)からそれらを直接返したかのように。 現在のエントリーはデフォルトを設定しません。
The attribute is called an MD, as this is descriptive of its normal use. It might point to a more closely defined part of the O/R Address space.
これが通常の使用で描写的であるので、属性はMDと呼ばれます。 それはO/R Addressスペースの密接により定義された地域を示すかもしれません。
It is possible for both access MD and MTAs to be specified. This might be done if the MTAs only support access over a restricted set of transport stacks. In this case, the access MD shall only be routed to if it is not possible to route to any of the MTAs.
アクセスMDとMTAsの両方が指定されるのは、可能です。 MTAsが制限されたセットの輸送スタックの上のアクセスをサポートするだけであるなら、これをするかもしれません。 この場合、それがMTAsのどれかに発送するのにおいて可能でない場合にだけ、アクセスMDに掘られるでしょう。
This structure can also be used as an optimisation, where a set of MTAs provides access to several parts of the O/R Address space. Rather than repeat the MTA information (list of MTAs) in each reference to the MD, a single access MD is used as a means of grouping the MTAs. The value of the Distinguished Name of the access MD will probably not be meaningful in this case (e.g., it might be the name "Access MTA List", within the organisation.)
また、最適化としてこの構造を使用できます、MTAsの1セットがO/R Addressスペースのいくつかの地域へのアクセスを提供するところで。 むしろ、aが意味するようにaシングルアクセスMDはMDの各参照におけるMTA情報(MTAsのリスト)を繰り返すよりMTAsを分類するのにおいて使用されています。 この場合アクセスMDのDistinguished Nameの値はたぶん重要にならないでしょう。(例えば、それは機構の中の名前「アクセスMTAリスト」であるかもしれません。)
If the MTA routing is unable to access the information in the Access MD due to directory security restrictions, the routing algorithm shall continue as if no MTA information was located in the routing entry.
MTAルーティングがディレクトリ安全保障制限のためAccess MDで情報にアクセスできないなら、まるでMTA情報が全くルーティングエントリーに位置しないかのようにルーティング・アルゴリズムは続くものとします。
11. Local Addresses (UAs)
11. ローカルのアドレス(UAs)
Local addresses (UAs) are a special case for routing: the endpoint. The definition of the routedUA object class is given in Figure 5. This identifies a User Agent in a routing tree. This is needed for several reasons:
ローカルのアドレス(UAs)はルーティングのための特別なケースです: 終点。 図5でroutedUAオブジェクトのクラスの定義を与えます。 これはルーティング木でUserエージェントを特定します。 これがいくつかの理由に必要です:
---------------------------------------------------------------------
---------------------------------------------------------------------
routedUA OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation}
KIND auxiliary
MAY CONTAIN {
-- from X.402
mhs-deliverable-content-length|
mhs-deliverable-content-types|
mhs-deliverable-eits|
mhs-message-store| 10
mhs-preferred-delivery-methods|
routedUAは以下をオブジェクトで分類します:= SUBCLASS OF routingInformation、KINDの補助のMAY CONTAIN、--X.402 mhs-提出物コンテンツの長さ| mhs-提出物content type| mhs-提出物eits| mhs-メッセージ店| 10mhsが都合のよい発送方法から|
Kille Experimental [Page 27] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[27ページ]RFC1801X.400-MHSルート設定
-- defined here
supportedExtensions|
redirect|
supportingMTA|
userName|
nonDeliveryInfo}
ID oc-routed-ua}
-- ここで、supportedExtensionsを定義します。| 再直接| supportingMTA| ユーザ名| nonDeliveryInfo uaに発送されたID oc
supportedExtensions ATTRIBUTE ::= { 20
SUBTYPE OF objectIdentifier
ID at-supported-extensions}
supportedExtensionsは以下を結果と考えます:= 20SUBTYPE OF objectIdentifier ID、サポートしている拡大
supportingMTA ATTRIBUTE ::= {
SUBTYPE OF mTAInfo
ID at-supporting-mta}
supportingMTAは以下を結果と考えます:= サポートすることでmtaしているSUBTYPE OF mTAInfo ID
userName ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-user-name} 30
ユーザ名は以下を結果と考えます:= SUBTYPE OF distinguishedName ID、ユーザ名、30
Figure 5: UA Attributes
図5: UA属性
---------------------------------------------------------------------
---------------------------------------------------------------------
1. To allow UAs to be defined without having an entry in another part
of the DIT.
1. UAsがDITの別の部分にエントリーを持っていなくて定義されるのを許容するために。
2. To identify which (leaf and non-leaf) nodes in a routing tree are
User Agents. In a pure X.400 environment, a UA (as distinct from
a connecting part of the O/R address space) is simply identified
by object class. Thus an organisation entry can itself be a UA. A
UA need not be a leaf, and can thus have children in the tree.
2. ルーティング木のどの(葉と非葉)ノードがUserエージェントであるかを特定するために。 純粋なX.400環境で、UA(O/Rアドレス空間の接続部分と異なるとしての)はオブジェクトのクラスによって単に特定されます。 その結果、機構エントリー缶自体、UAになってください。 UAは葉である必要はなく、その結果、木に子供を持つことができます。
3. To allow UA parameters as defined in X.402 (e.g., the
mhs-deliverable-eits) to be determined efficiently from the
routing tree, without having to go to the user's entry.
3. そうする必要はなくてX.402(例えば、mhs提出物のeits)で定義されるUAパラメタがルーティング木から効率的に決定しているのを許容するには、ユーザのエントリーに行ってください。
4. To provide access to other information associated with the UA, as
defined below.
4. 提供するために、他の情報へのアクセスは以下で定義されるようにUAと交際しました。
The following attributes are defined associated with the UA.
以下の属性はUAに関連していた状態で定義されます。
supportedExtensions MTS extensions supported by the MTA, which affect
delivery.
配送に影響するMTAによってサポートされたsupportedExtensions MTS拡張子。
supportingMTA The MTAs which support a UA directly are noted in the
supportingMTA attribute, which may be multi-valued. In the X.400
model, only one MTA is associated with a UA. In practice, it is
supportingMTA属性で直接UAをサポートするsupportingMTA MTAsに注意します。(それは、マルチ評価されているかもしれません)。 X.400モデルでは、1MTAだけがUAに関連しています。 実際には、それはそうです。
Kille Experimental [Page 28] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[28ページ]RFC1801X.400-MHSルート設定
possible and useful for several MTAs to be able to deliver to a
single UA. This attribute is a subtype of mTAInfo, and it defines
access information for an MTA which is able to deliver to the UA.
There may also be an mTAInfo attribute in the entry.
Components of the supportingMTA attribute are interpreted in the
same manner as mtaInfo is for routing, with one exception. The
values of the Route Weight are interpreted in the following
manner:
数個のMTAsが独身のUAに提供できるように、可能であって、役に立ちます。 この属性はmTAInfoの「副-タイプ」です、そして、それはUAに配送できるMTAのためのアクセス情報を定義します。 また、mTAInfo属性がエントリーにあるかもしれません。 supportingMTA属性のコンポーネントはmtaInfoがルーティングのためのものである、1つの例外がある同じ方法で解釈されます。 Route Weightの値は以下の方法で解釈されます:
o 0. A preferred MTA for delivery.
o 0. 配送のための都合のよいMTA。
o 5. A backup MTA.
o 5. バックアップMTA。
o 10. A backup MTA, which is not presferred.
o 10. バックアップMTA。(そのMTAはpresferredされません)。
The supportingMTA attribute shall be present, unless the address
is being non-delivered or redirected, in which case it may be
omitted.
アドレスが非提供されるか向け直されていないとsupportingMTA属性が存在する、その場合、それは省略されるかもしれません。
redirect The redirect attribute controls redirects, as described in
Section 22.1.
セクション22.1で説明されるようにコントロールが向け直す再直接の属性を向け直してください。
userName The attribute userName points to the distinguished Name of
the user, as defined by the mhs-user in X.402. The pointer from
the user to the O/R Address is achieved by the mhs-or-addresses
attribute. This makes the UA/User linkage symmetrical.
X.402でmhs-ユーザによって定義されるようにuserName属性userNameはユーザの顕著なNameを示します。 ユーザからO/R Addressまでの指針はmhsかアドレス属性によって達成されます。 これで、UA/ユーザリンケージは対称になります。
nonDeliveryInfo The attribute nonDeliveryInfo mandates non-delivery
to this address, as described in Section 22.3.
nonDeliveryInfo属性nonDeliveryInfoはセクション22.3で説明されるようにこのアドレスに非配送を強制します。
When routing to a UA, an MTA will read the supportingMTA attribute. If it finds its own name present, it will know that the UA is local, and invoke appropriate procedures for local delivery (e.g., co- resident or P3 access information). The cost of holding these attributes for each UA at a site will often be reduced by use of shared attributes (as defined in X.500(93)).
UAに掘るとき、MTAはsupportingMTA属性を読むでしょう。 それ自身の名前が存在しているのがわかると、UAが地方であることを知って、地方の配送のための適切な手順を呼び出す、(例えば、共同、-、居住者かP3アクセス情報) サイトに各UAのためのこれらの属性を保持するコストは共用属性の使用でしばしば削減されるでしょう。(X.500(93))で定義されるように。
Misconfiguration of the supportingMTA attribute could have serious operational and possibly security problems, although for the most part no worse than general routing configuration problems. An MTA using this attribute may choose to perform certain sanity checks, which might be to verify the routing tree or subtree that the entry resides in.
そして、supportingMTA属性のMisconfigurationが重大に持つことができた、操作上、エントリーが住んでいるルーティング木か下位木について確かめることであるかもしれないある健全度チェックを実行するために一般的なルーティング設定問題この属性を使用するMTAが選ぶかもしれないよりだいたい悪くはありませんが、ことによると警備上の問題。
The linkage between the UA and User entries was noted above. It is also possible to use a single entry for both User and UA, as there is no conflict between the attributes in each of the objects. In this case, the entries shall be in one part of the DIT, with aliases from
UAとUserエントリーの間のリンケージは上に述べられました。 また、UserとUAの両方に単一のエントリーを使用するのも可能です、それぞれのオブジェクトの属性の間に闘争が全くないとき。 この場合、エントリーが別名があるDITの一部にあるものとします。
Kille Experimental [Page 29] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[29ページ]RFC1801X.400-MHSルート設定
the other. Because the UA and User are named with different attributes, the aliases shall be at the leaf level.
もう片方。 UAとUserが異なった属性で命名されるので、別名が葉のレベルにあるものとします。
11.1 Searching for Local Users
11.1 ローカルユーザーを捜し求めること。
The approach defined in this specification performs all routing by use of reads. This is done for performance reasons, as it is a reasonable expectation that all DSA implementations will support a high performance read operation. For local routing only, an MTA in cooperation with the provider of the local routing tree may choose to use a search operation to perform routing. The major benefit of this is that there will not be a need to store aliases for alternate names, and so the directory storage requirement and alias management will be reduced. The difficulty with this approach is that it is hard to define search criteria that would be effective in all situations and well supported by all DUAs. There are also issues about determining the validity of a route on the basis of partial matches.
この仕様に基づき定義されたアプローチは読書の使用ですべてのルーティングを実行します。 性能理由でこれをします、すべてのDSA実装が操作が読まれた高性能をサポートするのが、合理的な期待であるので。 ローカルのルーティングだけのために、地元のルーティング木のプロバイダーと提携したMTAは、ルーティングを実行するのに索敵行動を使用するのを選ぶかもしれません。 この主要な利益が別名称のために別名を保存する必要がないということであるので、ディレクトリストレージ要件と別名管理は減らされるでしょう。 このアプローチにおける困難はすべての状況で有効ですべてのDUAsによってよくサポートされた検索評価基準を定義しにくいということです。 部分的なマッチに基づいてルートの正当性を決定することに関する問題もあります。
12. Direct Lookup
12. ダイレクトルックアップ
Where an O/R address is registered in the open community and has one or more "open" MTAs which support it, this will be optimised by storing MTA information in the O/R address entry. In general, the Directory will support this by use of attribute inheritance or an implementation will optimise the storage or repeated information, and so there will not be a large storage overhead implied. This is a function of the basic routing approach. As a further optimisation of this case, the User's distinguished name entry may contain the mTAInfo attribute. This can be looked up from the distinguished name, and thus routing on submission can be achieved by use of a single read.
O/Rアドレスが疎生群落に登録されて、それをサポートする1「開いている」MTAsを持っているところでは、これは、O/RアドレスエントリーにMTA情報を保存することによって、最適化されるでしょう。 一般に、ディレクトリが属性継承の使用でこれをサポートするだろうか、または実装がストレージか繰り返された情報を最適化するので、そして、暗示している大きいストレージオーバーヘッドがないでしょう。 これは基本的なルーティングアプローチの機能です。 本件のさらなる最適化として、Userの分類名エントリーはmTAInfo属性を含むかもしれません。 分類名からこれを見上げることができます、そして、その結果、読まれたシングルの使用で服従でのルーティングを達成できます。
Note: This performance optimisation has a management overhead, and
further experience is needed to determine if the effort
justifies the performance improvement.
以下に注意してください。 この性能最適化には、管理オーバーヘッドがあります、そして、さらなる経験が、取り組みが性能改良を正当化するかどうか決定するのに必要です。
13. Alternate Routes
13. 代替経路
13.1 Finding Alternate Routes
13.1 代替経路を見つけること。
The routing algorithm selects a single MTA to be routed to. It could be extended to find alternate routes to a single MTA with possibly different weights. How far this is done is a local configuration choice. Provision of backup routing is desirable, and leads to robust service, but excessive use of alternate routing is not usually beneficial. It will often force messages onto convoluted paths, when there was only a short outage on the preferred path. It is important
ルーティング・アルゴリズムは、独身のMTAが掘られるのを選択します。 ことによると異なった重りで独身のMTAにおいて代替経路を見つけるのは拡張できました。 どれくらい遠くにこれをするかは、ローカルの構成選択です。 バックアップルーティングの支給は、望ましく、体力を要しているサービスにつながりますが、通常、迂回中継の過用は有益ではありません。 短い供給停止しか都合のよい経路になかったとき、それはしばしば複雑な経路にメッセージを押しつけるでしょう。 それは重要です。
Kille Experimental [Page 30] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[30ページ]RFC1801X.400-MHSルート設定
to note that this strategy will lead to picking the first acceptable route. It is important to configure the routing trees so that the first route identified will also be the best route.
それに注意するために、この戦略は、最初の許容できるルートを選ぶのに通じるでしょう。 ルーティング木を構成するのは、また、特定された最初のルートが最も良いルートになるくらい重要です。
13.2 Sharing routing information
13.2 ルーティング情報を共有すること。
So far, only single addresses have been considered. Improving routing choice for multiple addresses is analogous to dealing with multiple routes. This section defines an optional improvement. When multiple addresses are present, and alternate routes are available, the preferred routes may be chosen so as to maximise the number of recipients sent with each message.
今までのところ、ただ一つのアドレスだけが考えられました。 複数のアドレスのためのルーティング選択を改良するのは複数のルートに対処するのに類似しています。 このセクションは任意の改良を定義します。 複数のアドレスが存在していて、代替経路が利用可能であるときに、都合のよいルートは、各メッセージと共に送られた受取人の数を最大にするために選ばれるかもしれません。
Specification of routing trees can facilitate this optimisation. Suppose there is a set of addresses (e.g., in an organisation) which have different MTAs, but have access to an MTA which will do local switching. If each address is registered with the optimal MTA as preferred, but has the "hub" MTA registered with a higher route weight, then optimisation may occur when a message is sent to multiple addresses in the group.
ルーティング木の仕様はこの最適化を容易にすることができます。 異なったMTAsを持っている1セットのアドレス(例えば、機構における)があると仮定しなさい、ただし、地方の切り換えをするMTAに近づく手段を持ってください。 グループで複数のアドレスにメッセージを送るとき、各アドレスで好まれるように最適のMTAに登録されますが、より高いルート重りに「ハブ」MTAとともに記名するなら、最適化は起こるかもしれません。
14. Looking up Information in the Directory
14. ディレクトリにおける情報を調べます。
The description so far has been abstract about lookup of information. This section considers how information is looked up in the Directory. Consider that an O/R Address is presented for lookup, and there is a sequence of routing trees. At any point in the lookup sequence, there is one of a set of actions that can take place:
今までのところの記述は情報のルックアップに関して抽象的です。 このセクションは、情報がディレクトリでどのように調べられるかを考えます。 ルックアップのためにO/R Addressを寄贈して、ルーティング木の系列があると考えてください。 ルックアップ系列の任意な点に、行われることができる1セットの機能の1つがあります:
Entry Found Information from the entry (node) is returned and shall
be examined. The routing process continues or terminates, based
on this information.
エントリー(ノード)からのエントリーFound情報は、返されて、調べられるものとします。 ルーティングプロセスは、この情報に基づいて続くか、または終わります。
Entry Not Found Return information on the length of best possible
match to the routing algorithm.
ルーティング・アルゴリズムへの可能な限り良いマッチの長さのエントリーNot Found Return情報。
Temporary Reject The MTA shall stop the calculation, and repeat the
request later. Repeated temporary rejects should be handled in a
similar manner to the way the local MTA would handle the failure
to connect to a remote MTA.
一時的なReject MTAは計算を止めて、後で要求を繰り返すものとします。 繰り返された一時的な廃棄物は同じように地方のMTAがリモートMTAに接続しないことを扱うだろうという方法に扱われるべきです。
Permanent Reject Administrative error on the directory which may be
fixed in future, but which currently prevents routing. The
routing calculation should be stopped and the message
non-delivered.
これから、修理されるかもしれませんが、現在掘るのを防ぐディレクトリにおける永久的なReject Administrative誤り。 ルーティング計算は、止まってメッセージであるべきです。非提供されています。
The algorithm proceeds by a series of directory read operations. If the read operation is successful, the Entry Found procedure should be
アルゴリズムは操作が読まれたディレクトリのシリーズで続きます。 読書操作がうまくいくなら、Entry Found手順はうまくいくべきです。
Kille Experimental [Page 31] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[31ページ]RFC1801X.400-MHSルート設定
followed. Errors from the lookup (directory read) shall be handled in terms of the above procedures as follows. The following handling is used when following a routing tree:
続かれる。 ルックアップ(ディレクトリは読んだ)からの誤りは以下の上の手順で扱われるものとします。 ルーティング木に続くとき、以下の取り扱いは使用されています:
AttributeError This leads to a Permanent Reject.
AttributeError ThisはPermanent Rejectに通じます。
NameError Entry Not Found is used. The matched parameter is used to
determine the number of components of the name that have matched
(possibly zero). The read may then repeated with this name.
This is the normal case, and allows the "best" entry in the
routingn tree to be located with two reads.
NameError Entry Not Foundは使用されています。 取り組んでいるパラメタは、合っていた名前の成分(ことによるとゼロ)の数を測定するのに使用されます。 読みはそしてときにこの名前で繰り返された状態でそうするかもしれません。 これは、正常なケースであり、routingn木における「最も良い」エントリーが2つの読書で見つけられるのを許容します。
Referral The referral shall be followed, and then the procedure
recurses.
紹介、紹介は、続かれていて次に、手順「再-呪い」になるでしょう。
SecurityError Entry Not Found is used. Return a match length of one
less than the name provided.
SecurityError Entry Not Foundは使用されています。 名前が提供されたほど1のマッチの長さを返さないでください。
ServiceError This leads to a Temporary Reject.
ServiceError ThisはTemporary Rejectに通じます。
There will be cases where the algorithm moves to a name outside of the routing tree being followed (Following an accessMD attribute, or a redirect or a matched routing filter). The handling will be the same as above, except:
ケースが続かれているルーティング木の外にアルゴリズムが名前に移行するところにあるでしょう(再直接のフィルタaccessMD属性、または取り組んでいるルーティングフィルタに続いて)。 取り扱いは同じに以下を除いて、上でなるでしょう。
NameError This leads to a Permanent Reject.
NameError ThisはPermanent Rejectに通じます。
SecurityError This leads to a Permanent Reject.
SecurityError ThisはPermanent Rejectに通じます。
When reading objects which of not of object class routingInformation, the following error handling is used:
オブジェクトを読む、どれ、どんなオブジェクトのクラスroutingInformationでも、以下のエラー処理は使用されていません:
AttributeError This leads to a Permanent Reject.
AttributeError ThisはPermanent Rejectに通じます。
NameError This leads to a Permanent Reject.
NameError ThisはPermanent Rejectに通じます。
Referral The referral shall be followed, and then the procedure
recurses.
紹介、紹介は、続かれていて次に、手順「再-呪い」になるでしょう。
SecurityError In the case of an MTA, treat as if it is not possible
to route to this MTA. In other cases, this leads to a Permanent
Reject.
SecurityError In、ケース、MTAでは、まるでそれがこのMTAに発送するのにおいて可能でないかのように、扱ってください。 他の場合では、これはPermanent Rejectに通じます。
ServiceError This leads to a Temporary Reject.
ServiceError ThisはTemporary Rejectに通じます。
The algorithm specifies the object class of entries which are read. If an object class does not match what is expected, this shall lead to a permanent reject.
アルゴリズムは読まれるエントリーのオブジェクトのクラスを指定します。 オブジェクトのクラスが予想されることに合っていないなら、これは永久的な廃棄物に通じるものとします。
Kille Experimental [Page 32] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[32ページ]RFC1801X.400-MHSルート設定
15. Naming MTAs
15. MTAsを命名します。
MTAs need to be named in the DIT, but the name does not have routing significance. The MTA name is simply a unique key. Attributes associated with naming MTAs are given in Figure 6. This figure also gives a list of attributes, which may be present in the MTA entry. The use of most of these is explained in subsequent sections. The mTAName and globalDomainID attributes are needed to define the information that an MTA places in trace information. As noted previously, an MTA is represented as an Application Process, with one or more Application Entities.
MTAsは、DITで命名される必要がありますが、名前には、ルーティング意味がありません。 MTA名は単にユニークキーです。 図6でMTAsを命名すると関連している属性を与えます。 また、この図は属性のリストを与えます。(属性はMTAエントリーに存在しているかもしれません)。 これらの大部分の使用はその後のセクションで説明されます。 mTANameとglobalDomainID属性が、MTAがトレース情報で入賞するという情報を定義するのに必要です。 以前に注意されるように、MTAは1Application EntitiesとApplication Processとして表されます。
---------------------------------------------------------------------
---------------------------------------------------------------------
mTAName ATTRIBUTE ::= {
SUBTYPE OF name
WITH SYNTAX DirectoryString{ub-mta-name-length}
SINGLE VALUE
ID at-mta-name}
-- used for naming when
-- MTA is named in O=R Address Hierarchy
mTANameは以下を結果と考えます:= SUBTYPE OFはWITH SYNTAX DirectoryString ub-mta名前の長さをSINGLE VALUE IDとmta名で命名します--いつを命名するかために、使用されます--、MTAはO=R Address Hierarchyで命名されます。
globalDomainID ATTRIBUTE ::= { 10
WITH SYNTAX GlobalDomainIdentifier
SINGLE VALUE
ID at-global-domain-id}
-- both attributes present when MTA
-- is named outside O=R Address Hierarchy
-- to enable trace to be written
globalDomainIDは以下を結果と考えます:= 10WITH SYNTAX GlobalDomainIdentifier SINGLE VALUE ID、グローバルなドメインイド、--両方の属性が跡が書かれているのを可能にするために、いつMTA(O=R Address Hierarchyの外で命名される)を寄贈する
mTAApplicationProcess OBJECT-CLASS ::= {
SUBCLASS OF {application-process}
KIND auxiliary 20
MAY CONTAIN {
mTAWillRoute|
globalDomainID|
routingTreeList|
localAccessUnit|
accessUnitsUsed
}
ID oc-mta-application-process}
mTAApplicationProcessは以下をオブジェクトで分類します:= SUBCLASS OFのアプリケーション・プロセスのKINDの補助の20MAY CONTAIN mTAWillRoute|globalDomainID|routingTreeList|localAccessUnit|accessUnitsUsed、ID oc-mta-アプリケーション・プロセス
mTA OBJECT CLASS ::= { -- Application Entity 30
SUBCLASS OF {mhs-message-transfer-agent}
KIND structural
MAY CONTAIN {
mTAName|
globalDomainID| -- per AE variant
mTAオブジェクトは以下を分類します:= --、アプリケーションEntity30のSUBCLASS OFのmhs-メッセージ転送エージェントのKINDの構造的なMAY CONTAIN、mTAName| globalDomainID|、AE異形
Kille Experimental [Page 33] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[33ページ]RFC1801X.400-MHSルート設定
responderAuthenticationRequirements|
initiatorAuthenticationRequirements|
responderPullingAuthenticationRequirements|
initiatorPullingAuthenticationRequirements|
initiatorP1Mode| 40
responderP1Mode|
polledMTAs|
protocolInformation|
respondingRTSCredentials|
initiatingRTSCredentials|
callingPresentationAddress|
callingSelectorValidity|
bilateralTable|
mTAWillRoute|
mhs-deliverable-content-length| 50
routingTreeList|
supportedMTSExtensions|
mTAsAllowedToPoll
}
ID oc-mta}
responderAuthenticationRequirements| initiatorAuthenticationRequirements| responderPullingAuthenticationRequirements| initiatorPullingAuthenticationRequirements| initiatorP1Mode| 40 responderP1Mode| polledMTAs| protocolInformation| respondingRTSCredentials| initiatingRTSCredentials| callingPresentationAddress| callingSelectorValidity| bilateralTable| mTAWillRoute| mhs提出物のコンテンツの長さ| 50 routingTreeList| supportedMTSExtensions| mTAsAllowedToPoll ID oc-mta
Figure 6: MTA Definitions
図6: MTA定義
---------------------------------------------------------------------
---------------------------------------------------------------------
In X.400 (1984), MTAs are named by MD and a single string. This style of naming is supported, with MTAs named in the O/R Address tree relative to the root of the DIT (or possibly in a different routing tree). The mTAName attribute is used to name MTAs in this case. For X.400(88) the Distinguished Name shall be passed as an AE Title. MTAs may be named with any other DN, which can be in the O/R Address or Organisational DIT hierarchy. There are several reasons why MTAs might be named differently.
X.400(1984)では、MTAsはMDと一連によって命名されます。 このスタイルの命名はサポートされます、MTAsがDIT(またはことによると異なったルーティング木で)の根に比例したO/R Address木での命名にされるので。 mTAName属性は、この場合MTAsを命名するのに使用されます。 X.400(88)に関しては、Distinguished NameはAE Titleとして渡されるものとします。 MTAsはいかなる他のDNと共にも命名されるかもしれません。(O/R AddressかOrganisational DIT階層構造にはDNはあることができます)。 MTAsが異なって命名されるかもしれないいくつかの理由があります。
o The flat naming space is inadequate to support large MDs. MTA
name assignment using the directory would be awkward.
o 平坦な命名スペースは、大きいMDsをサポートするために不十分です。 ディレクトリを使用するMTA名前課題はまずいでしょう。
o An MD does not wish to register its MTAs in this way (essentially,
it prefers to give them private names in the directory).
o MDはこのようにMTAsを登録したがっていません(本質的には、それは、ディレクトリの個人的な名前を彼らに与えるのを好みます)。
o An organisation has a policy for naming application processes,
which does not fit this approach.
o 機構には、アプリケーションをプロセスと命名するための方針があります。(それは、このアプローチに合いません)。
In this case, the MTA entry shall contain the correct information to be inserted in trace. The mTAName and globalDomainID attributes are used to do this. They are single value. For an MTA which inserts different trace in different circumstances, a more complex approach would be needed.
この場合、MTAエントリーは跡に挿入されるべき正確な情報を含むものとします。 mTANameとglobalDomainID属性は、これをするのに使用されます。 それらはただ一つの値です。 異なった跡を異なった事情に挿入するMTAにおいて、より複雑なアプローチが必要でしょう。
Kille Experimental [Page 34] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[34ページ]RFC1801X.400-MHSルート設定
An MD may choose to name its MTAs outside of the O/R address hierarchy, and then link some or all of them with aliases. A pointer from this space may help in resolving information based on MTA Trace. The situation considered so far is where an MTA supports one application context (protocol). The MTA is represented in the directory by a single directory entry, having no subordinate applicationEntity entries. This name is considered to be the name of the MTA and its Application Process Title. The MTA has no Application Entity Qualifier, and so this is also the Application Entity Title. In the case where an MTA supports more than one application context, the Application Process Title is exactly the same as above, but it also has one or more subordinate applicationEntity entries. Each of these subordinate entries is associated with a single application context. The relative distinguished name of the subordinate applicationEntity entry is the Application Entity Qualifier of the Application Entity Title. The Application Entity Title is the distinguished name of the applicationEntity. The term MTA Name is used to refer to the Application Process Title.
MDはいくつかか彼らを皆、O/Rアドレス階層構造の外でMTAsを命名して、次に、別名にリンクするのを選ぶかもしれません。 このスペースからの指針は、MTA Traceに基づく情報を決議するのを手伝うかもしれません。 今までのところ考えられている状況はMTAが1つのアプリケーションが文脈(プロトコル)であるとサポートするところです。 どんな下位のapplicationEntityエントリーも持っていなくて、MTAはディレクトリに単一ディレクトリエントリーで表されます。 この名前はMTAとそのApplication Process Titleという名前であると考えられます。 MTAにはApplication Entity Qualifierが全くないので、また、これはApplication Entity Titleです。 MTAが1つ以上のアプリケーション文脈をサポートする場合では、Application Process Titleはまさにまた、上に1つ以上の下位のapplicationEntityエントリーを持っているのと同じです。 それぞれのこれらの下位のエントリーはただ一つのアプリケーション文脈に関連しています。 下位のapplicationEntityエントリーの相対的な分類名はApplication Entity TitleのApplication Entity Qualifierです。 Application Entity TitleはapplicationEntityの分類名です。 MTA Nameという用語は、Application Process Titleについて言及するのに使用されます。
15.1 Naming 1984 MTAs
15.1 1984MTAsを命名すること。
Some simplifications are necessary for 1984 MTAs, and only one naming approach may be used. This is because Directory Names are not carried in the protocol, and so it must be possible to derive the name algorithmically from parameters carried. In X.400, MTAs are named by MD and a single string. This style of naming is supported, with MTAs named in the O/R Address tree relative to the root of the DIT (or possibly in a different routing tree). The MTAName attribute is used to name MTAs in this case.
いくつかの簡素化が1984MTAsに必要です、そして、1つの命名アプローチだけを使用してもよいです。 これがディレクトリNamesがプロトコルで運ばれないからであるパラメタからalgorithmicallyするという名前を得るのが運ばれたのは、可能であるに違いありません。 X.400では、MTAsはMDと一連によって命名されます。 このスタイルの命名はサポートされます、MTAsがDIT(またはことによると異なったルーティング木で)の根に比例したO/R Address木での命名にされるので。 MTAName属性は、この場合MTAsを命名するのに使用されます。
16. Attributes Associated with the MTA
16. MTAに関連している属性
This section lists the attributes which may be associated with an MTA as defined in Figure 6, and gives pointers to the sections that describe them.
このセクションは、図6で定義されるようにMTAに関連するかもしれない属性を記載して、それらについて説明するセクションに指針を与えます。
mTAName Section 15.
mTAName部15。
globalDomainID Section 15.
globalDomainID部15。
protocolInformation Section 18.1.
protocolInformation部18.1。
applicationContext Section 18.2.
applicationContext部18.2。
mhs-deliverable-content-length Section 18.3.
提出物のコンテンツの長さをmhsしているセクション18.3。
responderAuthenticationRequirements Section 20.2.
responderAuthenticationRequirements部20.2。
Kille Experimental [Page 35] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[35ページ]RFC1801X.400-MHSルート設定
initiatorAuthenticationRequirements Section 20.2.
initiatorAuthenticationRequirements部20.2。
responderPullingAuthenticationRequirements Section 20.2.
responderPullingAuthenticationRequirements部20.2。
initiatorPullingAuthenticationRequirements Section 20.2.
initiatorPullingAuthenticationRequirements部20.2。
initiatorP1Mode Section 19.
initiatorP1Mode部19。
responderP1Mode Section 19.
responderP1Mode部19。
polledMTAs Section 19.
polledMTAs部19。
mTAsAllowedToPoll Section 19.
mTAsAllowedToPoll部19。
respondingRTSCredentials Section 20.3.
respondingRTSCredentials部20.3。
initiatingRTSCredentials Section 20.3.
initiatingRTSCredentials部20.3。
callingPresentationAddress Section 20.3.
callingPresentationAddress部20.3。
callingSelectorValidity Section 20.3.
callingSelectorValidity部20.3。
bilateralTable Section 17.
bilateralTable部17。
mTAWillRoute Section 21.
mTAWillRoute部21。
routingTreeList Section 9.
routingTreeList部9。
supportedMTSExtensions Section 18.3.
supportedMTSExtensions部18.3。
---------------------------------------------------------------------
---------------------------------------------------------------------
mTABilateralTableEntry OBJECT-CLASS ::=
SUBCLASS OF {mTA| distinguishedNameTableEntry}
ID oc-mta-bilateral-table-entry}
mTABilateralTableEntryは以下をオブジェクトで分類します:= SUBCLASS OF、mTA| distinguishedNameTableEntry、IDのoc-mtaの双方のテーブル項目
Figure 7: MTA Bilateral Table Entry
図7: MTAの双方のテーブル項目
---------------------------------------------------------------------
---------------------------------------------------------------------
17. Bilateral Agreements
17. 二国間条約
Each MTA has an entry in the DIT. This will be information which is globally valid, and will be useful for handling general information about the MTA and for information common to all connections. In many cases, this will be all that is needed. This global information may be restricted by access control, and so need not be globally available. In some cases, MTAs will maintain bilateral and
各MTAはDITにエントリーを持っています。 これは、グローバルに有効な情報であり、MTAに関する取り扱い一般情報とすべての接続に、一般的な情報の役に立ちます。 多くの場合、これは必要であるすべてになるでしょう。 このグローバルな情報は、アクセスコントロールで制限されるかもしれないので、グローバルに利用可能である必要はありません。 そしていくつかの場合、MTAsが双方に維持する。
Kille Experimental [Page 36] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[36ページ]RFC1801X.400-MHSルート設定
multilateral agreements, which hold authentication and related information which is not globally valid. This section describes a mechanism for grouping such information into tables, which enables an MTA to have bilateral information or for a group of MTAs to share multilateral information. The description is for bilateral information, but is equally applicable to multilateral agreements.
多面的な協定。(その協定はグローバルに有効でない認証と関連する情報を保持します)。 テーブルへのMTAには双方の情報があるのを可能にするそのような情報を分類するか、またはMTAsのグループが多面的な情報を共有するように、このセクションはメカニズムについて説明します。 記述は、双方の情報のためにありますが、等しく多面的な協定に適切です。
For the purpose of a bilateral agreement, the MTA is considered to be an application entity. This means that when this is distinct from the application process, that the agreements are protocol specific.
二国間条約の目的のために、MTAはアプリケーション実体であると考えられます。 これはこれであるときに、それがアプリケーション・プロセスと異なっていて、協定がプロトコル特有であることを意味します。
A bilateral agreement is represented by one entry associated with each MTA participating in the bilateral agreement. For one end of the bilateral agreement, the agreement information will be keyed by the name of the MTA at the other end. Each party to the agreement will set up the entry which represents its half of the agreed policy. The fact that these correspond is controlled by the external agreement. In many cases, only one half of the agreement will be in the directory. The other half might be in an ADMD MTA configuration file.
二国間条約は二国間条約に参加する各MTAに関連している1つのエントリーで表されます。 二国間条約の片端に関しては、協定情報はMTAという名前によってもう一方の端に合わせられるでしょう。 協定への各当事者は同意された方針の半分を表すエントリーをセットアップするでしょう。 これらが対応しているという事実は外部の協定で制御されます。 多くの場合、協定の半分しかディレクトリにないでしょう。 もう片方の半分はADMD MTA構成ファイルにあるかもしれません。
MTA bilateral information is stored in a table, as defined in [15]. An MTA has access to a sequence of such tables, each of which controls agreements in both directions for a given MTA. Where an MTA is represented in multiple tables, the first agreement shall be used. This allows an MTA to participate in multilateral agreements, and to have private agreements which override these. The definition of entries in this table are defined in Figure 7. This table will usually be access controlled so that only a single MTA or selected MTAs which appear externally as one MTA can access it.
MTAの双方の情報は[15]で定義されるようにテーブルに保存されます。 MTAはそのようなテーブルの系列に近づく手段を持っています。それは与えられたMTAのためにそれぞれ両方の方向に協定を制御します。 MTAが複数のテーブルに表されるところでは、最初の協定は使用されるものとします。 これで、MTAは多面的な協定に参加して、これらをくつがえす個人的な協定を持っています。 このテーブルとのエントリーの定義は図7で定義されます。 通常、このテーブルは1MTAとして外部的に現れる独身のMTAか選択されたMTAsだけがそれにアクセスできるように制御されたアクセスになるでしょう。
---------------------------------------------------------------------
---------------------------------------------------------------------
bilateralTable ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE OF DistinguishedName
SINGLE VALUE
ID at-bilateral-table}
bilateralTableは以下を結果と考えます:= WITH SYNTAX SEQUENCE OF DistinguishedName SINGLE VALUE ID、テーブルの上に置く双方の。
Figure 8: Bilateral Table Attribute
エイト環: 双方のテーブル属性
---------------------------------------------------------------------
---------------------------------------------------------------------
Each entry in the table is of the object class distinguishedNameTableEntry, which is used to name the entry by the distinguished name of the MTA. In some cases discussed in Section 20.1, there will also be aliases of type textTableEntry. The MTA attributes needed as a part of the bilateral agreement (typically MTA Name/Password pairs), as described in Section 20.3, will always be
テーブルの各エントリーはオブジェクトのクラスdistinguishedNameTableEntryのものです。(distinguishedNameTableEntryは、MTAの分類名でエントリーを命名するのに使用されます)。 また、セクション20.1で議論したいくつかの場合には、タイプtextTableEntryの別名があるでしょう。 セクション20.3で説明される二国間条約(通常MTA Name/パスワード組)の一部がいつもあって必要であるMTA属性
Kille Experimental [Page 37] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[37ページ]RFC1801X.400-MHSルート設定
present. Other MTA attributes (e.g., presentation address) may be present for one of two reasons:
存在。 他のMTA属性(例えば、プレゼンテーションアドレス)は2つの理由の1つによって存在しているかもしれません:
1. As a performance optimisation
1. 性能最適化として
2. Because the MTA does not have a global entry
2. MTAにはグローバルなエントリーがないので
Every MTA with bilateral agreements will define a bilateral MTA table. When a connection from a remote MTA is received, its Distinguished Name is used to generate the name of the table entry. For 1984, the MTA Name exchanged at the RTS level is used as a key into the table. The location of the bilateral tables used by the MTA and the order in which they are used are defined by the bilateralTable attribute in the MTA entry, which is defined in Figure 8.
二国間条約があるあらゆるMTAが双方のMTAテーブルを定義するでしょう。 リモートMTAからの接続が受け取られているとき、Distinguished Nameは、テーブル項目の名前を生成するのに使用されます。 1984年のために、RTSレベルで交換されたMTA Nameはキーとしてテーブルに使用されます。 MTAエントリーでbilateralTable属性で、MTAによって使用された双方のテーブルの位置とそれらが使用されている注文を定義します。(それは、図8で定義されます)。
All of the MTA information described in Section 16 may be used in the bilateral table entries. This will allow bilateral control of a wide range of parameters.
セクション16で説明されたMTA情報のすべてが双方のテーブル項目で使用されるかもしれません。 これはさまざまなパラメタのバイラテラル制御を許容するでしょう。
Note: For some bilateral connections there is a need control various
other functions, such as trace stripping and originator address
manipulation. For now, this is left to implementation specific
extensions. This is expected to be reviewed in light of
implementation experience.
以下に注意してください。 何人かの双方の接続のために、他の様々な機能であって、跡などのように剥取っている必要性コントロールと創始者アドレス操作があります。 当分、これは実装の特定の拡大に残されます。 実装経験の観点からこれが見直されると予想されます。
18. MTA Selection
18. MTA選択
18.1 Dealing with protocol mismatches
18.1 プロトコルミスマッチに対処すること。
MTAs may operate over different stacks. This means that some MTAs cannot talk directly to each other. Even where the protocols are the same, there may be reasons why a direct connection is not possible. An environment where there is full connectivity over a single stack is known as a transport community [9]. The set of transport communities supported by an MTA is specified by use of the protocolInformation attribute defined in X.500(93). This is represented as a separate attribute for the convenience of making routing decisions.
MTAsは異なったスタックの上で作動するかもしれません。 これは、いくつかのMTAsが直接互いに話すことができないことを意味します。 プロトコルが同じであるところにさえ、ダイレクト接続が可能でない理由があるかもしれません。 単一のスタックの上に完全な接続性がある環境は輸送共同体[9]として知られています。 MTAによってサポートされた輸送共同体のセットはX.500(93)で定義されたprotocolInformation属性の使用で指定されます。 ルーティングを決定にすることの都合のためにこれは別々の属性として表されます。
Kille Experimental [Page 38] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[38ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
supportedMTSExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-mts-extensions}
supportedMTSExtensionsは以下を結果と考えます:= SUBTYPE OF objectIdentifier ID、サポートしているmts拡張子
Figure 9: Supported MTS Extensions
図9: MTS拡張子であるとサポートされます。
---------------------------------------------------------------------
---------------------------------------------------------------------
A community is identified by an object identifier, and so the mechanism supports both well known and private communities. A list of object identifiers corresponding to well known communities is given in Appendix B.
共同体がオブジェクト識別子によって特定されるので、メカニズムは、両方がよく知られていて私設の共同体であるとサポートします。 Appendix Bでよく知られている共同体に対応するオブジェクト識別子のリストを与えます。
18.2 Supported Protocols
18.2 サポートしているプロトコル
It is important to know the protocol capabilities of an MTA. This is done by the application context. There are standard definitions for the following 1988 protocols.
MTAのプロトコル能力を知るのは重要です。 アプリケーション文脈はこれをします。 以下の1988のプロトコルのための標準定義があります。
o P3 (with and without RTS, both user and MTS initiated)
o P3(RTSのあるなしにかかわらずユーザと開始されたMTSの両方)
o P7 (with and without RTS).
o P7(RTSのあるなしにかかわらず)。
o P1 (various modes). Strictly, this is the only one that matters
for routing.
o P1(様々なモード)。 厳密に、これはルーティングのために重要な唯一無二です。
In order to support P1(1984) and P1(1988) in X.410 mode, application contexts which define these protocols are given in Appendix C. This context is for use in the directory only, and would never be exchanged over the network.
P1(1984)とP1がX.410モードで(1988)であるとサポートするためにAppendix C.でこれらのプロトコルを定義するアプリケーション文脈を与えます。This文脈はディレクトリだけにおける使用のためにあって、ネットワークの上と決して交換しません。
For routing purposes, a message store which is not co-resident with an MTA is represented as if it had a co-resident MTA and configured with a single link to its supporting MTA.
ルーティング目的のために、MTAをもっているコレジデントでないメッセージ店は、まるでコレジデントMTAを持っているかのように表されて、MTAをサポートすることへの単一のリンクによって構成されます。
In cases where the UA is involved in exchanges, the UA will be of object class mhs-user-agent, and this will allow for appropriate communication information to be registered.
UAが交換にかかわる場合には、オブジェクトクラスのmhsユーザエージェントにはUAがあるでしょう、そして、これは適切なコミュニケーション情報が登録されるのを許容するでしょう。
18.3 MTA Capability Restrictions
18.3 MTA能力制限
In addition to policy restrictions, described in Section 21, an MTA may have capability restrictions. The maximum size of MPDU is defined by the standard attribute mhs-deliverable-content-length. The supported MTS extensions are defined by a new attribute specified in Figure 9.
セクション21で説明された方針制限に加えて、MTAには、能力制限があるかもしれません。 MPDUの最大サイズは標準の属性mhs提出物のコンテンツの長さによって定義されます。 サポートしているMTS拡張子は図9で指定された新しい属性によって定義されます。
Kille Experimental [Page 39] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[39ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
restrictedSubtree OBJECT-CLASS ::= {
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {
subtreeDeliverableContentLength|
subtreeDeliverableContentTypes|
subtreeDeliverableEITs}
ID oc-restricted-subtree}
10
subtreeDeliverableContentLength ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-length
ID at-subtree-deliverable-content-length}
restrictedSubtreeは以下をオブジェクトで分類します:= SUBCLASS OFがKINDの補助のMAY CONTAIN subtreeDeliverableContentLength|subtreeDeliverableContentTypes|subtreeDeliverableEITsを上回っている、IDのocの部外秘な下位木、10subtreeDeliverableContentLength ATTRIBUTE:、:= 下位木提出物のコンテンツの長さにおけるSUBTYPE OF mhs提出物のコンテンツの長さID
subtreeDeliverableContentTypes ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-types
ID at-subtree-deliverable-content-types}
subtreeDeliverableContentTypesは以下を結果と考えます:= SUBTYPE OF mhs提出物のcontent type ID、下位木提出物のcontent type
subtreeDeliverableEITs ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-eits 20
ID at-subtree-deliverable-eits}
subtreeDeliverableEITsは以下を結果と考えます:= 提出物がeitsする下位木のSUBTYPE OF mhs提出物がeitsされた20ID
Figure 10: Subtree Capability Restriction
図10: 下位木能力制限
---------------------------------------------------------------------
---------------------------------------------------------------------
It may be useful to define other capability restrictions, for example to enable routing of messages around MTAs with specific deficiencies. It has been suggested using MTA capabilities as an optimised means of expressing capabilities of all users associated with the MTA. This is felt to be undesirable.
他の能力制限を定義して、例えばMTAsの周りで特定の欠乏でメッセージのルーティングを可能にするのは役に立つかもしれません。 それは、MTAに関連しているすべてのユーザの能力を言い表す最適化された手段としてMTA能力を使用することで示されました。 これは望ましくないと感じられます。
18.4 Subtree Capability Restrictions
18.4 下位木能力制限
In many cases, users of a subtree will share the same capabilities. It is possible to specify this by use of attributes, as defined in Figure 10. This will allow for restrictions to be determined in cases where there is no entry for the user or O/R Address. This will be a useful optimisation in cases where the UA capability information is not available from the directory, either for policy reasons or because it is not there. This information may also be present in the domain tree (RFC 822).
多くの場合、下位木のユーザは同じ能力を共有するでしょう。 属性の使用でこれを指定するのは図10で定義されるように可能です。 これは、制限がユーザかO/R Addressのためのエントリーが全くない場合で決定しているのを許容するでしょう。 これはUA能力情報がディレクトリから利用可能でない場合で役に立つ最適化でしょう、方針が推論するか、またはそれがそこにないので。 また、この情報もドメイン木(RFC822)に存在しているかもしれません。
This shall be implemented as a collective attribute, so that it is available to all entries in the subtree below the entry. This can also be used for setting defaults in the subtree.
これは集合的な属性として実装されるものとします、それがエントリーの下の下位木におけるすべてのエントリーに利用可能であるように。 また、下位木にデフォルトをはめ込むのにこれを使用できます。
Kille Experimental [Page 40] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[40ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
initiatorP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-initiator-p1-mode}
initiatorP1Modeは以下を結果と考えます:= WITH SYNTAX P1Mode SINGLE VALUE ID、創始者p1モード
responderP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-responder-p1-mode} 10
responderP1Modeは以下を結果と考えます:= WITH SYNTAX P1Mode SINGLE VALUE ID、応答者p1モード、10
P1Mode ::= ENUMERATED {
push-only(0),
pull-only(1),
twa(2) }
P1Mode:、:= 列挙されます。唯一のプッシュ(0)、唯一の牽引力(1)、twa(2)
polledMTAs ATTRIBUTE ::= {
WITH SYNTAX PolledMTAs
ID at-polled-mtas}
20
PolledMTAs ::= SEQUENCE {
mta DistinguishedName,
poll-frequency INTEGER OPTIONAL --frequency in minutes
}
polledMTAsは以下を結果と考えます:= WITH SYNTAX PolledMTAs ID、投票されたmtas、20PolledMTAs:、:= 系列mta DistinguishedName、投票頻度INTEGER OPTIONAL--、数分間の頻度
mTAsAllowedToPoll ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-mtas-allowed-to-poll}
mTAsAllowedToPollは以下を結果と考えます:= 投票できたmtas SUBTYPE OF distinguishedName ID
Figure 11: Pulling Messages
図11: メッセージを引きます。
---------------------------------------------------------------------
---------------------------------------------------------------------
19. MTA Pulling Messages
19. メッセージを引くMTA
Pulling messages between MTAs, typically by use of two way alternate, is for bilateral agreement. It is not the common case. There are two circumstances in which it can arise.
通常ツーウェイ補欠の使用でMTAsの間にメッセージを引くのは、二国間条約のためのものです。 それはよくある例ではありません。 それが起こることができる2つの事情があります。
1. Making use of a connection that was opened to push messages.
1. 接続の使用をそれにするのは、メッセージを押すために開かれました。
2. Explicitly polling in order to pull messages
2. 明らかに、メッセージを引くために、投票します。
Attributes to support this are defined in Figure 11. These attributes indicate the capabilities of an MTA to pull messages, and allows a list of polled MTAs to be specified. If omitted, the normal case of push-only is specified. In the MTA Entry, the polledMTAs
これをサポートする属性は図11で定義されます。 これらの属性は、MTAがメッセージを引く能力を示して、投票されたMTAsのリストが指定されるのを許容します。 省略されるなら、プッシュだけの正常なケースは指定されます。 MTAエントリー、polledMTAsで
Kille Experimental [Page 41] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[41ページ]RFC1801X.400-MHSルート設定
attribute indicates MTAs which are to be polled and the mTAsAllowedToPoll attribute indicates MTAs that may poll the current MTA.
属性は投票されることになっているMTAsを示します、そして、mTAsAllowedToPoll属性は現在のMTAに投票するかもしれないMTAsを示します。
20. Security and Policy
20. セキュリティと方針
20.1 Finding the Name of the Calling MTA
20.1 呼んでいるMTAという名前を見つけること。
A key issue for authentication is for the called MTA to find the name of the calling MTA. This is needed for it to be able to look up information on a bilateral agreement.
認証のための主要な問題は呼ばれたMTAが呼んでいるMTAという名前を見つけることです。 これが、二国間条約の情報を調べることができるように必要です。
Where X.400(88) is used, the name is available as a distinguished name from the AE-Title derived from the AP-Title and AE-Qualifier in the A-Associate. For X.400(84), it will not be possible to derive a global name from the bind. The MTA Name exchanged in the RTS Bind will provide a key into the private bilateral agreement table (or tables), where the connection information can be verified. Thus for X.400(1984) it will only be possible to have bilateral inbound links or no authentication of the calling MTA.
X.400(88)が使用されているところでは、名前はA-仲間というAP-タイトルとAE-資格を与える人から得られたAE-タイトルからの分類名として利用可能です。 ひもからグローバル名を得るのはX.400(84)に関しては、可能にならないでしょう。 RTS Bindで交換されたMTA Nameは個人的な二国間条約テーブル(または、テーブル)にキーを供給するでしょう。そこでは、接続情報について確かめることができます。 したがって、双方のインバウンドリンクを持っていますが、呼んでいるMTAのどんな認証も持っていないのがX.400(1984)だけに関して、可能になるでしょう。
Note: CDC use a search here, as a mechanism to use a single table and
an 88/84 independent access. This may be considered for general
adoption. It appears to make the data model cleaner, possibly
at the expense of some performance. This will be considered in
the light of implementation experience.
以下に注意してください。 CDCは、単一のテーブルと88/84の独立しているアクセサリーを使用するのにメカニズムとしてここで検索を使用します。 これは一般的な採用のために考えられるかもしれません。 それはことによると何らかの性能を犠牲にしてモデルクリーナーにデータを作るように見えます。 これは実装経験の見地から考えられるでしょう。
20.2 Authentication
20.2 認証
The levels of authentication required by an MTA will have an impact on routing. For example, if an MTA requires strong authentication, not all MTAs will be able to route to it. The attributes which define the authentication requirements are defined in Figure 12.
MTAによって必要とされた認証のレベルはルーティングに影響を与えるでしょう。 MTAが例えばMTAsがそれに発送できるすべてではなく、強い認証を必要とするなら。 認証要件を定義する属性は図12で定義されます。
The attributes specify authentication levels for the following cases:
属性は以下のケースに認証レベルを指定します:
Responder These are the checks that the responder will make on the
initiator's credentials.
応答者Theseは応答者が創始者の資格証明書でするチェックです。
Initiator These are the checks that the initiator will make on the
responders credentials. Very often, no checks are needed ---
establishing the connection is sufficient.
創始者Theseは創始者が応答者資格証明書でするチェックです。 頻繁に、チェックは全く必要ではありません。--- 接続を確立するのは十分です。
Responder Pulling These are responder checks when messages are
pulled. These will often be stronger than for pushing.
メッセージが引かれるとき、応答者Pulling Theseは応答者チェックです。 これらは押すよりしばしばさらに強くなるでしょう。
Initiator Pulling For completeness.
創始者Pulling Forの完全性。
Kille Experimental [Page 42] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[42ページ]RFC1801X.400-MHSルート設定
If an attribute is omitted, no checks are required. If multiple checks are required, then each of the relevant bits shall be set. The attribute is single value, which implies that the MTA must set a single authentication policy.
属性が省略されるなら、チェックは全く必要ではありません。 複数のチェックが必要であるなら、それぞれの関連ビットは設定されるものとします。 属性はただ一つの値です。(その値は、MTAがただ一つの認証方針を設定しなければならないのを含意します)。
---------------------------------------------------------------------
---------------------------------------------------------------------
responderAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-authentication-requirements}
responderAuthenticationRequirementsは以下を結果と考えます:= WITH SYNTAX AuthenticationRequirements SINGLE VALUE ID、応答者認証要件
initiatorAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-authentication-requirements} 10
initiatorAuthenticationRequirementsは以下を結果と考えます:= WITH SYNTAX AuthenticationRequirements SINGLE VALUE ID、創始者認証要件、10
responderPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-pulling-authentication-requirements}
responderPullingAuthenticationRequirementsは以下を結果と考えます:= 認証要件を引いている応答者のWITH SYNTAX AuthenticationRequirements SINGLE VALUE ID
initiatorPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-pulling-authentication-requirements} 20
initiatorPullingAuthenticationRequirementsは以下を結果と考えます:= 認証要件を引いている創始者のWITH SYNTAX AuthenticationRequirements SINGLE VALUE ID、20
AuthenticationRequirements ::= BITSTRING {
mta-name-present(0),
aet-present(1),
aet-valid(2),
network-address(3),
simple-authentication(4),
strong-authentication(5),
bilateral-agreement-needed(6)}
AuthenticationRequirements:、:= BITSTRINGmta-名前現在の(0)、aet現在の(1)、aet有効な(2)、ネットワーク・アドレス(3)、強い認証(5)であって、双方の協定に必要な簡易認証(4)(6)
Figure 12: Authentication Requirements
図12: 認証要件
---------------------------------------------------------------------
---------------------------------------------------------------------
The values of the authentication requirements mean:
認証要件の値は以下を意味します。
mta-name-present That an RTS level MTA parameter shall be present for
logging purposes.
mta名前プレゼントThat、RTSの平らなMTAパラメタは伐採目的のために存在するでしょう。
aet-present That a distinguished name application entity title shall
be provided at the ACSE level.
分類名アプリケーション実体タイトルがACSEレベルで提供されるものとする現在のaet That。
Kille Experimental [Page 43] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[43ページ]RFC1801X.400-MHSルート設定
aet-valid As for aet-present, and that the AET be registered in the
directory. This may be looked up as a part of the validation
process. If mta-name-present is set, the RTS value of mta and
password shall correspond to those registered in the directory.
現在のaetのためのaet有効なAs、およびそれ、AET、ディレクトリに登録されてください。 これは合法化プロセスの一部として見上げられるかもしれません。 mta名前プレゼントが設定されるなら、mtaとパスワードのRTS値はディレクトリに登録されたものに対応するものとします。
network-address This can only be used for the responder. The AET
shall be looked up in the directory, and the
callingPresentationAddress attribute matched against the calling
address. This shall match exactly at the network level. The
validity of selectors will be matched according to the
callingSelectorValidity attribute.
応答者にネットワーク・アドレスThisを使用できるだけです。 AETはディレクトリで調べられるものとしました、そして、callingPresentationAddress属性は呼ぶアドレスに対して合っていました。 これはちょうどネットワークレベルで合っているものとします。 callingSelectorValidity属性に従って、セレクタの正当性は合わせられるでしょう。
simple-authentication All MTA and password parameters needed for
simple authentication shall be used. This will usually be in
conjunction with a bilateral agreement.
簡易認証All MTAと簡易認証に必要であるパスワードパラメタは使用されるものとします。 通常、これは二国間条約に関連しているでしょう。
strong-authentication Use of strong authentication.
強い認証の強い認証Use。
bilateral-agreement-needed This means that this MTA will only accept
connections in conjunction with a bilateral or multilateral
agreements. This link cannot be used unless such an agreement
exists.
必要である双方の協定Thisは、このMTAが双方の、または、多面的な協定に関連して接続を受け入れるだけであることを意味します。 そのような協定が存在していない場合、このリンクを使用できません。
These attributes may also be used to specify UA/MTA authentication policy. They may be resident in the UA entry in environments where this information cannot be modified by the user. Otherwise, it will be present in an MTA table (represented in the directory).
また、これらの属性は、UA/MTA認証方針を指定するのに使用されるかもしれません。 それらはユーザがこの情報を変更できない環境におけるUAエントリーで居住しているかもしれません。 さもなければ、それはMTAテーブル(ディレクトリでは、表される)に存在するでしょう。
An MTA could choose to have different authentication levels related to different policies (Section 21). This is seen as too complex, and so they are kept independent. The equivalent function can always be achieved by using multiple Application Entities with the application process.
MTAは、異なった認証レベルが異なった方針(セクション21)に関連させるのを選ぶことができました。 これが複雑過ぎるとみなされるので、それらは独立しているように保たれます。 アプリケーション・プロセスがある複数のApplication Entitiesを使用することによって、同等な機能をいつも獲得できます。
20.3 Authentication Information
20.3 認証情報
This section specifies connection information needed by P1. This is essentially RTS parameterisation needed for authentication. This is defined in Figure 13. Confidential bilateral information is implied by these attributes, and this will be held in the bilateral information agreement. This shall have appropriate access control applied. Note that in some cases, MTA information will be split across a private and public entry.
このセクションはP1によって必要とされた接続情報を指定します。 これは本質的には認証に必要であるRTSパラメタリゼーションです。 これは図13で定義されます。 秘密の双方の情報はこれらの属性によって含意されます、そして、これは双方の情報合意で保持されるでしょう。 これで、適切なアクセス管理を適用するものとします。 いくつかの場合、MTA情報が個人的で公共のエントリーの向こう側に分けられることに注意してください。
Kille Experimental [Page 44] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[44ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
respondingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-responding-rts-credentials}
respondingRTSCredentialsは以下を結果と考えます:= WITH SYNTAX RTSCredentials SINGLE VALUE ID、rts信任状を反応させていること。
initiatingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE 10
ID at-initiating-rts-credentials}
initiatingRTSCredentialsは以下を結果と考えます:= WITH SYNTAX RTSCredentials SINGLE VALUE10ID、rts信任状を開始していること。
RTSCredentials ::= SEQUENCE {
request [0] MTAandPassword OPTIONAL,
response [1] MTAandPassword OPTIONAL }
RTSCredentials:、:= 系列[0]MTAandPassword OPTIONAL、応答[1]MTAandPassword OPTIONALを要求してください。
MTAandPassword ::= SEQUENCE {
MTAName, 20
Password } -- MTAName and Password
-- from X.411
MTAandPassword:、:= X.411からMTAName、20パスワード(MTANameとパスワード)を配列してください。
callingPresentationAddress ATTRIBUTE ::= {
SUBTYPE OF presentationAddress
MULTI VALUE
ID at-calling-presentation-address}
callingPresentationAddressは以下を結果と考えます:= 呼んでいるプレゼンテーションが記述するSUBTYPE OF presentationAddress MULTI VALUE ID
callingSelectorValidity ATTRIBUTE ::= { 30
WITH SYNTAX CallingSelectorValidity
SINGLE VALUE
ID at-calling-selector-validity}
callingSelectorValidityは以下を結果と考えます:= 30WITH SYNTAX CallingSelectorValidity SINGLE VALUE ID、セレクタの正当性と呼ぶこと。
CallingSelectorValidity ::= ENUMERATED {
all-selectors-fixed(0),
tsel-may-vary(1),
all-selectors-may-vary(2) }
CallingSelectorValidity:、:= 列挙されます。オール(0)、tselをセレクタで修理する、-、-(1)、オールセレクタを変えてください、-、-(2)を変えるかもしれなくなってください。
Figure 13: MTA Authentication Parameters
図13: MTA認証パラメタ
---------------------------------------------------------------------
---------------------------------------------------------------------
Kille Experimental [Page 45] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[45ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
mTAWillRoute ATTRIBUTE ::= {
WITH SYNTAX MTAWillRoute
ID at-mta-will-route}
mTAWillRouteは以下を結果と考えます:= mtaで発送しているWITH SYNTAX MTAWillRoute ID
MTAWillRoute ::= SEQUENCE {
from [0] SET OF ORAddressPrefix OPTIONAL,
to [1] SET OF ORAddressPrefix OPTIONAL,
from-excludes [2] SET OF ORAddressPrefix OPTIONAL,
to-excludes [3] SET OF ORAddressPrefix OPTIONAL } 10
MTAWillRoute:、:= SEQUENCE、[1] [0] SET OF ORAddressPrefix OPTIONALからSET OF ORAddressPrefix OPTIONALまで-、除外、[2] SET OF ORAddressPrefix OPTIONAL、-、除外、[3] SET OF ORAddressPrefix OPTIONAL、10
ORAddressPrefix ::= DistinguishedName
ORAddressPrefix:、:= DistinguishedName
Figure 14: Simple MTA Policy Specification
図14: 簡単なMTA方針仕様
---------------------------------------------------------------------
---------------------------------------------------------------------
The parameters are:
パラメタは以下の通りです。
Initiating Credentials The credentials to be used when the local MTA
initiates the association. It gives the credentials to insert
into the request, and those expected in the response.
Credentialsを開始して、地方のMTAであるときに使用されるべき信任状は協会を開始します。 それは要求に挿入する信任状、および応答で予想されたものを与えます。
Responding Credentials The credentials to be used when the remote MTA
initiates the association. It gives the credential expected in
the request, and those to be inserted into the response.
Credentialsを反応させて、リモートMTAであるときに使用されるべき信任状は協会を開始します。 それは要求、およびそれらで応答に挿入されると予想された信任状を与えます。
Remote Presentation Address Valid presentation addresses, which the
remote MTA may connect from.
リモートPresentation Address Validプレゼンテーションアドレス。(リモートMTAはそのアドレスから接続するかもしれません)。
If an MTA/Password pair is omitted, the MTA shall default to the local MTA Name, and the password shall default to a zero-length OCTET STRING.
MTA/パスワード組が省略されるなら、MTAは地方のMTA Nameをデフォルトとするものとします、そして、パスワードは無の長さのOCTET STRINGをデフォルトとするものとします。
Note: Future versions of this specification may add more information
here relating to parameters required for strong authentication.
以下に注意してください。 この仕様の将来のバージョンは、強い認証に必要であるパラメタに関連しながら、ここで詳しい情報を加えるかもしれません。
21. Policy and Authorisation
21. 方針と認可
21.1 Simple MTA Policy
21.1の簡単なMTA方針
The routing trees will generally be configured in order to identify MTAs which will route to the destination. A simple means is identified to specify an MTA's policy. This is defined in Figure 14. If this attribute is omitted, the MTA shall route all traffic to the implied destinations from the context of the routing tree for any MTAs that have valid access to the routing tree.
一般に、ルーティング木は、目的地に発送するMTAsを特定するために構成されるでしょう。 簡潔な方法は、MTAの方針を指定するために特定されます。 これは図14で定義されます。 この属性が省略されるなら、MTAはルーティング木に有効なアクセスを持っているどんなMTAsのためにもすべての交通をルーティング木の文脈から暗示している目的地に発送するものとします。
Kille Experimental [Page 46] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[46ページ]RFC1801X.400-MHSルート設定
The multi-valued attribute gives a set of policies which the MTA will route. O/R Addresses are represented by a prefix, which identifies a subtree. A distinguished name encoding of O/R Address is used. There are three components:
マルチ評価された属性はMTAが発送する1セットの方針を与えます。 O/Rアドレスは接頭語によって表されます。(それは、下位木を特定します)。 O/R Addressをコード化する分類名は使用されています。 3つのコンポーネントがあります:
from This gives a set of O/R addresses which are granted permission
by this attribute value. If omitted, "all" is implied.
Thisから、許可がこの属性値によって与えられる1セットのO/Rアドレスを与えます。 省略されるなら、「すべて」は含意されます。
to This gives the set of acceptable destinations. If omitted,
"all" is implied.
Thisに許容できる目的地のセットにかけます。 省略されるなら、「すべて」は含意されます。
from-excludes This defines (by prefix) subtrees of the O/R address
tree which are explicitly excluded from the "from" definition.
If omitted, there are no exclusions.
-、除外、Thisは“from"定義から明らかに除かれるO/Rアドレス木の下位木を定義します(接頭語で)。 省略されるなら、除外が全くありません。
to-excludes This defines (by prefix) subtrees of the O/R address tree
which are explicitly excluded from the "to" definition. If
omitted, there are no exclusions.
-、除外、Thisは“to"定義から明らかに除かれるO/Rアドレス木の下位木を定義します(接頭語で)。 省略されるなら、除外が全くありません。
This simple policy will suffice for most cases. In particular, it gives sufficient information for most real situations where a policy choice is forced, and the application of this policy would prevent a message being routed.
この簡単な方針はほとんどのケースに十分でしょう。 特に、それは政治的選択が無理矢理、この方針の適用が、メッセージが発送されるのを防ぐところにほとんどの現実の状況のための十分な情報を与えます。
This simple prefixing approach does not deal explicitly with alias dereferencing. The prefixes refer to O/R addresses where aliases have been dereferenced. To match against these prefixes, O/R addresses being matched need to be "normalised by being looked up in the directory to resolve alias values. If the lookup fails, it shall be assumed that the provided address is already normalised. This means that policy may be misinterpreted for parts of the DIT not referenced in the directory.
アプローチが明らかに別名の「反-参照をつけ」を取扱わないこの簡単な前に置くこと。 接頭語は別名に「反-参照をつけ」てあるO/Rアドレスを参照します。 これらの接頭語に対して合うように、合わせられているO/Rアドレスは、「別名値を決議するためにディレクトリで調べられることによって、正常にされます」必要があります。 ルックアップが失敗すると、提供されたアドレスが既に正常にされると思われるでしょう。 これは、方針がディレクトリで参照をつけられないDITの部分に誤解されるかもしれないことを意味します。
The originator refers to the MTS originator, and the recipient to the MTS recipient, following any list expansion or redirect. This simple policy does not apply to delivery reports. Any advertised route shall work for delivery reports, and it does not makes sense to regulate this on the basis of the sender.
どんなリスト拡大か再直接でも続いて、創始者はMTS創始者、および受取人をMTS受取人に差し向けます。 この簡単な方針は配送レポートに適用されません。 広告を出しているルートがレポート、およびそれがそうしない配送のために扱うものとするいずれも送付者に基づいてこれを規制する意味になります。
21.2 Complex MTA Policy
21.2の複雑なMTA方針
MTAs will generally have a much more complex policy mechanism, such as that provided by PP MTA [10]. Representing this as a part of the routing decision is not done here, but may be addressed in future versions. Some of the issues which need to be tackled are:
一般に、MTAsには、PP MTA[10]によって提供されたそれなどのはるかに複雑な方針メカニズムがあるでしょう。 ルーティング決定の一部としてこれを表すのをここでしませんが、将来のバージョンに記述するかもしれません。 取り組まれる必要がある問題のいくつかは以下の通りです。
Kille Experimental [Page 47] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[47ページ]RFC1801X.400-MHSルート設定
o Use of charging and non-charging nets
o 請求と非請求ネットの使用
o Policy dependent on message size
o メッセージサイズに依存する方針
o Different policy for delivery reports.
o 配送のための異なった方針は報告します。
o Policy dependent on attributes of the originator or
recipient (e.g., mail from students)
o 創始者か受取人の属性に依存する方針(例えば、学生からのメール)
o Content type and encoded information types
o 満足しているタイプとコード化された情報タイプ
o The path which the message has traversed to reach the MTA
o メッセージがMTAに達するように横断した経路
o MTA bilateral agreements
o MTA二国間条約
o Pulling messages
o メッセージを引きます。
o Costs. This sort of policy information may also be for
information only.
o コスト。 また、この種類の方針情報は情報だけのためのものであるかもしれません。
MTAs may apply more complex routing policies. However, this shall not lead to the rejection of messages which might otherwise be correctly routed on the published policy information. Policies relating to submission do not need to be public. They can be private to the MTA.
MTAsは、より複雑なルーティング方針を適用するかもしれません。 しかしながら、これはそうでなければ発行された方針情報で正しく発送されるかもしれないメッセージの拒絶に通じないものとします。 服従に関連する方針は公共である必要はありません。 それらはMTAに個人的である場合があります。
---------------------------------------------------------------------
---------------------------------------------------------------------
redirect ATTRIBUTE ::= {
WITH SYNTAX Redirect
SINGLE VALUE
ID at-redirect}
ATTRIBUTEを向け直してください:、:= WITH SYNTAX Redirect SINGLE VALUE ID、-、再直接
Redirect ::= SEQUENCE OF SEQUENCE {
or-name ORName,
reason RedirectionReason, -- from X.411
filter CHOICE { 10
min-size [1] INTEGER,
max-size [2] INTEGER,
content [3] ContentType,
eit [4] ExternalEncodedInformationType } OPTIONAL
}
以下を向け直してください:= 系列の系列または、-、名前、X.411からのORName、理由RedirectionReasonがCHOICEをフィルターにかける、10分-サイズ[1]INTEGER、最大サイズ[2]INTEGER、内容[3]ContentType、eit[4]ExternalEncodedInformationType、OPTIONAL
Figure 15: Redirect Definition
図15: 定義を向け直してください。
---------------------------------------------------------------------
---------------------------------------------------------------------
Kille Experimental [Page 48] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[48ページ]RFC1801X.400-MHSルート設定
22. Delivery
22. 配送
22.1 Redirects
22.1は向け直します。
There is a need to specify redirects in the Directory. This will be useful for alternate names where an equivalent name (synonym) defined by an alias is not natural. An example where this might be appropriate is to redirect mail to a new O/R address where a user had changed organisation. A mechanism is given to allow conditional (filtered) redirects for different types of messages. This allow small messages, large messages, or messages containing specific EITs or content to be redirected. The definitions are given in Figure 15.
指定する必要があります。ディレクトリでは、向け直します。 これは別名によって定義された同等な名前(同義語)が当然でない別名称の役に立ちます。 これが適切であるかもしれない例はユーザが機構を変えた新しいO/Rアドレスにメールを転送することです。 許容する当然のことは条件付きです(フィルターにかけられます)。メカニズム、異なったタイプに関するメッセージのために、向け直します。 これは、特定のEITsか内容を含む小さいメッセージ、大きいメッセージ、またはメッセージが向け直されるのを許容します。 図15で定義を与えます。
Redirection is specified by the redirect attribute. If present, this attribute shall be processed before supportingMTA and nonDeliveryInfo. These two attributes shall only be considered if it is determined that no redirection applies. The redirect attribute is a sequence of elements which are considered in the order specified. Each element is examined in turn. The first element which applies is used, and no further elements are examined. Use of an element for redirection, shall follow the X.400 procedures for redirection, and an element shall not be used if prevented by a service control. If the redirect attribute is processed and no redirection is generated, processing shall continue irrespective of service controls. If non- delivery is intended in this event, this shall be achieved by use of the nonDeliveryInfo attribute.
リダイレクションは再直接の属性によって指定されます。 存在しているなら、この属性はsupportingMTAとnonDeliveryInfoの前で処理されるものとします。 リダイレクションが全く適用されないのが、決定しているなら、これらの2つの属性しか考えられないものとします。 再直接の属性は指定されたオーダーで考えられる要素の系列です。 各要素は順番に調べられます。 適用される最初の要素は使用されています、そして、さらなる要素は全く調べられません。 使用、サービス制御で防がれると、リダイレクションのための要素について、リダイレクション、および要素のためのX.400手順がそうするものとする尾行を使用しないでしょうか? 再直接の属性が処理されて、リダイレクションが全く発生しないなら、処理はサービス制御の如何にかかわらず続くものとします。 非配送がこの出来事で意図するなら、これはnonDeliveryInfo属性の使用で達成されるものとします。
The components have the following interpretations:
コンポーネントには、以下の解釈があります:
or-name This X.400 O/R Name is for use in the redirection. This O/R
Name will contain an optional directory name and optional O/R
address. One or both of the must be present. If the O/R Address
element is present, the Directory Name, if present, is for
information only. and is to be placed in the X.400 redirection.
If the O/R address element is absent, the Directory Name shall be
present and shall be looked up to determine the O/R address of the
redirected recipient. The O/R Address of the intended recipient
will either be present or derived by lookup. Routing shall be
done on the basis of this O/R Address.
または、-、名前、This X.400O/R Nameはリダイレクションにおける使用のためのものです。 このO/R Nameは任意のディレクトリ名と任意のO/Rアドレスを含むでしょう。 1つか必須では両方の、存在してください。 O/R Address要素が存在しているなら、存在しているなら、ディレクトリNameは情報だけのために存在しています。. X.400リダイレクションに置かれることになっています。 O/Rアドレス要素が欠けるなら、ディレクトリNameは、存在して、向け直された受取人のO/Rアドレスを決定するために見上げられるものとします。 意図している受取人のO/R Addressはルックアップによって現在か派生するようにならされるでしょう。 このO/R Addressに基づいてルート設定をするものとします。
reason This is the reason information to be placed in the X.400
redirect, and it shall take one of the following values of
RedirectReason defined in X.411:
理由ThisはX.400に再直接で置かれるべき理由情報です、そして、X.411で定義されたRedirectReasonの以下の値の1つを取るものとします:
recipient-assigned-alternate-recipient;
recipient-MD-assigned-alternate-recipient; or alias. It shall not
have the value originator-requested-alternate-recipient.
受取人は交互の受取人を選任しました。 受取人MDは交互の受取人を選任しました。 または、別名。 それは値を受取人を交替するように創始者が、要求したしないものとします。
Kille Experimental [Page 49] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[49ページ]RFC1801X.400-MHSルート設定
filter If filter is absent, the redirect is mandoatory and shall be
followed. If the filter is present, use of the redirect under
consideration depends on the type of filter as follows:
フィルタIfフィルタが欠けていて、再直接は、mandoatoryであり、続かれるものとします。 フィルタが存在しているなら、考慮している再直接の使用を以下のフィルタのタイプに頼っています:
min-size Follow redirect if the message (MT content) is larger
than min-size (measured in kBytes).
Followがメッセージ(MT内容)であるなら向け直す分-サイズは分-サイズ(kBytesでは、測定される)より大きいです。
max-size Follow redirect if the message (MT content) is smaller
than max-size (measured in kBytes).
Followがメッセージ(MT内容)であるなら向け直す最大サイズは最大サイズ(kBytesでは、測定される)より小さいです。
content Follow redirect if message content is of type content.
Followがメッセージ内容であるなら向け直す内容はタイプ内容のものです。
eit Follow redirect if the encoded information types registered
in the envelope contain eit.
封筒を示されたコード化された情報タイプがeitを含んでいるなら、eit Followは向け直します。
When a delivery report is sent to an address which would be redirected, X.400 would ignore the redirect. This means that every O/R address would need to have a valid means of delivery. This would seem to be awkward to manage. Therefore, the redirect shall be followed, and the delivery report delivered to the redirected address.
配送レポートを転送されるアドレスに送るとき、X.400は再直接を無視するでしょう。 これは、あらゆるO/Rアドレスが配送の実証された方法を必要とすることを意味します。 これは管理するために無器用であるように思えるでしょう。 したがって、再直接は続かれるものとしました、そして、配送レポートは向け直されたアドレスに配送されました。
These redirects are handled directly by the MTA. Redirects can also be initiated by the UA, for example in the context of a P7 interaction.
これらが向け直す、直接MTAによって扱われます。 向け直す、また、UA、例えば、P7相互作用の文脈で開始できます。
---------------------------------------------------------------------
---------------------------------------------------------------------
nonDeliveryInfo ATTRIBUTE ::= {
WITH SYNTAX NonDeliveryReason
SINGLE VALUE
ID at-non-delivery-info}
nonDeliveryInfoは以下を結果と考えます:= WITH SYNTAX NonDeliveryReason SINGLE VALUE ID、非配送しているインフォメーション
NonDeliveryReason ::= SEQUENCE {
reason INTEGER (0..ub-reason-codes),
diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
supplementaryInfo PrintableString OPTIONAL } 10
NonDeliveryReason:、:= SEQUENCEがINTEGER(0..ub理由コード)、診断INTEGER(0..ubの診断コード)OPTIONAL、supplementaryInfo PrintableString OPTIONALを推論する、10
Figure 16: Non Delivery Information
図16: 非配送情報
---------------------------------------------------------------------
---------------------------------------------------------------------
22.2 Underspecified O/R Addresses
22.2 Underspecified O/Rアドレス
X.400 requires that some underspecified O/R Addresses are handled in a given way (e.g., if a surname is given without initials or given name). Where an underspecified O/R Address is to be treated as if it were another O/R Address, an alias shall be used. If the O/R Address
X.400は、いくつかのunderspecified O/R Addressesが与えられた方法で扱われるのを必要とします(例えば、イニシャルも名なしで姓を与えるなら)。 underspecified O/R Addressがまるでそれが別のO/R Addressであるかのように扱われることになっているところでは、別名は使用されるものとします。 O/Rアドレスです。
Kille Experimental [Page 50] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[50ページ]RFC1801X.400-MHSルート設定
is to be rejected as ambiguous, an entry shall be created in the DIT, and forced non-delivery specified for this reason.
あいまいです、エントリーがDITで作成されるものとして、無理矢理の非配送がこの理由に指定したように拒絶されることになっています。
Note: It is also possible to handle this situation by searching. An
MTA conforming to this specification may handle underspecified
addresses in this manner. The choice of mechanism will be
reviewed after operational experience with both approaches.
以下に注意してください。 また、探すことによってこの状況を扱うのも可能です。 この仕様に従うMTAはこの様にunderspecifiedアドレスを扱うかもしれません。 両方の運用経験にアプローチした後にメカニズムの選択は見直されるでしょう。
22.3 Non Delivery
22.3 非配送
It is possible for a manager to define an address to non-deliver with specified reason and diagnostic codes. This might be used for a range of management purposes. The attribute to do this is defined in Figure 16. If a nonDeliveryInfo attribute is present, any supportingMTA attribute shall be ignored and the message non- delivered.
マネージャがアドレスを定義するのにおいてそれが可能である、非、配送、指定された理由と診断コードで。 これはさまざまな管理目的に使用されるかもしれません。 これをする属性は図16で定義されます。 nonDeliveryInfo属性が存在しているなら、どんなsupportingMTA属性も、無視されていてメッセージになるでしょう。非渡します。
22.4 Bad Addresses
22.4 悪いアドレス
If there is a bad address, it is desirable to do a directory search to find alternatives. This is a helpful user service and may be supported. This function is invoked after address checking has failed, and where this is no user supplied alternate recipient. This function would be an MTA-chosen alternative to administratively assigned alternate recipient.
悪いアドレスがあれば、代替手段を見つけるためにディレクトリ検索をするのは望ましいです。 これは、役立っているユーザサービスであり、支持されるかもしれません。 この機能はアドレスの照合が失敗して、後これが交互の受取人に提供されなかったユーザであるところに全く呼び出されます。 この機能は行政上割り当てられた交互の受取人へのMTAによって選ばれた代替手段でしょう。
Attributes to support handling of bad addresses are defined in Figure 17. The attributes are:
悪いアドレスのサポート取り扱いへの属性は図17で定義されます。 属性は以下の通りです。
badAddressSearchPoint This gives the point (or list of points) from
which to search.
badAddressSearchPoint Thisは探すポイント(または、ポイントのリスト)を与えます。
badAddressSearchAttributes This gives the set of attribute types to
search on. The default is common name.
badAddressSearchAttributes Thisは身体検査する属性タイプのセットをオンに与えます。 デフォルトは一般名です。
Kille Experimental [Page 51] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[51ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
badAddressSearchPoint ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-bad-address-search-point}
badAddressSearchPointは以下を結果と考えます:= 悪いアドレスをポイントを捜しているSUBTYPE OF distinguishedName ID
badAddressSearchAttributes ATTRIBUTE ::= {
WITH SYNTAX AttributeType
ID at-bad-address-search-attributes}
badAddressSearchAttributesは以下を結果と考えます:= 悪いアドレスを属性を捜しているWITH SYNTAX AttributeType ID
alternativeAddressInformation EXTENSION 10
AlternativeAddressInformation
::= id-alternative-address-information
-- X.400(92) continues to use MACRO notation
alternativeAddressInformation拡張子10AlternativeAddressInformation:、:= イド代替手段アドレス情報--X.400(92)は、MACRO記法を使用し続けています。
AlternativeAddressInformation ::= SET OF SEQUENCE {
distinguished-name DistinguishedName OPTIONAL,
or-address ORAddress OPTIONAL,
other-useful-info SET OF Attribute }
AlternativeAddressInformation:、:= 系列のセットまたは、分類名DistinguishedName OPTIONAL、-、アドレス、ORAddress OPTIONAL、他の役に立つインフォメーションSET OF Attribute
Figure 17: Bad Address Pointers
図17: 悪いアドレス・ポインタ
---------------------------------------------------------------------
---------------------------------------------------------------------
Searches are always single level, and always use approximate match. If a small number of matches are made, this is returned to the originator by use of the per recipient AlternativeAddressInformation in the delivery report (DR). This shall be marked non-critical, so that it will not cause the DR to be discarded (e.g., in downgrading to X.400(1984)). This attribute allows the Distinguished Name and O/R Address of possible alternate recipients to be returned with the delivery report. There is also the possibility to attach extra information in the form of directory attributes. Typically this might be used to return attributes of the entry which were matched in the search. A summary of the information shall also be returned using the delivery report supplementary information filed (e.g., "your message could not be delivered to smith, try J. Smith or P. Smith"), so that the information is available to user agents not supporting this extension. Note the length restriction of this field is 256 (ub-supplementary-info-length) in X.400(1988).
検索は、いつもただ一つのレベルであり、いつも大体のマッチを使用します。 少ない数のマッチを作るなら、使用でこれを創始者に返す、配送における受取人AlternativeAddressInformation単位で(DR)を報告してください。 これは非臨界であるとマークされるものとします、それでDRを捨てない(例えば、X.400(1984)への格下げで)ように。 この属性で、可能な交互の受取人のDistinguished NameとO/R Addressは配送レポートと共に返ります。 また、ディレクトリ属性の形でその他の情報を添付する可能性があります。 通常、これは、検索で合っていたエントリーの属性を返すのに使用されるかもしれません。 また、補助情報がファイルした配送レポートを使用することで情報の概要を返すものとします。(例えば、「メッセージを鍛冶屋に送ることができないで、J.スミスかP.スミスを裁いてください」), この拡大を支持していないユーザエージェントにとって、情報が利用可能であるように。 この分野の長さの制限がX.400(1988)の256(ubの補っているインフォメーションの長さ)であることに注意してください。
If the directory search fails, or there are no matches returned, a delivery report shall be returned as if this extra check had not been made.
ディレクトリ検索が失敗するか、または返されたマッチが全くなければ、まるでこの余分なチェックをしていないかのように配送レポートを返すものとします。
Note: It might be useful to allow control of search type, and also
single level vs subtree. This issue is for further study.
以下に注意してください。 下位木に対して検索タイプのコントロールを許して、また、ただ一つのレベルを許容するのは役に立つかもしれません。 さらなる研究にはこの問題があります。
Kille Experimental [Page 52] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[52ページ]RFC1801X.400-MHSルート設定
---------------------------------------------------------------------
---------------------------------------------------------------------
localAccessUnit ATTRIBUTE ::= {
WITH SYNTAX AccessUnitType
ID at-local-access-unit}
localAccessUnitは以下を結果と考えます:= 地方でユニットにアクセスしているWITH SYNTAX AccessUnitType ID
AccessUnitType ::= ENUMERATED {
fax (1),
physical-delivery (2),
teletex (3),
telex (4) } 10
AccessUnitType:、:= ENUMERATEDがファックスで(1)、物理的な配送(2)、テレテックス(3)、テレックス(4)を送る、10
accessUnitsUsed ATTRIBUTE ::= {
WITH SYNTAX SelectedAccessUnit
ID at-access-units-used}
accessUnitsUsedは以下を結果と考えます:= アクセスしているユニットが使用したWITH SYNTAX SelectedAccessUnit ID
SelectedAccessUnit ::= SEQUENCE {
type AccessUnitType,
providing-MTA DistinguishedName,
filter SET OF ORAddress OPTIONAL }
SelectedAccessUnit:、:= 系列タイプAccessUnitType(提供-MTA DistinguishedName)はSET OF ORAddress OPTIONALをフィルターにかけます。
Figure 18: Access UnitAttributes
図18: アクセスUnitAttributes
---------------------------------------------------------------------
---------------------------------------------------------------------
23. Submission
23. 服従
A message may be submitted with Distinguished Name only. If the MTA to which the message is submitted supports this service, this section describes how the mapping is done.
Distinguished Nameだけと共にメッセージを提出するかもしれません。 メッセージが提出されるMTAがこのサービスを支持するなら、このセクションは、マッピングがどのように完了しているかを説明します。
23.1 Normal Derivation
23.1 通常の派生
The Distinguished Name is looked up to find the attribute mhs-or- addresses. If the attribute is single value, it is straightforward. If there are multiple values, one O/R address shall be selected at random.
または、Distinguished Nameが属性がmhsであることがわかるために見上げられる、-、-、アドレス。 属性がただ一つの値であるなら、簡単です。 複数の値があれば、1つのO/Rアドレスが無作為に選択されるものとします。
23.2 Roles and Groups
23.2 役割とグループ
Some support for roles is given. If there is no O/R address, and the entry is of object class role, then the roleOccupant attribute shall be dereferenced, and the message submitted to each of the role occupants. Similarly, if the entry is of object class group, where the groupMember attribute is used.
役割の何らかのサポートを与えます。 O/Rアドレスが全くなくて、エントリーが物のクラスの役割のものであるなら、roleOccupant属性は「反-参照をつけ」られるものとしました、そして、メッセージは役割の占有者各人に提出されました。 groupMember属性が使用されているところで同様に、エントリーが物のクラスのものであるなら分類してください。
Kille Experimental [Page 53] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[53ページ]RFC1801X.400-MHSルート設定
24. Access Units
24. アクセスユニット
Attributes needed for support of Access Units, as defined in X.400(88), are defined in Figure 18. The attributes defined are:
X.400(88)で定義されるようにAccess Unitsのサポートに必要である属性は図18で定義されます。 定義された属性は以下の通りです。
localAccessUnit This defines the list of access units supported by
the MTA.
localAccessUnit ThisはMTAによって支持されたアクセスユニットのリストを定義します。
accessUnitsUsed This defines which access units are used by the MTA,
giving the type and MTA. An O/R Address filter is provided to
control which access unit is used for a given recipient. For a
filter to match an address, all attributes specificed in the
filter shall match the given address. This is specified as an O/R
Address, so that routing to access units can be filtered on the
basis of attributes not mapped onto the directory (e.g., postal
attributes). Where a remote MTA is used, it may be necessary to
use source routing.
accessUnitsUsed Thisは、タイプとMTAに与えて、どのアクセスユニットがMTAによって使用されるかを定義します。 どのアクセスユニットが与えられた受取人に使用されるかを制御するためにO/R Addressフィルタを提供します。 フィルタがアドレスに合うように、フィルタでspecificedされたすべての属性が与えられたアドレスに合っているものとします。 これはO/R Addressとして指定されます、ディレクトリ(例えば、郵便の属性)に写像されなかった属性に基づいてユニットにアクセスするために掘るのをフィルターにかけることができるように。 リモートMTAが使用されているところでは、ソースルーティングを使用するのが必要であるかもしれません。
Note 1: This mechanism might be used to replace the routefilter
mechanism of the MTS routing. Comments are solicited.
注意1: このメカニズムは、MTSルーティングのroutefilterメカニズムを置き換えるのに使用されるかもしれません。 コメントは請求されます。
Note 2: It has been proposed to add a more powerful filter mechanism.
Comments are solicited.
注意2: それは、より強力なフィルタメカニズムを加えるために提案されました。 コメントは請求されます。
Note 3: The utility of this specification as a mechanism to route
faxes and other non MHS messages has been noted, but not explored.
Comments as to how and if this should be developed are solicited.
注意3: ファックスを発送するメカニズムと他の非MHSメッセージとしてのこの仕様に関するユーティリティは、注意されますが、探られていません。 どのように、これがそうであるべきであるかどうかに関して開発されたコメントは請求されます。
These three issues are for further study.
さらなる研究にはこれらの3冊があります。
25. The Overall Routing Algorithm
25. 総合的なルーティング・アルゴリズム
Having provided all the pieces, a summary of how routing works can be given.
すべての断片を提供したので、ルーティングがどう利くかの概要をすることができます。
The core of the X.400 routing is described in Section 10. A sequence of routing trees are followed. As nodes of the routing tree are matched, a set of MTAs will be identified for evaluation as possible next hops. If all of these are rejected, the trees are followed further. (It might be argued that the trees should be followed to find alternate routes in the case that only one MTA is acceptable. This is not proposed.) A set of MTAs is evaluated on the following criteria:
X.400ルーティングのコアはセクション10で説明されます。 ルーティング木の順序は従われています。 ルーティング木の節が取り組んでいるので、MTAsの1セットは評価のために次の可能なホップとして特定されるでしょう。 これらのすべてが拒絶されるなら、木はさらに続かれています。 (木が1MTAだけが許容できて、代替経路を見つけるために続かれるべきであると主張されるかもしれません。 これは提案されません。) MTAsの1セットは以下の評価基準で評価されます:
o If an MTA is the local MTA, deliver locally.
o MTAが地方のMTAであるなら、局所的に配送してください。
o Supported protocols. The MTA shall support a protocol that the
current MTA supports, as described in Section 18.2.
o プロトコルをサポートしました。 MTAはセクション18.2で説明されるように現在のMTAがサポートするプロトコルをサポートするものとします。
Kille Experimental [Page 54] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[54ページ]RFC1801X.400-MHSルート設定
(Note that this could be an RFC 822 protocol, as well as an
X.400 protocol.)
(これがRFC822プロトコルと、X.400プロトコルであるかもしれないことに注意してください。)
o The protocols shall share a common transport community, as
described in Section 18.1.
o プロトコルはセクション18.1で説明されるように一般的な輸送共同体を共有するものとします。
o There shall be no capability restrictions in the MTA which
prevents transfer of the current message, as described in
Section 18.3.
o 能力制限が全く現在のメッセージの転送を防ぐMTAにないでしょう、セクション18.3で説明されるように。
o There shall be no policy restrictions in the MTA which prevents
transfer of the current message, as described in Section 21.
o 方針制限が全く現在のメッセージの転送を防ぐMTAにないでしょう、セクション21で説明されるように。
o The authentication requirements of the MTA shall be met by the
local MTA, as described in Section 20.2.
o MTAに関する認証必要条件はセクション20.2で説明されるように地方のMTAによって満たされるものとします。
o If the authentication (Section 20.2) indicates that a bilateral
agreement is present, the MTA shall be listed in the local set of
bilateral agreements, as described in Section 17.
o 認証(セクション20.2)が、二国間条約が存在しているのを示すなら、MTAは地方のセットの二国間条約で記載されるものとします、セクション17で説明されるように。
o In cases where the recipient UA's capabilities can be determined,
there should either be no mismatch, or there shall be an ability
to use local or remote reformatting capabilities, as described
in [12].
o 受取人UAの能力が決定できる場合には、ミスマッチが全くあるべきではありませんか、または地方の、または、リモートな再フォーマット能力を使用する能力があるでしょう、[12]で説明されるように。
26. Performance
26. パフォーマンス
The routing algorithm has been designed with performance in mind. In particular, care has been taken to use only the read function, which will in general be optimised. Routing trees may be configured so that routing decisions can be made with only two directory reads. More complex configurations will not require a substantially larger number of operations.
ルーティング・アルゴリズムは性能で念頭に設計されています。 注意は特に、使用だけに取って、読み(一般に、最適化される)が機能するということです。 ルート設定木は、2つのディレクトリ読書だけでルーティング決定をすることができるように構成されるかもしれません。 より複雑な構成は実質的により大きい手術件数を必要としないでしょう。
27. Acknowledgements
27. 承認
This memo is the central document of a series of specifications [14, 15, 16], and to other work in progress. The acknowledgements for all of this work is given here. Previous work, which significantly influenced these specifications is described in Section 3. This lead to an initial proposal by the editor, which was subsequently split into eight documents. Work on this specifications has been done by the IETF MHS-DS working group. Special credit is given to the joint chairs of this group: Harald Alvestrand (Uninett) and Kevin Jordan (CDC). Credit is given to all members of the WG. Those who have made active contribution include: Piete Brooks (Cambridge University); Allan Cargille (University of Wisconsin); Jim Craigie (JNT); Dennis Doyle (SSS); Urs Eppenberger (SWITCH); Peter Furniss; Christian
このメモは、一連の仕様[14、15、16]の主要なドキュメントであり、他の処理中の作業にそうです。 この仕事のすべてのための承認をここに与えます。 前の仕事(これらの仕様にかなり影響を及ぼした)はそうです。セクション3では、説明されます。 エディタによる最初の提案へのこのリード。(そのエディタは、次に、8通のドキュメントに分けられました)。 IETF MHS-DSワーキンググループはこの仕様に対する仕事を完了していました。 特別なクレジットはこのグループを接続いすに与えます: ハラルドAlvestrand(Uninett)とケビン・ジョーダン(CDC)。 クレジットはすべてのメンバーにWGを与えます。 活発な貢献をした人は: Pieteは(ケンブリッジ大学)に耐えます。 アランCargille(ウィスコンシン大学)。 ジム・クレーギー(JNT)。 デニス・ドイル(SSS)。 ウルスEppenberger(スイッチ)。 ピーター・ファーニス。 クリスチャン
Kille Experimental [Page 55] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[55ページ]RFC1801X.400-MHSルート設定
Huitema (Inria); Marko Kaittola (Dante); Sylvain Langlois (EDF); Lucy Loftin (AT&T GIS); Julian Onions (NEXOR); Paul-Andre Pays (Inria); Colin Robbins (NEXOR); Michael Roe (Cambridge University); Jim Romaguera (Netconsult); Michael Storz (Leibniz Rechenzentrum); Mark Wahl (ISODE Consortium); Alan Young (ISODE Consortium).
Huitema(Inria)。 マルコKaittola(ダンテ)。 シルバン・ラングロイ(EDF)。 ルーシーLoftin(AT&T地理的情報システム)。 ジュリアンOnions(NEXOR)。 ポール-アンドレは(Inria)を支払います。 コリン・ロビンス(NEXOR)。 マイケルRoe(ケンブリッジ大学)。 ジムRomaguera(Netconsult)。 マイケル・シュトルツ(ライプニッツRechenzentrum)。 ウォールが(ISODE共同体)であるとマークしてください。 アラン・ヤング(ISODE共同体)。
This work was partly funded by the COSINE Paradise project.
この仕事はCOSINE Paradiseプロジェクトによって一部資金を供給されました。
28. References
28. 参照
[1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.
[1] ディレクトリ--- 概念の、そして、モデルの、そして、サービスの概観、1993。 CCITT X.500シリーズ勧告。
[2] J.N. Chiappa. A new IP routing and addressing architecture,
1991.
[2] J.N.Chiappa。 新しいIPルーティングと構造、1991を記述すること。
[3] A. Consael, M. Tschicholz, O. Wenzel, K. Bonacker, and M. Busch.
DFN-Directory nutzung durch MHS, April 1990. GMD Report.
[3] A.Consael、M.Tschicholz、O.ウェンツェル、K.Bonacker、およびM.ブッシュ。 1990年4月のDFN-ディレクトリnutzung durch MHS。 GMDは報告します。
[4] P. Dick-Lauder, R.J. Kummerfeld, and K.R. Elz. ACSNet - the
Australian alternative to UUCP. In EUUG Conference, Paris, pages
60--69, April 1985.
[4] P.ディック-ローダー、R.J.Kummerfeld、およびK.R.Elz。 ACSNet--UUCPへのオーストラリアの代替手段。 EUUGコンファレンス、パリ、60--69ページ、1985年4月に。
[5] 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.
[5] Eppenberger、U.、「スタティックルーティングのためのマルチプロトコル/マルチネットワーク環境テーブル形式V3の中のX.400 MHSサービスのためのルート設定コーディネート」、RFC1465は切り替わります、1993年5月。
[6] K.E. Jordan. Using X.500 directory services in support of X.400
routing and address mapping, November 1991. Private Note.
[6] K.E.ジョーダン。 X.400ルーティングとアドレス・マッピング、1991年11月を支持してX.500ディレクトリサービスを使用します。 私募債。
[7] S.E. Kille. MHS use of directory service for routing. In IFIP
6.5 Conference on Message Handling, Munich, pages 157--164.
North Holland Publishing, April 1987.
[7] 東南Kille。 ディレクトリサービスのルーティングのMHS使用。 Message Handling、ミュンヘン157--164ページのIFIP6.5コンファレンスで。 1987年4月に発行される北のオランダ。
[8] S.E. Kille. Topology and routing for MHS. COSINE Specification
Phase 7.7, RARE, 1988.
[8] 東南Kille。 MHSのためのトポロジーとルーティング。 1988にコサイン仕様フェーズ7.7で、まれ
[9] Kille, S., "Encoding Network Addresses to support operation over
non-OSI lower layers", RFC 1277, Department of Computer Science,
University College London, November 1991.
[9] S. Kille、「非OSIの低級層の上の操作をサポートするためにNetwork Addressesをコード化すること」でのRFC1277、コンピュータScience、ユニバーシティ・カレッジロンドン(1991年11月)の部。
[10] S.E. Kille. Implementing X.400 and X.500: The PP and QUIPU
Systems. Artech House, 1991. ISBN 0-89006-564-0.
[10] 東南Kille。 X.400を実装して、X.500: ppと結び縄文字システムArtech家、1991 ISBN0-89006-564-0。
[11] Kille, S., "A Representation of Distinguished Names
(OSI-DS 23 (v5))", RFC 1485, Department of Computer Science,
University College London, January 1992.
[11]Kille、S.、「分類名(OSI-DS23(v5))の表現」、RFC1485、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドン(1992年1月)。
Kille Experimental [Page 56] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[56ページ]RFC1801X.400-MHSルート設定
[12] Kille, S., Mhs use of X.500 directory to support mhs content
conversion, Work in Progress, July 1993.
[12]Kille、S.、mhs内容変換、ProgressのWorkに1993年7月をサポートするX.500ディレクトリのMhs使用。
[13] Kille, S., "Use of the X.500 directory to support routing for
RFC 822 and related protocols", Work in Progress, July 1993.
[13]Kille、S.、「支えるRFC822と関連するプロトコルのために掘られるX.500ディレクトリの使用」、Progress(1993年7月)のWork。
[14] Kille, S., "Representing tables and subtrees in the X.500
directory", Work in Progress, September 1994.
[14] S. Kille、Progress、1994年9月の「X.500ディレクトリのテーブルと下位木を表す」Work。
[15] Kille, S., "Representing the O/R Address hierarchy in the X.500
directory information tree", Work in Progress, September 1994.
[15] S. Kille、Progress、1994年9月の「X.500ディレクトリ情報木にO/R Address階層構造を表す」Work。
[16] Kille, S., "Use of the X.500 directory to support mapping
between X.400 and RFC 822 addresses", Work in Progress,
September 1994.
[16]Kille、S.、「X.400とRFCの間で822のアドレスを写像する支えるX.500ディレクトリの使用」、Progress(1994年9月)のWork。
[17] Lauder, P., Kummerfeld, R., and A. Fekete. Hierarchical network
routing. In Tricomm 91, 1991.
[17] ローダー、P.、Kummerfeld、R.、およびA.Fekete。 階層的なネットワークルーティング。 Tricomm91、1991で。
[18] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service
Overview.
1988年4月の[18]CCITT推薦X.400 / ISO10021。 CCITT SG5/VII/ISO/IEC JTC1、メッセージハンドリング: システムとサービス概要。
[19] Zen and the ART of navigating through the dark and murky regions
of the message transfer system: Working document on MTS
routing, September 1991. ISO SC 18 SWG Messaging.
[19] メッセージ転送システムの暗くて暗い領域を通ってナビゲートする禅とART: MTSルーティング、1991年9月にドキュメントを扱います。 ISO Sc18SWGメッセージング。
29. Security Considerations
29. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Kille Experimental [Page 57] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[57ページ]RFC1801X.400-MHSルート設定
30. Author's Address
30. 作者のアドレス
Steve Kille ISODE Consortium The Dome The Square Richmond TW9 1DT England
スティーブKille ISODE共同体のドームの正方形のリッチモンドTW9 1DTイギリス
Phone: +44-81-332-9091 EMail: S.Kille@ISODE.COM X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE; A=Mailnet; C=FI;
以下に電話をしてください。 +44-81-332-9091 メールしてください: S.Kille@ISODE.COM X.400: I=S。 S=Kille。 O=ISODE共同体。 P=ISODE。 A=Mailnet。 CはFIと等しいです。
DN: CN=Steve Kille, O=ISODE Consortium, C=GB
DN: CNはスティーブKille、O=ISODE共同体と等しく、CはGBと等しいです。
UFN: S. Kille, ISODE Consortium, GB
UFN: S。 Kille、ISODE共同体、GB
Kille Experimental [Page 58] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[58ページ]RFC1801X.400-MHSルート設定
A Object Identifier Assignment
オブジェクト識別子課題
-----------------------------------------------------------------------
-----------------------------------------------------------------------
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
mhs-ds OBJECT-IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の企業(1)isode-共同体(453)mhs-dsインターネット(1)(4)(7)
routing OBJECT IDENTIFIER ::= {mhs-ds 3}
ルーティングOBJECT IDENTIFIER:、:= mhs-ds3
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
oc OBJECT IDENTIFIER:、:= オブジェクト識別子におけるルーティング1:、:= ルーティング2イドOBJECT IDENTIFIER:、:= ルーティング3
10
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8}
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}
10oc-mta OBJECT IDENTIFIER:、:= oc1のoc-mtaの双方のテーブル項目OBJECT IDENTIFIER:、:= oc2ocルーティング情報OBJECT IDENTIFIER:、:= ocが下位木を制限しているoc3OBJECT IDENTIFIER:、:= oc4のoc発送されたua OBJECT IDENTIFIER:、:= oc8ocルーティング木の根のOBJECT IDENTIFIER:、:= oc6oc-mta-アプリケーション・プロセスOBJECT IDENTIFIER:、:= oc7
at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2} 20
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}
アクセスMdのOBJECT IDENTIFIER:、:= 1、ユニットが使用したアクセスにおけるOBJECT IDENTIFIER:、:= 2、20 下位木情報のOBJECT IDENTIFIER:、:= 3時に悪いアドレス検索属性のOBJECT IDENTIFIER:、:= 4時に悪いアドレスをポイントを捜してください、OBJECT IDENTIFIER:、:= 5
at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7}
セレクタの正当性と呼ぶところのOBJECT IDENTIFIER:、:= 7
at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}30
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40}
at-mta-name OBJECT IDENTIFIER ::= {at 19}
グローバルなドメインイドのOBJECT IDENTIFIER:、:= 10時にrts資格証明書を開始しているOBJECT IDENTIFIER:、:= 11時に創始者認証要件のOBJECT IDENTIFIER:、:= 12、30 創始者p1モードのOBJECT IDENTIFIER:、:= 13時に創始者の引いている認証要件のOBJECT IDENTIFIER:、:= 14時に地方のアクセスユニットのOBJECT IDENTIFIER:、:= 15、-、再直接、OBJECT IDENTIFIER:、:= 46歳のmtaインフォメーションのOBJECT IDENTIFIER:、:= 40、mta名前のOBJECT IDENTIFIER:、:= 19
at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}40
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 25}
mtaでルートを望んでいるOBJECT IDENTIFIER:、:= 21時にプレゼンテーションをアドレスと呼んでいるOBJECT IDENTIFIER:、:= 22時に応答者認証要件のOBJECT IDENTIFIER:、:= 23、40 応答者p1モードのOBJECT IDENTIFIER:、:= 24時に応答者の引いている認証要件のOBJECT IDENTIFIER:、:= 25
Kille Experimental [Page 59] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[59ページ]RFC1801X.400-MHSルート設定
at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28}
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33} 50
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45}
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}
rts資格証明書を反応させるところのOBJECT IDENTIFIER:、:= 26歳ルーティング失敗動作しているOBJECT IDENTIFIER:、:= 27、フィルタを発送するところのOBJECT IDENTIFIER:、:= 28歳のときにルーティング木に記載してください、OBJECT IDENTIFIER:、:= 29歳の下位木提出物のコンテンツの長さのOBJECT IDENTIFIER、:、:= 30歳の下位木提出物のcontent typeのOBJECT IDENTIFIER:、:= 31歳の下位木提出物のeits OBJECT IDENTIFIER:、:= 32歳のときにmta OBJECT IDENTIFIERをサポートします:、:= 33、50 輸送共同体のOBJECT IDENTIFIER:、:= 34歳のユーザ名のOBJECT IDENTIFIER:、:= 35歳の非配送しているインフォメーションのOBJECT IDENTIFIER:、:= 47歳の投票されたmtas OBJECT IDENTIFIER:、:= 37、43歳の双方のテーブルのOBJECT IDENTIFIER45歳サポートしている拡大しているOBJECT IDENTIFIER42歳サポートしているmts拡大しているOBJECT IDENTIFIER、投票できたmtasのOBJECT IDENTIFIER44
id-alternative-address-information OBJECT IDENTIFIER ::= {id 1} 60
イド代替手段アドレス情報OBJECT IDENTIFIER:、:= イド1 60
Figure 19: Object Identifier Assignment
図19: オブジェクト識別子課題
-----------------------------------------------------------------------
-----------------------------------------------------------------------
B Community Identifier Assignments
B共同体識別子課題
-----------------------------------------------------------------------
-----------------------------------------------------------------------
ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) ts-communities (4)}
t共同体OBJECT-IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の企業(1)isode-共同体(453)t共同体インターネット(1)(4)(4)
tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
-- Without CONS10
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)
TcまやかしOBJECT IDENTIFIER:、:= t共同体1--オウシコンズTc-clns OBJECT IDENTIFIER:、:= t共同体2--OSI CLNS TcインターネットOBJECT IDENTIFIER:、:= t共同体3--インターネット+RFC1006Tc-int-x25 OBJECT IDENTIFIER:、:= CONS10Tc-ixi OBJECT IDENTIFIERのないt共同体4(国際X.25):、:= t共同体5--IXI(ヨーロッパ)TcジャネットOBJECT IDENTIFIER:、:= t共同体6--ジャネット(イギリス)
Figure 20: Transport Community Object Identifier Assignments
図20: 輸送共同体オブジェクト識別子課題
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Kille Experimental [Page 60] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[60ページ]RFC1801X.400-MHSルート設定
C Protocol Identifier Assignments
Cプロトコル識別子課題
-----------------------------------------------------------------------
-----------------------------------------------------------------------
mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4)n enterprises(1) isode-consortium (453) mail-protocol (5)}
メールプロトコルOBJECT-IDENTIFIER:、:= iso(1) org(3) dod(6)nインターネットの(1)の私設の(4)企業(1)isode-共同体(453)メールプロトコル(5)
ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984)
ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail
(UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5} -- p1(1988) in
X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984) 10
ac-p1-1984 OBJECT IDENTIFIER:、:= メールプロトコル1--p1(1984)ac-smtp OBJECT IDENTIFIER:、:= メールプロトコル2--、SMTP ac-uucp OBJECT IDENTIFIER:、:= メールプロトコル3--UUCPメールac-jnt-メールOBJECT IDENTIFIER:、:= メールプロトコル4--JNTメール(イギリス)ac-p1-1988-x410 OBJECT IDENTIFIER:、:= メールプロトコル5--X.410モードac-p3-1984 OBJECT IDENTIFIERによるp1(1988):、:= メールプロトコル6--p3(1984)10
Figure 21: Protocol Object Identifier Assignments
図21: プロトコルオブジェクト識別子課題
-----------------------------------------------------------------------
-----------------------------------------------------------------------
D ASN.1 Summary
D ASN.1概要
-----------------------------------------------------------------------
-----------------------------------------------------------------------
MHS-DS-Definitions DEFINITIONS ::= BEGIN
MHS-DS-定義定義:、:= 始まってください。
-- assign OID to module -- define imports and exports
-- OIDをモジュールに割り当ててください--輸入と輸出を定義してください。
routingTreeRoot OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation|subtree}
ID oc-routing-tree-root} 10
routingTreeRootは以下をオブジェクトで分類します:= SUBCLASS OF、routingInformation| 下位木、ID ocルーティング木の根、10
routingTreeList ATTRIBUTE ::= {
WITH SYNTAX RoutingTreeList
SINGLE VALUE
ID at-routing-tree-list}
routingTreeListは以下を結果と考えます:= ルーティング木に記載されたWITH SYNTAX RoutingTreeList SINGLE VALUE ID
RoutingTreeList ::= SEQUENCE OF RoutingTreeName
RoutingTreeList:、:= RoutingTreeNameの系列
RoutingTreeName ::= DistinguishedName
20
routingInformation OBJECT-CLASS ::= {
SUBCLASS OF top
KIND auxiliary
MAY CONTAIN {
RoutingTreeName:、:= DistinguishedName20routingInformationは以下をオブジェクトで分類します:= SUBCLASS OFはKINDの補助のMAY CONTAINを上回っています。
Kille Experimental [Page 61] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[61ページ]RFC1801X.400-MHSルート設定
subtreeInformation|
routingFilter|
routingFailureAction|
mTAInfo|
accessMD|
nonDeliveryInfo| 30
badAddressSearchPoint|
badAddressSearchAttributes}
ID oc-routing-information}
-- No naming attributes as this is not a
-- structural object class
subtreeInformation| routingFilter| routingFailureAction| mTAInfo| accessMD| nonDeliveryInfo| 30 badAddressSearchPoint| badAddressSearchAttributes ID ocルーティング情報 -- これがaでないので、属性を命名しません--構造的なオブジェクトのクラス
subtreeInformation ATTRIBUTE ::= {
WITH SYNTAX SubtreeInfo 40
SINGLE VALUE
ID at-subtree-information}
subtreeInformationは以下を結果と考えます:= WITH SYNTAX SubtreeInfo40SINGLE VALUE ID、下位木情報
SubtreeInfo ::= ENUMERATED {
all-children-present(0),
not-all-children-present(1) }
SubtreeInfo:、:= 列挙されます。オール(0)を子供と同じくらい提示して、オール(1)は子供ほど提示しません。
routingFilter ATTRIBUTE ::= {
WITH SYNTAX RoutingFilter 50
ID at-routing-filter}
routingFilterは以下を結果と考えます:= WITH SYNTAX RoutingFilter50ID、ルーティングフィルタ
RoutingFilter ::= SEQUENCE{
attribute-type OBJECT-IDENTIFIER,
weight RouteWeight,
dda-key String OPTIONAL,
regex-match IA5String OPTIONAL,
node DistinguishedName }
60
String ::= CHOICE {PrintableString, TeletexString}
RoutingFilter:、:= SEQUENCEがOBJECT-IDENTIFIER、重さのRouteWeight、dda主要なString OPTIONAL、regex-マッチIA5String OPTIONAL、ノードDistinguishedNameを属性でタイプする、60String:、:= 選択PrintableString、TeletexString
routingFailureAction ATTRIBUTE ::= {
WITH SYNTAX RoutingFailureAction
SINGLE VALUE
ID at-routing-failure-action}
routingFailureActionは以下を結果と考えます:= WITH SYNTAX RoutingFailureAction SINGLE VALUE ID、ルーティング失敗動作
RoutingFailureAction ::= ENUMERATED {
next-level(0),
next-tree-only(1), 70
next-tree-first(2),
stop(3) }
RoutingFailureAction:、:= 列挙されます。次の1木-番目の次のレベル(0)の、そして、木の唯一の次の(1)の70(2)、停止(3)
Kille Experimental [Page 62] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[62ページ]RFC1801X.400-MHSルート設定
mTAInfo ATTRIBUTE ::= {
WITH SYNTAX MTAInfo
ID at-mta-info}
mTAInfoは以下を結果と考えます:= WITH SYNTAX MTAInfo ID、mtaインフォメーション
MTAInfo ::= SEQUENCE {
name DistinguishedName, 80
weight [1] RouteWeight DEFAULT preferred-access,
mta-attributes [2] SET OF Attribute OPTIONAL,
ae-info SEQUENCE OF SEQUENCE {
aEQualifier PrintableString,
ae-weight RouteWeight DEFAULT preferred-access,
ae-attributes SET OF Attribute OPTIONAL} OPTIONAL
}
MTAInfo:、:= 系列DistinguishedName、80の重さ[1]RouteWeight DEFAULTの都合のよいアクセスであって、mta属性の[2]SET OF Attribute OPTIONAL、ae-インフォメーションのSEQUENCE OF SEQUENCEのaEQualifier PrintableStringの、そして、ae重さのRouteWeight DEFAULT都合のよいアクセスであって、ae属性のSET OF Attribute OPTIONALをOPTIONALと命名してください。
RouteWeight ::= INTEGER {endpoint(0),
preferred-access(5), 90
backup(10)} (0..20)
RouteWeight:、:= INTEGER、終点(0)、都合のよいアクセス(5)、90バックアップ(10)(0..20)
accessMD ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-access-md}
accessMDは以下を結果と考えます:= SUBTYPE OF distinguishedName ID、アクセスMd
routedUA OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation}
KIND auxiliary
MAY CONTAIN { 100
-- from X.402
mhs-deliverable-content-length|
mhs-deliverable-content-types|
mhs-deliverable-eits|
mhs-message-store|
mhs-preferred-delivery-methods|
-- defined here
supportedExtensions|
redirect|
supportingMTA| 110
userName|
nonDeliveryInfo}
ID oc-routed-ua}
routedUAは以下をオブジェクトで分類します:= X.402 mhs-提出物コンテンツの長さからの100| mhs-提出物content type| mhs-提出物eits| mhsに|メッセージで保存してください。SUBCLASS OF routingInformation、KINDの補助のMAY CONTAIN、mhsが都合のよい発送方法| --supportedExtensions| ここで定義されて、| supportingMTA| 110userNameを向け直してください|、nonDeliveryInfo、uaに発送されたID oc
supportedExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-extensions}
supportedExtensionsは以下を結果と考えます:= SUBTYPE OF objectIdentifier ID、サポートしている拡大
supportingMTA ATTRIBUTE ::= {
SUBTYPE OF mTAInfo 120
ID at-supporting-mta}
supportingMTAは以下を結果と考えます:= サポートすることでmtaしているSUBTYPE OF mTAInfo120ID
Kille Experimental [Page 63] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[63ページ]RFC1801X.400-MHSルート設定
userName ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-user-name}
ユーザ名は以下を結果と考えます:= SUBTYPE OF distinguishedName ID、ユーザ名
mTAName ATTRIBUTE ::= {
SUBTYPE OF name
WITH SYNTAX DirectoryString{ub-mta-name-length}
SINGLE VALUE 130
ID at-mta-name}
-- used for naming when
-- MTA is named in O=R Address Hierarchy
mTANameは以下を結果と考えます:= SUBTYPE OFはWITH SYNTAX DirectoryString ub-mta名前の長さをSINGLE VALUE130IDとmta名で命名します--いつを命名するかために、使用されます--、MTAはO=R Address Hierarchyで命名されます。
globalDomainID ATTRIBUTE ::= {
WITH SYNTAX GlobalDomainIdentifier
SINGLE VALUE
ID at-global-domain-id}
-- both attributes present when MTA
-- is named outside O=R Address Hierarchy 140
-- to enable trace to be written
globalDomainIDは以下を結果と考えます:= WITH SYNTAX GlobalDomainIdentifier SINGLE VALUE ID、グローバルなドメインイド、--両方の属性が跡が書かれているのを可能にするために、いつMTA(O=R Address Hierarchy140の外で命名される)を寄贈する
mTAApplicationProcess OBJECT-CLASS ::= {
SUBCLASS OF {application-process}
KIND auxiliary
MAY CONTAIN {
mTAWillRoute|
globalDomainID|
routingTreeList|
localAccessUnit| 150
accessUnitsUsed
}
ID oc-mta-application-process}
mTAApplicationProcessは以下をオブジェクトで分類します:= SUBCLASS OFのアプリケーション・プロセスのKINDの補助のMAY CONTAIN mTAWillRoute|globalDomainID|routingTreeList|localAccessUnit|150accessUnitsUsed、ID oc-mta-アプリケーション・プロセス
mTA OBJECT CLASS ::= { -- Application Entity
SUBCLASS OF {mhs-message-transfer-agent}
KIND structural
MAY CONTAIN {
mTAName|
globalDomainID| -- per AE variant 160
responderAuthenticationRequirements|
initiatorAuthenticationRequirements|
responderPullingAuthenticationRequirements|
initiatorPullingAuthenticationRequirements|
initiatorP1Mode|
responderP1Mode|
polledMTAs|
protocolInformation|
respondingRTSCredentials|
initiatingRTSCredentials| 170
mTAオブジェクトは以下を分類します:= --、アプリケーションのEntity SUBCLASS OFのmhs-メッセージ転送エージェントのKINDの構造的なMAY CONTAIN、mTAName| globalDomainID| --160responderAuthenticationRequirements| AE異形initiatorAuthenticationRequirements|responderPullingAuthenticationRequirements|initiatorPullingAuthenticationRequirements|initiatorP1Mode|responderP1Mode|polledMTAs|protocolInformation|respondingRTSCredentials|initiatingRTSCredentials単位で|、170
Kille Experimental [Page 64] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[64ページ]RFC1801X.400-MHSルート設定
callingPresentationAddress|
callingSelectorValidity|
bilateralTable|
mTAWillRoute|
mhs-deliverable-content-length|
routingTreeList|
supportedMTSExtensions|
mTAsAllowedToPoll
}
ID oc-mta} 180
callingPresentationAddress| callingSelectorValidity| bilateralTable| mTAWillRoute| mhs提出物のコンテンツの長さ| routingTreeList| supportedMTSExtensions| mTAsAllowedToPoll ID oc-mta 180
mTABilateralTableEntry OBJECT-CLASS ::=
SUBCLASS OF {mTA| distinguishedNameTableEntry}
ID oc-mta-bilateral-table-entry}
mTABilateralTableEntryは以下をオブジェクトで分類します:= SUBCLASS OF、mTA| distinguishedNameTableEntry、IDのoc-mtaの双方のテーブル項目
bilateralTable ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE OF DistinguishedName
SINGLE VALUE
ID at-bilateral-table}
190
supportedMTSExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-mts-extensions}
bilateralTableは以下を結果と考えます:= WITH SYNTAX SEQUENCE OF DistinguishedName SINGLE VALUE ID、テーブルの上に置く、双方の190supportedMTSExtensions ATTRIBUTE:、:= SUBTYPE OF objectIdentifier ID、サポートしているmts拡張子
restrictedSubtree OBJECT-CLASS ::= {
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {
subtreeDeliverableContentLength|
subtreeDeliverableContentTypes| 200
subtreeDeliverableEITs}
ID oc-restricted-subtree}
restrictedSubtreeは以下をオブジェクトで分類します:= SUBCLASS OFがKINDの補助のMAY CONTAIN subtreeDeliverableContentLength|subtreeDeliverableContentTypes|200subtreeDeliverableEITsを上回っている、IDのocの部外秘な下位木
subtreeDeliverableContentLength ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-length
ID at-subtree-deliverable-content-length}
subtreeDeliverableContentLengthは以下を結果と考えます:= 下位木提出物のコンテンツの長さにおけるSUBTYPE OF mhs提出物のコンテンツの長さID
subtreeDeliverableContentTypes ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-types
ID at-subtree-deliverable-content-types} 210
subtreeDeliverableContentTypesは以下を結果と考えます:= SUBTYPE OF mhs提出物のcontent type ID、下位木提出物のcontent type、210
subtreeDeliverableEITs ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-eits
ID at-subtree-deliverable-eits}
subtreeDeliverableEITsは以下を結果と考えます:= 提出物がeitsする下位木のSUBTYPE OF mhs提出物がeitsされたID
initiatorP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
initiatorP1Modeは以下を結果と考えます:= 構文P1Mode
Kille Experimental [Page 65] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[65ページ]RFC1801X.400-MHSルート設定
SINGLE VALUE
ID at-initiator-p1-mode} 220
SINGLE VALUE ID、創始者p1モード 220
responderP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-responder-p1-mode}
responderP1Modeは以下を結果と考えます:= WITH SYNTAX P1Mode SINGLE VALUE ID、応答者p1モード
P1Mode ::= ENUMERATED {
push-only(0),
pull-only(1),
twa(2) } 230
P1Mode:、:= (0)だけ、牽引力の唯一の(1)、twa(2)を押しているENUMERATED230
polledMTAs ATTRIBUTE ::= {
WITH SYNTAX PolledMTAs
ID at-polled-mtas}
polledMTAsは以下を結果と考えます:= WITH SYNTAX PolledMTAs ID、投票されたmtas
PolledMTAs ::= SEQUENCE {
mta DistinguishedName,
poll-frequency INTEGER OPTIONAL --frequency in minutes
}
240
mTAsAllowedToPoll ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-mtas-allowed-to-poll}
PolledMTAs:、:= SEQUENCE、mta DistinguishedName、投票頻度INTEGER OPTIONAL--、数分間の頻度、240mTAsAllowedToPoll ATTRIBUTE:、:= 投票できたmtas SUBTYPE OF distinguishedName ID
responderAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-authentication-requirements}
250
initiatorAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-authentication-requirements}
responderAuthenticationRequirementsは以下を結果と考えます:= WITH SYNTAX AuthenticationRequirements SINGLE VALUE ID、応答者認証要件、250initiatorAuthenticationRequirements ATTRIBUTE:、:= WITH SYNTAX AuthenticationRequirements SINGLE VALUE ID、創始者認証要件
responderPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-pulling-authentication-requirements}
260
initiatorPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-pulling-authentication-requirements}
responderPullingAuthenticationRequirementsは以下を結果と考えます:= 認証要件を引いている応答者のWITH SYNTAX AuthenticationRequirements SINGLE VALUE ID、260initiatorPullingAuthenticationRequirements ATTRIBUTE:、:= 認証要件を引いている創始者のWITH SYNTAX AuthenticationRequirements SINGLE VALUE ID
AuthenticationRequirements ::= BITSTRING {
AuthenticationRequirements:、:= BITSTRING
Kille Experimental [Page 66] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[66ページ]RFC1801X.400-MHSルート設定
mta-name-present(0),
aet-present(1),
aet-valid(2),
network-address(3), 270
simple-authentication(4),
strong-authentication(5),
bilateral-agreement-needed(6)}
mta-名前現在の(0)、aet現在の(1)、aet有効な(2)、ネットワーク・アドレス(3)、強い認証(5)であって、双方の協定に必要な270簡易認証(4)(6)
respondingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-responding-rts-credentials}
respondingRTSCredentialsは以下を結果と考えます:= WITH SYNTAX RTSCredentials SINGLE VALUE ID、rts資格証明書を反応させていること。
280
initiatingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-initiating-rts-credentials}
280initiatingRTSCredentialsが以下を結果と考えます:= WITH SYNTAX RTSCredentials SINGLE VALUE ID、rts資格証明書を開始していること。
RTSCredentials ::= SEQUENCE {
request [0] MTAandPassword OPTIONAL,
response [1] MTAandPassword OPTIONAL }
290
RTSCredentials:、:= SEQUENCEが[0]MTAandPassword OPTIONAL、応答[1]MTAandPassword OPTIONALを要求する、290
MTAandPassword ::= SEQUENCE {
MTAName,
Password } -- MTAName and Password
-- from X.411
MTAandPassword:、:= X.411からMTAName、パスワード(MTANameとパスワード)を配列してください。
callingPresentationAddress ATTRIBUTE ::= {
SUBTYPE OF presentationAddress
MULTI VALUE 300
ID at-calling-presentation-address}
callingPresentationAddressは以下を結果と考えます:= 呼んでいるプレゼンテーションが扱うSUBTYPE OF presentationAddress MULTI VALUE300ID
callingSelectorValidity ATTRIBUTE ::= {
WITH SYNTAX CallingSelectorValidity
SINGLE VALUE
ID at-calling-selector-validity}
callingSelectorValidityは以下を結果と考えます:= WITH SYNTAX CallingSelectorValidity SINGLE VALUE ID、セレクタの正当性と呼ぶこと。
CallingSelectorValidity ::= ENUMERATED {
all-selectors-fixed(0),
tsel-may-vary(1), 310
all-selectors-may-vary(2) }
CallingSelectorValidity:、:= 列挙されます。オール(0)、tselをセレクタで修理する、-、-(1)、310個のオールセレクタを変えてください、-、-(2)を変えるかもしれなくなってください。
mTAWillRoute ATTRIBUTE ::= {
WITH SYNTAX MTAWillRoute
mTAWillRouteは以下を結果と考えます:= 構文MTAWillRoute
Kille Experimental [Page 67] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[67ページ]RFC1801X.400-MHSルート設定
ID at-mta-will-route}
mtaでルートを望んでいるID
MTAWillRoute ::= SEQUENCE {
from [0] SET OF ORAddressPrefix OPTIONAL,
to [1] SET OF ORAddressPrefix OPTIONAL,
from-excludes [2] SET OF ORAddressPrefix OPTIONAL, 320
to-excludes [3] SET OF ORAddressPrefix OPTIONAL }
MTAWillRoute:、:= 系列[1] [0] SET OF ORAddressPrefix OPTIONALからSET OF ORAddressPrefix OPTIONALまで-、除外、[2] SET OF ORAddressPrefix OPTIONAL、320、-、除外、[3] SET OF ORAddressPrefix OPTIONAL
ORAddressPrefix ::= DistinguishedName
ORAddressPrefix:、:= DistinguishedName
redirect ATTRIBUTE ::= {
WITH SYNTAX Redirect
SINGLE VALUE
ID at-redirect}
ATTRIBUTEを向け直してください:、:= WITH SYNTAX Redirect SINGLE VALUE ID、-、再直接
Redirect ::= SEQUENCE OF SEQUENCE { 330
or-name ORName,
reason RedirectionReason, -- from X.411
filter CHOICE {
min-size [1] INTEGER,
max-size [2] INTEGER,
content [3] ContentType,
eit [4] ExternalEncodedInformationType } OPTIONAL
}
以下を向け直してください:= 系列の系列または、330、-、名前、X.411からのORName、理由RedirectionReasonがCHOICE[1]INTEGER[3] ([2] 最大サイズINTEGER、内容ContentType)がeitする分-サイズ[4]ExternalEncodedInformationTypeをフィルターにかける、OPTIONAL
nonDeliveryInfo ATTRIBUTE ::= { 340
WITH SYNTAX NonDeliveryReason
SINGLE VALUE
ID at-non-delivery-info}
nonDeliveryInfoは以下を結果と考えます:= 340WITH SYNTAX NonDeliveryReason SINGLE VALUE ID、非配送しているインフォメーション
NonDeliveryReason ::= SEQUENCE {
reason INTEGER (0..ub-reason-codes),
diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
supplementaryInfo PrintableString OPTIONAL }
NonDeliveryReason:、:= 系列理由INTEGER(0..ub理由コード)、診断INTEGER(0..ubの診断コード)OPTIONAL、supplementaryInfo PrintableString OPTIONAL
badAddressSearchPoint ATTRIBUTE ::= { 350
SUBTYPE OF distinguishedName
ID at-bad-address-search-point}
badAddressSearchPointは以下を結果と考えます:= 悪いアドレスをポイントを捜している350SUBTYPE OF distinguishedName ID
badAddressSearchAttributes ATTRIBUTE ::= {
WITH SYNTAX AttributeType
ID at-bad-address-search-attributes}
badAddressSearchAttributesは以下を結果と考えます:= 悪いアドレスを属性を捜しているWITH SYNTAX AttributeType ID
alternativeAddressInformation EXTENSION
AlternativeAddressInformation
::= id-alternative-address-information 360
-- X.400(92) continues to use MACRO notation
alternativeAddressInformation拡大AlternativeAddressInformation:、:= イド代替手段アドレス情報、360、--X.400(92)が、MACRO記法を使用し続けている
Kille Experimental [Page 68] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[68ページ]RFC1801X.400-MHSルート設定
AlternativeAddressInformation ::= SET OF SEQUENCE {
distinguished-name DistinguishedName OPTIONAL,
or-address ORAddress OPTIONAL,
other-useful-info SET OF Attribute }
AlternativeAddressInformation:、:= 系列のセットまたは、分類名DistinguishedName OPTIONAL、-、アドレス、ORAddress OPTIONAL、他の役に立つインフォメーションSET OF Attribute
localAccessUnit ATTRIBUTE ::= {
WITH SYNTAX AccessUnitType
ID at-local-access-unit} 370
localAccessUnitは以下を結果と考えます:= ローカルでユニットにアクセスしているWITH SYNTAX AccessUnitType ID、370
AccessUnitType ::= ENUMERATED {
fax (1),
physical-delivery (2),
teletex (3),
telex (4) }
AccessUnitType:、:= 列挙されます。ファックス(1)、物理的な配送(2)、テレテックス(3)は(4)をテレックスで送信します。
accessUnitsUsed ATTRIBUTE ::= {
WITH SYNTAX SelectedAccessUnit
ID at-access-units-used} 380
accessUnitsUsedは以下を結果と考えます:= アクセスしているユニットが使用したWITH SYNTAX SelectedAccessUnit ID、380
SelectedAccessUnit ::= SEQUENCE {
type AccessUnitType,
providing-MTA DistinguishedName,
filter SET OF ORAddress OPTIONAL }
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (7)}
SelectedAccessUnit:、:= SEQUENCEがAccessUnitType、提供-MTA DistinguishedName、フィルタSET OF ORAddress OPTIONALをタイプする、mhs-ds OBJECT-IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の企業(1)isode-共同体(453)mhs-dsインターネット(1)(4)(7)
routing OBJECT IDENTIFIER ::= {mhs-ds 3}
390
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8} 400
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}
ルーティングOBJECT IDENTIFIER:、:= mhs-ds3 390oc OBJECT IDENTIFIER:、:= オブジェクト識別子におけるルーティング1:、:= ルーティング2イドOBJECT IDENTIFIER:、:= ルーティング3oc-mta OBJECT IDENTIFIER:、:= oc1のoc-mtaの双方のテーブル項目OBJECT IDENTIFIER:、:= oc2ocルーティング情報OBJECT IDENTIFIER:、:= ocが下位木を制限しているoc3OBJECT IDENTIFIER:、:= oc4のoc発送されたua OBJECT IDENTIFIER:、:= oc8 400ocルーティング木の根のOBJECT IDENTIFIER:、:= oc6oc-mta-アプリケーション・プロセスOBJECT IDENTIFIER:、:= oc7
at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2}
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}
アクセスMdのOBJECT IDENTIFIER:、:= 1、ユニットが使用したアクセスにおけるOBJECT IDENTIFIER:、:= 2時に下位木情報のOBJECT IDENTIFIER:、:= 3時に悪いアドレス検索属性のOBJECT IDENTIFIER:、:= 4時に悪いアドレスをポイントを捜してください、OBJECT IDENTIFIER:、:= 5
at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7} 410
セレクタの正当性と呼ぶところのOBJECT IDENTIFIER:、:= 7、410
Kille Experimental [Page 69] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[69ページ]RFC1801X.400-MHSルート設定
at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40} 420
at-mta-name OBJECT IDENTIFIER ::= {at 19}
グローバルなドメインイドのOBJECT IDENTIFIER:、:= 10時にrts資格証明書を開始しているOBJECT IDENTIFIER:、:= 11時に創始者認証要件のOBJECT IDENTIFIER:、:= 12時に創始者p1モードのOBJECT IDENTIFIER:、:= 13時に創始者の引いている認証要件のOBJECT IDENTIFIER:、:= 14時に地方のアクセスユニットのOBJECT IDENTIFIER:、:= 15、-、再直接、OBJECT IDENTIFIER:、:= 46歳のmtaインフォメーションのOBJECT IDENTIFIER:、:= 40、420 mta名前のOBJECT IDENTIFIER:、:= 19
at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 25}
at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28} 430
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33}
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45} 440
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}
mtaでルートを望んでいるOBJECT IDENTIFIER:、:= 21時にプレゼンテーションをアドレスと呼んでいるOBJECT IDENTIFIER:、:= 22時に応答者認証要件のOBJECT IDENTIFIER:、:= 23時に応答者p1モードのOBJECT IDENTIFIER:、:= 24時に応答者の引いている認証要件のOBJECT IDENTIFIER:、:= 25歳のときにrts資格証明書を反応させているOBJECT IDENTIFIER:、:= 26歳ルーティング失敗動作しているOBJECT IDENTIFIER:、:= 27、フィルタを発送するところのOBJECT IDENTIFIER:、:= 28、430 木のリストを発送するところのOBJECT IDENTIFIER:、:= 29歳の下位木提出物のコンテンツの長さのOBJECT IDENTIFIER、:、:= 30歳の下位木提出物のcontent typeのOBJECT IDENTIFIER:、:= 31歳の下位木提出物のeits OBJECT IDENTIFIER:、:= 32歳のときにmta OBJECT IDENTIFIERをサポートします:、:= 33歳の輸送共同体のOBJECT IDENTIFIER:、:= 34歳のユーザ名のOBJECT IDENTIFIER:、:= 35歳の非配送しているインフォメーションのOBJECT IDENTIFIER:、:= 47歳の投票されたmtas OBJECT IDENTIFIER:、:= 37、45歳の双方のテーブルのOBJECT IDENTIFIER、43歳の440のサポートしている拡大しているOBJECT IDENTIFIER42歳サポートしているmts拡大しているOBJECT IDENTIFIER、投票できたmtasのOBJECT IDENTIFIER44
id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}
イド代替手段アドレス情報OBJECT IDENTIFIER:、:= イド1
ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) ts-communities (4)}
t共同体OBJECT-IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の企業(1)isode-共同体(453)t共同体インターネット(1)(4)(4)
450
tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
-- Without CONS
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)
450 TcまやかしOBJECT IDENTIFIER:、:= t共同体1--オウシコンズTc-clns OBJECT IDENTIFIER:、:= t共同体2--OSI CLNS TcインターネットOBJECT IDENTIFIER:、:= t共同体3--インターネット+RFC1006Tc-int-x25 OBJECT IDENTIFIER:、:= コンズTc-ixi OBJECT IDENTIFIERのないt共同体4(国際X.25):、:= t共同体5--IXI(ヨーロッパ)TcジャネットOBJECT IDENTIFIER:、:= t共同体6--ジャネット(イギリス)
Kille Experimental [Page 70] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[70ページ]RFC1801X.400-MHSルート設定
mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mail-protocol (5)} 460
メールプロトコルOBJECT-IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の(4)企業(1)isode-共同体(453)インターネット(1)メールプロトコル(5)、460
ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984)
ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail (UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5}
-- p1(1988) in X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984)
END
ac-p1-1984 OBJECT IDENTIFIER:、:= メールプロトコル1--p1(1984)ac-smtp OBJECT IDENTIFIER:、:= メールプロトコル2--、SMTP ac-uucp OBJECT IDENTIFIER:、:= メールプロトコル3--UUCPメールac-jnt-メールOBJECT IDENTIFIER:、:= メールプロトコル4--JNTメール(イギリス)ac-p1-1988-x410 OBJECT IDENTIFIER:、:= メールプロトコル5--X.410モードac-p3-1984 OBJECT IDENTIFIERによるp1(1988):、:= メールプロトコル6--p3(1984)END
Figure 22: ASN.1 Summary
図22: ASN.1概要
-----------------------------------------------------------------------
-----------------------------------------------------------------------
E Regular Expression Syntax
E正規表現構文
This appendix defines a form of regular expression for pattern matching. This pattern matching is derived from commonly available regular expression software including UNIX egrep(1) The matching is modified to be case insensitive.
この付録はパターン・マッチングのための正規表現の書式を定義します。 このパターン・マッチングはUNIX egrep(1)を含む一般的に利用可能な正規表現ソフトウェアから派生して、マッチングが大文字と小文字を区別しなくなるように変更されるということです。
A regular expression (RE) specifies a set of character strings to
match against - such as "any string containing digits 5 through
9". A member of this set of strings is said to be matched by the
regular expression.
正規表現(RE)は合っている1セットの「9インチを通してケタ5を含むどんなストリングも」などの文字列を指定します。 このセットのストリングのメンバーは正規表現で合わせられると言われています。
Where multiple matches are present in a line, a regular expression
matches the longest of the leftmost matching strings.
複数のマッチが並んで存在しているところでは、正規表現は最も長い間、一番左合っているストリングに合っています。
Regular expressions can be built up from the following
"single-character" RE's:
「単独のキャラクタ」REの以下のものから正規表現を確立できます:
c Any ordinary character not listed below. An ordinary
character matches itself.
どんな普通のキャラクタも以下に記載しなかったc。 普通のキャラクタはそれ自体に合っています。
\ Backslash. When followed by a special character, the RE
matches the "quoted" character, cancelling the special nature
of the character.
\バックスラッシュ。 特殊文字があとに続いていると、キャラクタの特別な本質を取り消して、REは「引用された」キャラクタに合っています。
. Dot. Matches any single character.
. 点を打ちます。 どんな単独のキャラクタも合わせます。
^ As the leftmost character, a caret (or circumflex) con-
strains the RE to match the leftmost portion of a string. A
match of this type is called an "anchored match" because it is
"anchored" to a specific place in the string. The ^ character
loses its special meaning if it appears in any position other
^一番左キャラクタとして、脱字記号(または、曲折アクセント)まやかしは、ストリングの一番左部分を合わせるためにREを張ります。 それがストリングの特定の場所に「据えつけられる」ので、このタイプのマッチは「据えつけられたマッチ」と呼ばれます。 どんな位置でも他に見えるなら、^キャラクタは特別な意味を失います。
Kille Experimental [Page 71] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[71ページ]RFC1801X.400-MHSルート設定
than the start of the RE.
REの始まりより。
$ As the rightmost character, a dollar sign constrains the RE to
match the rightmost portion of a string. The $ character
loses its special meaning if it appears in any position other
than at the end of the RE.
一番右のキャラクタ、ドル記号としての$は、REがストリングの一番右の部分に合っているのを抑制します。 REの端以外のどんな位置にも現れるなら、$キャラクタは特別な意味を失います。
^RE$ The construction ^RE$ constrains the RE to match the entire
string.
^工事^RE$がREを抑制するRE$は全体のストリングに合っています。
[c...]
A nonempty string of characters, enclosed in square brackets
matches any single character in the string. For example,
[abcxyz] matches any single character from the set `abcxyz'.
When the first character of the string is a caret (^), then
the RE matches any charac- ter except those in the remainder
of the string. For example, `[^45678]' matches any character
except `45678'. A caret in any other position is interpreted
as an ordinary character.
[c.。] キャラクタのnonemptyストリングであり、角括弧マッチに同封されて、いずれもストリングでキャラクタを選抜します。 例えば、[abcxyz]はセット'abcxyz'からどんな単独のキャラクタにも合っています。 そして、ストリングの最初のキャラクタが脱字記号(^)であるときに、REはストリングの残りにおけるそれら以外のどんなcharac- terにも合っています。 例えば、'[^45678]'は'45678'を除いたどんなキャラクタにも合っています。 いかなる他の位置の脱字記号も普通のキャラクタとして解釈されます。
[]c...]
The right square bracket does not terminate the enclosed
string if it is the first character (after an initial `^', if
any), in the bracketed string. In this position it is treated
as an ordinary character.
[]c.。] 右角括弧はそれが最初のキャラクタ(初期の'^'の後にもしあれば)であるなら同封のストリングを終えません、腕木を付けられたストリングで。 この位置では、それが普通のキャラクタとして扱われます。
[l-r]
The minus sign (hyphen), between two characters, indicates a
range of consecutive ASCII characters to match. For example,
the range `[0-9]' is equivalent to the string `[0123456789]'.
Such a bracketed string of characters is known as a character
class. The `-' is treated as an ordinary character if it
occurs first (or first after an initial ^) or last in the
string.
[l-r] マイナス記号(ハイフン)は、合うように2つのキャラクタの間にさまざまな連続したASCII文字を示します。 例えば、範囲'[0-9]'はストリング'[0123456789]'に同等です。 キャラクタのそのような腕木を付けられたストリングは文字クラスとして知られています。 最初に(または最初に、初期の^の後に)か最後にストリングに起こるなら、'--'は普通のキャラクタとして扱われます。
The following rules and special characters allow for
con-structing RE's from single-character RE's:
以下の規則と特殊文字は、単独のキャラクタREのものからREのものを組み立てると考慮します:
A concatenation of RE's matches a concatenation of text
strings, each of which is a match for a successive RE in the
search pattern.
REの連結はテキスト文字列の連結に合っています。それはそれぞれ検索パターンの連続したREのためのマッチです。
* A regular expression, followed by an asterisk (*) matches zero
or more occurrences of the regular expression. For example,
[a-z][a-z]* matches any string of one or more lower case
letters.
* マッチが合っているゼロアスタリスク(*)か正規表現の、より多くの発生によって続かれた正規表現。 例えば、[a-z][a-z]*は1つ以上の小文字のどんなストリングにも合っています。
Kille Experimental [Page 72] RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
ディレクトリ1995年6月にX.500を使用するKilleの実験的な[72ページ]RFC1801X.400-MHSルート設定
+ A regular expression, followed by a plus character (+) matches
one or more occurrences of the regular expression. For
example, [a-z]+ matches any string of one or more lower case
letters.
+ 正規表現であり、プラスがあとに続いていて、キャラクタ(+)は正規表現の1回以上の発生に合っています。 例えば、[a-z]+は1つ以上の小文字のどんなストリングにも合っています。
? A regular expression, followed by a question mark (?) matches
zero or one occurrences of the regular expression. For
example, ^[a-z]?[0-9]* matches a string starting with an
optional lower case letter, followed by zero or more digits.
正規表現のマッチが合っているゼロ疑問符(?)か1回の発生によって続かれたA正規表現。 例えば、ゼロか、より多くのケタがあとに続いた任意の小文字から始まって、^[a-z]?[0-9]*はストリングに合っています。
{m}
{m,}
{m,n}
A regular expression, followed by {m}, {m,}, or {m,n} matches
a range of occurrences of the regular expression. The values
of m and n must be non-negative integers less than 256; {m}
matches exactly m occurrences; {m,} matches at least m
occurrences; {m,n} matches any number of occurrences between m
and n inclusive. Whenever a choice exists, the regular
expression matches as many occurrences as possible.
m、m、m、正規表現であって、mによってあとに続くn、m、またはm、nが正規表現のさまざまな発生に合っています。 mとnの値は256未満の非負の整数でなければなりません。 mはまさにm発生に合っています。 mは少なくともm発生に合っています。 m、nは包括的にmとnの間のどんな反復回数にも合っています。 選択が存在しているときはいつも、正規表現はできるだけ多くの発生に合っています。
| Alternation: two regular expressions separated by `|' or
NEWLINE match either a match for the first or a match for the
second.
| 交互: '2つの正規表現が‘で分離しました。|'または、NEWLINEは1番目のためのマッチか2番目のためのマッチのどちらかに合っています'。
(...)
A regular expression enclosed between the character sequences
( and ) matches whatever the unadorned RE matches.
(...) 正規表現がキャラクタシーケンスの間に同封した、(そして)、簡素なREが合っているものなら何でも合わせます。
The order of precedence of operators at the same parenthesis level
is `[ ]' (character classes), then `*' `+' `?' '{m,n}' (closures),
then concatenation, then `|' (alternation) and NEWLINE.
'同じ挿入句レベルにおけるオペレータの先行の注文が'[ ]'(文字クラス)、次に、'+''*''?''m、n'(閉鎖)であり、その時が連結であり、その時は‘です。|'(交互)とニューライン'。
Kille Experimental [Page 73]
Kille実験的です。[73ページ]
一覧
スポンサーリンク
