RFC1615 日本語訳
1615 Migrating from X.400(84) to X.400(88). J. Houttuin, J. Craigie. May 1994. (Format: TXT=39693 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Houttuin
Request for Comments: 1615 RARE Secretariat
RARE Technical Report: 9 J. Craigie
Category: Informational Joint Network Team
May 1994
Houttuinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1615年のまれな事務局まれな技術報告書: 9J.クレーギーカテゴリ: 情報の共同ネットワークチーム1994年5月
Migrating from X.400(84) to X.400(88)
X.400(84)からX.400まで移動します。(88)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Scope
範囲
In the context of a European pilot for an X.400(88) messaging service, this document compares such a service to its X.400(84) predecessor. It is aimed at a technical audience with a knowledge of electronic mail in general and X.400 protocols in particular.
X.400(88)メッセージングサービスのためのヨーロッパ人のパイロットの文脈では、このドキュメントはそのようなサービスをX.400(84)前任者と比較します。 それは一般に、電子メールと特にX.400プロトコルに関する知識との技術聴衆を対象にします。
Abstract
要約
This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. It not only describes the technical complications, but also the effect the transition will have on the end users, especially concerning interworking between end users of the 84 and the 88 services.
このドキュメントは、X.400(88)をX.400(84)と比較して、移動でどんな問題を予期できるかを説明します、COSINE MHSプロジェクトによって作成された既存のX.400(84)インフラストラクチャからX.400(88)インフラストラクチャまでの移動を特に考える場合。 それは技術的な複雑さだけではなく、変遷がエンドユーザの上に特に84と88のサービスのエンドユーザの間の織り込むのに関して持っている効果も説明します。
Table of Contents
目次
1. New Functionality 2
2. OSI Supporting Layers 3
3. General Extension Mechanism 5
4. Interworking 5
4.1. Mixed 84/88 Domains 5
4.2. Generation of OR-Name Extensions from X.400(84) 6
4.3. Distribution List Interworking with X.400(84) 8
4.4. P2 Interworking 10
5. Topology for Migration 11
6. Conclusion 12
7. Security Considerations 13
Appendix A - DL-expanded and Redirected Messages in X.400(84) 14
Appendix B - Bibliography 14
Appendix C - MHS Terminology 15
1. 新しい機能性2 2。 層3 3を支えるOSI。 一般拡大メカニズム5 4。 織り込5む4.1。 Mixed84/88ドメイン5 4.2。 X.400(84)6 4.3からのOR-名前拡大の世代。 X.400(84)8 4.4がある発送先リストの織り込むこと。 P2の織り込10む5。 移動11 6のためのトポロジー。 結論12 7。 セキュリティ問題13付録A--X.400(84)14付録B--図書目録14付録C--MHS用語15のdlで広げられて向け直されたメッセージ
Houttuin & Craigie [Page 1] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[1ページ]RFC1615
Appendix D - Abbreviations 16 Authors' Addresses 17
付録D--略語16作者のアドレス17
1. New Functionality
1. 新しい機能性
Apart from the greater maturity of the standard and the fact that it makes proper use of the Presentation Layer, the principal features of most use to the European R&D world in X.400(88) not contained in X.400(84) are:
規格と事実のPresentation Layerの適切な使用をするよりすばらしい円熟は別として、X.400(84)に含まれなかったX.400(88)のヨーロッパの研究開発世界へのほとんどの使用に関する主な出し物は以下の通りです。
- A powerful mechanism for arbitrarily nested Distribution
Lists including the ability for DL owners to control access
to their lists and to control the destination of nondelivery
reports. The current endemic use of DLs in the research
community makes this a fundamental requirement.
- DL所有者が彼らのリストへのアクセスを制御して、不着損害の目的地を制御する能力を含む任意に入れ子にされたDistribution Listsのための強力なメカニズムは報告します。 研究団体でのDLsの現在の風土病の使用はこれを基本的な要件にします。
- The Message Store (MS) and its associated protocol, P7. The
Message Store provides a server for remote User Agents (UAs)
on Workstations and PCs enabling messages to be held for
their recipient, solving the problems of non-continuous
availability and variability of network addresses of such
UAs. It provides powerful selection mechanisms allowing the
user to select messages from the store to be transferred to
the workstation/PC. This facility is not catered for
adequately by the P3 protocol of X.400(84) and provides a
major incentive for transition.
- Messageストア(MS)と関連プロトコル、P7。 Messageストアは彼らの受取人のために保持されるべきメッセージを可能にするWorkstationsとPCでリモートUserエージェント(UAs)にサーバを提供します、非連続した有用性の問題とそのようなUAsのネットワーク・アドレスの可変性を解決して。 それはユーザが、店からのメッセージがワークステーション/PCに移されるのを選択できる強力な選択メカニズムを提供します。 この施設は、X.400(84)のP3プロトコルによって適切に満たされないで、主要な誘因を変遷に提供します。
- Use of X.500 Directories. Support for use of Directory Names
in MHS will allow a transition from use of O/R Addresses to
Directory Names when X.500 Directories become widespread,
thus removing the need for users to know about MHS
topological addressing components.
- X.500ディレクトリの使用。 X.500ディレクトリが広範囲になるとき、MHSにおけるディレクトリNamesの使用のサポートはO/R Addressesの使用からディレクトリNamesまでの変遷を許容するでしょう、その結果、ユーザがMHSの位相的なアドレシングの部品に関して知る必要性を取り除きます。
- The provision of message Security services including
authentication, confidentiality, integrity and non-
repudiation as well as secure access between MHS components
may be important for a section of the research community.
- 研究団体のセクションに、MHSの部品の間の認証、秘密性、保全、および非拒否であって安全なアクセスを含むメッセージSecurityサービスの支給は重要であるかもしれません。
- Redirection of messages, both by the recipient if
temporarily unable to receive them, and by the originator in
the event of failure to deliver to the intended recipient.
- ともに一時それらを受けることができない、および創始者による意図している受取人に配送しないことの場合、受取人によるメッセージのリダイレクション。
- Use of additional message body encodings such as ISO 8613
ODA (Office Document Architecture) reformattable documents or
proprietary word processor formats.
- ISO8613ODA(オフィスDocument Architecture)などの追加メッセージ本体encodingsの使用はドキュメントか独占ワードプロセッサ形式をreformattableします。
Houttuin & Craigie [Page 2] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[2ページ]RFC1615
- Physical Delivery services that cater for the delivery of an
electronic message on a physical medium (such as paper)
through the normal postal delivery services to a recipient
who (presumably) does not use electronic mail.
- (おそらく、)する受取人に対する通常の郵便物の配達サービスで物理的な媒体(紙などの)における電子メッセージの配送を満たす物理的なDeliveryサービスが電子メールを使用しません。
- The use of different body parts. In addition to the
extensible externally defined body parts, the most common
types are predefined in the standard. In order to give end-
users a real advantage as compared to other technologies, the
following body-parts should be supported as a minimum:
- 異なった身体の部分の使用。 外部的に定義された広げることができる身体の部分に加えて、最も一般的なタイプは規格に事前に定義されます。 他の技術と比べて、本当の利点を終わりのユーザに与えるために、以下の身体部分は最小限として支持されるべきです:
- IA5
- Message
- G3FAX
- External
- General Text
- Others
- IA5--メッセージ--G3FAX--外部(一般テキスト)の他のもの
The last bullet should be interpreted as follows: all UAs
should be configurable to use any type of externally defined
body part, but as a minimum General Text can be generated and
read.
最後の弾丸は以下の通り解釈されるべきです: すべてのUAsが外部的に定義された身体の部分にもかかわらず、最小の司令官のTextが発生できるようにどんなタイプも使用して、読めるのにおいて構成可能であるべきです。
- The use of extended character sets, both in O/R addresses
and in the General Text extended bodypart. As a minimum, the
character sets as described in the European profiles will be
supported. A management domain may choose as an internal
matter which character sets it wants to support in
generating, but all user agents must be able to copy (in
local address books and in replies) any O/R address, even if
it contains character sets it cannot interpret itself.
- 拡張文字集合の使用であり、O/Rアドレスと司令官のTextの両方がbodypartを広げました。 最小限として、ヨーロッパのプロフィールで説明される文字の組はサポートされるでしょう。 管理ドメインは、国内事情としてそれが発生でどの文字の組をサポートしたがっているかを選ぶかもしれませんが、すべてのユーザエージェントがどんなO/Rアドレスもコピーできなければなりません(ローカルアドレスの本と回答で)、解釈できない文字の組を含んでも。
2. OSI Supporting Layers
2. 層を支えるOSI
The development of OSI Upper Layer Architecture since 1984 allows the new MHS standards to sit on the complete OSI stack, unlike X.400(84). A new definition of the Reliable Transfer Service (RTS), ISO 9066, has a mode of operation, Normal-mode, which uses ACSE and the OSI Presentation Layer. It also defines another mode compatible with X.410(84) RTS that was intended only for interworking with X.400(84) systems.
1984年以来のOSI Upper Layer Architectureの開発は完全なOSIスタックの上に座るために新しいMHS規格を許容します、X.400(84)と異なって。 Reliable Transfer Service(RTS)の新しい定義(ISO9066)には、運転モード、ACSEとOSI Presentation Layerを使用するNormal-モードがあります。 また、それはX.400(84)と共にシステムを織り込むためだけに意図したX.410(84) RTSとのコンパチブル別のモードを定義します。
However, there are differences between the conformance requirements of ISO MOTIS and CCITT X.400(88) for mandatory support for the complete OSI stack. ISO specify use of Normal-mode RTS as a mandatory requirement with X.410-mode RTS as an additional option, whereas CCITT require X.410-mode and have Normal-mode optional. The ISO standard identifies three MTA types to provide options in RTS modes:
しかしながら、完全なOSIスタックの義務的なサポートのためのISO MOTISとCCITT X.400(88)の順応要件の間には、違いがあります。 ISOは追加オプションとしてのX.410-モードRTSと共に義務的な要件としてNormal-モードRTSの使用を指定します、CCITTが、X.410-モードを必要として、Normal-モードを任意にしますが。 ISO規格はRTSモードにオプションを提供するために3つのMTAタイプを特定します:
Houttuin & Craigie [Page 3] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[3ページ]RFC1615
- MTA Type A supports only Normal-mode RTS, and provides
interworking within a PRMD and with other PRMDs (conforming
to ISO 10021), and with ADMDs which have complete
implementations of X.400(88) or which conform to ISO 10021.
- MTA Type AはNormal-モードRTSだけを支持して、PRMD以内と他のPRMDs(ISO10021に従う)と、X.400(88)の完全な実現を持っているか、またはISO10021に従うADMDsとの織り込むことを提供します。
- MTA Type B adds to the functionality of MTA type A the
ability to interwork with ADMDs implementing only the minimal
requirements of X.400(88), by requiring support for X.410-
mode RTS in addition to Normal-mode.
- MTA Type BはADMDsがX.400(88)の最小量の要件だけを実行している状態で織り込む能力をMTAタイプAの機能性に追加します、X.410モードRTSにNormal-モードに加えて支持を要することによって。
- MTA Type C adds to the functionality of MTA type B the
ability to interwork with external X.400(84) Management
Domains (MDs, i.e., PRMDs and ADMDs), by requiring support for
downgrading (see 5.1) to the X.400(84) P1 protocol.
- MTA Type Cは外部のX.400(84)と共に管理Domainsが(MDs、すなわち、PRMDs、およびADMDs)であると織り込む能力をMTAタイプBの機能性に追加します、格下げにX.400(84) P1プロトコルに支持を要することによって(5.1を見ます)。
The interworking between ISO and CCITT conformant systems is summarised in the following table:
以下のテーブルでISOとCCITT conformantシステムの間の織り込むことについて略言します:
CCITT
CCITT
X.400(84) X.400(88)
minimal complete
implementation
X.400(84) X.400(88)の最小量の完全な実現
ISO 10021/ MTA Type A N N Y
MOTIS MTA Type B N Y Y
MTA Type C Y Y Y
ISO10021/ MTAはN N Y MOTIS MTAタイプB N Y Y MTAタイプC Y Y Yをタイプします。
Table 1: Interworking ISO <-> CCITT systems
テーブル1: ISO<->CCITTがシステムであると織り込みます。
The RTS conformance difference would totally prevent interworking between the two versions of the standard if implementations never contained more than the minimum requirements for conformance, but in practice many 88 implementations will be extensions of 84 systems, and will thus support both modes of RTS. (At the moment we are aware of only one product that doesn't support Normal mode.)
実現が順応のための必要最小限以上を決して含んでいないならRTS順応差が、規格の2つのバージョンの間で織り込むのを完全に防ぎますが、習慣多くの88では、実現は、84台のシステムの拡大であり、その結果、RTSの両方のモードを支持するでしょう。 (現在、私たちはNormalモードを支持しない1個の製品だけを意識しています。)
Both ISO and CCITT standards require P7 (and P3) to be supported directly over the Remote Operations Service (ROS), ISO 9072, and use Normal-mode presentation (and not X.410-mode). Both allow optionally ROS over RTS (in case the Transport Service doesn't provide an adequately reliable service), again using Normal-mode and not X.410- mode.
ISOとCCITT規格の両方が、P7(そして、P3)がRemote Operations Service(ROS)、ISO9072の直接上で支えられて、Normal-モードプレゼンテーション(そして、X.410-モードでない)を使用するのを必要とします。 両方がRTSの上に任意にROSを許容します(Transport Serviceが適切に信頼できるサービスを提供しないといけないので)、再びX.410モードではなく、Normal-モードを使用して。
CCITT made both Normal and X.410 mode mandatory in its X.400(92) version, and it is expected that the 94 version will have the X.410 mode as an option only.
CCITTはNormalとX.410の両方をX.400(92)バージョンで義務的なモードにしました、そして、94バージョンにはオプションだけとしてX.410モードがあると予想されます。
Houttuin & Craigie [Page 4] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[4ページ]RFC1615
3. General Extension Mechanism
3. 一般拡大メカニズム
One of the major assets in ISO 10021/X.400(88) is the extension mechanism. This is used to carry most of the extensions defined in these standards, but its principal benefit will be in reducing the trauma of transitions to future versions of the standards. Provided that implementations of the 88 standards do not try to place restrictions on the values that may be present, any future extension will be relayed by these implementations when appropriate (i.e., when the extension is not critical), thus providing a painless migration to new versions of the standards.
ISO10021/X.400(88)の主要な資産の1つは拡大メカニズムです。 これはこれらの規格で定義された拡大の大部分を運ぶのに使用されますが、規格の将来のバージョンへの変遷のトラウマを減少させるのにおいて主要な利益があるでしょう。 適切であるときに(すなわち、拡大はいつ批判的ではありませんか)、88の規格の実現が存在するかもしれない値に関して制限を課そうとしないと、どんな今後の拡大もこれらの実現でリレーされるでしょう、その結果、規格の新しいバージョンに無痛の移動を提供します。
4. Interworking
4. 織り込むこと
4.1. Mixed 84/88 Domains
4.1. 84/88の複雑なドメイン
ISO 10021-6/X.419(88) defines rules for interworking with X.400(84), called downgrading. As X.400 specifies the interconnection of MDs, these rules define the actions necessary by an X.400(88) MD to communicate with an X.400(84) MD. The interworking rules thus apply at domain boundaries. Although it would not be difficult to extend these to rules to convert Internal Trace formats which might be thought a sufficient addition to allow mixed X.400(84)/X.400(88) domains, the problems involved in attempting to define mixed 84/88 domains are not quite that simple.
ISO10021-6/X.419(88)は格下げと呼ばれるX.400(84)との織り込む規則を定義します。 これらの規則は、X.400(84) MDとコミュニケートするためにX.400がMDsのインタコネクトを指定するとX.400(88) MDで必要な動作を定義します。 その結果、織り込む規則はドメイン境界で適用されます。 複雑なX.400(84)/X.400(88)ドメインを許容できるくらいの添加であると考えられるかもしれないInternal Trace形式を変換するためにこれらを規則に広げるのが難しくないでしょうが、84/88の複雑なドメインを定義するのを試みるのにかかわる問題はそんなに簡単ではありません。
The principle problem is in precisely defining the standard that would be used between MTAs within an X.400(84) domain, as X.400(84) only defines the interconnection of MDs. In practice, MTA implementations either use X.400(84) unmodified, or X.400(84) with the addition of Internal Trace from the first MOTIS DIS (DIS 8883), or support MOTIS as defined in DIS 8505, DIS 8883, and DIS 9065. The second option is recommended in the NBS Implementors Agreements, and the third option is in conformance with the CEN/CENELEC MHS Functional Standard [1], which requires as a minimum tolerance of all "original MOTIS" protocol extensions. An 84 MD must decide which of these options it will adopt, and then require all its MTAs to adopt (or at least be compatible with) this choice. No doubt this is one of the reasons for the almost total absence currently of mixed- vendor X.400(84) MDs in the European R&D MHS community. The fact that none of these three options for communication between MTAs within a domain have any status within the standardisation bodies accounts for the absence from ISO 10021/X.400(88) of detailed rules for interworking within mixed 84/88 domains.
X.400(84)ドメインの中に正確にMTAsの間で使用される規格を定義するのにおいて原則問題があります、X.400(84)がMDsのインタコネクトを定義するだけであるとき。 実際には、MTA実現が変更されていなくX.400(84)を使用する、DIS8505、DIS8883、およびDIS9065で定義される最初のMOTIS DIS(DIS8883)、またはサポートMOTISからのInternal Traceの添加があるX.400(84) 2番目のオプションはNBS Implementors Agreementsでお勧めです、そして、3番目のオプションは順応CEN/CENELEC MHS Functional Standard[1]がある中です。([1]はすべての「オリジナルのMOTIS」プロトコルの最小の寛容として拡大を必要とします)。 または、すべてのMTAsが採用する、それがこれらのオプションのどれを採用するだろうか、そして、その時が、必要であるMDがそうしなければならない84が、決める(少なくとも互換性がある、)、この選択。 間違いなく、これはヨーロッパのR&D MHS共同体の現在混ぜられた業者X.400(84) MDsのほとんど総不在の理由の1つです。 ドメインの中のMTAsのコミュニケーションのためのこれらの3つのオプションのいずれも規格化本体の中に少しの状態も持っていないという事実は84/88の中に複雑なドメインを織り込むための細則のISO10021/X.400(88)の不在を説明します。
Use of the first option, unmodified X.400(84), carries the danger of undetectable routing loops occurring. Although these can only occur if MTAs have inconsistent routing tables, the absence of standardised
第1の選択の使用(変更されていないX.400(84))は検知されないルーティング輪の発生の危険を運びます。 MTAsに矛盾した経路指定テーブル、標準化されることの不在がある場合にだけ、これらは起こることができますが
Houttuin & Craigie [Page 5] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[5ページ]RFC1615
methods of disseminating routing information makes this a possibility which if it occurred might cause severe disruption before being detected. The only addition to the interworking rules needed for this case is the deletion of Internal Trace when downgrading a message.
ルーティング情報を広める方法はこれを起こるなら検出される前に厳しい分裂を引き起こす可能性にします。 メッセージを格下げするとき、規則が必要とした織り込むことへの唯一の添加はこのような場合Internal Traceの削除です。
Use of the second option, X.400(84) plus Internal Trace, allows the detection and prevention of routing loops. Details of the mapping between original-MOTIS Internal Trace and the Internal Trace of ISO 10021 can be found in Annex A. This should be applied not only when downgrading from 88 to 84, but also in reverse when an 84 MPDU is received by the 84/88 Interworking MTA. If the 84 domain properly implements routing loop detection algorithms, then this will allow completely consistent reception of messages by an 84 recipient even after DL expansion or Redirection within that domain (but see also section 5.3). Unfortunately, the first DIS MOTIS like X.400(84) left far too much to inference, so not all implementors may have understood that routing loop detection algorithms must only consider that part of the trace after the last redirection flag in the trace sequence.
2番目のオプションの使用(X.400(84)とInternal Trace)は、ルーティング輪の検出と防止を許します。 88〜84を格下げしないときだけ、Annex A.Thisで適用されるべきですが、オリジナルのMOTIS Internal TraceとISO10021のInternal Traceの間のマッピングの詳細を見つけることができる84MPDUが84/88Interworking MTAによって受け取られたらまた逆でもあり適用されるべきであってください。 84ドメインが適切にルーティング輪の検出アルゴリズムを実行すると、これはそのドメインの中のDL拡大かRedirectionの後にさえ84受取人でメッセージの完全に一貫したレセプションを許容するでしょう(また、セクション5.3を見てください)。 残念ながら遠くに推論まで残り過ぎているX.400(84)のように最初のDIS MOTISであり、したがって、すべての作成者が、ルーティング輪の検出アルゴリズムが跡の系列における最後のリダイレクション旗の後に跡のその地域を考えるだけでよいのを理解するかもしれないというわけではありませんでした。
Use of the third option, tolerance of all original-MOTIS extensions, would in principle allow a still higher level of interworking between the 84 and 88 systems. However, no implementations are known which do more than relay the syntax of original-MOTIS extensions: there is no capability to generate these protocol elements or ability to correctly interpret their semantics.
3番目のオプションの使用(すべてのオリジナルのMOTIS拡張子の寛容)は原則としてシステムを84と88の間織り込むなお高いレベルを許容するでしょう。しかしながら、実現は全く知られていません(リレーよりオリジナルのMOTIS拡張子の構文をします): これらのプロトコル要素か正しくそれらの意味論を解釈する能力を発生させる能力が全くありません。
The choice between the first two options for mixed domains can be left to individual management domains. It has no impact on other domains provided the topology recommended in section 5 is adopted.
複雑なドメインへの最初の2つのオプションの選択を個々の管理ドメインに発つことができます。 セクション5のお勧めのトポロジーが採用されるなら、それは他のドメインに変化も与えません。
4.2. Generation of OR-Name Extensions from X.400(84)
4.2. X.400からのOR-名前拡大の世代(84)
The interworking rules defined in DIS 10021-6/X.419 Annex B allow for delivery of 88 messages to 84 recipients, but do not make any 88 extensions available to 84 originators. In general this is an adequate strategy. Most 88 extensions provide optional services or have sensible defaults. The exception to this is the OR-Name extensions. These fall into three categories: the new CommonName attribute; fifteen new attributes for addressing physical delivery recipients; and alternative Teletex (T.61) encodings for all attributes that were defined as Printable Strings. Without some mechanism to generate these attributes, 84 originators are unable to address 88 recipients with OR-Addresses containing these attributes. Such a mechanism is defined in RARE Technical Report 3 ([2]), "X.400 1988 to 1984 downgrading".
DIS10021-6/X.419 Annex Bで定義された織り込む規則で、84人の受取人にとって88のメッセージの配送を考慮しますが、少しの88の拡大も利用可能に84人の創始者までなりません。 一般に、これは適切な戦略です。 ほとんどの88の拡大には、任意のサービスを提供するか、または実際的なデフォルト値があります。 これへの例外はOR-名前拡大です。 これらは3つのカテゴリになります: 新しいCommonName属性。 物理的な配送受取人に演説するための15の新しい属性。 そして、Printable Stringsと定義されたすべての属性のための代替のTeletex(T.61)encodings。 これらの属性を発生させる何らかのメカニズムがなければ、これらの属性を含んで、84人の創始者はOR-アドレスで88人の受取人に演説できません。 そのようなメカニズムはRARE Technical Report3([2])、「X.400 1988年から1984格下げ」で定義されます。
Houttuin & Craigie [Page 6] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[6ページ]RFC1615
Common-name appears likely to be a widely used attribute because it remedies a serious deficiency in the X.400(84) OR-Name: it provides an attribute suitable for naming Distribution Lists and roles, and even individuals where the constraints of the 84 personal-name structure are inappropriate or undesirable. As 84 originators will no doubt wish to be able to address 88 DLs (and roles), [2] defines a Domain Defined Attribute (DDA) to enable generation of common-name by 84 originators. This consists of a DDA with its type set to "common- name" and its value containing the Printable String encoding to be set into the 88 common-name attribute.
一般名はX.400(84) OR-名前の重大な欠乏を改善するのによる広く使用された属性であることがありそうに見えます: それは84個人名構造の規制が不適当であるか、または望ましくないところにDistribution Lists、役割、および個人さえ命名するのに適当な属性を提供します。 84として、創始者は間違いなく88DLs(そして、役割)を記述できるようになりたくなって、[2]は、84人の創始者による一般名の世代を可能にするために、Domain Defined Attribute(DDA)を定義します。 これは、88一般名属性に設定されるために「一般的な名前」に用意ができているタイプとその値がPrintable Stringコード化を含んでいるDDAから成ります。
This requires that all European R&D MHS 88 MTAs capable of interworking with 84 systems shall be able to map the value of "common-name" DDA in OR-Names received from 84 systems to the 88 standard attribute extension component common-name, and vice versa.
これは、84台のシステムで織り込むことができるすべてのヨーロッパのR&D MHS88MTAsが84台のシステムから標準の88属性まで受け取られたOR-名前拡大コンポーネント一般名の「一般名」DDAの値を写像できるだろうというのを必要とします、逆もまた同様に。
X.400(84) originators will only be able to make use of this ability to address 88 common-name recipients if their system is capable of generating DDAs. Unfortunately, one of the many serious deficiencies with the CEN/CENELEC and CEPT 84 MHS Functional Standards ([1] and [3]), as originally published, is that this ability is not a requirement for all conformant systems. Thus if existing European R&D MHS X.400(84) users wish to be able to address a significant part of the ISO 10021/X.400(84) world they must explicitly ensure that their 84 systems are capable of generating DDAs. However, this will be a requirement in the revised versions of ENV 41201 and ENV 41202, which are to be published soon. There is no alternative mechanism for providing this functionality to 84 users. It is estimated that currently 95% of all European R&D MHS users are able to generate DDAs.
彼らのシステムがDDAsを発生させることができる場合にだけ、X.400(84)創始者は88人の一般名受取人に演説するこの能力を利用できるでしょう。 残念ながら、CEN/CENELECとCEPT84MHS Functional Standards([1]がある多くの重大な欠乏と元々発行されているとしての[3])の1つはこの能力がすべてのconformantシステムのための要件でないということです。その結果、既存のヨーロッパ人のR&D MHS X.400(84)ユーザがISO10021/X.400(84)世界のかなりの地域を記述できるようになりたがっているなら、彼らは、彼らの84台のシステムがDDAsを発生させることができるのを明らかに確実にしなければなりません。 しかしながら、これはENV41201とENV41202の改訂版でなるでしょう。(ENVは要件、すぐ、発行されることになっています)。 この機能性を84人のユーザに提供するためのどんな代替のメカニズムもありません。 現在のすべてのヨーロッパ人のR&D MHSユーザの95%がDDAsを発生させることができると見積もられています。
When messages are sent to both ISO 10021/X.400(88) and X.400(84) recipients outside the European R&D MHS community, this representation of common-name will not enable the external recipients to communicate directly unless their 84/88 interworking MTA also implements this mapping. However, use of this mapping within the European R&D MHS community has not reduced external connectivity, and provided RTR 3, RFC 1328 is universally implemented within this community it will enhance connectivity within the community.
ヨーロッパのR&D MHS共同体の外のISO10021/X.400(88)とX.400(84)受取人の両方にメッセージを送るとき、また、彼らの84/88織り込むMTAがこのマッピングを実行しないと、一般名のこの表現は、外部の受取人が直接伝達するのを可能にしないでしょう。 しかしながら、ヨーロッパのR&D MHS共同体の中のこのマッピングの使用は外部の接続性を減らしていません、そして、RTR3、RFC1328が一般にそうなら、この共同体の中で実行されて、それは共同体の中で接続性を高めるでしょう。
As for the new Physical Delivery address attributes in X.400(88), RTR 3 (RFC1328) takes the following approach. A DDA with type "X400-88" is used, whose value is an std-or encoding of the address as defined in RARE Technical Report 2 ([4]), "Mapping between X.400(1988)/ISO 10021 and RFC 822". This allows source routing through an appropriate gateway. Where the generated address is longer than 128 characters, up to three overflow DDAs are used: X400-C1; X400-C2; X400-C3. This solution is general, and does not require co-operation, i.e., it can
X.400(88)の新しいPhysical Deliveryアドレス属性に関して、RTR3(RFC1328)は以下のアプローチを取ります。 または、タイプがあるDDA、「X400-88インチがそう、使用されていて、だれの値があるか、std、-、アドレスは2([4])、「X.400(1988)/ISO10021とRFC822インチの間のマッピング」というまれな技術報告書で定義されるようにコード化されます。 これは適切なゲートウェイにソースルーティングの通ることを許します。 生成アドレスが128のキャラクタより長いところでは、最大3オーバーフローDDAsが使用されています: X400-C1。 X400-C2。 X400-C3。 この解決策は、一般的であり、協力を必要としないで、すなわち、それはそうすることができます。
Houttuin & Craigie [Page 7] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[7ページ]RFC1615
be implemented in the gateways only.
ゲートウェイだけで実行されてください。
Note that the two DDA solutions mentioned above have the undesirable property that the P2 heading will still contain the DDA form, unless content upgrading is also done. In order to shield the user from cryptic DDAs, such content upgrading is in general recommended, also for nested forwarded messages, even though the available standards and profiles do not dictate this.
前記のように2つのDDA解決策にはそれでもP2が向かう場合DDAフォームを含む望ましくない特性があることに注意してください、また、して、満足しているアップグレードがそうでないなら。 不可解なDDAsからユーザを保護するために、一般に、そのような満足しているアップグレードは推薦されます、入れ子にされた転送されたメッセージのためにも、利用可能な規格とプロフィールはこれを決めませんが。
4.3. Distribution List Interworking with X.400(84)
4.3. X.400との発送先リストの織り込むこと(84)
Before all X.400(84) systems are upgraded to ISO 10021, the interaction of Distribution Lists with X.400(84) merits special attention as DLs are already widely used.
すべてのX.400(84)システムがISO10021にアップグレードする前に、DLsが既に広く使用されるとき、X.400(84)とのDistribution Listsの相互作用は特別な注意に値します。
Nothing, apart perhaps from the inability to generate the DL's OR- Address if the DL uses the common-name attribute, prevents an X.400(84) originator from submitting a message to a DL.
何も、X.400(84)創始者がDLにメッセージを提出するのを恐らくDLが一般名属性を使用するならDL ORのアドレスを作ることができないことから離れて防ぎません。
X.400(84) users can also be members (i.e., recipients) of a DL. However, if the X.400(84) systems involved correctly implement routing loop detection, the X.400(84) recipient may not receive all messages sent to the DL. X.400(84) routing loop detection involves a recipient MD in scanning previous entries in a message's trace sequence for an occurrence of its own domain, and if such an entry is found the message is non-delivered. The new standards extend the trace information to contain flags to indicate DL-expansion and redirection, and re-define the routing loop detection algorithm to only examine trace elements from the last occurrence of either of these flags. Thus 88 systems allow a message to re-traverse an MD (or be relayed again by an MTA) after either DL-expansion or redirection. However, these flags cannot be included in X.400(84) trace, so are deleted on downgrading. Therefore the 84 DL recipient will receive all messages sent to the DL except those which had a common point in the path to the DL expansion point with the path from the expansion points to his UA. This common point is an MD in the case of a DL in another MD or an MTA in the case of a DL in the same MD. Although this is quite deterministic behaviour, the user is unlikely to understand it and instead regard it as erratic or inconsistent behaviour.
また、X.400(84)ユーザはDLのメンバー(すなわち、受取人)であるかもしれない。 しかしながら、正しくかかわるX.400(84)システムがルーティング輪の検出を実行するなら、X.400(84)受取人はDLに送られたすべてのメッセージを受け取らないかもしれません。 X.400(84)ルーティング輪の検出はそれ自身のドメインの発生のためにメッセージの跡の系列で前のエントリーをスキャンするのに受取人MDにかかわります、そして、そのようなエントリーが見つけられるなら、メッセージは非渡されます。 新しい規格は、これらの旗のどちらかの最後の発生からDL-拡大とリダイレクションを示して、微量元素を調べるだけであるためにルーティング輪の検出アルゴリズムを再定義する旗を含むようにトレース情報を広げています。 したがって、88台のシステムがDL-拡大かリダイレクションのどちらかの後にMDを再横断する(MTAによってもう一度リレーされてください)メッセージを許容します。 しかしながら、これらの旗は、X.400(84)跡に含むことができないので、格下げのときに削除されます。 したがって、経路と共に経路にDL拡大ポイントに一般的なポイントを拡大ポイントから彼のUAまで持っていたものを除いて、84DL受取人はDLに送られたすべてのメッセージを受け取るでしょう。 この一般的なポイントは、別のMDのDLの場合におけるMDか同じMDのDLの場合でMTAです。 これはかなり決定論的なふるまいですが、それを理解して、代わりにそれを不安定であるか無節操なふるまいと見なすとはユーザはありそうもないです。
Another problem with X.400(84) DL members will be that delivery and non-delivery reports will be sent back directly to the originator of a message, rather than routed through the hierarchy of DL expansion points where they could have been routed to the DL administrator instead of (or as well as) the originator.
X.400(84) DLメンバーに関する別の問題は配送と非配送レポートがそれらが創始者の(or as well as)の代わりにDL管理者に発送されたかもしれないDL拡大ポイントの階層構造を通して掘るよりむしろ直接メッセージの創始者に返送されるということでしょう。
Houttuin & Craigie [Page 8] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[8ページ]RFC1615
No general solution to this problem has yet been devised, despite much thought from a number of experts. The nub of the problem is that changing the downgrading rules to enable 84 recipients to receive all such messages also allows the possibility of undetectable infinite DL or redirection looping where there is an 84 transit domain.
多くの考えにもかかわらず、この問題の一般解は全く多くの専門家からまだ工夫されていません。 84人の受取人がそのようなすべてのメッセージを受け取るのを可能にするために格下げ規則を変えて、また84トランジットドメインがあるところに検知されない無限のDLかリダイレクションループの可能性を許容する問題のこぶがあります。
A potential solution is to extend the DL expansion procedures to explicitly identify X.400(84) recipients and to treat them specially, at least by deleting all trace prior to the expansion point. This solution is only dangerous if another DL reached through an 84 transit domain is inadvertently configured as an 84 recipient, when infinite looping could occur. It does however impose the problems of 84 interworking into MHS components which need to know nothing even of the existence of X.400(84). It also requires changes to the Directory attribute mhs-dl-members to accommodate the indication that identifies the recipient as an X.400(84) user, unless European R&D MHS DLs are restricted to being implemented by local tables rather than making use of the Directory.
潜在的解決策は明らかにX.400(84)受取人を特定して、特に、彼らを扱うためにDL拡大手順を広げることです、少なくとも拡大ポイントの前ですべての跡を削除することによって。 84トランジットドメインを通して達した別のDLが84受取人としてうっかり構成される場合にだけ、この解決策は危険です、無限のループが起こることができたなら。 しかしながら、それは84がX.400(84)の存在さえについて何も知らない必要があるコンポーネントをMHSに織り込むという問題を課します。 また、受取人がX.400(84)ユーザであると認識する指示を収容するのがディレクトリ属性mhs dlメンバーへの変化を必要とします、むしろヨーロッパの研究開発MHS DLsがディレクトリを利用するより地方のテーブルによって実行されるのに制限されない場合。
A similar change would be required for Redirection. However, the change for Redirection would have substantially more impact as it would require European R&D MHS-specific MHS protocol extensions to identify the redirected recipient as an X.400(84) user. If the European R&D MHS adopts a reasonable quality of MHS(88) service, all its MTAs would be capable of Redirection and all UAs would be capable of requesting originator-specified-alternate-recipient and thus be required to incorporate these non-standard additions. A special European R&D MHS modification affecting all MTAs and UAs seems impractical, too!
同様の変化がRedirectionに必要でしょう。 しかしながら、Redirectionのための変化には、向け直された受取人がX.400(84)ユーザであると認識するのがヨーロッパのR&D MHS特有のMHSプロトコル拡張子を必要とするように実質的により多くの影響力があるでしょう。 ヨーロッパのR&D MHSが妥当なMHS(88)サービスの品質を採用するなら、すべてのMTAsはRedirectionができて、すべてのUAsが、創始者の指定された交互の受取人を要求できて、その結果、これらの標準的でない追加を取り入れるのに必要でしょう。 また、すべてのMTAsとUAsに影響する特別なヨーロッパのR&D MHS変更は非実用的に見えます!
If the recommended European R&D MHS topology for MHS migration (See chapter 5) is adopted there will never be an X.400(84) transit domain (or MTA) between two ISO 10021 systems. This allows the deletion of trace prior to the last DL expansion or redirection to be performed as part of the downgrading, giving the X.400(84) user a consistent service. This solution has the advantage of only requiring changes at the convertors between X.400(84) and ISO 10021/X.400(88), where other European R&D MHS specific extensions have also been identified. A precise specification of this solution is given in Annex A.
MHS移動(第5章を見る)のためのお勧めのヨーロッパのR&D MHSトポロジーが採用されると、2台のISO10021システムの間には、X.400(84)トランジットドメイン(または、MTA)が決してないでしょう。これは最後の格下げの一部として実行されるべきDL拡大かリダイレクションの前で跡の削除を許します、一貫したサービスをX.400(84)ユーザに与えて。 この解決策はX.400(84)とISO10021/X.400(88)の間に変換器で変化を必要とするだけの利点を持っています。また、他のヨーロッパのR&D MHS特定の拡張子はそこで特定されました。 Annex Aでこの解決策の正確な仕様を与えます。
Finally, problems might occur because some X.400(84) MTAs could object to messages containing more than one recipient with the same extension-id (called originally-requested-recipient-number in the new standards), since this was not defined in X.400(84). Note that X.400(84) only requires that all extension-id's be different at submission time, so 84 software that does not except messages with identical extension-id's for relaying or delivery must be considered broken.
最終的に、いくつかのX.400(84) MTAsが同じ拡大イド(新しい規格における元々要求された受取人番号と呼ばれる)で1人以上の受取人を含むメッセージに反対するかもしれないので、問題は起こるかもしれません、これがX.400(84)で定義されなかったので。 壊れているとリレーか配送のための同じイドの拡大ものがあるメッセージ以外に、そうしない84ソフトウェアを考えなければならないためにX.400(84)が、イドのすべての拡大ものが服従時に異なっているのを必要とするだけであることに注意してください。
Houttuin & Craigie [Page 9] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[9ページ]RFC1615
4.4. P2 Interworking
4.4. P2の織り込むこと
RTR 3, RFC 1328 also defines the downgrading rules for P2 (IPM) interworking: The IPM service in X.400(1984) is usually provided by content type 2. In many cases, it will be useful for a gateway to downgrade P2 from content type 22 to 2. This will clearly need to be made dependent on the destination, as it is quite possible to carry content type 22 over P1(1984). The decision to make this downgrade will be on the basis of gateway configuration.
RTR3、また、RFC1328はP2(IPM)の織り込む格下げ規則を定義します: 通常、X.400(1984)でのIPMサービスは満足しているタイプ2によって提供されます。 多くの場合、満足しているタイプからP2を22〜2に格下げするのはゲートウェイの役に立ちます。 これは、明確に目的地で依存しているのに作られている必要があるでしょう、P1(1984)の上まで満足しているタイプ22を運ぶのがかなり可能であるときに。 このダウングレードを作るという決定がゲートウェイ構成のベースにあるでしょう。
When a gateway downgrades from 22 to 2, the following should be done:
22〜2までのゲートウェイダウングレードであるときに、以下をするべきです:
1. Strip any 1988 specific headings (language indication, and
partial message indication).
1. あらゆる1988の特定の見出し(言語指示、および部分的なメッセージ指示)を剥取ってください。
2. Downgrade all O/R addresses, as described in Section 3.
2. セクション3で説明されるようにすべてのO/Rアドレスを格下げしてください。
3. If a directory name is present, there is no method to
preserve the semantics within a 1984 O/R Address. However, it
is possible to pass the information across, so that the
information in the Distinguished Name can be informally
displayed to the end user. This is done by appending a text
representation of the Distinguished Name to the Free Form
Name enclosed in round brackets. It is recommended that the
"User Friendly Name" syntax is used to represent the
Distinguished Name [5]. For example:
3. ディレクトリ名が存在しているなら、1984O/R Addressの中に意味論を保存する方法が全くありません。 しかしながら、横切って情報を通過するのは可能です、Distinguished Nameの情報をエンドユーザに非公式に表示できるように。 Distinguished Nameのテキスト表現を丸括弧で同封されたFree Form Nameに追加することによって、これをします。 構文という「ユーザフレンドリーな名前」がDistinguished Name[5]を表すのに使用されるのは、お勧めです。 例えば:
(Steve Hardcastle-Kille, Computer Science,
University College London, GB)
(スティーブHardcastle-Kille、コンピュータサイエンス、ユニバーシティ・カレッジロンドン、GB)
4. The issue of body part downgrade is discussed in Section 6.
4. セクション6でボディー部分ダウングレードの問題について議論します。
Note that a message represented as content type 22 may have originated from [6]. The downgrade for this type of message can be improved. This is discussed in RTR 2, RFC 1327.
満足しているタイプ22として表されたメッセージが[6]から発したかもしれないことに注意してください。 このタイプに関するメッセージのためのダウングレードを改良できます。 RTR2、RFC1327でこれについて議論します。
Note that the newer EWOS/ETSI recommendations specify further rules for downgrading, which are not all completely compatible with the rules in RTR 3, RFC 1328. This paper does not state which set of rules is preferred for the European R&D MHS, it only states that a choice will have to be made.
より新しいEWOS/ETSI推薦が格下げのためのさらなる規則を指定することに注意してください。(規則はRTR3(RFC1328)の規則とすべて完全に互換性があるというわけではありません)。 この論文は、どのセットの規則がヨーロッパのR&D MHSのために好まれるかを述べないで、それは、選択をしなければならないと述べるだけです。
As the transition topology recommended for the European R&D MHS is to never use 84 transit systems between 88 systems, it is possible to improve on the P2 originator downgrading and resending scenario. The absence of 84 transit systems means that the necessity for a P1 downgrade implies that the recipient is on an 84 system, and thus that it is better to downgrade 88 P2 contents to 84 P2 rather than to
ヨーロッパのR&D MHSのために推薦された変遷トポロジーが88台のシステムの間の84個の輸送システムを決して使用することになっていないとき、シナリオを格下げして、再送するP2創始者を改良するのは可能です。 84個の輸送システムの欠如は、受取人が84システムの上にいて、その結果、P1ダウングレードの必要性がむしろ88のP2内容を84P2に格下げしているほうがよいつもりであることを意味します。
Houttuin & Craigie [Page 10] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[10ページ]RFC1615
relay it in the knowledge that it will not be delivered.
それが届けられないという知識でそれをリレーしてください。
5. Topology for Migration
5. 移動のためのトポロジー
Having decided that a transition from X.400(84) is appropriate, it is necessary to consider the degree of planning and co- ordination required to preserve interworking during the transition.
X.400(84)からの変遷が適切であると決めたので、計画の度を考えるのが必要であり、共同叙階式が変遷の間の織り込むことを保存するのが必要です。
It is assumed as a fundamental tenet that interworking must be preserved during the transition. This requires that one or more system in the European R&D MHS community must act as a protocol converter by implementing the rules for "Interworking with 1984 Systems" listed in Annex B of ISO 10021-6/X.419.
基本的な主義として、変遷の間織り込むことを保存しなければならないと思われます。 これは、「1984で、システムを織り込みます」のための規則を実行するのによるプロトコルコンバータがISO10021-6/X.419のAnnex Bに記載したようにヨーロッパのR&D MHS共同体の1台以上のシステムが作動しなければならないのを必要とします。
When downgrading from ISO 10021/X.400(88) to X.400(84) all extensions giving functionality beyond X.400(84) are discarded, or if a critical extension is present then downgrading fails and a non-delivery results. Thus, although it is possible to construct topologies of interconnected MTAs so that two 88 MTAs can only communicate by relaying through one or more 84 MTA, to maximise the quality of service which can be provided in the European R&D MHS community it is proposed that it require that no two European R&D MHS 88 MTAs shall need to communicate by relaying through a X.400(84) MTA. Furthermore, if this is extended to require that no two European R&D MHS 88 MTAs shall ever communicate by relaying through an X.400(84) MTA, then the European R&D MHS can provide enhanced interworking functionality to its X.400(84) users.
いつ、ISO10021/X.400(88)からX.400(84)までX.400(84)を超えて機能性を与えるすべての拡大を格下げするのが捨てられるか、または批判的な拡大が存在しているなら格下げが失敗するか、そして、非配送は結果として生じます。 したがって、2 88MTAsが、ヨーロッパのR&D MHS共同体にどれを提供できるかをサービスの質を最大にするために1以上を通して84MTAをリレーすることによって伝えることができるだけであるくらいインタコネクトされたMTAsのtopologiesを組み立てるのが可能ですが、2ヨーロッパのR&D MHS88MTAsが、X.400(84) MTAを通してリレーすることによって交信する必要でないだろうというのが必要であるよう提案されます。 その上、これが88MTAsがかつてそうするものとする2ヨーロッパのR&D MHSがX.400(84) MTAを通してリレーすることによって交信しないのが必要であるように広げられるなら、ヨーロッパのR&D MHSは、X.400(84)ユーザに機能性を織り込みながら、高められた状態で提供できます。
If mixed vintage 88 and 84 Management Domains (MDs) are created, the routing loop detection rules, which specify that a message shall not re-enter an MD it has previously traversed, require that downgrading is performed within that mixed vintage MD. That MD therefore requires at least one MTA capable of downgrading from 88 to 84. It is unlikely that every MTA within an MD will be configured to act as an entry- point to that MD from other MDs. However, the proposed European R&D MHS migration topology requires that as soon as a domain has an 88 MTA it shall also have an 88 entry point - this may, of course, be that same MTA.
混ぜられたヴィンテージの88と84Management Domains(MDs)が作成されるなら、ルーティングは検出規則を輪にします。(規則は、メッセージがMDに再入しないだろうと指定します)。それは、横断されて、以前に、必要であり、格下げがその混ぜられたヴィンテージのMDの中で実行されるのを必要とします。 したがって、そのMDは88〜84を格下げできる少なくとも1MTAを必要とします。 MDの中のあらゆるMTAがエントリーポイントとして他のMDsからそのMDに機能するように構成されるのは、ありそうもないです。 しかしながら、提案されたヨーロッパのR&D MHS移動トポロジーは、また、ドメインに88MTAがあるとすぐに、それには88エントリー・ポイントがあるだろうというのを必要とします--これはもちろんその同じMTAであるかもしれません。
Even for MDs operating all the same MHS vintage internally, providing entry-points for both MHS vintages will give considerable advantage in maximising the connectivity to other MDs. Initially, it will be particularly important for 88 MDs to be able to communicate with 84 only MDs, but as 88 becomes more widespread eventually the 84 MDs will become a minority for which the ability to support 88 will be important to maintain connectivity. For most practical MDs providing entry-points that implement options in the supporting layers will also be important. Support for at least the following is recommended
内部的にちょうど同じMHSヴィンテージを操作するMDsに関してはさえ、両方のMHSヴィンテージのための提供エントリー・ポイントは他のMDsに接続性を最大にする際に相当の便宜を与えるでしょう。 初めは、88MDsが84とMDsしか伝えることができないのが、特に重要ですが、88が結局より広範囲になるのに従って、84MDsが重要である88を支持する能力が接続性を維持するためになる少数になるでしょう。 また、層は支持におけるオプションを実行するほとんどの実用的なMDs提供エントリー・ポイントに重要になるでしょう。 少なくとも以下のサポートはお勧めです。
Houttuin & Craigie [Page 11] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[11ページ]RFC1615
at MD entry-points:
MDエントリー・ポイントで:
88-P1/Normal-mode RTS/CONS/X.25(84)
88-P1/Normal-mode RTS/RFC1006/TCP/IP
84-P1/X.25(80)
84-P1/RFC1006/TCP/IP
88-P1/正規モードRTS/まやかし/X.25(84) 88-P1/正規モードRTS/RFC1006/TCP/IP84-P1/X.25(80) 84-P1/RFC1006/TCP/IP
The above table omits layers where the choice is obvious (e.g., Transport class zero), or where no choice exists (e.g., RTS for 84- P1).
上のテーブルは選択が明白であるか(例えば、Transportクラスゼロ)、または選択が全く存在しない層(例えば、84P1のためのRTS)を省略します。
The requirement for no intermediate 84 systems does require that the European R&D MHS use direct PRMD to PRMD routing between 88 PRMDs at least until such time as all ADMDs will relay the 88 MHS protocols.
中間的84台のシステムでない要件は、すべてのADMDsのような時間が88のMHSプロトコルをリレーするまでヨーロッパのR&D MHSが少なくとも88PRMDsの間のPRMDルーティングにダイレクトPRMDを使用するのを必要とします。
Finally, in order to keep routing co-ordination overhead to a minimum, an important requirement for the migration strategy is that only one common set of routing procedures is used for both 84 and 88 systems in the European R&D MHS.
最終的に、ルーティングコーディネーションオーバーヘッドを最小に抑えるために、移動戦略のための重要な要件は一般的な1セットのルーティング手順だけがヨーロッパのR&D MHSの84と88台のシステムの両方に用いられるということです。
6. Conclusion
6. 結論
1. The transition from X.400(84) to ISO 10021/X.400(88) is
worthwhile for the European R&D MHS, to provide:
1. ヨーロッパのR&D MHSにおいて、X.400(84)からISO10021/X.400(88)までの変遷提供するために価値があります:
- P7 Message Store to support remote UAs.
- Distribution Lists.
- Support for Directory Names.
- Standardised external Body Part types.
- Redirection.
- Security.
- Future extensibility.
- Physical Delivery.
- リモートUAsを支持するP7メッセージストア。 - 発送先リスト。 - ディレクトリ名のために、支持します。 - 標準化された外部のBody Partはタイプします。 - リダイレクション。 - セキュリティ。 - 将来の伸展性。 - 物理的な配送。
2. To minimise the number of transitions the European R&D MHS
target should be ISO 10021 rather than CCITT X.400(88) -
i.e., straight to use of the full OSI stack with Normal-mode
RTS.
2. ヨーロッパのR&D MHSが狙う変遷の数を最小とならせるのは、CCITT X.400(88)よりむしろすなわち、まっすぐNormal-モードRTSとの完全なOSIスタックの使用へのISO10021であるべきである。
3. To give a useful quality of service, the European R&D MHS
should not use minimal 88 MTAs which relay the syntax but
understand none of the semantics of extensions. In
particular, all European R&D MHS 88 MTAs should generate
reports containing extensions copied from the subject message
and route reports through the DL expansion hierarchy where
appropriate.
3. 役に立つサービスの質を与えるために、ヨーロッパのR&D MHSは構文をリレーする最小量の88MTAsを使用しませんが、拡大の意味論のいずれも理解しているはずがありません。 特に、88MTAsが発生させるはずであるすべてのヨーロッパのR&D MHSが、適切であるところに対象のメッセージとルートレポートからDL拡大階層構造までコピーされた拡大を含むと報告します。
Houttuin & Craigie [Page 12] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[12ページ]RFC1615
4. The European R&D MHS should carefully plan the transition so
that it is never necessary to relay through an 84 system to
provide connectivity between any two 88 systems.
4. ヨーロッパのR&D MHSは、それがどんな2の間の接続性に88台のシステムを提供するために84システムを通してリレーするのに決して必要でないように、慎重に変遷を計画しているはずです。
5. The European R&D MHS should consider the additional
functionality that can be provided to X.400(84) users by
adopting an enhanced specification of the interworking rules
between X.400(84) and ISO 10021/X.400(88), and weigh this
against the cost of building and maintaining its own
convertors. The advantages to X.400(84) users are:
5. ヨーロッパのR&D MHSは織り込むことの高められた仕様を採用することによってX.400(84)ユーザに提供できる追加機能性がX.400(84)とISO10021/X.400(88)の間で統治されると考えて、建築費とそれ自身の変換器を維持するとこれについて比較考量するはずです。 X.400(84)ユーザの利点は以下の通りです。
- Ability to generate 88 common-name attribute, likely to
be widely used for naming DLs.
- Consistent reception of DL-expanded and Redirected
messages.
- Ability to receive extended 88 P2 contents
automatically downgraded to 84 P2.
- DLsを命名するのに広く使用されそうな88一般名属性を発生させる能力。 - DLによって広げられるのとRedirectedメッセージの一貫したレセプション。 - 自動的に84P2に格下げされた88の拡張P2内容を受け取る能力。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Houttuin & Craigie [Page 13] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[13ページ]RFC1615
Appendix A - DL-expanded and Redirected Messages in X.400(84)
付録A--X.400のdlで広げられて向け直されたメッセージ(84)
This Annex provides an additional to the rules for "Interworking with 1984 Systems" contained in Annex B of ISO 10021-6/X.419, to give X.400(84) recipients consistent reception of messages that have been expanded by a DL or redirected. It is applicable only if the transition topology for the European R&D MHS recommended in section 3 is adopted.
このAnnexが提供する、「1984で、システムを織り込みます」のためのDLによって広げられるか、または向け直されたメッセージの一貫したレセプションをX.400(84)受取人に与えるためにISO10021-6/X.419のAnnex Bに含まれて、規則に追加しています。 セクション3のお勧めのヨーロッパのR&D MHSのための変遷トポロジーが採用される場合にだけ、適切です。
Replace the first paragraph of B.2.3 by:
B.2.3の第一節を以下に取り替えてください。
If an other-actions element is present in any trace- information- elements, that other-actions element and all preceding trace- information-elements shall be deleted. If an other-actions element is present in any subject-intermediate-trace-information- elements, that other-actions element shall be deleted.
他の動作要素がどんな跡情報の要素にも存在しているなら、その他の動作要素とすべての前の跡の情報要素が削除されるものとします。 他の動作要素がどんな対象中間的な跡情報要素にも存在しているなら、その他の動作要素は削除されるものとします。
Appendix B - Bibliography
付録B--図書目録
[1] ENV 41201, "Private MHS UA and MTA: PRMD to PRMD", CEN/CENELEC,
1988.
[1] ENV41201、「個人的なMHS UAとMTA:」 「PRMDへのPRMD」、CEN/CENELEC、1988。
[2] Kille, S., "X.400 1988 to 1984 downgrading", RTR 3, RFC 1328,
University College London, May 1992.
[2]Kille、S.、「X.400 1988年から1984格下げ」、RTR3、RFC1328、ユニバーシティ・カレッジロンドン1992年5月。
[3] ENV 41202, "Protocol for InterPersonal Messaging between MTAs
accessing the Public MHS", CEPT, 1988.
[3] ENV41202、「MTAsの間のInterPersonal MessagingのためのPublic MHSにアクセスするプロトコル」、CEPT、1988。
[4] Kille, S. "Mapping between X.400(1988)/ISO 10021 and RFC 822",
RTR 2, RFC 1327; University College London. May 1992.
S. [4]Kille、「X.400(1988)/ISO10021とRFC822の間のマッピング」、RTR2、RFC1327。 ユニバーシティ・カレッジロンドン。 1992年5月。
[5] Kille, S., "Using the OSI Directory to achieve User Friendly
Naming", RFC 1484, ISODE Consortium, July 1993.
[5]Kille、S.、「User Friendly Namingを達成するのにOSIディレクトリを使用します」、RFC1484、ISODE Consortium、1993年7月。
[6] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[6] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学(1982年8月)。
[7] Craigie, J., "COSINE Study 8.2.2. Migration Strategy for
X.400(84) to X.400(88)/MOTIS", Joint Network Team, 1988.
[7] クレーギー、J.、「コサイン研究8.2.2。」 「X.400(88)/MOTISへのX.400(84)のための移動戦略」、共同ネットワークチーム、1988。
[8] Craigie, J., "ISO 10021-X.400(88): A Tutorial for those familiar
with X.400(84)", Computer Networks and ISDN systems 16, 153-160,
North-Holland, 1988.
[8] クレーギー、J.、「ISO 10021-X.400(88):」 「X.400(84)になじみ深いそれらのためのTutorial」、コンピュータNetworksとISDNシステム16、153-160、北部オランダ1988。
[9] Manros, C.-U., "The X.400 Blue Book Companion", ISBN 1 871802 00
8, Technology Appraisals Ltd, 1989.
[9]Manros、C.U.、「X.400紳士録仲間」、ISBN、1、871802 00、8、技術評価Ltd、1989
Houttuin & Craigie [Page 14] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[14ページ]RFC1615
[10] CCITT Recommendations X.400 - X.430, "Data Communication
Networks: Message Handling Systems", CCITT Red Book, Vol. VIII -
Fasc. VIII.7, Malaga-Torremolinos, 1984.
[10]CCITT推薦X.400--X.430、「データ通信は以下をネットワークでつなぎます」。 「メッセージハンドリングシステム」、CCITT職員録、Vol.VIII--Fasc。 VIII.7、マラガ-トレモリノス、1984。
[11] CCITT Recommendations X.400 - X.420 (ISO IS-10021), "Data
Communication Networks: Message Handling Systems", CCITT Blue
Book, Vol. VIII - Fasc. VIII.7, Melbourne, 1988.
[11] CCITT推薦X.400--X.420、(ISO、-10021である、)、「データ通信は以下をネットワークでつなぎます」。 「メッセージハンドリングシステム」、CCITT紳士録、Vol.VIII--Fasc。 VIII.7、メルボルン、1988。
Appendix C - MHS Terminology
付録C--MHS用語
Message Handling is performed by four types of functional entity: User Agents (UAs) which enable the user to compose, send, receive, read and otherwise process messages; Message Transfer Agents (MTAs) which provide store-and-forward relaying services; Message Stores (MSs) which act on behalf of UAs located remotely from their associated MTA (e.g., UAs on PCs or workstations); and Access Units (AUs) which interface MHS to other communications media (e.g., Telex, Teletex, Fax, Postal Services). Each UA (and MS, and AU) is served by a single MTA, which provides that user's interface into the Message Transfer Service (MTS).
メッセージHandlingは4つのタイプの機能的な実体によって実行されます: 構成して、送って、受け取って、読んで、そうでなければ、ユーザがメッセージを処理するのを可能にするユーザエージェント(UAs)。 提供するメッセージTransferエージェント(MTAs)が、リレーサービスを格納して、進めます。 UAsを代表して行動するメッセージストア(MSs)は離れて彼らの関連MTAから(例えば、PCかワークステーションの上のUAs)の場所を見つけました。 そして、他の通信機関(例えば、Telex、Teletex、ファックス、Postal Services)にMHSを連結するAccess Units(AUs)。 各UA(そして、MS、およびAU)は独身のMTAによって役立たれています。(MTAはMessage Transfer Service(MTS)にそのユーザのインタフェースを供給します)。
Collections of MTAs (and their associated UAs, MSs and AUs) which are operated by or under the aegis of a single management authority are termed a Management Domain (MD). Two types of MD are defined: an ADMD, which provides a global public message relaying service directly or indirectly to all other ADMDs; and a PRMD operated by a private concern to serve its own users.
アイギスの近く、または、ただ一つの経営権のアイギスの下で操作されるMTAs(そして、彼らの関連UAs、MSs、およびAUs)の収集はManagement Domain(MD)と呼ばれます。 MDの2つのタイプが定義されます: ADMD(ADMDは直接か間接的に他のすべてのADMDsに対するサービスをリレーするグローバルな公共のメッセージを提供します)。 そして、PRMDは、それ自身のユーザに役立つように個人的な関心で作動しました。
A Message is comprised of an envelope and its contents. Apart from the MTS content-conversion service, the content is not examined or modified by the MTS which uses the envelope alone to provide the information required to convey the message to its destination.
Messageは封筒とそのコンテンツから成ります。 MTS内容変換サービスは別として、内容は、メッセージを目的地に伝えるのに必要である情報を提供するために単独の封筒を使用するMTSによって調べられもしませんし、変更もされません。
The MTS is the store-and-forward message relay service provided by the set of all MTAs. MTAs communicate with each other using the P1 Message Transfer protocol.
MTSはすべてのMTAsのセットによって提供された店とフォワードメッセージリレーサービスです。 MTAsは、P1 Message Transferプロトコルを使用することで互いにコミュニケートします。
Houttuin & Craigie [Page 15] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[15ページ]RFC1615
Appendix D - Abbreviations
付録D--略語
ACSE Association Control Service Element
ADMD Administration Management Domain
ASCII American Standard Code for Information Exchange
ASN.1 Abstract Syntax Notation One
AU Access Unit
CCITT Comite Consultatif International de Telegraphique et
Telephonique
CEN Comite Europeen de Normalisation
CENELEC Comite Europeen de Normalisation Electrotechnique
CEPT Conference Europeene des Postes et Telecommunications
CONS Connection Oriented Network Service
COSINE Co-operation for OSI networking in Europe
DL Distribution List
DIS Draft International Standard
EN European Norm
ENV Draft EN, European functional standard
IEC International Electrotechnical Commission
IPM Inter-Personal Message
IPMS Inter-Personal Messaging Service
IPN Inter-Personal Notification
ISO International Organisation for Standardisation
JNT Joint Network Team (UK)
JTC Joint Technical Committee (ISO/IEC)
MD Management Domain (either an ADMD or a PRMD)
MHS Message Handling System
MOTIS Message-Oriented Text Interchange Systems
MTA Message Transfer Agent
MTL Message Transfer Layer
MTS Message Transfer System
NBS National Bureau of Standardization
OSI Open Systems Interconnection
PRMD Private Management Domain
RARE Reseaux Associes pour la Recherche Europeenne
RFC Request for Comments
RTR RARE Technical Report
RTS Reliable Transfer Service
WG-MSG RARE Working Group on Mail and Messaging
ACSEアソシエーション制御サービス要素ADMD政権管理ドメインASCIIアメリカン・スタンダードは情報交換のためにASNをコード化します; 1 ヨーロッパDL Distribution List DIS国際規格案でENのヨーロッパのNorm ENV Draft ENをネットワークでつなぐOSIのための抽象的な国際Syntax Notation One AU Access Unitのヨーロッパ標準化機構Electrotechnique CEPTコンファレンスEuropeene des Postes et TelecommunicationsコンズCCITT Comite Consultatif de Telegraphique et Telephonique CENヨーロッパ標準化機構CENELEC Connection Oriented Network Service COSINE Co-事業; Standardisation JNT Joint Network Team(イギリス)JTC Joint Technical Committee(ISO/IEC)MD Management Domain(ADMDかPRMDのどちらか)のMHS Message Handling System MOTIS Messageが指向のText Interchange Systems MTA Message Transfer AgのIPM Inter個人的なヨーロッパの機能標準のMessage IPMS Inter個人的なメッセージサービスIPN Inter個人的なNotification ISO国際IEC国際電気標準化会議OrganisationStandardization OSIオープン・システム・インターコネクションPRMD兵士のManagement Domain RARE Reseaux Associesのent MTL Message Transfer Layer MTS Message Transfer System NBS National事務局はComments RTR RARE Technical Report RTS Reliable Transfer Service WG-MSG RARE作業部会のためにメールとMessagingでla Recherche Europeenne RFC Requestを注ぎます。
Houttuin & Craigie [Page 16] RFC 1615 Migrating from X.400(84) to X.400(88) May 1994
1994年5月にX.400(84)からX.400(88)まで移動するHouttuinとクレーギー[16ページ]RFC1615
Authors' Addresses
作者のアドレス
Jeroen Houttuin RARE Secretariat Singel 466-468 NL-1017 AW Amsterdam Europe
ジョロエン・Houttuinのまれな事務局Singel466-468NL-1017 AWアムステルダムヨーロッパ
Phone: +31 20 6391131 RFC 822: houttuin@rare.nl X.400: C=NL;ADMD=400net;PRMD=surf; O=rare;S=houttuin;
以下に電話をしてください。 +31 20 6391131RFC822: houttuin@rare.nl X.400: C=NL; ADMD=400net; PRMD=はサーフィンします。 O=まれです; S=houttuin;。
Jim Craigie Joint Network Team Rutherford Appleton Laboratory UK-OX11 OQX Chilton Didcot, Oxfordshire Europe
ジム・クレーギーJointのネットワークのラザフォード・アップルトーン研究所イギリス-OX11 OQXチルトン・ジドコット、オックスフォードシャーチームヨーロッパ
Phone: +44 235 44 5539 RFC 822: J.Craigie@jnt.ac.uk X.400: C=GB;ADMD= ;PRMD=UK.AC; O=jnt;I=J;S=Craigie;
以下に電話をしてください。 +44 235 44 5539RFC822: J.Craigie@jnt.ac.uk X.400: CはGB; ADMD=; PRMD=UK.ACと等しいです。 O=jnt; I=J; Sはクレーギーと等しいです。
Houttuin & Craigie [Page 17]
Houttuinとクレーギー[17ページ]
一覧
スポンサーリンク
