RFC1328 日本語訳
1328 X.400 1988 to 1984 downgrading. S. Hardcastle-Kille. May 1992. (Format: TXT=10006 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hardcastle-Kille
Request for Comments: 1328 University College London
May 1992
Hardcastle-Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1328 ユニバーシティ・カレッジロンドン1992年5月
X.400 1988 to 1984 downgrading
X.400 1988年から1984格下げ
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe.
このドキュメントはX.400(1988)からX.400(1984)まで[MHS88a、MHS84]を格下げする問題を考えます。 X.419の別館Bは規則[MHS88b]を格下げしながら、いくつかを指定しますが、これらは1984と1988のコンポーネントの両方を含む環境へのサービスの支給では十分ではありません。 このドキュメントは多くの拡大をこの別館と定義します。
This specification is not tutorial. COSINE Study 8.2 by J.A.I. Craigie gives a useful overview [Cra88].
この仕様は教授ではありません。 J.A.I.クレーギーによるCOSINE Study8.2は役に立つ概観[Cra88]を与えます。
1. The need to Downgrade
1. Downgradeにおける必要性
It is expected that X.400(1988) systems will be extensively deployed, whilst there is still substantial use of X.400(1984). If 1988 features are to be used, it it important for there to be a clear approach to downgrading. This document specifies an approach to downgrading for the Internet and COSINE communities. As 1988 is a strict superset of 1984, the mapping is a one-way problem.
X.400(1984)のかなりの使用がまだある間、X.400(1988)システムが手広く配備されると予想されます。 特徴が1988であるなら使用されていることであり、それがそれである、そこに重要である、格下げへの明確なアプローチになるように。 このドキュメントはインターネットとCOSINEのために共同体を格下げすることへのアプローチを指定します。 1988が1984年の厳しいスーパーセットであるので、マッピングは片道問題です。
2. Avoiding Downgrading
2. 格下げするのを避けます。
Perhaps the most important consideration is to configure systems so as to minimise the need for downgrading. Use of 1984 systems to interconnect 1988 systems should be strenuously avoided.
恐らく最も重要な考慮すべき事柄は格下げの必要性を最小とならせるようにシステムを構成することです。 1988台のシステムとインタコネクトする1984台のシステムの使用は精力的に避けられるべきです。
In practice, many of the downgrading issues will be avoided. When a 1988 originator sends to a 1984 recipient, 1988 specific features will not be used as they will not work! For distribution lists with 1984 and 1988 recipients, messages will tend to be "lowest common denominator".
実際には、格下げ問題の多くが避けられるでしょう。 1988年の創始者が1984年の受取人に発信するとき、働かないとき、1988の特定の特徴は使用されないでしょう! 1984がある発送先リストと1988人の受取人に関しては、メッセージは、「最小公分母」である傾向があるでしょう。
Hardcastle-Kille [Page 1] RFC 1328 X.400 1988 to 1984 downgrading May 1992
1992年5月を格下げするHardcastle-Kille[1ページ]RFC1328X.400 1988年から1984
3. Addressing
3. アドレシング
In general there is a problem with O/R addresses which use 88 specific features. The X.419 downgrade approach will mean that addresses using these features cannot be specified from 84 systems. Worse, a message originating from such an address cannot be transferred into X.400(1984). This is unacceptable. Two approaches are defined. The first is a general purpose mechanism, which can be implemented by the gateway only. The second is a special purpose mechanism to optimise for a form of X.400(88) address which is expected to be used frequently (Common Name). The second approach requires cooperation from all X.400(88) UAs and MTAs which are involved in these interactions.
一般に、88の特定の特徴を使用するO/Rアドレスに関する問題があります。 X.419ダウングレードアプローチは、84台のシステムからこれらの特徴を使用するアドレスを指定できないことを意味するでしょう。よりひどく、そのようなアドレスから発するメッセージはX.400(1984)に移すことができません。 これは容認できません。 2つのアプローチが定義されます。 1番目は汎用のメカニズムです。(ゲートウェイだけはそのメカニズムを実行できます)。 2番目は頻繁に使用されると予想されるX.400(88)アドレス(俗称)のフォームのために最適化する専用メカニズムです。 2番目のアプローチはこれらの相互作用にかかわるすべてのX.400(88) UAsとMTAsから協力を必要とします。
3.1 General Approach
3.1 一般的方法
The first approach is to use a DDA "X400-88". The DDA value is an std-or encoding of the address as defined in RFC 1327 [Kil92]. This will allow source routing through an appropriate gateway. This solution is general, and does not require co-operation. For example:
最初のアプローチはDDA「X400-88インチ」を使用することです。 または、DDA値がそうである、std、-、アドレスはRFC1327[Kil92]で定義されるようにコード化されます。 これは適切なゲートウェイにソースルーティングの通ることを許すでしょう。 この解決策は、一般的であり、協力を必要としません。 例えば:
88:
PD-ADDRESS=Empire State Building; PRMD=XX; ADMD=ZZ; C=US;
88: PD-アドレスはエンパイア・ステート・ビルディングと等しいです。 PRMD=XX。 ADMD=ZZ。 Cは米国と等しいです。
84:
O=MHS-Relay; PRMD=UK.AC; C=GB;
DD.X400-88=/PD-ADDRESS=Empire State Building/PRMD=XX/ADMD=ZZ/C=US/;
84: O=MHS-リレー。 PRMD=UK.AC。 CはGBと等しいです。 DD.X400-88=/PDアドレス=エンパイア・ステート・ビルディング/PRMD=XX/ADMD=ZZ/CはU.S./と等しいです。
The std-or syntax can use IA5 characters not in the printable string set (typically to handle teletext versions). To enable this to be handled, the std-or encoded in encapsulated into printable string using the mappings of Section 3.4 of RFC 1327. Where the generated address is longer than 128 characters, up to three overflow domain defined attributes are used: X400-C1; X400-C2; X400-C3.
または、std、-、構文は印刷可能なストリングで用意ができていない(通常ハンドル文字放送バージョンに)IA5キャラクタを使用できます。 または、これが扱われるのを可能にするためにstd、-、印刷可能なストリングへの要約にされるのでは、RFC1327のセクション3.4に関するマッピングを使用することで、コード化されます。 生成アドレスが128のキャラクタより長いところでは、3オーバーフロードメインまで、定義された属性は使用されています: X400-C1。 X400-C2。 X400-C3。
3.2 Common Name
3.2 俗称
Where a common name attribute is used, this is downgraded to the Domain Defined Attribute "Common". For example:
一般名属性が使用されているところでは、これはDomain Defined Attributeに「一般的に」格下げされます。 例えば:
88:
CN=Postmaster; O=A; ADMD=B; C=GB;
88: CNは郵便局長と等しいです。 O=A。 ADMD=B。 CはGBと等しいです。
84:
DD.Common=Postmaster; O=A; ADMD=B; C=GB;
84: DD.Commonは郵便局長と等しいです。 O=A。 ADMD=B。 CはGBと等しいです。
The downgrade will always happen correctly. However, it will not always be possible for the gateway to do the reverse mapping.
ダウングレードはいつも正しく起こるでしょう。 しかしながら、いつも、ゲートウェイが逆のマッピングをするのは、可能であるというわけではないでしょう。
Hardcastle-Kille [Page 2] RFC 1328 X.400 1988 to 1984 downgrading May 1992
1992年5月を格下げするHardcastle-Kille[2ページ]RFC1328X.400 1988年から1984
Therefore, this approach requires that all 1988 MTAs and UAs which wish to interact with 1984 systems through gateways following this specification will need to understand the equivalence of these two forms of address.
したがって、このアプローチは、すべての1988MTAsとこの仕様に従って、ゲートウェイを通して1984台のシステムと対話したがっているUAsが、これらの2つのフォームのアドレスの等価性を理解する必要であるのを必要とします。
4. MTS
4. MTS
Annexe B of X.419 is sufficient, apart from the addressing.
アドレシングは別として、X.419の別館Bは十分です。
The discard of envelope fields is unfortunate. However, the criticality mechanism ensures that no information the originator specifies to be critical is discarded. There is no sensible alternative. If mapping to a system which support the MOTIS-86 trace extensions, it is recommended that the internal trace of X.400(88) is mapped on to this, noting the slight differences in syntax.
封筒分野の破棄は不運です。 しかしながら、臨界メカニズムは、創始者が批判的になるように指定しない情報が全く捨てられるのを確実にします。 どんな賢明な代替手段もありません。 どのサポートをシステムに写像するかなら、MOTIS-86は拡大をたどって、X.400(88)の内部の跡がこれに写像されるのは、お勧めです、構文のわずかな違いに注意して。
5. IPM Downgrading
5. IPM格下げ
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.
通常、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 appendend 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 [Kil90]. For
example:
3. ディレクトリ名が存在しているなら、1984O/R Addressの中に意味論を保存する方法が全くありません。 しかしながら、横切って情報を通過するのは可能です、Distinguished Nameの情報をエンドユーザに非公式に表示できるように。 丸括弧でFree Form Nameに同封されて、appendendによるDistinguished Nameのテキスト表現をこれにします。 構文という「ユーザフレンドリーな名前」がDistinguished Name[Kil90]を表すのに使用されるのは、お勧めです。 例えば:
(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でボディー部分ダウングレードの問題について議論します。
Hardcastle-Kille [Page 3] RFC 1328 X.400 1988 to 1984 downgrading May 1992
1992年5月を格下げするHardcastle-Kille[3ページ]RFC1328X.400 1988年から1984
5.1 RFC 822 Considerations
5.1 RFC822問題
A message represented as content type 22 may have originated from RFC 822 [Cro82]. The downgrade for this type of message can be improved. This is discussed in RFC 1327 [Kil92].
満足しているタイプ22として表されたメッセージはRFC822[Cro82]から発したかもしれません。 このタイプに関するメッセージのためのダウングレードを改良できます。 RFC1327[Kil92]でこれについて議論します。
6. Body Part downgrading
6. ボディーPart格下げ
The issue of body part downgrade is very much linked up with the whole issue of body part format conversion. If no explicit conversion is requested, conversion depends on the MTA knowing the remote UA's capabilities. The following options are available for body part conversion in all cases, including this one. It is assumed that body part conversion is avoided where possible.
ボディー部分ダウングレードの問題はボディー部分フォーマット変換の全体の問題でたいへんリンクされます。 どんな明白な変換も要求されないなら、変換はリモートUAの能力を知っているMTAによります。 以下のオプションはこれを含むすべての場合におけるボディー部分変換に利用可能です。 ボディー部分変換が可能であるところで避けられると思われます。
1. Downgrade to a standard 1984 body part, without loss of
information
1. 情報の損失なしで1984身体の部分を規格に格下げしてください。
2. Downgrade to a standard 1984 body part, with loss of information
2. 情報の損失に伴う1984身体の部分を規格に格下げしてください。
3. Discard the body part, and replace with a (typically IA5 text)
message. For example:
3. ボディーが(通常IA5テキスト)メッセージに分けて、取り替える破棄。 例えば:
**********************************************
*
* There was a hologram here which could
* not be converted
*
**********************************************
********************************************** * * *変換された***********************が************************でないならそうすることができるホログラムがここにありました。
4. Bounce the message
4. メッセージを弾ませてください。
If conversion is prohibited, 4) must be done. If conversion-with- loss is prohibited, 1) should be done if possible, otherwise 4). In other cases 2) should be done if possible. If it is not possible, the choice between 3) and 4) should be a configuration choice. X.419 only recognises 4). 3) Seems to be a useful choice in practice, particularly where the message contains other body parts. Another option is available when downgrading:
変換を禁止するなら、4を)しなければなりません。 -損失を禁止して、できれば、別の方法で1を)するべきです。変換である、-、4)。 できれば、他の場合では、2を)するべきです。 それが可能でないなら、特選している3〜)4は)構成選択であるべきです。 X.419は4しか)認識しません。 3) 実際にはメッセージが他の身体の部分を含む特にところでの役に立つ選択であるように思えます。 以下を格下げするとき、別のオプションは利用可能です。
1. Encapsulate the body part as a Nationally Defined 1984
body part (body part 7).
1. Nationally Defined1984身体の部分(身体のパート7)として身体の部分を要約してください。
This should be used when configured for the recipient UA.
受取人UAのために構成されると、これは使用されるべきです。
Hardcastle-Kille [Page 4] RFC 1328 X.400 1988 to 1984 downgrading May 1992
1992年5月を格下げするHardcastle-Kille[4ページ]RFC1328X.400 1988年から1984
References
参照
[Cra88] Craigie, J., "Migration strategy for x.400(84) to
x.400(88)/MOTIS", COSINE Specification Phase 8.2, RARE, 1988.
[Cra88] クレーギー、J.、「x.400(88)/MOTISへのx.400(84)のための移動戦略」、COSINE Specification Phase8.2、RARE、1988。
[Cro82] Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", RFC 822, UDEL, August 1982.
[Cro82] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、UDEL、1982年8月。
[Kil90] Kille, S., "Using the OSI directory to achieve user friendly
naming", Research Note RN/90/29, Department of Computer
Science, University College London, February 1990.
S. [Kil90]Kille、「ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用すること」でのResearch Note RN/90/29、コンピュータScience、ユニバーシティ・カレッジロンドン(1990年2月)の部。
[Kil92] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
822", RFC 1327, University College London, May 1992.
[Kil92]Kille、S.、「X.400(1988)/ISO10021とRFC822インチ、RFC1327、ユニバーシティ・カレッジロンドンの間で5月1992日を写像すること。
[MHS84] Recommendations X.400, October 1984. CCITT SG 5/VII, Message
Handling Systems: System Model - Service Elements.
1984年10月の[MHS84]推薦X.400。 CCITT SG5/VII、メッセージハンドリングシステム: システムモデル--Elementsにサービスを提供してください。
[MHS88a] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
SG 5/VII / ISO/IEC JTC1, Message Handling: System and
Service Overview.
1988年4月の[MHS88a]CCITT推薦X.400 / ISO10021。 CCITT SG5/VII/ISO/IEC JTC1、メッセージハンドリング: システムとサービス概観。
[MHS88b] CCITT recommendations X.419/ ISO 10021, April 1988.
CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: Protocol
Specifications.
1988年4月の[MHS88b]CCITT推薦X.419/ ISO10021。 CCITT SG5/VII/ISO/IEC JTC1、メッセージハンドリング: 仕様を議定書の中で述べてください。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Author's Address
8. 作者のアドレス
Steve Hardcastle-Kille Department of Computer Science University College London Gower Street WC1E 6BT England
スティーブHardcastle-Killeコンピュータサイエンス学部ユニバーシティ・カレッジロンドンWC1E 6BTイギリスガウアー・ストリート
Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK
以下に電話をしてください。 +44-71-380-7294 メールしてください: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille [Page 5]
Hardcastle-Kille[5ページ]
一覧
スポンサーリンク
