RFC1138 日本語訳
1138 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. December 1989. (Format: TXT=191029 bytes) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC0822) (Updated by RFC1148) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kille Request for Comments 1138 University College London Updates: RFCs 822, 987, 1026 December 1989
ネットワークワーキンググループS.Killeはコメントのために1138のユニバーシティ・カレッジロンドンアップデートを要求します: RFCs822、987、1026 1989年12月
Mapping between X.400(1988) / ISO 10021 and RFC 822
X.400(1988)/ISO10021とRFC822の間のマッピング
Status of this Memo
このMemoの状態
This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティ、イギリスのAcademic Community、および要求のために改良のための議論と提案を写像する電子メールプロトコルを勧めます。 このメモはインターネット標準を指定しません。 このメモの分配は無制限です。
This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 (1988) Recommendations on Message Handling Systems / ISO IEC 10021 Message Oriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and systems using the RFC 822 mail protocol [Crocker82a] or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings. The mappings should not require any changes to end systems.
このドキュメントはMessage Handling Systems / ISO IEC10021Message Oriented Text Interchange Systems(MOTIS)[CCITT/ISO88a]と、RFC822メールプロトコルを使用するシステム[Crocker82a]かRFC822から得られたプロトコルでCCITT X.400(1988)推薦を操作するシステムの間の織り込むことを可能にする1セットのマッピングについて説明します。 アプローチは、過度に複雑なマッピングを必要としていない間に境界の向こう側に提供されたサービスを最大にすることを目指します。 マッピングは、どんな変化もシステムを終わらせるのを必要とするべきではありません。
This document is based on RFC 987 and RFC 1026 [Kille86a, Kille87a], which define a similar mapping for X.400 (1984). This document does not obsolete the earlier ones, as its domain of application is different.
このドキュメントはRFC987とRFC1026[Kille86a、Kille87a]に基づいています。(RFCはX.400(1984)のための同様のマッピングを定義します)。 アプリケーションのドメインが異なっているとき、このドキュメントは以前のものを時代遅れにしません。
Specification
仕様
This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected.
このドキュメントは2つのプロトコルの間のマッピングを指定します。 このマッピングがインターネットの上、または、イギリスのAcademic Communityで実行されるとき、この仕様は使用されるべきです。 この仕様は実現経験の見地から変更されるかもしれませんが、大きな変化は全く予想されません。
Table of Contents
目次
1. Overview ............................................... 2 1.1 X.400 ................................................. 2 1.2 RFC 822 ............................................... 3 1.3 The need for conversion ............................... 4 1.4 General approach ...................................... 4 1.5 Gatewaying Model ...................................... 5 1.6 RFC 987 ............................................... 7 1.7 Aspects not covered ................................... 8 1.8 Subsetting ............................................ 9 1.9 Document Structure .................................... 9
1. 概観… 2 1.1X.400… 2 1.2 RFC822… 3 1.3 変換の必要性… 4 1.4 一般アプローチ… 4 1.5 モデルをGatewayingします… 5 1.6 RFC987… 7 カバーされなかった1.7の局面… 8 1.8 Subsettingします… 9 1.9 構造を記録してください… 9
Kille [Page 1] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[1ページ]RFC1138
1.10 Acknowledgements ..................................... 10 2. Service Elements ....................................... 10 2.1 The Notion of Service Across a Gateway ................ 10 2.2 RFC 822 ............................................... 11 2.3 X.400 ................................................. 15 3. Basic Mappings ........................................ 24 3.1 Notation .............................................. 24 3.2 ASCII and IA5 ......................................... 25 3.3 Standard Types ........................................ 25 3.4 Encoding ASCII in Printable String .................... 28 4. Addressing ............................................. 29 4.1 A textual representation of MTS.ORAddress ............. 30 4.2 Basic Representation .................................. 30 4.3 EBNF.822-address <-> MTS.ORAddress .................... 34 4.4 Repeated Mappings ..................................... 43 4.5 Directory Names ....................................... 45 4.6 MTS Mappings .......................................... 45 4.7 IPMS Mappings ....... ................................. 48 5. Detailed Mappings ...................................... 52 5.1 RFC 822 -> X.400 ...................................... 52 5.2 Return of Contents .................................... 59 5.3 X.400 -> RFC 822 ...................................... 60 Appendix A Differences with RFC 987 ....................... 78 1. Introduction ........................................... 78 2. Service Elements ....................................... 78 3. Basic Mappings ......................................... 78 4. Addressing ............................................. 78 5. Detailed Mappings ...................................... 79 6. Appendices ............................................. 79 Appendix B Mappings specific to the JNT Mail .............. 79 1. Introduction ........................................... 79 2. Domain Ordering ........................................ 79 3. Acknowledge-To: ........................................ 79 4. Trace .................................................. 80 5. Timezone specification ................................. 80 6. Lack of 822-MTS originator specification ............... 80 Appendix C Mappings specific to UUCP Mail ................. 81 Appendix D Object Identifier Assignment ................... 82 Appendix E BNF Summary .................................... 82 Appendix F Format of address mapping tables ............... 89 References ................................................. 91
1.10の承認… 10 2. Elementsにサービスを提供してください… 10 2.1 ゲートウェイの向こう側のサービスの概念… 10 2.2 RFC822… 11 2.3X.400… 15 3. 基本のマッピング… 24 3.1記法… 24 3.2のASCIIとIA5… 25 3.3 標準のタイプ… 25 3.4 印刷可能なストリングのASCIIをコード化します… 28 4. 記述します。 29 4.1 MTS.ORAddressの原文の表現… 30 4.2 基本的な表現… 30 4.3 EBNF.822-アドレス<->MTS.ORAddress… 34 4.4 マッピングを繰り返します… 43 4.5のディレクトリ名… 45 4.6のMTSマッピング… 45 4.7のIPMSマッピング… ................................. 48 5. マッピングを詳しく述べます… 52 5.1 RFC822->X.400… 52 5.2 コンテンツの復帰… 59 5.3 X.400->RFC822… 60 RFC987がある付録A差… 78 1. 序論… 78 2. Elementsにサービスを提供してください… 78 3. 基本のマッピング… 78 4. 記述します。 78 5. マッピングを詳しく述べます… 79 6. 付録… 79 JNTメールに特定の付録B Mappings… 79 1. 序論… 79 2. ドメイン注文… 79 3. To:を承認します。 ........................................ 79 4. 跡… 80 5. タイムゾーン仕様… 80 6. 822-MTS創始者仕様の不足… 80 UUCPメールに特定の付録C Mappings… 81付録D物の識別子課題… 82付録E BNF概要… 82 アドレス変換テーブルの付録F Format… 89の参照箇所… 91
Chapter 1 -- Overview
第1章--概観
1.1. X.400
1.1. X.400
This document relates to the CCITT 1988 X.400 Series Recommendations / ISO IEC 10021 on the Message Oriented Text Interchange Service
このドキュメントはMessage Oriented Text Interchange Serviceの上のCCITT1988X.400 Series Recommendations / ISO IEC10021に関連します。
Kille [Page 2] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[2ページ]RFC1138
(MOTIS). This ISO/CCITT standard is referred to in this document as "X.400", which is a convenient shorthand. Any reference to the 1984 CCITT Recommendations will be explicit. X.400 defines an Interpersonal Messaging System (IPMS), making use of a store and forward Message Transfer System. This document relates to the IPMS, and not to wider application of X.400. It is expected that X.400 will be implemented very widely.
(MOTIS。) このISO/CCITT規格は本書では"X.400"と呼ばれます。(それは、便利な速記です)。 1984CCITT Recommendationsのどんな参照も明白になるでしょう。 店と前進のMessage Transfer Systemを利用して、X.400はInterpersonal Messaging System(IPMS)を定義します。 このドキュメントはX.400の、より広いアプリケーションではなく、IPMSに関係します。 X.400が非常に広く実行されると予想されます。
1.2. RFC 822
1.2. RFC822
RFC 822 is the current specification of the messaging standard on the Internet. This standard evolved with the evolution of the network from the ARPANET (created by the Defense Advanced Research Projects Agency) to the Internet, which now involves over 1000 networks and is sponsored by DARPA, NSF, DOE, NASA, and NIH. It specifies an end to end message format. It is used in conjunction with a number of different message transfer protocol environments.
RFC822はインターネットのメッセージング規格の現在の仕様です。 この規格は、ネットワークのアルパネット(国防高等研究計画庁によって作成される)から現在1000以上のネットワークにかかわるインターネットまでの発展に従って発展して、DARPA、NSF、ドウ、NASA、およびNIHによって保証されます。 それは、メッセージ・フォーマットを終わらせるために終わりを指定します。 それは多くの異なったメッセージ転送プロトコル環境に関連して使用されます。
SMTP Networks
SMTPネットワーク
On the Internet and other TCP/IP networks, RFC 822 is used in
conjunction with two other standards: RFC 821, also known as
Simple Mail Transfer Protocol (SMTP) [Postel82a], and RFC 1034
which is a Specification for domains and a distributed name
service [Mockapetris87a].
インターネットと他のTCP/IPネットワークでは、RFC822は他の2つの規格に関連して使用されます: また、シンプルメールトランスファプロトコル(SMTP)として知られているRFC821[Postel82a]、およびドメインへのSpecificationと分配された名前サービスであるRFC1034[Mockapetris87a]。
UUCP Networks
UUCPネットワーク
UUCP is the UNIX to UNIX CoPy protocol, which is usually used
over dialup telephone networks to provide a simple message
transfer mechanism. There are some extensions to RFC 822,
particularly in the addressing. They use domains which conform
to RFC 1034, but not the corresponding domain nameservers
[Horton86a].
UUCPはUNIX CoPyプロトコルへのUNIXです。(通常、そのUNIXは、簡単なメッセージトランスファ・メカニズムを提供するのにダイアルアップ電話網の上で使用されます)。 RFC822と、特にアドレシングにはいくつかの拡大があります。 彼らは対応するドメインネームサーバ[Horton86a]ではなく、RFC1034に従うドメインを使用します。
Csnet
Csnet
Some portions of Csnet follow the Internet protocols. The
dialup portion of Csnet uses the Phonenet protocols as a
replacement for RFC 821. This portion uses domains which
conform to RFC 1034, but not the corresponding domain
nameservers.
Csnetのいくつかの一部がインターネットプロトコルに従います。 Csnetのダイアルアップ一部がRFC821に交換としてPhonenetプロトコルを使用します。 この部分は対応するドメインネームサーバではなく、RFC1034に従うドメインを使用します。
Bitnet
Bitnet
Some parts of Bitnet and related networks use RFC 822 related
protocols, with EBCDIC encoding.
Bitnetと関連するネットワークのいくつかの部分がEBCDICコード化があるRFC822関連するプロトコルを使用します。
Kille [Page 3] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[3ページ]RFC1138
JNT Mail Networks
JNTはネットワークに郵送します。
A number of X.25 networks, particularly those associated with
the UK Academic Community, use the JNT (Joint Network Team)
Mail Protocol, also known as Greybook [Kille84a]. This is used
with domains and name service specified by the JNT NRS (Name
Registration Scheme) [Larmouth83a].
多くのX.25ネットワーク(特にイギリスのAcademic Communityに関連づけられたもの)がまた、Greybook[Kille84a]として知られているJNT(共同Network Team)メールプロトコルを使用します。 これはJNT NRS(名前Registration Scheme)[Larmouth83a]によって指定されるドメインと名前サービスと共に使用されます。
The mappings specified here are appropriate for all of these
networks.
これらのネットワークのすべてに、ここで指定されたマッピングは適切です。
1.3. The need for conversion
1.3. 変換の必要性
There is a large community using RFC 822 based protocols for mail services, who will wish to communicate with users of the IPMS provided by X.400 systems. This will also be a requirement in cases where communities intend to make a transition to use of an X.400 IPMS, as conversion will be needed to ensure a smooth service transition. It is expected that there will be more than one gateway, and this specification will enable them to behave in a consistent manner. Note that the term gateway is used to describe a component performing the protocol mappings between RFC 822 and X.400. This is standard usage amongst mail implementors, but should be noted carefully by transport and network service implementors.
また、これは共同体が使用する変遷をするつもりであるX.400 IPMSに関するケースの中で要件になるでしょう、変換が滑らかなサービス変遷を確実にするのに必要であるときに。メールサービスにRFC822に基づいているプロトコルを使用する大きい共同体があります。(共同体はX.400システムによって提供されたIPMSのユーザとコミュニケートしたくなるでしょう)。 複数のゲートウェイがあると予想されて、この仕様は、彼らが一貫した態度で振る舞うのを可能にするでしょう。 用語ゲートウェイがRFC822とX.400の間のプロトコルマッピングを実行するコンポーネントについて説明するのに使用されることに注意してください。 これは、メール作成者の中の標準的用法ですが、輸送とネットワーク・サービス作成者によって慎重に注意されるべきです。
Consistency between gateways is desirable to provide:
ゲートウェイの間の一貫性は提供するのにおいて望ましいです:
1. Consistent service to users.
1. ユーザに対する一貫したサービス。
2. The best service in cases where a message passes through
multiple gateways.
2. メッセージが複数のゲートウェイを通り抜ける場合で最も良いサービス。
1.4. General approach
1.4. 一般的方法
There are a number of basic principles underlying the details of the specification. These principles are goals, and are not achieved in all aspects of the specification.
仕様の細目の基礎となる多くの基本原理があります。 これらの原則は、目標であり、仕様の全面で達成されません。
1. The specification should be pragmatic. There should not be
a requirement for complex mappings for "Academic" reasons.
Complex mappings should not be required to support trivial
additional functionality.
1. 仕様は実践的であるべきです。 「アカデミックな」理由による複雑なマッピングのための要件があるべきではありません。 些細な追加機能性を支持するために複雑なマッピングを必要とするべきではありません。
2. Subject to 1), functionality across a gateway should be as
high as possible.
2. 1)を条件として、ゲートウェイの向こう側の機能性はできるだけ高いはずです。
3. It is always a bad idea to lose information as a result of
any transformation. Hence, it is a bad idea for a gateway
3. いつもどんな変化の結果、情報を失うのは、悪い考えです。 したがって、それはゲートウェイのための悪い考えです。
Kille [Page 4] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[4ページ]RFC1138
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
物で情報を捨てるために、それは処理されます。 これは完全に写像できるというわけではない要求されたサービスを含んでいます。
4. All mail gateways actually operate at exactly one level
above the layer on which they conceptually operate. This
implies that the gateway must not only be cognisant of the
semantics of objects at the gateway level, but also be
cognisant of higher level semantics. If meaningful
transformation of the objects that the gateway operates on
is to occur, then the gateway needs to understand more than
the objects themselves.
4. すべてのメール・ゲートウェイが実際にそれらが概念的に作動させる層を超えたまさに1つのレベルで作動します。 これは、ゲートウェイが単にゲートウェイレベルにおいて物の意味論で認識力があるのではなく、より高い平らな意味論において認識力がありもするに違いないのを含意します。 ゲートウェイが作動させる物の重要な変化が起こるつもりであるなら、ゲートウェイは、物自体より分かる必要があります。
5. The specification should be reversible. That is, a double
transformation should bring you back to where you started.
5. 仕様はリバーシブルであるべきです。 すなわち、二重変化はあなたが出発したところにあなたを返すべきです。
1.5. Gatewaying Model
1.5. モデルをGatewayingします。
1.5.1. X.400
1.5.1. X.400
X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7, [CCITT/ISO88b] which comprises of three basic services:
X.420/ISO10021-7、3で基本サービスを包括する[CCITT/ISO88b]でX.400はIPMSの抽象的なServiceを定義します:
1. Origination
1. 創作
2. Reception
2. レセプション
3. Management
3. 管理
Management is a local interaction between the user and the IPMS, and is therefore not relevant to gatewaying. The first two services consist of operations to originate and receive the following two objects:
管理は、ユーザとIPMSとの局所的相互作用であり、したがって、gatewayingに関連していません。 最初の2つのサービスが以下の2個の物を溯源して、受け取るために操作から成ります:
1. IPM (Interpersonal Message). This has two components: a
heading, and a body. The body is structured as a sequence
of body parts, which may be basic components (e.g., IA5
text, or G3 fax), or IP Messages. The heading consists of
fields containing end to end user information, such as
subject, primary recipients (To:), and importance.
1. IPM(個人間のメッセージ)。 これには、2つのコンポーネントがあります: 見出し、およびボディー。 ボディーは基本的なコンポーネントであるかもしれない身体の部分(例えば、IA5テキスト、またはG3ファックス)、またはIP Messagesの系列として構造化されます。 見出しはエンドユーザ情報の受けることがあって、第一の受取人などの終わり(To:)、および重要性を含む分野から成ります。
2. IPN (Inter Personal Notification). A notification about
receipt of a given IPM at the UA level.
2. IPN(間の個人的な通知)。 UAレベルにおける与えられたIPMの領収書に関する通知。
The Origination service also allows for origination of a probe, which is an object to test whether a given IPM could be correctly received.
また、正しく与えられたIPMを受け取ることができたか否かに関係なく、Originationサービスは、物である徹底的調査の創作がテストされるのを許容します。
The Reception service also allows for receipt of Delivery Reports (DR), which indicate delivery success or failure.
また、ReceptionサービスはDelivery Reports(DR)の領収書を考慮します。(Delivery Reportsは配送成否を示します)。
Kille [Page 5] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[5ページ]RFC1138
These IPMS Services utilise the Message Transfer (MT) Abstract Service [CCITT/ISO88c]. The MT Abstract Service provides the following three basic services:
これらのIPMS ServicesはMessage Transfer(MT)の抽象的なService[CCITT/ISO88c]を利用します。 MTの抽象的なServiceは以下の3つの基本サービスを提供します:
1. Submission (used by IPMS Origination)
1. 服従(IPMS創作で、使用されます)
2. Delivery (used by IPMS Reception)
2. 配送(IPMSレセプションで、使用されます)
3. Administration (used by IPMS Management)
3. 政権(IPMS経営者側によって使用されます)
Administration is a local issue, and so does not affect this standard. Submission and delivery relate primarily to the MTS Message (comprising Envelope and Content), which carries an IPM or IPN (or other uninterpreted contents). There is also an Envelope, which includes an ID, an originator, and a list of recipients. Submission also includes the probe service, which supports the IPMS Probe. Delivery also includes Reports, which indicate whether a given MTS Message has been delivered or not.
政権は、ローカルの問題であるのでこの規格に影響しません。 服従と配送は主としてMTS Message(Envelopeを包括して、Content)に関連します。(MTS MessageはIPMかIPN(または、他の非解釈されたコンテンツ)を運びます)。 また、Envelopeがあります。(EnvelopeはID、創始者、および受取人のリストを含んでいます)。 また、服従は徹底的調査サービスを含んでいます。(それは、IPMS Probeを支持します)。 また、配送はReportsを含んでいます。(Reportsは、与えられたMTS Messageが届けられたかどうかを示します)。
The MTS is REFINED into the MTA (Message Transfer Agent) Service, which define the interaction between MTAs, along with the procedures for distributed operation. This service provides for transfer of MTS Messages, Probes, and Reports.
MTSはMTA(メッセージTransferエージェント)サービスへのREFINEDです、分配された操作のための手順と共に。(REFINEDはMTAsの間の相互作用を定義します)。 このサービスはMTS Messages、Probes、およびReportsの転送に備えます。
1.5.2. RFC 822
1.5.2. RFC822
RFC 822 is based on the assumption that there is an underlying service, which is here called the 822-MTS service. The 822-MTS service provides three basic functions:
RFC822は822-MTSサービスと呼ばれて、ここにある基本的なサービスがあるという仮定に基づいています。 822-MTSサービスは3つの基本機能を提供します:
1. Identification of a list of recipients.
1. 受取人のリストの識別。
2. Identification of an error return address.
2. 誤り返送先の識別。
3. Transfer of an RFC 822 message.
3. RFC822メッセージの転送。
It is possible to achieve 2) within the RFC 822 header. Some 822-MTS protocols, in particular SMTP, can provide additional functionality, but as these are neither mandatory in SMTP, nor available in other 822-MTS protocols, they are not considered here. Details of aspects specific to two 822-MTS protocols are given in Appendices B and C. An RFC 822 message consists of a header, and content which is uninterpreted ASCII text. The header is divided into fields, which are the protocol elements. Most of these fields are analogous to P2 heading fields, although some are analogous to MTS Service Elements or MTA Service Elements.
RFC822ヘッダーの中に2を)達成するのは可能です。 いくつかの822-MTSプロトコル(特にSMTP)がこれらとして追加機能性を提供できますが、SMTPで義務的でなくて、また他の822-MTSプロトコルでは利用可能でない、それらはここで考えられません。 2つの822-MTSプロトコルに特定の局面の詳細はAppendices Bで明らかにされます、そして、C.An RFC822メッセージは非解釈されたASCIIテキストであるヘッダー、および内容から成ります。 ヘッダーは分野に分割されます。(分野はプロトコル要素です)。 これらの分野の大部分はP2見出し分野に類似しています、或るものがMTS Service ElementsかMTA Service Elementsに類似していますが。
Kille [Page 6] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[6ページ]RFC1138
1.5.3. The Gateway
1.5.3. ゲートウェイ
Given this functional description of the two services, the functional nature of a gateway can now be considered. It would be elegant to consider the 822-MTS service mapping onto the MTS Service Elements and RFC 822 mapping onto an IPM, but reality just does not fit. Another elegant approach would be to treat this document as the definition of an X.400 Access Unit (AU). Again, reality does not fit. It is necessary to consider that the IPM format definition, the IPMS Service Elements, the MTS Service Elements, and MTA Service Elements on one side are mapped into RFC 822 + 822-MTS on the other in a slightly tangled manner. The details of the tangle will be made clear in Chapter 5. Access to the MTA Service Elements is minimised.
2つのサービスのこの機能的な記述を考えて、現在、ゲートウェイの機能的な自然を考えることができます。 822-MTSがサービス対応表であるとIPMへのMTS Service ElementsとRFC822マッピングと考えるのが上品でしょうが、現実はただ合いません。 別の上品なアプローチはX.400 Access Unit(AU)の定義としてこのドキュメントを扱うだろうことです。 一方、現実は合いません。 半面の上のIPM形式定義、IPMS Service Elements、MTS Service Elements、およびMTA Service Elementsがもう片方でわずかにもつれている方法でRFC822+822-MTSに写像されると考えるのが必要です。 もつれの詳細は第5章で明らかにされるでしょう。 MTA Service Elementsへのアクセスは最小となります。
The following basic mappings are thus defined. When going from RFC 822 to X.400, an RFC 822 message and the associated 822-MTS information is always mapped into an IPM (MTA, MTS, and IPMS Services). Going from X.400 to RFC 822, an RFC 822 message and the associated 822-MTS information may be derived from:
以下の基本のマッピングはこのようにして定義されます。 RFC822からX.400まで行くとき、RFC822メッセージと関連822-MTS情報はいつもIPM(MTA、MTS、およびIPMS Services)に写像されます。 RFC822、RFC822メッセージ、およびX.400から関連822-MTS情報まで行くのは以下から引き出されるかもしれません。
1. A Report (MTA, and MTS Services)
1. レポート(MTA、およびMTSサービス)
2. An IPN (MTA, MTS, and IPMS Services)
2. IPN(MTA、MTS、およびIPMSサービス)
3. An IPM (MTA, MTS, and IPMS Services)
3. IPM(MTA、MTS、およびIPMSサービス)
Probes (MTA Service) must be processed by the gateway, as discussed in Chapter 5. MTS Messages containing Content Types other than those defined by the IPMS are not mapped by the gateway, and should be rejected at the gateway.
第5章で議論するようにゲートウェイで徹底的調査(MTA Service)を処理しなければなりません。 IPMSによって定義されたもの以外のContent Typesを含むMTS Messagesはゲートウェイによって写像されないで、ゲートウェイで拒絶されるべきです。
1.5.4. Repeated Mappings
1.5.4. 繰り返されたマッピング
The mappings specified here are designed to work where a message traverses multiple times between X.400 and RFC 822. This is often essential, particularly in the case of distribution lists. However, in general, this will lead to a level of service which is the lowest common denominator (approximately the services offered by RFC 822). In particular, there is no expectation of additional X.400 services being mapped - although this may be possible in some cases.
ここで指定されたマッピングは、メッセージがX.400とRFC822の間で複数の回を横断するところで働くように設計されています。 これは特に発送先リストの場合でしばしば不可欠です。 しかしながら、一般に、これは最小公分母(RFC822によって提供されたおよそサービス)であるサービスのレベルに通じるでしょう。 特に、これがいくつかの場合可能であるかもしれませんが、写像される追加X.400サービスへの期待が全くありません。
1.6. RFC 987
1.6. RFC987
Much of this work is based on the initial specification of RFC 987 and in its addendum RFC 1026. A basic decision is that the mapping will be to the full 1988 version of X.400, and not to a 1984 compatible subset. This is important, to give good support to communities which will utilise full X.400 at an early date. This has
この仕事の多くがRFC987の初期の仕様に基づいたその付加物RFC1026にあります。 基本的な決定は1984年のコンパチブル部分集合ではなく、1988年のX.400の完全なバージョンにはマッピングがあるということです。 これは、期日前半に完全なX.400を利用する共同体に良いサポートを与えるために重要です。 これはそうしました。
Kille [Page 7] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[7ページ]RFC1138
the following implications:
以下の含意:
- This document does not obsolete RFC 987, as it has a
different domain of application.
- それにアプリケーションの異なったドメインがあるとき、このドキュメントはRFC987を時代遅れにしません。
- If a gatewayed message is being transferred to a 1984
system, then RFC 987 should be used. If the X.400 side of
the gateway is a 1988 system, then it should be operated in
1984 compatibility mode. There is no advantage and some
disadvantage in using the new mapping, and later on applying
X.400 downgrading rules. Note that in an environment where
RFC 822 is of major importance, it may be desirable for
downgrading to consider the case where the message was
originated in an RFC 822 system, and mapped according to
this specification.
- 1984年のシステムにgatewayedメッセージを移しているなら、RFC987を使用するべきです。 ゲートウェイのX.400側面が1988年のシステムであるなら、それは1984年の互換性モードで操作されるべきです。 新しいマッピングを使用して、後で間の規則を格下げするX.400を適用する利点がなくて何らかの難点があります。 格下げに、RFC822が主要に重要である環境で、メッセージがRFC822システムで溯源されて、この仕様通りに写像されたケースを考えるのが望ましいかもしれないことに注意してください。
- New features of X.400 can be used to provide a much cleaner
mapping than that defined in RFC 987.
- RFC987で定義されたそれよりはるかに清潔なマッピングを提供するのにX.400に関する新機能を使用できます。
Unnecessary change is usually a bad idea. Changes on the RFC 822 side are avoided as far as possible, so that RFC 822 users do not see arbitrary differences between systems conforming to this specification, and those following RFC 987. Changes on the X.400 side are minimised, but are more acceptable, due to the mapping onto a new set of services and protocols.
通常、不要な変化は悪い考えです。 RFC822側の上の変化はできるだけ避けられます、822人のユーザがするRFCが、システムの任意の違いがこの仕様に従うことを確認して、ものがRFC987に続くことを確認しないように。 X.400側の上の変化は、最小となりますが、より許容できます、新しいサービスのセットへのマッピングとプロトコルのため。
A summary of changes made is given in Appendix A.
Appendix Aで行われた変更の概要をします。
1.7. Aspects not covered
1.7. カバーされなかった局面
There have been a number of cases where RFC 987 was used in a manner which was not intended. This section is to make clear some limitations of scope. In particular, this specification does not specify:
件数がRFC987が意図しなかった方法で使用されたところにありました。 このセクションは範囲のいくつかの限界を明らかにすることになっています。 特に、この仕様は指定しません:
- Extensions of RFC 822 to provide access to all X.400
services
- 提供するRFC822の拡大はすべてのX.400にサービスにアクセスします。
- X.400 user interface definition
- X.400ユーザーインタフェース定義
These are really coupled. To map the X.400 services, this specification defines a number of extensions to RFC 822. As a side effect, these give the 822 user access to SOME X.400 services. However, the aim on the RFC 822 side is to preserve current service, and it is intentional that access is not given to all X.400 services. Thus, it will be a poor choice for X.400 implementors to use RFC 987(88) as an interface - there are too many aspects of X.400 which
これらは本当に結合されます。 X.400サービスを写像するために、この仕様は多くの拡大をRFC822と定義します。 副作用として、これらはSOME X.400サービスへの822ユーザアクセスを与えます。 しかしながら、RFC822側の上の目的が当期の勤務を保持すること的であり、アクセスがすべてのX.400サービスに与えられていないのは、意図的です。 したがって、X.400作成者がインタフェースとしてRFC 987(88)を使用するのは、不十分な選択でしょう--X.400のあまりに多くの局面がある、どれ
Kille [Page 8] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[8ページ]RFC1138
cannot be accessed through it. If a text interface is desired, a specification targeted at X.400, without RFC 822 restrictions, would be more appropriate.
それを通してアクセスできません。 テキストインタフェースが望まれているなら、RFC822制限なしでX.400をターゲットにした仕様は、より適切でしょう。
1.8. Subsetting
1.8. Subsettingします。
This proposal specifies a mapping which is appropriate to preserve services in existing RFC 822 communities. Implementations and specifications which subset this specification are strongly discouraged.
この提案は既存のRFC822共同体にサービスを保持するのが適切なマッピングを指定します。 実現、仕様がどの部分集合をがっかりさせるか、この仕様は強くがっかりしています。
1.9. Document Structure
1.9. ドキュメント構造
This document has five chapters:
このドキュメントには、5つの章があります:
1. Overview - this chapter.
1. 概観--本章。
2. Service Elements - This describes the (end user) services
mapped by a gateway.
2. Elementsにサービスを提供してください--これはゲートウェイによって写像された(エンドユーザ)サービスについて説明します。
3. Basic mappings - This describes some basic notation used in
Chapters 3-5, the mappings between character sets, and some
fundamental protocol elements.
3. 基本のマッピング--これは第3-5章、文字の組の間のマッピングで使用される、何らかの基本的な記法、およびいくつかの基本的なプロトコル要素について説明します。
4. Addressing - This considers the mapping between X.400 O/R
names and RFC 822 addresses, which is a fundamental gateway
component.
4. アドレシング--これはX.400O/R名とRFC822のアドレスの間のマッピングを考えます。(それは、基本的なゲートウェイの部品です)。
5. Detailed Mappings - This describes the details of all other
mappings.
5. 詳細なMappings--これは他のすべてのマッピングの詳細について説明します。
There are also six appendices:
また、6個の付録があります:
A. Differences with RFC 987
RFC987があるA.差
B. Mappings Specific to JNT Mail
JNTに特定のマッピングが郵送するB.
C. Mappings Specific to UUCP Mail
UUCPに特定のマッピングが郵送するC.
D. Object Identifier Assignment
D.物の識別子課題
E. BNF Summary
E.BNF概要
F. Format of Address Tables
アドレス・テーブルのF.形式
WARNING:
警告:
THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED.
この仕様の残りは技術的に詳細です。
Kille [Page 9] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[9ページ]RFC1138
IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND
X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS
YOU ARE FAMILIAR WITH THESE SPECIFICATIONS.
RFC822とX.400(1988)の文脈以外に、それは理解できないでしょう。 これらの仕様になじみ深くない場合、このドキュメントを読むのを試みないでください。
1.10. Acknowledgements
1.10. 承認
This work was partly sponsored by the Joint Network Team. The workshop at UCL in June 1989 to work on this specification was also an IFIP WG 6.5 meeting.
この仕事はJoint Network Teamによって一部後援されました。 また、この仕様を扱う1989年6月のUCLのワークショップはIFIP WG6.5ミーティングでした。
The work in this specification was substantially based on RFC 987, which had input from many people.
この仕様に基づく仕事は実質的にRFC987に基づきました。(RFCは多くから人々を入力しました)。
Useful comments and suggestions were made by Pete Cowen (Nottingham Univ), Jim Craigie (JNT), Christian Huitema (Inria), Peter Lynch (Prime), Julian Onions (Nottingham Univ), Sandy Shaw (Edinburgh Univ), Einar Stefferud (NMA), and Peter Sylvester (GMD).
役に立つコメントと提案はピートカウエン(ノッティンガムUniv)、ジム・クレーギー(JNT)、クリスチャンのHuitema(Inria)、ピーター・リンチ(主要な)、ジュリアン・アニアンズ(ノッティンガムUniv)、サンディー・ショー(エディンバラUniv)、Einar Stefferud(NMA)、およびピーター・シルベスター(GMD)によってされました。
Chapter 2 -- Service Elements
第2章--Service Elements
This chapter considers the services offered across a gateway built according to this specification. It gives a view of the functionality provided by such a gateway for communication with users in the opposite domain. This chapter considers service mappings in the context of SINGLE transfers only, and not repeated mappings through multiple gateways.
本章はこの仕様通りに建設されたゲートウェイの向こう側に提供されたサービスを考えます。 それはそのようなゲートウェイによって反対のドメインのユーザとのコミュニケーションに提供された機能性に関する意見を与えます。 本章は、複数のゲートウェイを通してサービスが繰り返されたマッピングではなく、SINGLE転送だけの文脈のマッピングであると考えます。
2.1. The Notion of Service Across a Gateway
2.1. ゲートウェイの向こう側のサービスの概念
RFC 822 and X.400 provide a number of services to the end user. This chapter describes the extent to which each service can be supported across an X.400 <-> RFC 822 gateway. The cases considered are single transfers across such a gateway, although the problems of multiple crossings are noted where appropriate.
RFC822とX.400はエンドユーザに対する多くのサービスを提供します。 本章はX.400<->RFC822ゲートウェイの向こう側に各サービスを支持できる範囲について説明します。 多系交雑の問題は適切であるところで有名ですが、考えられたケースはそのようなゲートウェイの向こう側の単一の転送です。
2.1.1. Origination of Messages
2.1.1. メッセージの創作
When a user originates a message, a number of services are available. Some of these imply actions (e.g., delivery to a recipient), and some are insertion of known data (e.g., specification of a subject field). This chapter describes, for each offered service, to what extent it is supported for a recipient accessed through a gateway. There are three levels of support:
ユーザがメッセージを溯源するとき、多くのサービスが利用可能です。 これらの或るものは動作(例えば、受取人への配送)を含意します、そして、何かが知られているデータ(例えば、対象の分野の仕様)の挿入です。 本章は、各提供サービスのためにそれがゲートウェイを通してアクセスされた受取人のためにどんな範囲に支持されるかを説明します。 サポートの3つのレベルがあります:
Supported
The corresponding protocol elements map well, and so the
service can be fully provided.
よく、サービスを完全に提供できるように対応するプロトコル要素地図をサポートしました。
Kille [Page 10] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[10ページ]RFC1138
Not Supported
The service cannot be provided, as there is a complete
mismatch.
完全なミスマッチがあるときサービスを提供できないSupportedでない。
Partial Support
The service can be partially fulfilled.
部分的なSupport、サービスが部分的に実現できます。
In the first two cases, the service is simply marked as "Supported" or "Not Supported". Some explanation may be given if there are additional implications, or the (non) support is not intuitive. For partial support, the level of partial support is summarised. Where partial support is good, this will be described by a phrase such as "Supported by use of.....". A common case of this is where the service is mapped onto a non- standard service on the other side of the gateway, and this would have lead to support if it had been a standard service. In many cases, this is equivalent to support. For partial support, an indication of the mechanism is given, in order to give a feel for the level of support provided. Note that this is not a replacement for Chapter 5, where the mapping is fully specified.
最初の2つの場合では、サービスは「支持される」か、または「支持されない」ように単にマークされます。 または、追加含意があれば何らかの説明をするかもしれない、(非、)、サポートは直感的ではありません。 部分的なサポートにおいて、部分的なサポートのレベルについて略言します。 部分的なサポートがいいぞ、これが句によって説明されるということであるところ、「使用で支持される、」、… このよくある例はサービスがゲートウェイの反対側の上で非標準のサービスに写像されるところです、そして、これには、支持するリードがそれが標準のサービスであったならあるでしょう。 多くの場合、これは、支持するために同等です。 部分的なサポートにおいて、メカニズムのしるしを与えます、提供されたサポート水準の感じを与えるために。 これが第5章への交換でないことに注意してください。(そこでは、マッピングが完全に指定されます)。
If a service is described as supported, this implies:
サービスが支持されるように説明されるなら、これは以下を含意します。
- Semantic correspondence.
- 意味通信。
- No (significant) loss of information.
- 情報の(重要)の損失がありません。
- Any actions required by the service element.
- どんな動作もサービス要素が必要です。
An example of a service gaining full support: If an RFC 822 originator specifies a Subject: field, this is considered to be supported, as an X.400 recipient will get a subject indication.
全面的な支援を獲得するサービスの例: RFC822創始者がSubject:を指定するなら 分野、X.400受取人が対象の指示を得るとき、これが支持されると考えられます。
All RFC 822 services are supported or partially supported for origination. The implications of non-supported X.400 services is described under X.400.
すべてのRFC822サービスが、支持されるか、または創作のために部分的に支持されます。 非サポートされたX.400サービスの含意はX.400の下で説明されます。
2.1.2. Reception of Messages
2.1.2. メッセージのレセプション
For reception, the list of service elements required to support this mapping is specified. This is really an indication of what a recipient might expect to see in a message which has been remotely originated.
レセプションとして、要素がこのマッピングを支持するのを必要としたサービスのリストは指定されます。 これは本当に受取人が離れて溯源されたメッセージで見ると予想するかもしれないもののしるしです。
2.2. RFC 822
2.2. RFC822
RFC 822 does not explicitly define service elements, as distinct from protocol elements. However, all of the RFC 822 header fields, with the exception of trace, can be regarded as corresponding to implicit
RFC822は明らかにサービス要素をプロトコル要素と異なると定義しません。 しかしながら、跡以外のRFC822ヘッダーフィールドのすべてを暗黙に対応すると見なすことができます。
Kille [Page 11] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[11ページ]RFC1138
RFC 822 service elements.
RFC822は要素を調整します。
2.2.1. Origination in RFC 822
2.2.1. RFC822での創作
A mechanism of mapping, used in several cases, is to map the RFC 822 header into a heading extension in the IPM (InterPersonal Message). This can be regarded as partial support, as it makes the information available to any X.400 implementations which are interested in these services. Communities which require significant RFC 822 interworking should require that their X.400 User Agents are able to display these heading extensions. Support for the various service elements (headers) is now listed.
いろいろな場合に使用されるマッピングのメカニズムはIPM(InterPersonal Message)の見出し拡張子にRFC822ヘッダーを写像することです。 これを部分的なサポートと見なすことができます、情報をこれらのサービスに興味を持っているどんなX.400実現にも利用可能にするとき。 重要なRFC822の織り込むことを必要とする共同体は、彼らのX.400 Userエージェントがこれらの見出し拡張子を表示できるのを必要とするべきです。 様々なサービス要素(ヘッダー)のサポートは現在、記載されます。
Date:
Supported.
日付: 支持にされる。
From:
Supported. For messages where there is also a sender field,
the mapping is to "Authorising Users Indication", which has
subtly different semantics to the general RFC 822 usage of
From:.
From: 支持にされる。 また、送付者分野があって、「ユーザ指示を認可します」にはマッピングがある(From:の一般的なRFC822用法にかすかに異なった意味論を持っています)メッセージのために。
Sender:
Supported.
送付者: 支持にされる。
Reply-To:
Supported.
Reply-To 支持にされる。
To: Supported.
To: 支持にされる。
Cc: Supported.
Cc: 支持にされる。
Bcc: Supported.
Bcc: 支持にされる。
Message-Id:
Supported.
メッセージイド: 支持にされる。
In-Reply-To:
Supported, for a single reference. Where multiple
references are given, partial support is given by mapping to
"Cross Referencing Indication". This gives similar
semantics.
以下に対して ただ一つの参照のために、支持されます。 複数の参照が与えられているところに、マッピングで部分的なサポートを与えて、「指示に参照をつけて、交差します」。 これは同様の意味論を与えます。
References:
Supported.
参照: 支持にされる。
Keywords:
Supported by use of a heading extension.
キーワード: 見出し拡張子の使用で、支持されます。
Kille [Page 12] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[12ページ]RFC1138
Subject:
Supported.
Subject: 支持にされる。
Comments:
Supported by use of an extra body part.
コメント: 余分な身体の部分の使用で、支持されます。
Encrypted:
Supported by use of a heading extension.
コード化される: 見出し拡張子の使用で、支持されます。
Resent-*
Supported by use of a heading extension. Note that
addresses in these fields are mapped onto text, and so are
not accessible to the X.400 user as addresses. In
principle, fuller support would be possible by mapping onto
a forwarded IP Message, but this is not suggested.
*に憤慨する、見出し拡張子の使用で、支持されます。 X.400ユーザにとって、これらの分野のアドレスがアドレスとして理解できないようにテキストに写像されることに注意してください。 原則として、よりふくよかなサポートは進められたIPにMessageを写像することによって、可能でしょうが、これは示されません。
Other Fields
In particular X-* fields, and "illegal" fields in common
usage (e.g., "Fruit-of-the-day:") are supported by use of
heading extensions.
フィールズIn特定のX-*がさばいて、「不法入国者」が一般的な用法でさばく(例えば、「1日に実を結ばせてください」)もう一方は見出し拡張子の使用で支持されます。
2.2.2. Reception by RFC 822
2.2.2. RFC822によるレセプション
This considers reception by an RFC 822 User Agent of a message originated in an X.400 system and transferred across a gateway. The following standard services (headers) may be present in such a message:
これは、メッセージのRFC822UserエージェントによるレセプションがX.400システムで起こって、ゲートウェイの向こう側に移されたと考えます。 以下の標準のサービス(ヘッダー)はそのようなメッセージに存在しているかもしれません:
Date:
日付:
From:
From:
Sender:
送付者:
Reply-To:
Reply-To
To:
To:
Cc:
Cc:
Bcc:
Bcc:
Message-Id:
メッセージイド:
In-Reply-To:
以下に対して
References:
参照:
Kille [Page 13] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[13ページ]RFC1138
Subject:
Subject:
The following non-standard services (headers) may be present. These are defined in more detail in Chapter 5 (5.3.4, 5.3.6, 5.3.7):
以下の標準的でないサービス(ヘッダー)は存在しているかもしれません。 これらがさらに詳細に第5章で定義される、(5.3 .4 5.3 .6、5.3、.7):
Autoforwarded:
Autoforwardedしました:
Content-Identifier:
満足している識別子:
Conversion:
変換:
Conversion-With-Loss:
損失との変換:
Delivery-Date:
納品日:
Discarded-X400-IPMS-Extensions:
捨てられたX400-IPMS拡張子:
Discarded-X400-MTS-Extensions:
捨てられたX400-MTS拡張子:
DL-Expansion-History:
dl拡大歴史:
Deferred-Delivery:
延期した納入:
Expiry-Date:
有効期限日:
Importance:
重要性:
Incomplete-Copy:
不完全なコピー:
Language:
言語:
Latest-Delivery-Time:
最新の納期:
Message-Type:
メッセージタイプ:
Obsoletes:
時代遅れにします:
Original-Encoded-Information-Types:
オリジナルは情報タイプをコード化しました:
Originator-Return-Address:
創始者返送先:
Priority:
優先権:
Redirection-History:
リダイレクション歴史:
Reply-By:
返答してください:
Requested-Delivery-Method:
要求された発送方法:
Kille [Page 14] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[14ページ]RFC1138
Sensitivity:
感度:
X400-Content-Type:
X400-コンテントタイプ:
X400-MTS-Identifier:
X400-MTS-識別子:
X400-Originator:
X400-創始者:
X400-Received:
X400が受け取られている:
X400-Recipients:
X400-受取人:
2.3. X.400
2.3. X.400
2.3.1. Origination in X.400
2.3.1. X.400での創作
When mapping services from X.400 to RFC 822 which are not supported by RFC 822, new RFC 822 headers are defined. It is intended that these fields will be registered, and that co-operating RFC 822 systems may use them. Where these new fields are used, and no system action is implied, the service can be regarded as being partially supported. Chapter 5 describes how to map X.400 services onto these new headers. Other elements are provided, in part, by the gateway as they cannot be provided by RFC 822.
サービスを写像するとき、X.400からRFC822、新しいRFCによって支持されないRFC822まで822個のヘッダーが定義されます。 これらの分野が示されて、協力RFC822システムがそれらを使用するかもしれないことを意図します。 これらの新しい分野が使用されていて、システム動作が全く含意されないところでは、サービスを部分的に支持されると見なすことができます。 第5章はこれらの新しいヘッダーにX.400サービスを写像する方法を説明します。 RFC822がそれらを提供できないようにゲートウェイは他の要素を一部提供します。
Some service elements are marked N/A (not applicable). There are five cases, which are marked with different comments:
いくつかのサービス要素がN/A(適切でない)であるとマークされます。 5つのケースがあります:(ケースは異なったコメントでマークされます)。
N/A (local)
These elements are only applicable to User Agent / Message
Transfer Agent interaction and so they cannot apply to RFC
822 recipients.
N/、これらの(地方の)要素が単にUserエージェント/メッセージTransferエージェント相互作用に適切であるので、それらは822人の受取人をRFCに適用できません。
N/A (PDAU)
These service elements are only applicable where the
recipient is reached by use of a Physical Delivery Access
Unit (PDAU), and so do not need to be mapped by the gateway.
Physical Delivery Access Unit(PDAU)の使用で受取人が連絡されているところで適切であるだけであるので、ゲートウェイによってこれらのサービス要素のN/A(PDAU)は写像される必要はありません。
N/A (reception)
These services are only applicable for reception.
レセプションだけに、(レセプション)これらが修理するN/は適切です。
N/A (prior)
If requested, this service must be performed prior to the
gateway.
N/A、(優先的に) 要求されるなら、ゲートウェイの前でこのサービスを実行しなければなりません。
N/A (MS)
These services are only applicable to Message Store (i.e., a
local service).
N、これらが修理する/A(MS)は単にMessageストア(すなわち、ローカル・サービス)に適切です。
Kille [Page 15] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[15ページ]RFC1138
Finally, some service elements are not supported. In particular, the new security services are not mapped onto RFC 822. Unless otherwise indicated, the behaviour of service elements marked as not supported will depend on the criticality marking supplied by the user. If the element is marked as critical for transfer or delivery, a non- delivery notification will be generated. Otherwise, the service request will be ignored.
最終的に、いくつかのサービス要素は支えられません。 特に、新しいセキュリティー・サービスはRFC822に写像されません。 別の方法で示されないと、支持されないようにマークされたサービス要素のふるまいはユーザによって供給された臨界マークであることによるでしょう。 要素が転送か配送に重要であるとしてマークされると、非配送している通知は発生するでしょう。 さもなければ、サービスのリクエストは無視されるでしょう。
2.3.1.1. Basic Interpersonal Messaging Service
2.3.1.1. 基本的な個人間のメッセージサービス
These are the mandatory IPM services as listed in Section 19.8 of X.400 / ISO/IEC 10021-1, listed here in the order given. Section 19.8 has cross references to short definitions of each service.
これらはX.400/ISO/IECのセクション19.8に10021-1に記載されているように義務的なIPMサービスです、ここ、与えられたオーダーでは、記載されています。 セクション19.8はそれぞれのサービスの短い定義に相互参照を持っています。
Access management
N/A (local).
(地方)で管理N/Aにアクセスしてください。
Content Type Indication
Supported by a new RFC 822 header (Content-Type:).
新しいRFC822ヘッダーによる内容Type Indication Supported、(コンテントタイプ:、)
Converted Indication
Supported by a new RFC 822 header (X400-Received:).
新しいRFC822ヘッダー(X400が受け取られている:)でIndication Supportedを変換しました。
Delivery Time Stamp Indication
N/A (reception).
配送タイムスタンプ指示、なし、(レセプション。)
IP Message Identification
Supported.
識別が支持したIPメッセージ。
Message Identification
Supported, by use of a new RFC 822 header
(X400-MTS-Identifier). This new header is required, as
X.400 has two message-ids whereas RFC 822 has only one (see
previous service).
新しいRFC822ヘッダー(X400-MTS-識別子)の使用によるメッセージIdentification Supported。 X.400に2つのメッセージイドがあるとき、この新しいヘッダーが必要ですが、RFC822には、1つしかありません(前のサービスを見てください)。
Non-delivery Notification
Not supported, although in general an RFC 822 system will
return error reports by use of IP messages. In other
service elements, this pragmatic result can be treated as
effective support of this service element.
RFC822システムがIPメッセージの使用でエラー・レポートを一般に返しますが、支持された非配送Notification Not。 他のサービス要素では、このサービス要素の有効なサポートとしてこの実践的な結果を扱うことができます。
Original Encoded Information Types Indication
Supported as a new RFC 822 header
(Original-Encoded-Information-Types:).
新しいRFC822ヘッダー(オリジナルは情報タイプをコード化した:)としてのオリジナルのEncoded情報Types Indication Supported。
Submission Time Stamp Indication
Supported.
タイムスタンプ指示が支持した服従。
Kille [Page 16] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[16ページ]RFC1138
Typed Body
Some types supported. IA5 is fully supported.
ForwardedIPMessage is supported, with some loss of
information. Other types get some measure of support,
dependent on X.400 facilities for conversion to IA5. This
will only be done where content conversion is not
prohibited.
タイプされたBody Someは支持されていた状態でタイプします。 IA5は完全に支持されます。 ForwardedIPMessageは情報のいくらかの損失で支持されます。 他のタイプはIA5への変換において、X.400施設に依存するサポートの何らかの手段を得ます。 内容変換が禁止されていないところでこれをするだけでしょう。
User Capabilities Registration
N/A (local).
ユーザ能力登録、なし、(ローカル。)
2.3.1.2. IPM Service Optional User Facilities
2.3.1.2. IPMのサービスの任意の利用者機能
This section describes support for the optional (user selectable) IPM services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1, listed here in the order given. Section 19.9 has cross references to short definitions of each service.
このセクションはX.400/ISO/IECのセクション19.9に10021- 1に記載されているように任意(ユーザ選択可能な)のIPMサービスのサポートについて説明します、ここ、与えられたオーダーでは、記載されています。 セクション19.9はそれぞれのサービスの短い定義に相互参照を持っています。
Additional Physical Rendition
N/A (PDAU).
なし、追加物理的な表現(PDAU。)
Alternate Recipient Allowed
Not supported. There is no RFC 822 service equivalent to
prohibition of alternate recipient assignment (e.g., an RFC
822 system may freely send an undeliverable message to a
local postmaster). Thus, the gateway cannot prevent
assignment of alternative recipients on the RFC 822 side.
This service really means giving the user control as to
whether or not an alternate recipient is allowed. This
specification requires transfer of messages to RFC 822
irrespective of this service request, and so this service is
not supported.
支持されたRecipient Allowed Notを交替してください。 交互の受取人課題の禁止に同等などんなRFC822サービスもありません(例えば、RFC822システムは自由に「非-提出物」メッセージを地元の郵便局長に送るかもしれません)。 したがって、ゲートウェイはRFC822側における代替の受取人の課題を防ぐことができません。 このサービスは、本当に交互の受取人が許容されているかどうかに関してユーザ支配力を与えることを意味します。 この仕様がこのサービスのリクエストの如何にかかわらずRFC822へのメッセージの転送を必要とするので、このサービスは支持されません。
Authorising User's Indication
Supported.
支持されたユーザの指示を認可します。
Auto-forwarded Indication
Supported as new RFC 822 header (Auto-Forwarded:).
新しいRFC822ヘッダー(自動Forwarded:)としての自動進められたIndication Supported。
Basic Physical Rendition
N/A (PDAU).
なし、基本的な物理的な表現(PDAU。)
Blind Copy Recipient Indication
Supported.
指示が支持した写し受信者の目をくらましてください。
Body Part Encryption Indication
Supported by use of a new RFC 822 header
(Original-Encoded-Information-Types:), although in most
大部分で新しいRFC822ヘッダー(オリジナルは情報タイプをコード化した:)の使用によるボディーPart Encryption Indication Supported
Kille [Page 17] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[17ページ]RFC1138
cases it will not be possible to map the body part in
question.
可能であるそれがならないケースは問題の身体の部分を写像します。
Content Confidentiality
Not supported.
支持された内容Confidentiality Not。
Content Integrity
Not supported.
支持された内容Integrity Not。
Conversion Prohibition
Supported. In this case, only messages with IA5 body parts,
other body parts which contain only IA5, and Forwarded IP
Messages (subject recursively to the same restrictions),
will be mapped.
禁止が支持した変換。 この場合、IA5身体の部分がある唯一のメッセージ(IA5だけを含む他の身体の部分、およびForwarded IP Messages(同じ制限に再帰的にかける))が、写像されるでしょう。
Conversion Prohibition in Case of Loss of Information
Supported.
情報の損失の場合の禁止が支持した変換。
Counter Collection
N/A (PDAU).
なし、収集(PDAU)を打ち返してください。
Counter Collection with Advice
N/A (PDAU).
なし、アドバイス(PDAU)との収集に対抗してください。
Cross Referencing Indication
Supported.
指示が支持した参照箇所に交差してください。
Deferred Delivery
N/A (prior). This service should always be provided by the
MTS prior to the gateway. A new RFC 822 header
(Deferred-Delivery:) is provided to transfer information on
this service to the recipient.
延期した納入、なし、(優先的に。) このサービスはいつもMTSによってゲートウェイの前に提供されるはずです。 受取人に対するこのサービスの情報を移すために、新しいRFC822ヘッダー(延期された配送:)を提供します。
Deferred Delivery Cancellation
N/A (local).
延期した納入キャンセル、なし、(ローカル。)
Delivery Notification
Supported. This is performed at the gateway. Thus, a
notification is sent by the gateway to the originator. If
the 822-MTS protocol is JNT Mail, a notification may also be
sent by the recipient UA.
通知が支持した配送。 これはゲートウェイで実行されます。 したがって、ゲートウェイは通知を創始者に送ります。 また、822-MTSプロトコルがJNTメールであるなら、通知は受取人UAによって送られるかもしれません。
Delivery via Bureaufax Service
N/A (PDAU).
Bureaufax Service N/A(PDAU)を通した配送。
Designation of Recipient by Directory Name
N/A (local).
ディレクトリ名による受取人の名称、なし、(ローカル。)
Kille [Page 18] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[18ページ]RFC1138
Disclosure of Other Recipients
Supported by use of a new RFC 822 header (X400-Recipients:).
This is descriptive information for the RFC 822 recipient,
and is not reverse mappable.
新しいRFC822ヘッダーの使用によるOther Recipients Supportedの公開、(X400-受取人:、) これは、RFC822受取人にとって、描写的である情報であり、逆のmappableではありません。
DL Expansion History Indication
Supported by use of a new RFC 822 header
(DL-Expansion-History:).
新しいRFC822ヘッダー(DL拡大歴史:)の使用によるDL Expansion歴史Indication Supported。
DL Expansion Prohibited
Distribution List means MTS supported distribution list, in
the manner of X.400. This service does not exist in the RFC
822 world. RFC 822 distribution lists should be regarded as
an informal redistribution mechanism, beyond the scope of
this control. Messages will be sent to RFC 822,
irrespective of whether this service is requested.
Theoretically therefore, this service is supported, although
in practice it may appear that it is not supported.
DL Expansion Prohibited Distribution Listは、MTSがX.400の方法で発送先リストを支持したことを意味します。 このサービスはRFC822世界に存在していません。 RFC822発送先リストはこのコントロールの範囲を超えて非公式の再分配メカニズムと見なされるべきです。 このサービスが要求されているかどうかの如何にかかわらずRFC822にメッセージを送るでしょう。 理論的に、それが支持されないように実際には見えるかもしれませんが、したがって、このサービスは支持されます。
Express Mail Service
N/A (PDAU).
なし、メールサービス(PDAU)を言い表してください。
Expiry Date Indication
Supported as new RFC 822 header (Expiry-Date:). In general,
no automatic action can be expected.
新しいRFC822ヘッダー(満期日付:)としての満期Date Indication Supported。 一般に、どんな自動動作も予想できません。
Explicit Conversion
N/A (prior).
明白な変換、なし、(優先的に。)
Forwarded IP Message Indication
Supported, with some loss of information. The message is
forwarded in an RFC 822 body, and so can only be interpreted
visually.
情報のいくらかの損失はIP Message Indication Supportedを進めました。 RFC822ボディーで転送するので、目視によりメッセージを解釈できるだけです。
Grade of Delivery Selection
N/A (PDAU)
配送選択のグレード、なし。(PDAU)
Importance Indication
Supported as new RFC 822 header (Importance:).
新しいRFC822ヘッダーとしての重要性Indication Supported、(重要性:、)
Incomplete Copy Indication
Supported as new RFC 822 header (Incomplete-Copy:).
新しいRFC822ヘッダー(不完全なコピー:)としての不完全なCopy Indication Supported。
Language Indication
Supported as new RFC 822 header (Language:).
新しいRFC822ヘッダーとしての言語Indication Supported、(言語:、)
Latest Delivery Designation
Not supported. A new RFC 822 header (Latest-Delivery-Time:)
支持された最新のDelivery Designation Not。 新しいRFC822ヘッダー(最新の納期:)
Kille [Page 19] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[19ページ]RFC1138
is provided, which may be used by the recipient.
提供していて、どれが受取人によって使用されるかもしれないか。
Message Flow Confidentiality
Not supported.
Flow Confidentiality Notが支持したメッセージ。
Message Origin Authentication
N/A (reception).
メッセージ起源認証、なし、(レセプション。)
Message Security Labelling
Not supported.
Security Labelling Notが支持したメッセージ。
Message Sequence Integrity
Not supported.
Sequence Integrity Notが支持したメッセージ。
Multi-Destination Delivery
Supported.
配送が支持したマルチの目的地。
Multi-part Body
Supported, with some loss of information, in that the
structuring cannot be formalised in RFC 822.
RFC822で構造を正式にすることができないので情報のいくらかの損失を伴う複合Body Supported。
Non Receipt Notification Request
Not supported.
支持された非Receipt Notification Request Not。
Non Repudiation of Delivery
Not supported.
支持されたDelivery Notの非Repudiation。
Non Repudiation of Origin
N/A (reception).
起源の非拒否、なし、(レセプション。)
Non Repudiation of Submission
N/A (local).
服従の非拒否、なし、(ローカル。)
Obsoleting Indication
Supported as new RFC 822 header (Obsoletes:).
新しいRFC822ヘッダー(時代遅れにする:)としてIndication Supportedを時代遅れにします。
Ordinary Mail
N/A (PDAU).
なし、普通郵便(PDAU。)
Originator Indication
Supported.
指示が支持した創始者。
Originator Requested Alternate Recipient
Not supported, but is placed as comment next to address
(X400-Recipients:).
支持しますが、創始者Requested Alternate Recipient Notが次に記述するためにコメントとして置かれる、(X400-受取人:、)
Physical Delivery Notification by MHS
N/A (PDAU).
MHSによる物理的な配送通知、なし、(PDAU。)
Kille [Page 20] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[20ページ]RFC1138
Physical Delivery Notification by PDS
N/A (PDAU).
PDSによる物理的な配送通知、なし、(PDAU。)
Physical Forwarding Allowed
Supported by use of a comment in a new RFC 822 header
(X400-Recipients:), associated with the recipient in
question.
新しいRFC822ヘッダーにおけるコメントの使用による物理的なForwarding Allowed Supported、(X400-受取人:、)、受取人がはっきりしていなく、関連しています。
Physical Forwarding Prohibited
Supported by use of a comment in a new RFC 822 header
(X400-Recipients:), associated with the recipient in
question.
新しいRFC822ヘッダーにおけるコメントの使用による物理的なForwarding Prohibited Supported、(X400-受取人:、)、受取人がはっきりしていなく、関連しています。
Prevention of Non-delivery notification
Supported, as delivery notifications cannot be generated by
RFC 822. In practice, errors will be returned as IP
Messages, and so this service may appear not to be supported
(see Non-delivery Notification).
通知が発生できない配送としてのNon-配送通知Supported RFC822の防止。 実際には、誤りがIP Messagesとして返されるので、このサービスは支持されないように見えるかもしれません(Non-配送Notificationを見てください)。
Primary and Copy Recipients Indication
Supported.
指示が支持した予備選挙と写し受信者。
Probe
Supported at the gateway (i.e., the gateway services the
probe).
ゲートウェイでSupportedを調べてください、(すなわち、ゲートウェイサービス、徹底的調査)
Probe Origin Authentication
N/A (reception).
起源認証を調べてください、なし、(レセプション。)
Proof of Delivery
Not supported.
支持されたDelivery Notの証拠。
Proof of Submission
N/A (local).
服従の証拠、なし、(ローカル。)
Receipt Notification Request Indication
Not supported.
支持されたNotification Request Indication Notを領収書を出させてください。
Redirection Allowed by Originator
Redirection means MTS supported redirection, in the manner
of X.400. This service does not exist in the RFC 822 world.
RFC 822 redirection (e.g., aliasing) should be regarded as
an informal redirection mechanism, beyond the scope of this
control. Messages will be sent to RFC 822, irrespective of
whether this service is requested. Theoretically therefore,
this service is supported, although in practice it may
appear that it is not supported.
Originator RedirectionによるリダイレクションAllowedは、MTSがX.400の方法でリダイレクションを支持したことを意味します。 このサービスはRFC822世界に存在していません。 RFC822リダイレクション(例えば、エイリアシング)はこのコントロールの範囲を超えて非公式のリダイレクションメカニズムと見なされるべきです。 このサービスが要求されているかどうかの如何にかかわらずRFC822にメッセージを送るでしょう。 理論的に、それが支持されないように実際には見えるかもしれませんが、したがって、このサービスは支持されます。
Kille [Page 21] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[21ページ]RFC1138
Registered Mail
N/A (PDAU).
なし、書留(PDAU。)
Registered Mail to Addressee in Person
N/A (PDAU).
自分で、なし、受け取り人(PDAU)への書留。
Reply Request Indication
Supported as comment next to address.
アドレスの横のコメントとしての回答Request Indication Supported。
Replying IP Message Indication
Supported.
IPメッセージ指示が支持した返答。
Report Origin Authentication
N/A (reception).
起源認証を報告してください、なし、(レセプション。)
Request for Forwarding Address
N/A (PDAU).
フォーワーディング・アドレスには、なしよう要求してください(PDAU)。
Requested Delivery Method
N/A (local). The services required must be dealt with at
submission time. Any such request is made available through
the gateway by use of a comment associated with the
recipient in question.
発送方法を要求する、なし、(ローカル。) 服従時に必要であるサービスに対処しなければなりません。 どんなそのような要求もゲートウェイを通して関連しているはっきりしていない受取人でコメントの使用で利用可能にします。
Return of Content
In principle, this is N/A, as non-delivery notifications are
not supported. In practice, most RFC 822 systems will
return part or all of the content along with the IP Message
indicating an error (see Non-delivery Notification).
Content In原則に戻ってください、そして、非配送通知が支持されないとき、これはN/Aです。 実際には、ほとんどのRFC822システムが誤りを示すIP Messageに伴う内容の部分かすべてを返すでしょう(Non-配送Notificationを見てください)。
Sensitivity Indication
Supported as new RFC 822 header (Sensitivity:).
新しいRFC822ヘッダーとしての感度Indication Supported、(感度:、)
Special Delivery
N/A (PDAU).
なし、速達郵便(PDAU。)
Stored Message Deletion
N/A (MS).
なし、メッセージ削除(MS)を格納しました。
Stored Message Fetching
N/A (MS).
なし、(MS)をとって来ながら、メッセージを格納しました。
Stored Message Listing
N/A (MS).
なしと記載するメッセージ(MS)を格納しました。
Stored Message Summary
N/A (MS).
なし、メッセージ概要(MS)を格納しました。
Kille [Page 22] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[22ページ]RFC1138
Subject Indication
Supported.
支持された対象の指示。
Undeliverable Mail with Return of Physical Message
N/A (PDAU).
Undeliverableは物理メッセージの復帰でなし、(PDAU)に郵送します。
Use of Distribution List
In principle this applies only to X.400 supported
distribution lists (see DL Expansion Prohibited).
Theoretically, this service is N/A (prior). In practice,
because of informal RFC 822 lists, this service can be
regarded as supported.
これがX.400だけに適用するDistribution List In原則の使用は発送先リストを支持しました(DL Expansion Prohibitedを見てください)。 理論的に、このサービスはN/A(優先的である)です。 非公式のRFC822リストのために、実際には、支持されるようにこのサービスを見なすことができます。
2.3.2. Reception by X.400
2.3.2. X.400によるレセプション
2.3.2.1. Standard Mandatory Services
2.3.2.1. 標準の義務的なサービス
The following standard IPM mandatory user facilities may be required for reception of RFC 822 originated mail by an X.400 UA.
利用者機能がRFC822のレセプションに必要であるかもしれないことが義務的な以下の標準のIPMはX.400 UAによるメールを溯源しました。
Content Type Indication
満足しているタイプ指示
Delivery Time Stamp Indication
配送タイムスタンプ指示
IP Message Identification
IPメッセージ識別
Message Identification
メッセージ識別
Non-delivery Notification
非配送通知
Original Encoded Information Types Indication
オリジナルのコード化された情報は指示をタイプします。
Submission Time Stamp Indication
服従タイムスタンプ指示
Typed Body
タイプされたボディー
2.3.2.2. Standard Optional Services
2.3.2.2. 標準の任意のサービス
The following standard IPM optional user facilities may be required for reception of RFC 822 originated mail by an X.400 UA.
以下の標準のIPM任意の利用者機能がX.400 UAによるRFC822の溯源されたメールのレセプションに必要であるかもしれません。
Authorising User's Indication
ユーザの指示を認可します。
Blind Copy Recipient Indication
盲目の写し受信者指示
Cross Referencing Indication
指示に参照をつけて、交差してください。
Originator Indication
創始者指示
Kille [Page 23] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[23ページ]RFC1138
Primary and Copy Recipients Indication
予備選挙と写し受信者指示
Replying IP Message Indication
返答しているIPメッセージ指示
Subject Indication
対象の指示
2.3.2.3. New Services
2.3.2.3. 新種業務
A new service "RFC 822 Header Field" is defined using the extension facilities. This allows for any RFC 822 header field to be represented. It may be present in RFC 822 originated messages, which are received by an X.400 UA.
新しいサービス「RFC822ヘッダーフィールド」は、拡大施設を使用することで定義されます。 これは、どんなRFC822ヘッダーフィールドも表されるのを許容します。 それはRFC822の溯源されたメッセージに存在しているかもしれません。(メッセージはX.400 UAによって受け取られます)。
Chapter 3 -- Basic Mappings
第3章--基本のマッピング
3.1. Notation
3.1. 記法
The X.400 protocols are encoded in a structured manner according to ASN.1, whereas RFC 822 is text encoded. To define a detailed mapping, it is necessary to refer to detailed protocol elements in each format. A notation to achieve this is described in this section.
ASN.1によると、X.400プロトコルは構造化された方法でコード化されますが、RFC822はコード化されたテキストです。 詳細なマッピングを定義するために、各形式で詳細なプロトコル要素を示すのが必要です。 これを達成する記法はこのセクションで説明されます。
3.1.1. RFC 822
3.1.1. RFC822
Structured text is defined according to the Extended Backus Naur Form (EBNF) defined in Section 2 of RFC 822 [Crocker82a]. In the EBNF definitions used in this specification, the syntax rules given in Appendix D of RFC 822 are assumed. When these EBNF tokens are referred to outside an EBNF definition, they are identified by the string "822." appended to the beginning of the string (e.g., 822.addr-spec). Additional syntax rules, to be used throughout this specification, are defined in this chapter.
RFC822[Crocker82a]のセクション2で定義されたExtendedバッカスナウアForm(EBNF)に従って、構造化されたテキストは定義されます。 この仕様で使用されるEBNF定義では、RFC822のAppendix Dで与えられたシンタックス・ルールは想定されます。 EBNF定義の外でこれらのEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、822.addr-仕様)にされるのであるストリング「822」で特定されます。 追加シンタックス・ルールは、この仕様中で使用されるために本章で定義されます。
The EBNF is used in two ways.
EBNFは2つの方法で使用されます。
1. To describe components of RFC 822 messages (or of 822-MTS
components). In this case, the lexical analysis defined in
Section 3 of RFC 822 should be used. When these new EBNF
tokens are referred to outside an EBNF definition, they are
identified by the string "EBNF." appended to the beginning
of the string (e.g., EBNF.bilateral-info).
1. RFC822メッセージ(または822-MTSの部品について)の成分について説明するために。 この場合、RFC822のセクション3で定義された字句解析は使用されるべきです。 EBNF定義の外でこれらの新しいEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、EBNF.bilateral-インフォメーション)にされるのであるストリング"EBNF"によって特定されます。
2. To describe the structure of IA5 or ASCII information not in
an RFC 822 message. In these cases, tokens will either be
self delimiting, or be delimited by self delimiting tokens.
Comments and LWSP are not used as delimiters.
2. RFC822メッセージでないところのIA5かASCII情報の構造について説明するために。 これらの場合では、象徴は、自己の区切りである、または象徴を区切る自己によって区切られるでしょう。 コメントとLWSPはデリミタとして使用されません。
Kille [Page 24] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[24ページ]RFC1138
3.1.2. ASN.1
3.1.2. ASN.1
An element is referred to with the following syntax, defined in EBNF:
要素はEBNFで定義された以下の構文で示されます:
element = service "." definition *( "." definition )
service = "IPMS" / "MTS" / "MTA"
definition = identifier / context
identifier = ALPHA *< ALPHA or DIGIT or "-" >
context = "[" 1*DIGIT "]"
「要素=サービス」 」 定義*(「.」 定義)サービスは識別子/文脈識別子=アルファー*<「IPMS」/「MTS」/"MTA"定義=アルファーか「[「1*ケタ」]」というケタか「-」>文脈=と等しいです。
The EBNF.service keys are shorthand for the following service specifications:
EBNF.serviceキーは以下のサービス仕様のための速記です:
IPMS IPMSInformationObjects defined in Annex E of X.420 / ISO
10021-7.
IPMS IPMSInformationObjectsはAnnexでX.420 / ISO10021-7のEを定義しました。
MTS MTSAbstractService defined in Section 9 of X.411 / ISO
10021-4.
X.411 / ISO10021-4のセクション9で定義されたMTS MTSAbstractService。
MTA MTAAbstractService defined in Section 13 of X.411 / ISO
10021-4.
X.411 / ISO10021-4のセクション13で定義されたMTA MTAAbstractService。
The first EBNF.identifier identifies a type or value key in the context of the defined service specification. Subsequent EBNF.identifiers identify a value label or type in the context of the first identifier (SET or SEQUENCE). EBNF.context indicates a context tag, and is used where there is no label or type to uniquely identify a component. The special EBNF.identifier keyword "value" is used to denote an element of a sequence.
最初のEBNF.identifierは定義されたサービス仕様の文脈で主要なタイプか値を特定します。 その後のEBNF.identifiersは値のラベルを特定するか、または最初の識別子(SETかSEQUENCE)の文脈をタイプします。 EBNF.contextは文脈タグを示して、唯一コンポーネントを特定するためにラベルなしかタイプがあるところで使用されます。 「値」という特別なEBNF.identifierキーワードは、系列の原理を指示するのに使用されます。
For example, IPMS.Heading.subject defines the subject element of the IPMS heading. The same syntax is also used to refer to element values. For example, MTS.EncodedInformationTypes.[0].g3Fax refers to a value of MTS.EncodedInformationTypes.[0].
例えば、IPMS.Heading.subjectはIPMS見出しの対象の要素を定義します。 また、同じ構文は、要素値について言及するのに使用されます。 例えば、MTS.EncodedInformationTypes.[0].g3FaxはMTS.EncodedInformationTypes.[0]の値について言及します。
3.2. ASCII and IA5
3.2. ASCIIとIA5
A gateway will interpret all IA5 as ASCII. Thus, mapping between these forms is conceptual.
ゲートウェイはASCIIとしてすべてのIA5を解釈するでしょう。 したがって、これらのフォームの間のマッピングは概念的です。
3.3. Standard Types
3.3. 標準体型
There is a need to convert between ASCII text, and some of the types defined in ASN.1 [CCITT/ISO88d]. For each case, an EBNF syntax definition is given, for use in all of this specification, which leads to a mapping between ASN.1, and an EBNF construct.
ASCIIテキストと、ASN.1[CCITT/ISO88d]で定義されたタイプの何人かの間で変換する必要があります。 各ケースにおいて、EBNF構文定義を与えます、ASN.1と、EBNF構造物の間のマッピングにつながるこの仕様のすべてにおける使用のために。
All EBNF syntax definitions of ASN.1 types are in lower case, whereas
ところが、小文字にはASN.1タイプのすべてのEBNF構文定義があります。
Kille [Page 25] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[25ページ]RFC1138
ASN.1 types are referred to with the first letter in upper case. Except as noted, all mappings are symmetrical.
大文字における最初の手紙でASN.1タイプは言及されます。 注意されるのを除いて、すべてのマッピングが対称です。
3.3.1. Boolean
3.3.1. 論理演算子
Boolean is encoded as:
論理演算子は以下としてコード化されます。
boolean = "TRUE" / "FALSE"
論理演算子=「本当」/「誤っています」。
3.3.2. NumericString
3.3.2. NumericString
NumericString is encoded as:
NumericStringは以下としてコード化されます。
numericstring = *DIGIT
numericstringは*DIGITと等しいです。
3.3.3. PrintableString
3.3.3. PrintableString
PrintableString is a restricted IA5String defined as:
PrintableStringは以下と定義された制限されたIA5Stringです。
printablestring = *( ps-char )
ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
ps-delim = "(" / ")"
ps-char = ps-delim / ps-restricted-char
printablestringがpsが炭を制限している*(ps-炭)=1DIGIT / 1ALPHA /と等しい、「「/「'「/「+」/」」、/「-」/」'、」 / "/" / ":" ps-delim / psが炭を制限していた状態で、/「=」/“?" ps-delimは「(「/」)」ps-炭の=と等しいです。
This can be used to represent real printable strings in EBNF.
EBNFに全く印刷可能なストリングを表すのにこれを使用できます。
3.3.4. T.61String
3.3.4. T.61String
In cases where T.61 strings are only used for conveying human interpreted information, the aim of a mapping should be to render the characters appropriately in the remote character set, rather than to maximise reversibility. For these cases, the mappings to IA5 defined in CCITT Recommendation X.408 (1988) should be used [CCITT/ISO88a]. These will then be encoded in ASCII.
T.61ストリングが人間の解釈された情報を伝えるのに使用されるだけである場合では、マッピングの目的はリバーシブルを最大にするというよりむしろ適切にキャラクタをリモート文字の組にすることであるべきです。 これらのケースのために、CCITT Recommendation X.408(1988)で定義されたIA5へのマッピングは使用されるべきです[CCITT/ISO88a]。 そして、これらはASCIIでコード化されるでしょう。
There is also a need to represent Teletex Strings in ASCII, for some aspects of O/R Address. For these, the following encoding is used:
O/R Addressのいくつかの局面のASCIIでTeletex Stringsを表す必要もあります。 これらに関しては、以下のコード化は使用されています:
teletex-string = *( ps-char / t61-encoded )
t61-encoded = "{" 1* t61-encoded-char "}"
t61-encoded-char = 3DIGIT
t61が炭をコード化しているテレテックスストリング=*(t61によってps-炭/コード化された)t61によってコード化された=「「1 *t61は炭をコード化」だった」=3DIGIT
Common characters are mapped simply. Other octets are mapped using a quoting mechanism similar to the printable string mechanism. Each octet is represented as 3 decimal digits.
一般的なキャラクタは単に写像されます。 他の八重奏は、印刷可能なストリングメカニズムと同様の引用メカニズムを使用することで写像されます。 各八重奏は3つの10進数字として表されます。
There are a number of places where a string may have a Teletex and/or
そして/または多くの場所がストリングがTeletexを持っているかもしれないところにある。
Kille [Page 26] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[26ページ]RFC1138
Printable String representation. The following BNF is used to represent this.
印刷可能なString表現。 以下のBNFは、これを表すのに使用されます。
teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]
テレテックス、または、psする、=[printablestring][「*」テレテックスストリング]
The natural mapping is restricted to EBNF.ps-char, in order to make the full BNF easier to parse.
自然なマッピングは、完全なBNFを分析するのをより簡単にするようにEBNF.ps-焦げに制限されます。
3.3.5. UTCTime
3.3.5. UTCTime
Both UTCTime and the RFC 822 822.date-time syntax contain: Year (lowest two digits), Month, Day of Month, hour, minute, second (optional), and Timezone. 822.date-time also contains an optional day of the week, but this is redundant. Therefore a symmetrical mapping can be made between these constructs.
UTCTimeとRFC 822 822.date-時間構文の両方が以下を含んでいます。 年(最も低い2ケタ)、Month、Monthのデー、時間、分、2(任意の)番目、およびTimezone。 また、822.日付-時間は任意の曜日を含んでいますが、これは余分です。 したがって、これらの構造物の間で対称のマッピングを作ることができます。
Note:
In practice, a gateway will need to parse various illegal
variants on 822.date-time. In cases where 822.date-time
cannot be parsed, it is recommended that the derived UTCTime
is set to the value at the time of translation.
以下に注意してください。 実際には、ゲートウェイは、822.date-時に様々な不法な異形を分析する必要があるでしょう。 822.date-時間を分析できない場合では、派生しているUTCTimeが翻訳時点で値に用意ができているのは、お勧めです。
The UTCTime format which specifies the timezone offset should be used.
タイムゾーンオフセットを指定するUTCTime形式は使用されるべきです。
3.3.6. Integer
3.3.6. 整数
A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In many cases ASN.1 will enumerate Integer values or use ENUMERATED. An EBNF encoding labelled-integer is provided. When mapping from EBNF to ASN.1, only the integer value is mapped, and the associated text is discarded. When mapping from ASN.1 to EBNF, addition of an appropriate text label is strongly encouraged.
基本的なASN.1IntegerはEBNF.numericstringに写像されるでしょう。 多くの場合、ASN.1はInteger値を列挙するか、またはENUMERATEDを使用するでしょう。 ラベルされた整数をコード化するEBNFを提供します。 EBNFからASN.1まで写像するとき、整数値だけが写像されます、そして、関連テキストは捨てられます。 ASN.1からEBNFまで写像するとき、適切なテキストラベルの添加は強く奨励されます。
labelled-integer ::= [ key-string ] "(" numericstring ")"
ラベルされた整数:、:= [主要なストリング]の「(「numericstring」)」
key-string = *key-char
key-char = <a-z, A-Z, 1-9, and "-">
そして、主要なストリング=*主要な炭キー炭が<a-z、A-Z、1-9と等しい、「-、">"
3.3.7. Object Identifier
3.3.7. 物の識別子
Object identifiers are represented in a form similar to that given in ASN.1. The numbers are mandatory, to ease encoding. It is recommended that as many strings as possible are used, to facilitate user recognition.
物の識別子はASN.1で与えられたそれと同様のフォームに表されます。 数は、コード化を緩和するために義務的です。 できるだけ多くのストリングがユーザ認識を容易にするのに使用されるのは、お勧めです。
object-identifier ::= [ defined-value ] oid-comp-list
物識別子:、:= [定義された値]のoidコンピュータリスト
Kille [Page 27] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[27ページ]RFC1138
oid-comp-list ::= oid-comp oid-comp-list
| oid-comp
oidコンピュータリスト:、:= oid-コンピュータoidコンピュータリスト| oid-コンピュータ
defined-value ::= key-string
定義された値:、:= 主要なストリング
oid-comp ::= [ key-string ] "(" numericstring ")"
oid-コンピュータ:、:= [主要なストリング]の「(「numericstring」)」
3.4. Encoding ASCII in Printable String
3.4. 印刷可能なストリングのASCIIをコード化します。
Some information in RFC 822 is represented in ASCII, and needs to be mapped into X.400 elements encoded as printable string. For this reason, a mechanism to represent ASCII encoded as PrintableString is needed.
RFC822の何らかの情報が、ASCIIで表されて、印刷可能なストリングとしてコード化されたX.400要素に写像される必要があります。 この理由で、PrintableStringとしてコード化されたASCIIを表すメカニズムが必要です。
A structured subset of EBNF.printablestring is now defined. This can be used to encode ASCII in the PrintableString character set.
EBNF.printablestringの構造化された部分集合は現在、定義されます。 PrintableString文字の組のASCIIをコード化するのにこれを使用できます。
ps-encoded = *( ps-restricted-char / ps-encoded-char )
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(l)" ; "("
/ "(r)" ; ")"
/ "(" 3DIGIT ")"
psが炭をコード化しているpsによってコード化された=*(psが炭をpsの部外秘な炭/コード化している)=「(a)」。 (@) /「(p)」。 (%) /"(b)"。 (!) /"(q)"。 (") /"(u)"。 (_) /"(l)"。 「(「/"(r)"」)」/「("3DIGIT")」
The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127, and is
interpreted in decimal as the corresponding ASCII character. Special
encodings are given for: at sign (@), percent (%), exclamation
mark/bang (!), double quote ("), underscore (_), left bracket ((),
and right bracket ()). These characters, with the exception of round
brackets, are not included in PrintableString, but are common in RFC
822 addresses. The abbreviations will ease specification of RFC 822
addresses from an X.400 system. These special encodings should be
mapped in a case insensitive manner, but always be generated in lower
case.
EBNF.psが炭をコード化していたところの822.3DIGITは範囲0-127を持たなければならなくて、対応するASCII文字として小数で解釈されます。 以下のために特別なencodingsを与えます。 サイン(@)では、パーセント(%)(感嘆符/衝撃音(!))が引用文を倍にする、(「)、強調(_)ブラケット(()、および右のブラケット())に残されて、 これらのキャラクタは、丸括弧以外に、PrintableStringに含まれていませんが、RFC822アドレスで一般的です。 略語はX.400システムからのRFC822アドレスの仕様を緩和するでしょう。 これらの特別なencodingsは大文字と小文字を区別しない方法で写像されるべきですが、小文字でいつも発生してください。
A reversible mapping between PrintableString and ASCII can now be
defined. The reversibility means that some values of printable
string (containing round braces) cannot be generated from ASCII.
Therefore, this mapping must only be used in cases where the
printable strings may only be derived from ASCII (and will therefore
have a restricted domain). For example, in this specification, it is
only applied to a Domain defined attribute which will have been
generated by use of this specification and a value such as "(" would
not be possible.
現在、PrintableStringとASCIIの間のリバーシブルのマッピングを定義できます。 リバーシブルは、印刷可能なストリング(丸い支柱を含んでいる)のいくつかの値がASCIIから発生できないことを意味します。 したがって、印刷可能なストリングがASCII(そして、したがって、制限されたドメインを持つ)から得られるだけであるかもしれない場合にこのマッピングを使用するだけでよいです。 例えば、aに適用されるだけであって、Domainがどれがこの仕様の使用で発生してしまうだろうか、そして、aがそのようなものを評価する属性を定義したというこの仕様では、ことである、「(「可能でないでしょう」。
Kille [Page 28] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[28ページ]RFC1138
To encode ASCII as PrintableString, the EBNF.ps-encoded syntax is used, with all EBNF.ps-restricted-char mapped directly. All other 822.CHAR are encoded as EBNF.ps-encoded-char.
PrintableStringとしてASCIIをコード化するために、EBNF.psによってコード化された構文は、中古で、EBNF.psがすべて、炭を制限していたことで直接写像されています。 EBNF.psが炭をコード化していたとして他のすべての822.CHARがコード化されます。
To encode PrintableString as ASCII, parse PrintableString as EBNF.ps-encoded, and then reverse the previous mapping. If the PrintableString cannot be parsed, then the mapping is being applied in to an inappropriate value, and an error should be given to the procedure doing the mapping. In some cases, it may be preferable to pass the printable string through unaltered.
ASCIIとしてPrintableStringをコード化するために、EBNF.psによってコード化されるとしてPrintableStringを分析してください、そして、次に、前のマッピングを逆にしてください。 PrintableStringを分析できないなら、マッピングで不適当な値に適用しています、そして、マッピングをする手順に誤りを与えるべきです。 いくつかの場合、非変更にされるを通して印刷可能なストリングを渡すのは望ましいかもしれません。
Some examples are now given. Note the arrows which indicate asymmetrical mappings:
いくつかの例が現在、出されます。 非対称的なマッピングを示す矢に注意してください:
PrintableString ASCII
PrintableString ASCII
'a demo.' <-> 'a demo.'
foo(a)bar <-> foo@bar
(q)(u)(p)(q) <-> "_%"
(a) <-> @
(A) <-> @
(l)a(r) <-> (a)
(126) <-> ~
( -> (
(l) <-> (
'aデモ'<->'aデモ'foo(a)bar<-> foo@bar (q)(u)(p)(q)<->"_%"(a)<->@(A)<->@(l)a(r)<->(a)(126)<->~、(->( (l)<->、(
Chapter 4 -- Addressing
第4章--アドレシング
Addressing is probably the trickiest problem of an X.400 <-> RFC 822 gateway. Therefore it is given a separate chapter. This chapter, as a side effect, also defines a textual representation of an X.400 O/R Address.
アドレシングはたぶんX.400<->RFC822ゲートウェイの最も扱いにくい問題です。 したがって、別々の章にそれを与えます。 また、本章はX.400O/R Addressの原文の表現を副作用と定義します。
Initially, we consider an address in the (human) mail user sense of "what is typed at the mailsystem to reference a mail user". A basic RFC 822 address is defined by the EBNF EBNF.822-address:
初めは、私たちは「メールユーザに参照をつけるためにmailsystemでタイプされるもの」に関する(人間)のメールユーザ意味におけるアドレスを考えます。 基本的なRFC822アドレスはEBNF EBNF.822-アドレスによって定義されます:
822-address = [ route ] addr-spec
822アドレスが[ルート]addr-仕様と等しいです。
In an 822-MTS protocol, the originator and each recipient should be considered to be defined by such a construct. In an RFC 822 header, the EBNF.822-address is encapsulated in the 822.address syntax rule, and there may also be associated comments. None of this extra information has any semantics, other than to the end user.
822-MTSプロトコルでは、そのような構造物によって創始者と各受取人が定義されると考えられるべきです。 RFC822ヘッダーでは、EBNF.822-アドレスは822.address syntax規則で要約されます、そして、また、関連コメントがあるかもしれません。 このその他の情報のいずれにはも、エンドユーザ以外の少しの意味論もありません。
The basic X.400 O/R Address, used by the MTS for routing, is defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is encapsulated within
ルーティングにMTSによって使用された基本的なX.400O/R AddressはMTS.ORAddressによって定義されます。 IPMSでは、MTS.ORAddressで要約されます。
Kille [Page 29] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[29ページ]RFC1138
IPMS.ORDescriptor.
IPMS.ORDescriptor。
It can be seen that RFC 822 822.address must be mapped with IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped with MTS.ORAddress.
IPMS.ORDescriptorと共にRFC 822 822.addressを写像しなければならなくて、MTS.ORAddressと共にRFC822EBNF.822-アドレスを写像しなければならないのを見ることができます。
4.1. A textual representation of MTS.ORAddress
4.1. MTS.ORAddressの原文の表現
MTS.ORAddress is structured as a set of attribute value pairs. It is clearly necessary to be able to encode this in ASCII for gatewaying purposes. All aspects should be encoded, in order to guarantee return of error messages, and to optimise third party replies.
1セットの属性値が対にされるとき、MTS.ORAddressは構造化されます。 gatewaying目的のためのASCIIでこれをコード化できるのが明確に必要です。 全面は、エラーメッセージの復帰を保証して、第三者回答を最適化するためにコード化されるべきです。
4.2. Basic Representation
4.2. 基本的な表現
An O/R Address has a number of structured and unstructured attributes. For each unstructured attribute, a key and an encoding is specified. For structured attributes, the X.400 attribute is mapped onto one or more attribute value pairs. For domain defined attributes, each element of the sequence will be mapped onto a triple (key and two values), with each value having the same encoding. The attributes are as follows, with 1984 attributes given in the first part of the table. For each attribute, a reference is given, consisting of the relevant sections in X.402 / ISO 10021-2, and the extension identifier for 88 only attributes:
O/R Addressには、多くの構造化されて不統一な属性があります。 それぞれの不統一な属性として、キーとコード化は指定されます。 構造化された属性において、X.400属性は1属性値組以上に写像されます。 ドメインの定義された属性において、系列の各原理は三重(キーと2つの値)に写像されるでしょう、同じコード化を持っている各値で。 属性はテーブルの最初の部分で1984の属性を与えていて以下の通りです。 各属性において、88が以下を結果と考えるだけであるのでX.402 / ISO10021-2、および拡大識別子で関連セクションから成って、参照を与えます。
Attribute (Component) Key Enc Ref Id
属性(コンポーネント)キーEnc審判イド
84/88 Attributes
84/88の属性
MTS.CountryName C P 18.3.3 MTS.AdministrationDomainName ADMD P 18.3.1 MTS.PrivateDomainName PRMD P 18.3.21 MTS.NetworkAddress X121 N 18.3.7 MTS.TerminalIdentifier T-ID N 18.3.23 MTS.OrganizationName O P/T 18.3.9 MTS.OrganizationalUnitNames.value OU P/T 18.3.10 MTS.NumericUserIdentifier UA-ID N 18.3.8 MTS.PersonalName PN P/T 18.3.12 MTS.PersonalName.surname S P/T 18.3.12 MTS.PersonalName.given-name G P/T 18.3.12 MTS.PersonalName.initials I P/T 18.3.12 MTS.PersonalName .generation-qualifier GQ P/T 18.3.12 MTS.DomainDefinedAttribute.value DD P/T 18.1
18.3MTS.CountryName C P18.3.3MTS.AdministrationDomainName ADMD P18.3.1MTS.PrivateDomainName PRMD P18.3.21MTS.NetworkAddress X121N18.3.7MTS.TerminalIdentifier T-ID N18.3.23MTS.OrganizationName O P/T18.3.9MTS.OrganizationalUnitNames.value OU P/T.10MTS; 18.3NumericUserIdentifier UA-ID N18.3.8MTS.PersonalName PN P/T18.3.12MTS.PersonalName.surname S P/T18.3.12MTS.PersonalName.given-name G P/T.12MTS.PersonalName.initials、I P/T18.3.12MTS.PersonalName .generation-資格を与える人GQ P/t18.3.12MTS.DomainDefinedAttribute.value DD P/T18.1
Kille [Page 30] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[30ページ]RFC1138
88 Attributes
88の属性
MTS.CommonName CN P/T 18.3.2 1 MTS.TeletexCommonName CN P/T 18.3.2 2 MTS.TeletexOrganizationName O P/T 18.3.9 3 MTS.TeletexPersonalName PN P/T 18.3.12 4 MTS.TeletexPersonalName.surname S P/T 18.3.12 4 MTS.TeletexPersonalName.given-name G P/T 18.3.12 4 MTS.TeletexPersonalName.initials I P/T 18.3.12 4 MTS.TeletexPersonalName .generation-qualifier GQ P/T 18.3.12 4 MTS.TeletexOrganizationalUnitNames .value OU P/T 18.3.10 5 MTS.TeletexDomainDefinedAttribute .value DD P/T 18.1 6 MTS.PDSName PD-SYSTEM P 18.3.11 7 MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 MTS.PostalCode POSTCODE P 18.3.19 9 MTS.PhysicalDeliveryOfficeName PD-OFFICE P/T 18.3.14 10 MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11 MTS.ExtensionORAddressComponents PD-EXT-D P/T 18.3.4 12 MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13 MTS.PhysicalDelivery PD-O P/T 18.3.16 14 OrganizationName MTS.ExtensionPhysicalDelivery AddressComponents PD-EXT-LOC P/T 18.3.5 15 MTS.UnformattedPostalAddress PD-ADDRESS P/T 18.3.25 16 MTS.StreetAddress STREET P/T 18.3.22 17 MTS.PostOfficeBoxAddress PO-BOX P/T 18.3.18 18 MTS.PosteRestanteAddress POSTE-RESTANTE P/T 18.3.20 19 MTS.UniquePostalName PD-UNIQUE P/T 18.3.26 20 MTS.LocalPostalAttributes PD-LOCAL P/T 18.3.6 21 MTS.ExtendedNetworkAddress .e163-4-address.number NET-NUM N 18.3.7 22 MTS.ExtendedNetworkAddress .e163-4-address.sub-address NET-SUB N 18.3.7 22 MTS.ExtendedNetworkAddress .psap-address NET-PSAP X 18.3.7 22 MTS.TerminalType NET-TTYPE I 18.3.24 23
MTS.CommonName CN P/T18.3.2 1MTS.TeletexCommonName CN P/T18.3.2 2MTS.TeletexOrganizationName O P/T18.3.9 3MTS.TeletexPersonalName PN P/T18.3.12 4MTS.TeletexPersonalName.surname S P/T18.3.12 4MTS.TeletexPersonalName.given-name G P/T18.3.12 4MTS; GQ P/T18.3.12 4MTS.TeletexOrganizationalUnitNames .value OU P/T18.3.10 5MTS.TeletexDomainDefinedAttribute .value DD P/T18.1 6TeletexPersonalName.initials I P/T18.3.12 4MTS.TeletexPersonalName .generation-資格を与える人MTS.PDSName PD-システムP18.3.11 7MTS; PhysicalDeliveryCountryName PD-C P18.3.13 8MTS.PostalCode郵便番号P18.3.19 9MTS.PhysicalDeliveryOfficeName PD-オフィスT18.3.14 10MTS.PhysicalDeliveryOfficeNumber PDオフィスP/NUM P/T18.3.15 11MTS.ExtensionORAddressComponents PD-EXT-D P/T18.3.4 12MTS.PhysicalDeliveryPersonName PD-PN P/T18.3.17 13MTS.PhysicalDelivery PD-O P/T18.3.16 14OrganizationName MTS.ExtensionPhysicalDelivery AddressComponents PD-EXT-LOC P/T18.3.5 15MTS.UnformattedPostalAddress PD-アドレスP/T18.3.25 16MTS.StreetAddress通りP/T18.3.22 17MTS.PostOfficeBoxAddress PO-BOX P/T18.3.18 18MTS.PosteRestanteAddress POSTE-RESTANTE P/T18.3.20 19MTS.UniquePostalName PD-UNIQUE P/T18.3.26 20MTS.LocalPostalAttributes PD-LOCAL P/T18.3.6 21MTS.ExtendedNetworkAddress .e163-4-address.number NET-NUM N18.3.7 22MTS.ExtendedNetworkAddress .e163-4-address.sub-アドレスNET-SUB N18.3.7 22MTS.ExtendedNetworkAddress .psap-アドレスネット-PSAP X18.3.7 22MTS.TerminalTypeネット-TTYPE I18.3.24 23
The following keys identify different EBNF encodings, which are associated with the ASCII representation of MTS.ORAddress.
以下のキーは異なったEBNF encodingsを特定します。(EBNF encodingsはMTS.ORAddressのASCII表現に関連しています)。
Key Encoding
主要なコード化
P printablestring
N numericstring
T teletex-string
TテレテックスストリングをnumericstringしながらNをprintablestringするP
Kille [Page 31] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[31ページ]RFC1138
P/T teletex-and-or-ps
I labelled-integer
X presentation-address
P/T、テレテックス、または、psする、Iラベルされた整数Xプレゼンテーションアドレス
The BNF for presentation-address is taken from the specification "A String Encoding of Presentation Address" [Kille89a].
プレゼンテーションアドレスのためのBNFは「プレゼンテーションアドレスをコード化するストリング」[Kille89a]という仕様から抜粋されます。
In most cases, the EBNF encoding maps directly to the ASN.1 encoding of the attribute. There are a few exceptions. In cases where an attribute can be encoded as either a PrintableString or NumericString (Country, ADMD, PRMD), either form should be mapped into the BNF. When generating ASN.1, the NumericString encoding should be used if the string contains only digits.
多くの場合直接属性のASN.1コード化するのに地図をコード化するEBNF。 いくつかの例外があります。 PrintableStringかNumericStringのどちらかとして属性をコード化できる場合(国、ADMD、PRMD)では、どちらのフォームもBNFに写像されるべきです。 ASN.1を発生させるとき、ストリングがケタだけを含んでいるなら、NumericStringコード化は使用されるべきです。
There are a number of cases where the P/T (teletex-and-or-ps) representation is used. Where the key maps to a single attribute, this choice is reflected in the encoding of the attribute (attributes 10-21). For most of the 1984 attributes and common name, there is a printablestring and a teletex variant. This pair of attributes is mapped onto the single component here. This will give a clean mapping for the common cases where only one form of the name is used.
件数がそこでは、どこであるか、P/T、(テレテックス、または、psする、)、表現が使用されています。 ただ一つの属性への概念図でありこの選択が属性(属性10-21)のコード化に反映されるところ。 1984の属性と一般名の大部分のために、printablestringとテレテックス異形があります。 属性のこの組はここでただ一つのコンポーネントに写像されます。 これは名前の1つのフォームだけが使用されているよくある例のための清潔なマッピングを与えるでしょう。
4.2.1. Encoding of Personal Name
4.2.1. 個人名のコード化
Handling of Personal Name and Teletex Personal Name based purely on the EBNF.standard-type syntax defined above is likely to be clumsy. It seems desirable to utilise the "human" conventions for encoding these components. A syntax is defined, which is designed to provide a clean encoding for the common cases of O/R address specification where:
純粋に上で定義されたEBNF.standard-type構文に基づくパーソナルNameとTeletexパーソナルNameの取り扱いは不器用である傾向があります。 「人間」のコンベンションをこれらのコンポーネントをコード化するのに利用するのは望ましく思えます。 構文(O/Rアドレス指定のよくある例のための清潔なコード化にどこを提供するように設計されている)は定義されます:
1. There is no generational qualifier
1. どんな世代の資格を与える人もいません。
2. Initials contain only letters
2. イニシャルは手紙だけを含んでいます。
3. Given Name does not contain full stop ("."), and is at least
two characters long.
3. 与えられたNameが終止符を含んでいない、(「」、)、少なくとも2キャラクタ長さはそうです。
4. If Surname contains full stop, then it may not be in the
first two characters, and either initials or given name is
present.
4. Surnameが終止符を含んでいるなら、最初の2つのキャラクタ、およびどちらのイニシャルにはそれがないかもしれませんか、または名は存在しています。
The following EBNF is defined:
以下のEBNFは定義されます:
encoded-pn = [ given "." ] *( initial "." ) surname
「コード化されたpnが等しい、[付与、」、」、]、*、(初期、」、」、)、姓
given = 2*<ps-char not including ".">
. 「包含ではなく、与えられた=2*<ps-炭」">"
Kille [Page 32] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[32ページ]RFC1138
initial = ALPHA
初期の=アルファー
surname = printablestring
姓=printablestring
This can be used to map from any string containing only printable string characters to an O/R address personal name. Parse the string according to the EBNF. The given name and surname are assigned directly. All EBNF.initial tokens are concatenated without intervening full stops to generate the initials.
O/Rアドレスに個人的な印刷可能なストリング性格だけが命名するどんなストリング含有からも地図にこれを使用できます。 EBNFに従って、ストリングを分析してください。 名と姓は直接割り当てられます。 すべてのEBNF.initial象徴が、イニシャルを発生させるように介入している終止符なしで連結されます。
For an O/R address which follows the above restrictions, a string can be derived in the natural manner. In this case, the mapping will be reversible.
上の制限に続くO/Rアドレスにおいて、生まれながらの方法でストリングを引き出すことができます。 この場合、マッピングはリバーシブルになるでしょう。
For example:
例えば:
GivenName = "Marshall"
Surname = "Rose"
「マーシャル」GivenName=姓=は「上昇しました」。
Maps with "Marshall.Rose"
"Marshall.Rose"がある地図
Initials = "MT"
Surname = "Rose"
「MT」イニシャル=姓=は「上昇しました」。
Maps with "M.T.Rose"
「M.T.は上昇したこと」がある地図
GivenName = "Marshall"
Initials = "MT"
Surname = "Rose"
「MT」「マーシャル」GivenName=イニシャル=姓=は「上昇しました」。
Maps with "Marshall.M.T.Rose"
「Marshall.M.T.は上昇したこと」がある地図
Note that X.400 suggest that Initials is used to encode ALL initials. Therefore, the proposed encoding is "natural" when either GivenName or Initials, but not both, are present. The case where both are present can be encoded, but this appears to be contrived!
X.400が、Initialsがすべてのイニシャルをコード化するのに使用されるのを示すことに注意してください。 したがって、両方ではなく、GivenNameかInitialsのどちらかが存在しているとき、提案されたコード化は「自然です」。 両方が出席しているケースをコード化できますが、これは案出されるように見えます!
4.2.2. Standard Encoding of MTS.ORAddress
4.2.2. MTS.ORAddressの標準のコード化
Given this structure, we can specify a BNF representation of an O/R Address.
この構造を考えて、私たちはO/R AddressのBNF表現を指定できます。
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ registered-dd-type
/ dd-key "." std-printablestring
standard-type = key-string
」 . 」 std-printablestringが主要なストリングと等しいのを規格でタイプするdd」 属性=標準体型/"RFC-822"/登録されたdd「stdかアドレス=1*(「/」属性「=」価値)」/タイプ/キー
Kille [Page 33] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[33ページ]RFC1138
registered-dd-type
= key-string
dd-key = key-string
登録されたddタイプ=主要なストリングdd-キー=キーストリング
value = std-printablestring
値はstd-printablestringと等しいです。
std-printablestring
= *( std-char / std-pair )
std-char = <"{", "}", "*", and any ps-char
except "/" and "=">
std-pair = "$" ps-char
そして、「std-printablestring=*(std std-炭/対にしている)std-炭は<と等しい」、「」、」、「*」 /を除いて、」 いずれもps焦げる」、「=「>std-組=「$」ps-炭」
The standard-type is any key defined in the table in Section 4.2, except PN, and DD. The value, after quote removal, should be interpreted according to the defined encoding.
標準体型はPN、およびDDを除いて、セクション4.2でテーブルで定義されたあらゆるキーです。 定義されたコード化に従って、値は引用文の取り外しの後に解釈されるべきです。
If the standard-type is PN, the value is interpreted according to EBNF.encoded-pn, and the components of MTS.PersonalName and/or MTS.TeletexPersonalName derived accordingly.
標準体型がPNであるなら、EBNF.encoded-pn、およびそれに従って、引き出されたMTS.PersonalName、そして/または、MTS.TeletexPersonalNameの部品に従って、値は解釈されます。
If dd-key is the recognised Domain Defined string (DD), then the type and value should be interpreted according to the syntax implied from the encoding, and aligned to either the teletex or printable string form. Key and value should have the same encoding.
dd-キーが認識されたDomain Definedストリング(DD)であるなら、タイプと値は、コード化によって暗示している構文によって解釈されて、テレテックスか印刷可能なストリングフォームに並べられるべきです。 キーと値には、同じコード化があるべきです。
If value is "RFC-822", then the (printable string) Domain Defined Type of "RFC-822" is assumed. This is an optimised encoding of the domain defined type defined by this specification.
値が"RFC-822"であるなら、"RFC-822"の(印刷可能なストリング)ドメインの定義されたタイプは思われます。 これはこの仕様で定義されたドメインの定義されたタイプの最適化されたコード化です。
The matching of all keywords should be done in a case- independent manner.
ケースの独立している方法ですべてのキーワードのマッチングをするべきです。
If the value is registered-dd-type, the value is registered with the IANA and will be listed in the Assigned Numbers RFC, then the value should be interpreted accordingly. This restriction maximises the syntax checking which can be done at a gateway.
値が登録されたddタイプであるなら、値は、IANAに示されて、Assigned民数記RFCに記載されて、次に、値はそれに従って、解釈されるべきです。 この制限はどれがゲートウェイにできるかをチェックする構文を最大にします。
4.3. EBNF.822-address <-> MTS.ORAddress
4.3. EBNF.822-アドレス<->MTS.ORAddress
Ideally, the mapping specified would be entirely symmetrical and global, to enable addresses to be referred to transparently in the remote system, with the choice of gateway being left to the Message Transfer Service. There are two fundamental reasons why this is not possible:
理想的に、指定されたマッピングは、アドレスがリモートシステムで透明に参照されるのを可能にするために完全に対称であってグローバルでしょう、ゲートウェイの選択がMessage Transfer Serviceに残されている状態で。 これが可能でない2つの基本的な理由があります:
1. The syntaxes are sufficiently different to make this
awkward.
1. 構文はこれを無器用にすることができるくらい異なっています。
Kille [Page 34] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[34ページ]RFC1138
2. In the general case, there would not be the necessary
administrative co-operation between the X.400 and RFC 822
worlds, which would be needed for this to work.
2. 一般的な場合には、X.400とRFC822の世界の間には、必要な管理協力がないでしょう。世界が、これが働くのに必要でしょう。
Therefore, an asymmetrical mapping is defined, which can be symmetrical where there is appropriate administrative control.
したがって、非対称的なマッピング(適切な運営管理コントロールがあるところで対称である場合がある)は定義されます。
4.3.1. X.400 encoded in RFC 822
4.3.1. RFC822でコード化されたX.400
The std-or-address syntax is used to encode O/R Address information in the 822.local-part of EBNF.822-address. Further O/R Address information may be associated with the 822.domain component. This cannot be used in the general case, basically due to character set problems, and lack of order in X.400 O/R Addresses. The only way to encode the full PrintableString character set in a domain is by use of the 822.domain-ref syntax (i.e., 822.atom). This is likely to cause problems on many systems. The effective character set of domains is in practice reduced from the RFC 822 set, by restrictions imposed by domain conventions and policy.
stdかアドレス構文が、EBNF.822-アドレスの822.local-部分でO/R Address情報をコード化するのに使用されます。 一層のO/R Address情報は822.domainの部品に関連しているかもしれません。 一般的なケース、基本的に文字の組問題への支払われるべきもの、およびX.400O/R Addressesのオーダーの不足にこれを使用できません。 ドメインで完全なPrintableString文字の組をコード化する唯一の方法は822.domain-審判構文(すなわち、822.atom)を使用します。 これは多くのシステムの上で問題を起こしそうです。ドメインの有効な文字の組が実際にはRFC822セットから減少するあります、ドメインコンベンションと方針で課された制限で。
A generic 822.address consists of a 822.local-part and a sequence of 822.domains (e.g., <@domain1,@domain2:user@domain3>). All except the 822.domain associated with the 822.local-part (domain3 in this case) should be considered to specify routing within the RFC 822 world, and will not be interpreted by the gateway (although they may have identified the gateway from within the RFC 822 world).
一般的な822.addressが822.local-部分と822.domainsの系列から成る、(@domain2: 例えば、 <@domain1 、 user@domain3 、gt;、) 822.local-部分(この場合、domain3)に関連している822.domain以外のすべてが、RFC822世界の中でルーティングを指定すると考えられるべきであり、ゲートウェイによって解釈されないでしょう(彼らはRFC822世界からゲートウェイを特定したかもしれませんが)。
This form of source routing is now discouraged in the Internet
(Host Requirements, page 58 [Braden89a]).
このフォームのソースルーティングは現在、インターネット(58ページ[Braden89a]のホストRequirements)でがっかりしています。
The 822.domain associated with the 822.local-part may also identify the gateway from within the RFC 822 world. This final 822.domain may be used to determine some number of O/R Address attributes. The following O/R Address attributes are considered as a hierarchy, and may be specified by the domain. They are (in order of hierarchy):
また、822.local-部分に関連している822.domainはRFC822世界からゲートウェイを特定するかもしれません。 この最終的な822.domainは、何らかの数のO/R Address属性を決定するのに使用されるかもしれません。 以下のO/R Address属性は、階層構造であるとみなされて、ドメインによって指定されるかもしれません。 それらはこと(階層構造の順に)です:
Country, ADMD, PRMD, Organisation, Organisational Unit
国、ADMD、PRMD、機構、Organisationalユニット
There may be multiple Organisational Units.
複数のOrganisational Unitsがあるかもしれません。
Associations may be defined between domain specifications, and
some set of attributes. This association proceeds hierarchically.
For example, if a domain implies ADMD, it also implies country.
Subdomains under this are associated according to the O/R Address
hierarchy. For example:
協会はドメイン仕様と、何らかのセットの属性の間で定義されるかもしれません。 この協会は階層的で続きます。 例えば、また、ドメインがADMDを含意するなら、それは国を含意します。 O/R Address階層構造に従って、これの下のサブドメインは関連しています。 例えば:
=> "AC.UK" might be associated with
C="GB", ADMD="GOLD 400", PRMD="UK.AC"
=>"AC.UK"がC=「GB」に関連しているかもしれない、ADMDは「金400」と等しく、PRMDは"UK.AC"と等しいです。
Kille [Page 35] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[35ページ]RFC1138
then domain "R-D.Salford.AC.UK" maps with
C="GB", ADMD="GOLD 400", PRMD="UK.AC", O="Salford", OU="R-D"
そして、「R-D.Salford.AC.UK」というCがあるドメイン地図は「GB」、ADMD=「GOLD400」PRMD="UK.AC"、O=「ソルフォード」OU="R-D"と等しいです。
There are three basic reasons why a domain/attribute mapping might
be maintained, as opposed to using simply subdomains:
単にサブドメインを使用することと対照的にドメイン/属性マッピングが維持されるかもしれない3つの根本的な理由があります:
1. As a shorthand to avoid redundant X.400 information. In
particular, there will often be only one ADMD per country,
and so it does not need to be given explicitly.
1. 余分なX.400情報を避ける速記として。 特に、1国あたり1ADMDしかしばしばないので、それによって明らかに与えられる必要はありません。
2. To deal with cases where attribute values do not fit the
syntax:
2. 属性値が構文に合わないケースに対処するために:
domain-syntax = alphanum [ *alphanumhyphen alphanum ]
alphanum = <ALPHA or DIGIT>
alphanumhyphen = <ALPHA or DIGIT or HYPHEN>
ドメイン構文=alphanum[*alphanumhyphen alphanum]alphanumが<アルファーと等しいです、またはDIGIT>alphanumhyphenは<アルファー、DIGITまたはHYPHEN>と等しいです。
Although RFC 822 allows for a more general syntax, this
restricted syntax is chosen as it is the one chosen by the
various domain service administrations.
RFC822は、より一般的な構文を考慮しますが、この制限された構文は、それが様々なドメインサービス運営によって選ばれたものであるので、選ばれています。
3. To deal with missing elements in the hierarchy. A domain
may be associated with an omitted attribute in conjunction
with several present ones. When performing the algorithmic
insertion of components lower in the hierarchy, the omitted
value should be skipped. For example, if "HNE.EGM" is
associated with "C=TC", "ADMD=ECQ", "PRMD=HNE", and omitted
organisation, then "ZI.HNE.EGM" is mapped with "C=TC",
"ADMD=ECQ", "PRMD=HNE", "OU=ZI". It should be noted that
attributes may have null values, and that this is treated
separately from omitted attributes (whilst it would be bad
practice to treat these two cases differently, they must be
allowed for).
3. 階層構造でなくなった要素に対処するために。 ドメインはいくつかの現在のものに関連して省略された属性に関連しているかもしれません。 階層構造で、より低くコンポーネントのアルゴリズムの挿入を実行するとき、省略された値はスキップされるべきです。 例えば、"HNE.EGM"が「CはTcと等しい」、"ADMD=ECQ"、"PRMD=HNE"、および省略された機構に関連しているなら、"ZI.HNE.EGM"は「CはTcと等しい」"ADMD=ECQ"、"PRMD=HNE""OU=ZI"と共に写像されます。 ヌル値が属性にあるかもしれなくて、これが別々に省略された属性から扱われることに(これらの2つのケースを異なって扱うのが、悪い習慣であるだろうという間、それらを考慮しなければなりません)注意されるべきです。
This set of mappings need only be known by the gateways relaying between the RFC 822 world, and the O/R Address space associated with the mapping in question. However, it is desirable (for the optimal mapping of third party addresses) for all gateways to know these mappings. A format for the exchange of this information is defined in Appendix F.
このセットのマッピングはRFC822世界と、O/R Addressの間で関連しているマッピングがはっきりしていなかった状態でスペースをリレーするゲートウェイによって知られているだけでよいです。 しかしながら、すべてのゲートウェイに、これらのマッピングを知るのは望ましいです(第三者アドレスの最適のマッピングのための)。 この情報の交換のための書式はAppendix Fで定義されます。
The remaining attributes are encoded on the LHS, using the EBNF.std- or-address syntax. For example:
EBNF.stdを使用して、残っている属性がLHSでコード化される、-構文を扱ってください。 例えば:
/I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM
/I=J/S=Linnimouth/GQは 5/@Marketing.Widget.COM と等しいです。
encodes the MTS.ORAddress consisting of:
以下から成りながら、MTS.ORAddressをコード化します。
Kille [Page 36] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[36ページ]RFC1138
MTS.CountryName = "TC"
MTS.AdministrationDomainName = "BTT"
MTS.OrganizationName = "Widget"
MTS.OrganizationalUnitNames.value = "Marketing"
MTS.PersonalName.surname = "Linnimouth"
MTS.PersonalName.initials = "J"
MTS.PersonalName.generation-qualifier = "5"
MTS.CountryNameは「Tc」MTS.AdministrationDomainName="BTT"MTS.OrganizationName=「ウィジェット」MTS.OrganizationalUnitNames.value=「マーケティング」MTS.PersonalName.surname="Linnimouth"MTS.PersonalName.initials=「J」とMTS.PersonalName.generation-資格を与える人=「5インチ」等しいです。
The first three attributes are determined by the domain Widget.COM. Then, the first element of OrganizationalUnitNames is determined systematically, and the remaining attributes are encoded on the LHS. In an extreme case, all of the attributes will be on the LHS. As the domain cannot be null, the RHS will simply be a domain indicating the gateway.
最初の3つの属性がドメインWidget.COMのそばで決定しています。 次に、OrganizationalUnitNamesの最初の要素は系統的に決定しています、そして、残っている属性はLHSでコード化されます。 はなはだしきに至っては、属性のすべてがLHSにあるでしょう。 ドメインがヌルであるはずがないので、RHSは単にゲートウェイを示すドメインになるでしょう。
The RHS (domain) encoding is designed to deal cleanly with common addresses, and so the amount of information on the RHS should be maximised. In particular, it covers the Mnemonic O/R Address using a 1984 compatible encoding. This is seen as the dominant form of O/R Address. Use of other forms of O/R Address, and teletex encoded attributes will require an LHS encoding.
RHS(ドメイン)コード化が清潔に一般的なアドレスに対処するように設計されているので、RHSの情報量は最大にされるべきです。 特に、それは、1984年のコンパチブルコード化を使用することでMnemonic O/R Addressをカバーしています。 優位がO/R Addressを形成するとき、これは見られます。 Address、およびテレテックスのコード化された属性がそうするO/Rの他のフォームの使用はLHSコード化を必要とします。
There is a further mechanism to simplify the encoding of common cases, where the only attributes to be encoded on the LHS is a (non- Teletex) Personal Name attributes which comply with the restrictions of 4.2.1. To achieve this, the 822.local-part shall be encoded as EBNF.encoded-pn. In the previous example, if the GenerationQualifier was not present, the encoding J.Linnimouth@Marketing.Widget.COM would result.
唯一のLHSでコード化されるべき属性が.1に4.2の制限に従う(非テレテックス)の個人的なName属性であるよくある例のコード化を簡素化するために、さらなるメカニズムがあります。 これを達成するために、822.local-部分はEBNF.encoded-pnとしてコード化されるものとします。 前の例に、GenerationQualifierが存在していないなら、コード化している J.Linnimouth@Marketing.Widget.COM は結果として生じるでしょうに。
From the standpoint of the RFC 822 Message Transfer System, the domain specification is simply used to route the message in the standard manner. The standard domain mechanisms are are used to select appropriate gateways for the corresponding O/R Address space. In most cases, this will be done by registering the higher levels, and assuming that the gateway can handle the lower levels.
RFC822Message Transfer Systemの見地から、ドメイン仕様は、標準の方法によるメッセージを発送するのに単に使用されます。 標準のドメインメカニズムはそうです。対応するO/R Addressスペースに適切なゲートウェイを選択するために、使用されます。 多くの場合、より高いレベルを示して、ゲートウェイが下のレベルを扱うことができるのに就くことによって、これをするでしょう。
4.3.2. RFC 822 encoded in X.400
4.3.2. X.400でコード化されたRFC822
In some cases, the encoding defined above may be reversed, to give a "natural" encoding of genuine RFC 822 addresses. This depends largely on the allocation of appropriate management domains.
いくつかの場合、上で定義されたコード化は、本物のRFC822アドレスの「自然な」コード化を与えるために逆にされるかもしれません。 これは主に適切な管理ドメインの配分によります。
The general case is mapped by use of domain defined attributes. A Domain defined type "RFC-822" is defined. The associated attribute value is an ASCII string encoded according to Section 3.3.3 of this specification. The interpretation of the ASCII string depends on the context of the gateway.
一般的なケースはドメインの定義された属性の使用で写像されます。 Domain定義されたタイプ"RFC-822"が定義されます。 関連属性値はこの.3のセクション3.3仕様通りにコード化されたASCIIストリングです。 ASCIIストリングの解釈はゲートウェイの文脈によります。
Kille [Page 37] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[37ページ]RFC1138
1. In the context of RFC 822, and RFC 1034
[Crocker82a, Mockapetris87a], the string can be used
directly.
1. RFC822、およびRFC1034[Crocker82a、Mockapetris87a]の文脈では、直接ストリングを使用できます。
2. In the context of the JNT Mail protocol, and the NRS
[Kille84a, Larmouth83a], the string should be interpreted
according to Mailgroup Note 15 [Kille84b].
2. JNTメールプロトコルの文脈、およびNRS[Kille84a、Larmouth83a]では、Mailgroup Note15[Kille84b]によると、ストリングは解釈されるべきです。
3. In the context of UUCP based systems, the string should be
interpreted as defined in [Horton86a].
3. UUCPのベースのシステムの文脈では、ストリングは[Horton86a]で定義されるように解釈されるべきです。
Other O/R Address attributes will be used to identify a context in which the O/R Address will be interpreted. This might be a Management Domain, or some part of a Management Domain which identifies a gateway MTA. For example:
他のO/R Address属性は、O/R Addressが解釈される文脈を特定するのに使用されるでしょう。 これは、Management Domain、またはゲートウェイMTAを特定するManagement Domainの何らかの部分であるかもしれません。 例えば:
C = "GB"
ADMD = "GOLD 400"
PRMD = "UK.AC"
O = "UCL"
OU = "CS"
"RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK"
「Cs」"UCL"「金400」「GB」C=ADMD=PRMD="UK.AC"O=OU="RFC-822"は"Jimmy(a)WIDGET-LABS.CO.UK"と等しいです。
OR
OR
C = "TC"
ADMD = "Wizz.mail"
PRMD = "42"
"rfc-822" = "Postel(a)venera.isi.edu"
"Wizz.mail"「Tc」C=ADMD=PRMDは「42インチ"rfc-822"は"Postel(a)venera.isi.edu"と等しいこと」と等しいです。
Note in each case the PrintableString encoding of "@" as "(a)". In the second example, the "RFC-822" domain defined attribute is interpreted everywhere within the (Private) Management Domain. In the first example, further attributes are needed within the Management Domain to identify a gateway. Thus, this scheme can be used with varying levels of Management Domain co-operation.
「(a)」としてその都度"@"のPrintableStringコード化に注意してください。 2番目の例では、"RFC-822"ドメインの定義された属性は(個人的)の管理ドメインの中のいたる所で解釈されます。 最初の例では、さらなる属性が、ゲートウェイを特定するのにManagement Domainの中で必要です。 したがって、異なったレベルのManagement Domain協力と共にこの体系を使用できます。
4.3.3. Component Ordering
4.3.3. コンポーネント注文
In most cases, ordering of O/R Address components is not significant for the mappings specified. However, Organisational Units (printable string and teletex forms) and Domain Defined Attributes are specified as SEQUENCE in MTS.ORAddress, and so their order may be significant. This specification needs to take account of this:
多くの場合、指定されたマッピングには、O/R Addressの部品の注文は重要ではありません。 しかしながら、Organisational Units(印刷可能なストリングとテレテックス用紙)とDomain Defined AttributesがSEQUENCEとしてMTS.ORAddressで指定されるので、彼らのオーダーは重要であるかもしれません。 この仕様は、これを考慮に入れる必要があります:
1. To allow consistent mapping into the domain hierarchy
1. ドメイン階層構造に一貫したマッピングを許容するために
2. To ensure preservation of order over multiple mappings.
2. 複数のマッピングの上の秩序の維持を確実にするために。
Kille [Page 38] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[38ページ]RFC1138
There are three places where an order must be specified:
3つの場所がオーダーを指定しなければならないところにあります:
1. The text encoding (std-or-address) of MTS.ORAddress as used
in the local-part of an RFC 822 address. An order is needed
for those components which may have multiple values
(Organisational Unit, and Domain Defined Attributes). When
generating an 822.std-or-address, components of a given type
shall be in hierarchical order with the most significant
component on the RHS. If there is an Organisation
Attribute, it shall be to the right of any Organisational
Unit attributes. These requirements are for the following
reasons:
1. RFC822アドレスの地方の部分で使用されるようにMTS.ORAddressの(stdかアドレス)をコード化するテキスト。 オーダーが複数の値(Organisational Unit、およびDomain Defined Attributes)を持っているかもしれないそれらのコンポーネントに必要です。 822.stdかアドレスを作るとき、与えられたタイプの成分がRHSで最も重要なコンポーネントと共に階層的順序にあるものとします。 Organisation Attributeがあれば、どんなOrganisational Unit属性の右にはもそれがあるものとします。 これらの要件が以下の理由であります:
- Alignment to the hierarchy of other components in RFC
822 addresses (thus, Organisational Units will appear
in the same order, whether encoded on the RHS or LHS).
Note the differences of JNT Mail as described in
Appendix B.
- RFC822アドレス(その結果、Organisational Unitsは同次に現れるでしょう、RHSかLHSでコード化されるか否かに関係なく)の他のコンポーネントの階層構造への整列。 Appendix Bで説明されるようにJNTメールの違いに注意してください。
- Backwards compatibility with RFC 987/1026.
- RFC987/1026との遅れている互換性。
- To ensure that gateways generate consistent addresses.
This is both to help end users, and to generate
identical message ids.
- それを確実にするために、ゲートウェイは一貫したアドレスを作ります。 これは、ともにエンドユーザを助けて、同じメッセージイドを生成するためのものです。
Further, it is recommended that all other attributes are
generated according to this ordering, so that all attributes
so encoded follow a consistent hierarchy.
さらに、この注文に従って他のすべての属性が生成されるのは、お勧めです、そのようにコード化されたすべての属性が一貫した階層構造に従うように。
There will be some cases where an X.400 O/R address of this
encoding will be generated by an end user from external
information. The ordering of attributes may be inverted or
mixed. For this reason, the following heuristics may be
applied:
いくつかのケースがこのコード化のX.400O/Rアドレスがエンドユーザによって外部の情報から作られるところにあるでしょう。 属性の注文を逆にするか、または混ぜるかもしれません。 この理由で、以下の発見的教授法は適用されるかもしれません:
- If there is an Organisation attribute to the left of
any Org Unit attribute, assume that the hierarchy is
inverted.
- どんなOrg Unit属性の左へのOrganisation属性もあれば、階層構造が逆さであると仮定してください。
- If an inversion of the Org Unit hierarchy generates a
valid address, when the preferred order does not,
assume that the hierarchy is inverted.
- 都合のよいオーダーが作らないとき、Org Unit階層構造の逆が有効なアドレスを作るなら、階層構造が逆さであると仮定してください。
2. For the Organisational Units (OU) in MTS.ORAddress, the
first OU in the SEQUENCE is the most significant, as
specified in X.400.
2. MTS.ORAddressのOrganisational Units(OU)に関しては、SEQUENCEで最初のOUは最も重要です、X.400で指定されるように。
3. For the Domain Defined Attributes in MTS.ORAddress, the
3. ドメインがMTS.ORAddressで属性を定義したので
Kille [Page 39] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[39ページ]RFC1138
First Domain Defined Attribute in the SEQUENCE is the most
significant.
まず最初に、SEQUENCEのDomain Defined Attributeは最も重要です。
Note that although this ordering is mandatory for this
mapping, there are NO implications on ordering significance
within X.400, where this is a Management Domain issue.
この注文がこのマッピングに義務的ですが、X.400の中で意味を注文するとき、含意が全くないことに注意してください。そこでは、これがManagement Domain問題です。
4.3.4. RFC 822 -> X.400
4.3.4. RFC822->X.400
There are two basic cases:
2つの基本的なケースがあります:
1. X.400 addresses encoded in RFC 822. This will also include
RFC 822 addresses which are given reversible encodings.
1. RFC822でコード化されたX.400アドレス。 また、これはリバーシブルのencodingsが与えられているRFC822アドレスを含むでしょう。
2. "Genuine" RFC 822 addresses.
2. 「本物」のRFC822アドレス。
The mapping should proceed as follows, by first assuming case 1).
マッピングは、以下の通り最初にケース1)を仮定することによって、続くべきです。
STAGE I.
Iを上演してください。
1. If the 822-address is not of the form:
1. 822アドレスがフォームのものでないなら:
local-part "@" domain
地方の部分"@"ドメイン
Go to stage II.
ステージIIまで行ってください。
NOTE:It may be appropriate to reduce a source route address
to this form by removal of all bar the last domain. In
terms of the design intentions of RFC 822, this would
be an incorrect action. However, in most real cases,
it will do the "right" thing and provide a better
service to the end user. This is a reflection on the
excessive and inappropriate use of source routing in
RFC 822 based systems. Either approach, or the
intermediate approach of stripping only domain
references which reference the local gateway are
conformant to this specification.
注意: ソースルート・アドレスをこのフォームにすべての取り外しで減少させるのが最後のドメインを禁じるのは、適切であるかもしれません。 RFC822の設計目標で、これは不正確な動作でしょう。 しかしながら、ほとんどの本当の場合では、それは、「正しい」ことをして、エンドユーザに対する、より良いサービスを提供するでしょう。 これはRFC822に基づいているシステムにおけるソースルーティングの過度の、そして、不適当な使用に関する反省です。地方のゲートウェイに参照をつけるドメイン参照だけを剥取るアプローチか中間的アプローチのどちらかがこの仕様へのconformantです。
2. Attempt to parse EBNF.domain as:
2. 以下としてEBNF.domainを分析するのを試みてください。
*( domain-syntax "." ) known-domain
*「(ドメイン構文、」、」、) 知られているドメイン
Where EBNF.known-domain is the longest possible match in a
list of supported mappings (see Appendix F). If this fails,
and the EBNF.domain does not explicitly identify the local
gateway, go to stage II. If it succeeds, allocate the
attributes associated with EBNF.known-domain, and
systematically allocate the attributes implied by each
EBNF.known-ドメインがサポートしているマッピングのリストで可能な限り長いマッチ(Appendix Fを見る)であるところ。 これが失敗して、EBNF.domainが明らかに地方のゲートウェイを特定しないなら、ステージIIまで行ってください。 成功するなら、EBNF.known-ドメインに関連している属性を割り当ててください、そして、系統的にそれぞれによって含意された属性を割り当ててください。
Kille [Page 40] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[40ページ]RFC1138
EBNF.domain-syntax component. If the domain explicitly
identifies the gateway, allocate no attributes.
EBNF.domain-構文コンポーネント。 ドメインが明らかにゲートウェイを特定するなら、属性を全く割り当てないでください。
3. If the local-part contains any characters not in
PrintableString, go to stage II.
3. 地方の部分がどんなPrintableStringにも何かキャラクタを含まないなら、ステージIIまで行ってください。
4. If the 822.local-part uses the 822.quoted-string encoding,
remove this quoting. Parse the (unquoted) 822.local-part
according to the EBNF EBNF.std-or-address. If this parse
fails, parse the local-part according to the EBNF
EBNF.encoded-pn. The result is a set of type/value pairs.
If the values generated conflict with those derived in step
2 (e.g., a duplicated country attribute), the domain should
be assumed to be an RFC 987 gateway. In this case, take
only the LHS derived attributes. Otherwise add LHS and RHS
derived attributes together.
4. 822.local-部分が822.quoted-stringコード化を使用するなら、この引用を取り除いてください。 EBNF EBNF.stdかアドレスに従って、(引用を終わられます)822.local-部分を分析してください。 これであるなら、やり損ないを分析してください、そして、EBNF EBNF.encoded-pnに従って、地方の部分を分析してください。 結果は1セットのタイプ/値の組です。 値が、ステップ2で引き出されるそれらとの闘争が(例えば、コピーされた国の属性)であると生成するなら、ドメインはRFC987ゲートウェイであると思われるでしょうに。 この場合、派生している属性をLHSだけに取ってください。 さもなければ、LHSとRHSが属性を一緒に引き出したと言い足してください。
5. Associate the EBNF.attribute-value syntax (determined from
the identified type) with each value, and check that it
conforms. If not, go to stage II.
5. EBNF.attribute-value構文(特定されたタイプから断固とした)を各値に関連づけてください、そして、それが従うのをチェックしてください。そうでなければ、ステージIIまで行ってください。
6. Ensure that the set of attributes conforms both to the
MTS.ORAddress specification and to the restrictions on this
set given in X.400. If not go to stage II.
6. 属性のセットがX.400で与えられているこのセットでMTS.ORAddress仕様と、そして、制限に一致しているのを確実にしてください。 そうでなければ、ステージIIまで行ってください。
7. Build the O/R Address from this information.
7. この情報からO/R Addressを造ってください。
STAGE II.
IIを上演してください。
This will only be reached if the RFC 822 EBNF.822-address is not a valid X.400 encoding. If the address is an 822-MTS recipient address, it must be rejected, as there is a need to interpret such an address in X.400. For the 822-MTS return address, and any addresses in the RFC 822 header, they should now be encoded as RFC 822 addresses in an X.400 O/R Name:
これにRFC822EBNF.822-アドレスが有効なX.400コード化でない場合にだけ達するでしょう。 アドレスが822-MTS受取人アドレスであるなら、それを拒絶しなければなりません、そのようなアドレスを解釈する必要がX.400にあるとき。 822-MTS返送先、およびRFC822ヘッダーのどんなアドレスにおいても、RFC822がX.400O/RでNameを扱うとき、それらは現在、コード化されるべきです:
1. Convert the EBNF.822-address to PrintableString, as
specified in Chapter 3.
1. 第3章で指定されるようにEBNF.822-アドレスをPrintableStringに変換してください。
2. The "RFC-822" domain defined attribute should be generated
from this string.
2. "RFC-822"ドメインの定義された属性はこのストリングから生成されるべきです。
3. Build the rest of the O/R Address in the local Management
Domain agreed manner, so that the O/R Address will receive a
correct global interpretation.
3. 地方のManagement DomainのO/R Addressの残りに同意された方法を築き上げてください、O/R Addressが正しいグローバルな解釈を受けるように。
Note that the domain defined attribute value has a maximum length
ドメインが属性値を定義したというメモには、最大の長さがあります。
Kille [Page 41] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[41ページ]RFC1138
of MTS.ub-domain-defined-attribute-value-length (128). If this is exceeded by a mapping at the MTS level, then the gateway should reject the message in question. If this occurs at the IPMS level, then the action should depend on the policy being taken, which is discussed in Section 5.1.3.
定義されたMTS.ubドメインが値の長さを結果と考えている(128)について。 これがMTSレベルにおけるマッピングによって超えられているなら、ゲートウェイは問題のメッセージを拒絶するはずです。 これがIPMSレベルで起こるなら、動作は方針存在に取った状態でよるべきです(セクション5.1.3で議論します)。
4.3.5. X.400 -> RFC 822
4.3.5. X.400->RFC822
There are two basic cases:
2つの基本的なケースがあります:
1. RFC 822 addresses encoded in X.400.
1. X.400でコード化されたRFC822アドレス。
2. "Genuine" X.400 addresses. This may include symmetrically
encoded RFC 822 addresses.
2. 「本物」のX.400アドレス。 これは対称的にコード化されたRFC822アドレスを含むかもしれません。
When a MTS Recipient O/R Address is interpreted, gatewaying will be selected if there a single "RFC-822" domain defined attribute present. In this case, use mapping A. For other O/R Addresses which:
MTS Recipient O/R Addressが解釈されるとき、ただ一つの"RFC-822"ドメインがそこで属性プレゼントを定義したなら、gatewayingは選択されるでしょう。 この場合マッピングA.For他のO/R Addressesを使用してください、どれ、:
1. Contain the special attribute.
1. 特別な属性を含んでください。
AND
AND
2. Identifies the local gateway or any other known gateway with
the other attributes.
2. 他の属性がある地方のゲートウェイかいかなる他の知られているゲートウェイも特定します。
Use mapping A. In other cases, use mapping B.
マッピングA.In他のケース、Bを写像する使用を使用してください。
NOTE:
A pragmatic approach would be to assume that any O/R
Address with the special domain defined attribute identifies
an RFC 822 address. This will usually work correctly, but is
in principle not correct.
以下に注意してください。 実際的なアプローチは特別なドメイン定義された属性があるどんなO/R AddressもRFC822アドレスを特定すると仮定するだろうことです。 これは、通常正しく働きますが、原則として正しくはありません。
Mapping A
Aを写像します。
1. Map the domain defined attribute value to ASCII, as defined
in Chapter 3.
1. 第3章で定義されるようにドメインの定義された属性値をASCIIに写像してください。
Mapping B
Bを写像します。
This will be used for X.400 addresses which do not use the explicit RFC 822 encoding.
これは明白なRFC822コード化を使用しないX.400アドレスに使用されるでしょう。
1. For all string encoded attributes, remove any leading or
trailing spaces, and replace adjacent spaces with a single
space.
1. すべてに関しては、コード化された属性を結んでください、そして、あらゆる主であるか引きずっている空間を移してください、そして、隣接している空間をシングルスペースに取り替えてください。
Kille [Page 42] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[42ページ]RFC1138
2. Noting the hierarchy specified in 4.3.1, determine the
maximum set of attributes which have an associated domain
specification. If no match is found, allocate the domain as
the domain specification of the local gateway, and go to
step 4.
2. 階層構造が指定したことに注意する、4.3、.1、関連ドメイン仕様を持っている最大のセットの属性を決定してください。 マッチが全く見つけられないなら、地方のゲートウェイのドメイン仕様としてドメインを割り当ててください、そして、ステップ4に行ってください。
3. Following the 4.3.1 hierarchy and noting any omitted
components implied by the mapping tables (see Appendix F),
if each successive component exists, and conforms to the
syntax EBNF.domain-syntax (as defined in 4.3.1), allocate
the next subdomain. At least one attribute of the X.400
address should not be mapped onto subdomain, as
822.local-part cannot be null.
3. 4.3に続いて、.1階層構造といずれかにも注意すると、マッピングテーブルによって含意されたコンポーネントは省略されました(Appendix Fを見てください)、それぞれの連続したコンポーネントが構文EBNF.domain-構文に存在していて、一致しているなら(中で定義される、4.3、.1、)、次のサブドメインを割り当ててください。 822.local-部分がヌルであるはずがないので、X.400アドレスの少なくとも1つの属性をサブドメインに写像するべきではありません。
4. If the remaining components are personal-name components,
conforming to the restrictions of 4.2.1, then EBNF.encoded-
pn should be derived to form 822.local-part. In other cases
the remaining components should simply be encoded as a
822.local-part using the EBNF.std-or-address syntax. If
necessary, the 822.quoted-string encoding should be used.
4. 残っているコンポーネントが.1、当時のEBNF.encoded- pnを4.2の制限に従わせるコンポーネントがそうするべきである個人名であるなら引き出されて、822.local-部分を形成してください。 他の場合では、残っているコンポーネントは、822.local-部分として単にEBNF.stdかアドレス構文を使用することでコード化されるべきです。 必要なら、822.quoted-stringコード化は使用されるべきです。
If the derived 822.local-part can only be encoded by use of
822.quoted-string, then use of the mapping defined
in [Kille89b] may be appropriate. Use of this mapping is
discouraged.
822.quoted-stringの使用で派生している822.local-部分をコード化できるだけであるなら、[Kille89b]で定義されたマッピングの使用は適切であるかもしれません。 このマッピングの使用はお勧めできないです。
4.4. Repeated Mappings
4.4. 繰り返されたマッピング
The mappings defined are symmetrical and reversible across a single gateway. The symmetry is particularly useful in cases of (mail exploder type) distribution list expansion. For example, an X.400 user sends to a list on an RFC 822 system which he belongs to. The received message will have the originator and any 3rd party X.400 O/R Addresses in correct format (rather than doubly encoded). In cases (X.400 or RFC 822) where there is common agreement on gateway identification, then this will apply to multiple gateways.
定義されたマッピングは、1門の向こう側に対称であってリバーシブルです。 対称は(メール発破器タイプ)発送先リスト拡大の場合で特に役に立ちます。 例えば、X.400ユーザは彼が属すRFC822システムの上のリストに発信します。 受信されたメッセージは正しい形式(二倍コード化されているよりむしろ)で創始者とどんな第3パーティーX.400O/R Addressesも持つでしょう。 そして、ゲートウェイ識別の一般的な協定がある場合(X.400かRFC822)では、これは複数のゲートウェイに適用されるでしょう。
When a message traverses multiple gateways, the mapping will always be reversible, in that a reply can be generated which will correctly reverse the path. In many cases, the mapping will also be symmetrical, which will appear clean to the end user. For example, if countries "AB" and "XY" have RFC 822 networks, but are interconnected by X.400, the following may happen: The originator specifies:
メッセージが複数のゲートウェイを横断するとき、マッピングはいつもリバーシブルになるでしょう、正しく経路を逆にする回答が発生できるので。 多くの場合、また、マッピングは対称になるでしょう(エンドユーザにとってきれいに見えるでしょう)。 例えば、RFCには822のネットワークがありますが、国の「AB」と"XY"がX.400によってインタコネクトされるなら、以下は起こるかもしれません: 創始者は指定します:
Joe.Soap@Widget.PTT.XY
Joe.Soap@Widget.PTT.XY
Kille [Page 43] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[43ページ]RFC1138
This is routed to a gateway, which generates:
これはゲートウェイに発送されます。(それは、以下を発生させます)。
C = "XY"
ADMD = "PTT"
PRMD = "Griddle MHS Providers"
Organisation = "Widget Corporation"
Surname = "Soap"
Given Name = "Joe"
名前=「ジョー」と考えて、「PTT」"XY"C=ADMD=PRMDは「フライパンMHSプロバイダー」機構=「ウィジェット社」姓=「石鹸」と等しいです。
This is then routed to another gateway where the mapping is reversed to give:
次に、これは与えるためにマッピングが逆にされるもう1門に発送されます:
Joe.Soap@Widget.PTT.XY
Joe.Soap@Widget.PTT.XY
Here, use of the gateway is transparent.
ここで、ゲートウェイの使用はわかりやすいです。
Mappings will only be symmetrical where mapping tables are defined. In other cases, the reversibility is more important, due to the (far too frequent) cases where RFC 822 and X.400 services are partitioned.
マッピングはマッピングテーブルが定義されるところで対称になるだけでしょう。 他の場合では、リバーシブルは、より重要です、RFC822とX.400サービスが仕切られる(はるかに頻繁過ぎる)のケースのため。
The syntax may be used to source route. THIS IS STRONGLY DISCOURAGED. For example:
構文は送信元経路に使用されるかもしれません。 これは強くがっかりしています。 例えば:
X.400 -> RFC 822 -> X.400
X.400->RFC822->X.400
C = "UK"
ADMD = "Gold 400"
PRMD = "UK.AC"
"RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR"
「C=「イギリス」ADMD=「金400インチのPRMD="UK.AC""RFC-822"=」/PN=デュバル/DD.Titleはマネージャ/(a)Inria.ATLAS.FRと等しいです」
This will be sent to an arbitrary UK Academic Community gateway by X.400. Then it will be sent by JNT Mail to another gateway determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This will then derive the X.400 O/R Address:
これはX.400によって任意のイギリスのAcademic Communityゲートウェイに送られるでしょう。 そして、JNTメールはドメインInria.ATLAS.FR(FR.ATLAS.Inria)のそばで断固としたもう1つの門にそれを送るでしょう。 次に、これはX.400O/R Addressを引き出すでしょう:
C = "FR"
ADMD = "ATLAS"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
「デュバル」という"Inria"「ATLAS」「フラン」C=ADMD=PRMD=PN.S=「タイトル」は「マネージャ」と等しいです。
Similarly: RFC 822 -> X.400 -> RFC 822
同様に: RFC822->X.400->RFC822
"/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"
@monet.berkeley.edu
@monet「/C=イギリス/ADMDはBT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/と等しく」.berkeley.edu
This will be sent to monet.berkeley.edu by RFC 822, then to the AC
RFC822によるmonet.berkeley.eduと、そして、そして、西暦にこれを送るでしょう。
Kille [Page 44] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[44ページ]RFC1138
PRMD by X.400, and then to jj@seismo.css.gov by RFC 822.
X.400と、そして、RFC822による jj@seismo.css.gov へのPRMD。
4.5. Directory Names
4.5. ディレクトリ名
Directory Names are an optional part of O/R Name, along with O/R Address. The RFC 822 addresses are mapped onto the O/R Address component. As there is no functional mapping for the Directory Name on the RFC 822 side, a textual mapping should be used. There is no requirement for reversibility in terms of the goals of this specification. There may be some loss of functionality in terms of third party recipients where only a directory name is given, but this seems preferable to the significant extra complexity of adding a full mapping for Directory Names.
ディレクトリNamesはO/R Addressに伴うO/R Nameの任意の部分です。 RFC822アドレスはO/R Addressの部品に写像されます。 ディレクトリNameのための機能的マッピングが全くRFC822側になくて、原文のマッピングは使用されるべきです。 この仕様の目標に関してリバーシブルのための要件が全くありません。 第三者受取人に関して機能性のいくらかの損失がディレクトリ名だけを与えますが、これがディレクトリNamesに、完全なマッピングを加える重要な余分な複雑さより望ましく見えるところにあるかもしれません。
4.6. MTS Mappings
4.6. MTSマッピング
The basic mappings at the MTS level are:
MTSレベルにおける基本のマッピングは以下の通りです。
1) 822-MTS originator ->
MTS.PerMessageSubmissionFields.originator-name
MTS.OtherMessageDeliveryFields.originator-name ->
822-MTS originator
1) 822-MTS創始者->MTS.PerMessageSubmissionFields.originator-名前MTS.OtherMessageDeliveryFields.originator-名前->822-MTS創始者
2) 822-MTS recipient ->
MTS.PerRecipientMessageSubmissionFields
MTS.OtherMessageDeliveryFields.this-recipient-name ->
822-MTS recipient
2) 822-MTS受取人->MTS.PerRecipientMessageSubmissionFields MTS.OtherMessageDeliveryFields.this-受取人名義の->822-MTS受取人
822-MTS recipients and return addresses are encoded as EBNF.822- address.
822-MTS受取人と返送先はEBNF.822アドレスとしてコード化されます。
The MTS Originator is always encoded as MTS.OriginatorName, which maps onto MTS.ORAddressAndOptionalDirectoryName, which in turn maps onto MTS.ORName.
MTS OriginatorがMTS.OriginatorName、MTS.ORAddressAndOptionalDirectoryNameへのどの地図としていつもコード化されるか、どれ、順番に、MTS.ORNameに写像するか。
4.6.1. RFC 822 -> X.400
4.6.1. RFC822->X.400
From the 822-MTS Originator, use the basic ORAddress mapping, to generate MTS.PerMessageSubmissionFields.originator-name (MTS.ORName), without a DirectoryName.
822-MTS Originatorから、基本のORAddressマッピングを使用して、DirectoryNameなしでMTS.PerMessageSubmissionFields.originator-名前(MTS.ORName)を発生させてください。
For recipients, the following settings should be made for each component of MTS.PerRecipientMessageSubmissionFields.
受取人に関しては、以下の設定はMTS.PerRecipientMessageSubmissionFieldsの各部品のために作られているべきです。
recipient-name
This should be derived from the 822-MTS recipient by the
basic ORAddress mapping.
基本のORAddressマッピングは822-MTS受取人から受取人名のThisを得るべきです。
Kille [Page 45] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[45ページ]RFC1138
originator-report-request
This should be set according to content return policy, as
discussed in Section 5.2.
満足している返品条件によると、創始者レポート要求Thisはセクション5.2で議論するように用意ができるべきです。
explicit-conversion
This optional component should be omitted, as this service
is not needed.
このサービスは必要でないように明白な変換のThisの任意の部品が省略されるべきです。
extensions
The default value (no extensions) should be used.
デフォルトが評価する拡張子(拡大がない)は使用されるべきです。
4.6.2. X.400 -> RFC 822
4.6.2. X.400->RFC822
The basic functionality is to generate the 822-MTS originator and recipients. There is information present on the X.400 side, which cannot be mapped into analogous 822-MTS services. For this reason, new RFC 822 fields are added for the MTS Originator and Recipients. The information discarded at the 822-MTS level should be present in these fields. There may also be the need to generate a delivery report.
基本機能は822-MTS創始者と受取人を発生させることです。 類似の822-MTSサービスに写像できないX.400側の現在の情報があります。 この理由で、新しいRFC822分野はMTS OriginatorとRecipientsのために加えられます。 822-MTSレベルで捨てられた情報はこれらの分野に存在しているべきです。 また、配送レポートを作る必要があるかもしれません。
4.6.2.1. 822-MTS Mappings
4.6.2.1. 822-MTSマッピング
Use the basic ORAddress mapping, to generate the 822-MTS originator (return address) from MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName). If MTS.ORName.directory-name is present, it should be discarded.
基本のORAddressマッピングを使用して、MTS.OtherMessageDeliveryFields.originator-名前(MTS.ORName)から822-MTS創始者(返送先)を発生させてください。 MTS.ORName.directory-nameが存在しているなら、それは捨てられるべきです。
The 822-MTS recipient is conceptually generated from MTS.OtherMessageDeliveryFields.this-recipient-name. This is done by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and generating an 822-MTS recipient according to the basic ORAddress mapping, discarding MTS.ORName.directory-name if present. However, if this model was followed exactly, there would be no possibility to have multiple 822-MTS recipients on a single message. This is unacceptable, and so layering is violated. The mapping needs to use the MTA level information, and map each value of MTA.PerRecipientMessageTransferFields.recipient-name, where the responsibility bit is set, onto an 822-MTS recipient.
822-MTS受取人はMTS.OtherMessageDeliveryFields.this受取人名から概念的に発生します。 MTS.OtherMessageDeliveryFields.this受取人名を取って、基本のORAddressマッピングに応じて822-MTS受取人を発生させることによって、これをします、存在しているならMTS.ORName.directory-nameを捨てて。 しかしながら、このモデルがまさに従われているなら、複数の822-MTS受取人がただ一つのメッセージにいる可能性が全くないでしょうに。 これが容認できないので、レイヤリングは違反されます。 マッピングは、MTAの平らな情報を使用して、MTA.PerRecipientMessageTransferFields.recipient-名前の各値を写像する必要があります、822-MTS受取人に。そこでは、責任ビットが設定されます。
4.6.2.2. Generation of RFC 822 Headers
4.6.2.2. RFC822ヘッダーの世代
Not all per-recipient information can be passed at the 822-MTS level. For this reason, two new RFC 822 headers are created, in order to carry this information to the RFC 822 recipient. These fields are "X400-Originator:" and "X400-Recipients:".
822-MTSレベルですべての1受取人あたりの情報を通過できるというわけではありません。 これは推論します、2の新しいRFC。822個のヘッダーが創造されます、RFC822受取人までこの情報を運ぶために。 これらの分野がそうである、「X400-創始者:」 そして、「X400-受取人:」
The "X400-Originator:" field should be set to the same value as the
「X400-創始者:」 分野は同じ値に設定されるべきです。
Kille [Page 46] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[46ページ]RFC1138
822-MTS originator. In addition, if MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) contains MTS.ORName.directory-name then this Directory Name should be represented in an 822.comment.
822-MTS創始者。 さらに、MTS.OtherMessageDeliveryFields.originator-名前(MTS.ORName)がMTS.ORName.directory-nameを含んでいるなら、このディレクトリNameは822.commentに表されるべきです。
Recipient names, taken from each value of MTS.OtherMessageDeliveryFields.this-recipient-name and MTS.OtherMessageDeliveryFields.other-recipient-names should be made available to the RFC 822 user by use of the "X400-Recipients:" field. By taking the recipients at the MTS level, disclosure of recipients will be dealt with correctly. If any MTS.ORName.directory-name is present, it should be represented in an 822.comment. If MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name is present, then it should be represented in an associated 822.comment, starting with the string "Originally Intended Recipient".
MTS.OtherMessageDeliveryFields.this受取人名とMTS.OtherMessageDeliveryFields.other受取人名の値がRFC822ユーザにとって使用で利用可能にされるべきであるそれぞれから取られた受取人名、「X400-受取人:」 さばきます。 MTSレベルで受取人を連れて行くことによって、受取人の公開は正しく対処されるでしょう。 どれかMTS.ORName.directory-nameが存在しているなら、それは822.commentに表されるべきです。 MTS.OtherMessageDeliveryFields.orignallyが受取人名を意図したなら、ストリング「元々意図した受取人」から始めて、プレゼント、それが表されるべきであるその時は関連822.commentですか?
In addition, the following per-recipient services from MTS.OtherMessageDeliveryFields.extensions should be represented in comments if they are used. None of these services can be provided on RFC 822 networks, and so in general these will be informative strings associated with other MTS recipients. In some cases, string values are defined. For the remainder, the string value may be chosen by the implementor. If the parameter has a default value, then no comment should be inserted.
さらに、それらが使用されているなら、MTS.OtherMessageDeliveryFields.extensionsからの以下の1受取人あたりのサービスはコメントで表されるべきです。 RFC822ネットワークでこれらのサービスのどれかを提供できないので、一般に、これらは他のMTS受取人に関連している有益なストリングになるでしょう。 いくつかの場合、ストリング値は定義されます。 残りにおいて、ストリング値は作成者によって選ばれるかもしれません。 パラメタにデフォルト値があるなら、ノーコメントは挿入されるべきです。
requested-delivery-method
要求された発送方法
physical-forwarding-prohibited
"(Physical Forwarding Prohibited)".
「(禁止された物理的な推進)」という禁止された物理的な推進。
physical-forwarding-address-request
"(Physical Forwarding Address Requested)".
「(アドレスが要求した物理的な推進)」という物理的な推進アドレス要求。
physical-delivery-modes
物理的な配送モード
registered-mail-type
登録されたメールタイプ
recipient-number-for-advice
アドバイスの受取人番号
physical-rendition-attributes
物理的な表現属性
physical-delivery-report-request
"(Physical Delivery Report Requested)".
「(要求された物理的な配送レポート)」という物理的な配送レポート要求。
proof-of-delivery-request
"(Proof of Delivery Requested)".
「(要求された配達証明)」という配送要求の証拠。
Kille [Page 47] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[47ページ]RFC1138
4.6.2.3. Delivery Report Generation
4.6.2.3. 配送レポート作成
If MTA.PerRecipientMessageTransferFields.per-recipient-indicators requires a positive delivery notification, this should be generated by the gateway. Supplementary Information should be set to indicate that the report is gateway generated.
MTA.PerRecipientMessageTransferFields.per受取人インディケータが積極的な配送通知を必要とするなら、これはゲートウェイで発生するべきです。 補っている情報が、レポートが発生するゲートウェイであることを示すように設定されるべきです。
4.6.3. Message IDs (MTS)
4.6.3. メッセージID(MTS)
A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The reverse mapping is not needed, as MTS.MTSIdentifier is always mapped onto new RFC 822 fields. The value of MTS.MTSIdentifier.local-part will facilitate correlation of gateway errors.
822.msg-イドからMTS.MTSIdentifierまでのマッピングは定義されます。 MTS.MTSIdentifierがいつも新しいRFC822フィールドに写像されるとき、逆のマッピングは必要ではありません。 MTS.MTSIdentifier.local-部分の値はゲートウェイ誤りの相関関係を容易にするでしょう。
To map from 822.msg-id, apply the standard mapping to 822.msg-id, in order to generate an MTS.ORAddress. The Country, ADMD, and PRMD components of this should be used to generate MTS.MTSIdentifier.global-domain-identifier. MTS.MTSIdentifier.local-identifier should be set to the 822.msg-id, including the braces "<" and ">". If this string is longer than MTS.ub-local-id-length (32), then it should be truncated to this length.
写像する、822.msg-イドから、MTS.ORAddressを発生させるように標準のマッピングを822.msg-イドに適用してください。 このCountry、ADMD、およびPRMDの部品は、MTS.MTSIdentifier.globalドメイン識別子を発生させるのに使用されるべきです。 MTS.MTSIdentifier.local-識別子は支柱"<"と">"を含む822.msg-イドに設定されるべきです。 このストリングがMTS.ubの地方のイドの長さの(32)より長いなら、それはこの長さに先端を切られるべきです。
The reverse mapping is not used in this specification. It would be applicable where MTS.MTSIdentifier.local-identifier is of syntax 822.msg-id, and it algorithmically identifies MTS.MTSIdentifier.
逆のマッピングはこの仕様で使用されません。 それはMTS.MTSIdentifier.local-識別子が構文822.msg-イドのものであるところで適切でしょう、そして、algorithmicallyに、MTS.MTSIdentifierを特定します。
4.7. IPMS Mappings
4.7. IPMSマッピング
All RFC 822 addresses are assumed to use the 822.mailbox syntax. This should include all 822.comments associated with the lexical tokens of the 822.mailbox. In the IPMS O/R Names are encoded as MTS.ORName. This is used within the IPMS.ORDescriptor, IPMS.RecipientSpecifier, and IPMS.IPMIdentifier. An asymmetrical mapping is defined between these components.
すべてのRFC822アドレスが822.mailbox構文を使用すると思われます。 これは822.mailboxの字句に関連しているすべての822.commentsを含むべきです。 IPMS O/Rでは、NamesはMTS.ORNameとしてコード化されます。 これはIPMS.ORDescriptor、IPMS.RecipientSpecifier、およびIPMS.IPMIdentifierの中で使用されます。 非対称的なマッピングはこれらのコンポーネントの間で定義されます。
4.7.1. RFC 822 -> X.400
4.7.1. RFC822->X.400
To derive IPMS.ORDescriptor from an RFC 822 address.
RFC822アドレスからIPMS.ORDescriptorを得るために。
1. Take the address, and extract an EBNF.822-address. This can
be derived trivially from either the 822.addr-spec or
822.route-addr syntax. This is mapped to MTS.ORName as
described above, and used as IMPS.ORDescriptor.formal-name.
1. アドレスを取ってください、そして、EBNF.822-アドレスを抜粋してください。 822.addr-仕様か822.route-addr構文からこれを些細なことに得ることができます。 これは上で説明されて、IMPS.ORDescriptor.formal-nameとして使用されるようにMTS.ORNameに写像されます。
2. A string should be built consisting of (if present):
2. 成ることが五弦に建てられるべきである、(存在しているなら):
Kille [Page 48] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[48ページ]RFC1138
- The 822.phrase component if the 822.address is an
822.phrase 822.route-addr construct.
- 822.addressであるなら、822.phraseの部品は822.phrase 822.route-addr構造物です。
- Any 822.comments, in order, retaining the parentheses.
- 括弧を保有するオーダーにおけるどんな822.comments。
This string should then be encoded into T.61 us a human
oriented mapping (as described in Chapter 3). If the string
is not null, it should be assigned to
IPMS.ORDescriptor.free-form-name.
次に、このストリングがT.61にコード化されるべきである、私たち、人間はマッピングを適応させました(第3章で説明されるように)。 ストリングがヌルでないなら、それはIPMS.ORDescriptor.freeフォーム名に割り当てられるべきです。
3. IPMS.ORDescriptor.telephone-number should be omitted.
3. IPMS.ORDescriptor.telephone-numberは省略されるべきです。
If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier, IPMS.RecipientSpecifier.reply-request and IPMS.RecipientSpecifier.notification-requests should be set to default values (none and false).
IPMS.ORDescriptorがIPMS.RecipientSpecifierで使用されているなら、IPMS.RecipientSpecifier.reply-要求とIPMS.RecipientSpecifier.notification-要求はデフォルト値(なにもと虚偽)に設定されるべきです。
If the 822.group construct is present, any included 822.mailbox should be encoded as above to generate a separate IPMS.ORDescriptor. The 822.group should be mapped to T.61, and a IPMS.ORDescriptor with only an free-form-name component built from it.
822.group構造物が存在しているなら、どんな含まれている822.mailboxも、別々のIPMS.ORDescriptorを発生させるように同じくらい上でコード化されるべきです。 無料のフォーム名のコンポーネントだけがそれから造られている状態で、822.groupはT.61、およびIPMS.ORDescriptorに写像されるべきです。
4.7.2. X.400 -> RFC 822
4.7.2. X.400->RFC822
Mapping from IPMS.ORDescriptor to RFC 822 address. In the basic case, where IPMS.ORDescriptor.formal-name is present, proceed as follows.
IPMS.ORDescriptorからRFC822アドレスまで写像します。 基本的な場合では、以下の通り続いてください。そこでは、IPMS.ORDescriptor.formal-nameが出席しています。
1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as
EBNF.822-address.
1. EBNF.822-アドレスとしてIPMS.ORDescriptor.formal-name(MTS.ORName)をコード化してください。
2a. If IPMS.ORDescriptor.free-form-name is present, convert it
to ASCII (Chapter 3), and use this as the 822.phrase
component of 822.mailbox using the 822.phrase 822.route-addr
construct.
2a。 IPMS.ORDescriptor.freeフォーム名が存在しているなら、ASCII(第3章)にそれを変換してください、そして、822.mailboxの822.phraseの部品として822.phrase 822.route-addr構造物を使用することでこれを使用してください。
2b. If IPMS.ORDescriptor.free-form-name is absent. If
EBNF.822-address is parsed as 822.addr-spec use this as the
encoding of 822.mailbox. If EBNF.822-address is parsed as
822.route 822.addr-spec, then a 822.phrase taken from
822.local-part should be added.
2b。 IPMS.ORDescriptor.freeフォーム名が欠けるなら。 EBNF.822-アドレスが822.addr-仕様として分析されるなら、822.mailboxのコード化としてこれを使用してください。 EBNF.822-アドレスが822.route 822.addr-仕様として分析されるなら、822.local-部分から取られた822.phraseは加えられるべきです。
3. If IPMS.ORDescriptor.telephone-number is present, this
should be placed in an 822.comment, with the string "Tel ".
The normal international form of number should be used. For
example:
3. IPMS.ORDescriptor.telephone-numberが存在しているなら、これはストリング"Tel"と共に822.commentに置かれるべきです。 正常な国際的なフォームの数は使用されるべきです。 例えば:
(Tel +44-1-387-7050)
(Tel+44-1-387-7050)
Kille [Page 49] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[49ページ]RFC1138
4. If IPMS.ORDescriptor.formal-name.directory-name is present,
then a text representation should be placed in a trailing
822.comment.
4. IPMS.ORDescriptor.formal-name.directory-nameが存在しているなら、テキスト表現は引きずっている822.commentに置かれるべきです。
5. If IPMS.RecipientSpecifier.report-request has any non-
default values, then an 822.comment "(Receipt Notification
Requested)", and/or "(Non Receipt Notification Requested)",
and/or "(IPM Return Requested)" should be appended to the
address. The effort of correlating P1 and P2 information is
too great to justify the gateway sending Receipt
Notifications.
5. IPMS.RecipientSpecifier.report-要求に何か非デフォルト値があるなら、822.comment「(通知が要求した領収書)」、「(通知が要求した非領収書)」、そして/または、「(要求されたIPMリターン)」をアドレスに追加するべきです。 P1とP2情報を関連させる努力はゲートウェイがReceipt Notificationsを送るのを正当化できないくらい大きいです。
6. If IPMS.RecipientSpecifier.reply-request is True, an
822.comment "(Reply requested)" should be appended to the
address.
6. IPMS.RecipientSpecifier.reply-要求がTrueであるなら、「(要求された回答)」という822.commentをアドレスに追加するべきです。
If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free- form-name should be converted to ASCII, and used as 822.phrase within the RFC 822 822.group syntax. For example:
IPMS.ORDescriptor.formal-nameが欠けるなら、IPMS.ORDescriptor.freeフォーム名は、ASCIIに変換されて、822.phraseとしてRFC 822 822.group構文の中で使用されるべきです。 例えば:
Free Form Name ":" ";"
「フォーム名を解放してください」:、」 ";"
Steps 3-6 should then be followed.
そして、方法3-6は従われるべきです。
4.7.3. IP Message IDs
4.7.3. IPメッセージID
There is a need to map both ways between 822.msg-id and IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications, Replies, and Cross References to reference an RFC 822 Message ID, which is preferable to a gateway generated ID. A reversible and symmetrical mapping is defined. This allows for good things to happen when messages pass multiple times across the X.400/RFC 822 boundary.
822.msg-イドとIPMS.IPMIdentifierの間には、両方の道を写像する必要があります。 これは参照RFC822Message IDへのX.400 Receipt Notifications、Replies、およびCross Referencesを考慮します。(IDはゲートウェイ発生しているIDより望ましいです)。 リバーシブルの、そして、対称のマッピングは定義されます。 メッセージがX.400/RFC822境界の向こう側に複数の回を通過するとき、これは起こる良いものを考慮します。
An important issue with messages identifiers is mapping to the exact form, as many systems use these ids as uninterpreted keys. The use of table driven mappings is not always symmetrical, particularly in the light of alternative domain names, and alternative management domains. For this reason, a purely algorithmic mapping is used. A mapping which is simpler than that for addresses can be used for two reasons:
メッセージ識別子の切迫した課題は正確なフォームへのマッピングです、多くのシステムが非解釈されたキーとしてこれらのイドを使用するとき。 テーブルの駆動マッピングの使用はいつも対称であるというわけではありません、特に代替のドメイン名、および代替の管理ドメインの見地から。 この理由で、純粋にアルゴリズムのマッピングは使用されています。 2つの理由にアドレスのためのそれを使用できるより簡単なマッピング:
- There is no major requirement to make message IDs "natural"
- メッセージIDを「自然に」するというどんな主要な要件もありません。
- There is no issue about being able to reply to message IDs.
(For addresses, creating a return path which works is more
important than being symmetrical).
- メッセージIDに答えることができることに関する問題が全くありません。 (アドレスにおいて、働いているリターンパスを作成するのは対称であるより重要です。)
Kille [Page 50] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[50ページ]RFC1138
The mapping works by defining a way in which message IDs generated on one side of the gateway can be represented on the other side in a systematic manner. The mapping is defined so that the possibility of clashes is is low enough to be treated as impossible.
マッピングは、反対側の上に系統的な方法でゲートウェイの半面の上で発生するメッセージIDを表すことができる方法を定義することによって、働いています。 マッピングは衝突の可能性がそうである定義されたそうが不可能であるとして扱うことができるくらい低いということです。
4.7.3.1. 822.msg-id represented in X.400
4.7.3.1. 822. X.400に表されたmsg-イド
IPMS.IPMIdentifier.user is omitted. The IPMS.IPMIdentifier.user-
relative-identifier is set to a printable string encoding of the
822.msg-id with the angle braces ("<" and ">") removed.
IPMS.IPMIdentifier.userは省略されます。 IPMS.IPMIdentifier.userの相対的な識別子は角度支柱("<"と">")による822.msg-イドのコード化が取り除いた印刷可能なストリングに設定されます。
4.7.3.2. IPMS.IPMIdentifier represented in RFC 822
4.7.3.2. RFC822に表されたIPMS.IPMIdentifier
The 822.domain of 822.msg-id is set to the value "MHS". The 822.local-part of 822.msg-id is built as:
822.msg-イドの822.domainは値の「MHS」に用意ができています。 822.msg-イドの822.local-部分は以下として造られます。
[ printablestring ] "*" [ std-or-address ]
[printablestringします] 「*」[stdかアドレス]
with EBNF.printablestring being the IPMS.IPMIdentifier.user- relative-identifier, and std-or-address being an encoding of the IPMS.IPMIdentifier.user. If necessary, the 822.quoted-string encoding is used. For example:
EBNF.printablestringがIPMS.IPMIdentifier.userの相対的な識別子であり、stdかアドレスがIPMS.IPMIdentifier.userのコード化であることで。 必要なら、822.quoted-stringコード化は使用されています。 例えば:
<"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS>
「147 */Sはディートリッヒ/O=シーメンス/ADMD=DBP/C=DE/と等しい」という<@MHS>。
4.7.3.3. 822.msg-id -> IPMS.IPMIdentifier
4.7.3.3. 822. msg-イド->IPMS.IPMIdentifier
If the 822.local-part can be parsed as:
822.local-部分がそうすることができるなら、以下として分析されてください。
[ printablestring ] "*" [ std-or-address ]
[printablestringします] 「*」[stdかアドレス]
and the 822.domain is "MHS", then this ID was X.400 generated. If EBNF.printablestring is present, the value is assigned to IPMS.IPMIdentifier.user-relative-identifier. If EBNF.std-or-address is present, the O/R Address components derived from it are used to set IPMS.IPMIdentifier.user.
そして、822.domainが「MHS」である、そして、このIDは発生するX.400でした。 EBNF.printablestringが存在しているなら、値はIPMS.IPMIdentifier.userの相対的な識別子に割り当てられます。 EBNF.stdかアドレスが存在しているなら、それから得られたO/R Addressの部品は、IPMS.IPMIdentifier.userを設定するのに使用されます。
Otherwise, this is an RFC 822 generated ID. In this case, set IPMS.IPMIdentifier.user-relative-identifier to a printable string encoding of the 822.msg-id without the angle braces.
さもなければ、これはRFC822発生しているIDです。 この場合、角度支柱なしで822.msg-イドをコード化する印刷可能なストリングにIPMS.IPMIdentifier.userの相対的な識別子を設定してください。
4.7.3.4. IPMS.IPMIdentifier -> 822.msg-id
4.7.3.4. IPMS.IPMIdentifier->822.msg-イド
If IPMS.IPMIdentifier.user is absent, and IPMS.IPMIdentifier.user- relative-identifier mapped to ASCII and angle braces added parses as 822.msg-id, then this is an RFC 822 generated ID.
IPMS.IPMIdentifier.userが欠けていて、ASCIIに写像された相対的な識別子と角度支柱が加えたIPMS.IPMIdentifier.userが822.msg-イドとして分析するなら、これはRFC822発生しているIDです。
Otherwise, the ID is X.400 generated. Use the
さもなければ、IDは発生するX.400です。 使用
Kille [Page 51] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[51ページ]RFC1138
IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form string. Build the 822.local-part of the 822.msg-id with the syntax:
EBNF.stdかアドレスを作るIPMS.IPMIdentifier.userはストリングを形成します。 構文で822.msg-イドの822.local-部分を造ってください:
[ printablestring ] "*" [ std-or-address ]
[printablestringします] 「*」[stdかアドレス]
The printablestring is taken from IPMS.IPMIdentifier.user-relative- identifier. Use 822.quoted-string if necessary. The 822.msg-id is generated with this 822.local-part, and "MHS" as the 822.domain.
printablestringはIPMS.IPMIdentifier.user相対的な識別子から抜粋されます。 必要なら、822.quoted-stringを使用してください。 822.msg-イドはこの822.local-部分、および「MHS」と共に822.domainとして発生します。
4.7.3.5. Phrase form
4.7.3.5. 句のフォーム
In "Reply-To:" and "References:", the encoding 822.phrase may be used as an alternative to 822.msg-id. To map from 822.phrase to IPMS.IPMIdentifier, assign IPMS.IPMIdentifier.user-relative- identifier to the phrase. When mapping from IPMS.IPMIdentifier for "Reply-To:" and "References:", if IPMS.IPMIdentifier.user is absent and IPMS.IPMIdentifier.user-relative-identifier does not parse as 822.msg-id, generate an 822.phrase rather than adding the domain MHS.
「Reply-To」で そして、「以下に参照をつける」、コード化している822.phraseは822.msg-イドに代わる手段として使用されるかもしれません。 822.phraseから句へのIPMS.IPMIdentifier.user相対的な識別子のIPMS.IPMIdentifier、案配まで写像するために。 IPMS.IPMIdentifierから、「Reply-To」のために写像します。 そして、「参照:」 IPMS.IPMIdentifier.userが欠けていて、IPMS.IPMIdentifier.userの相対的な識別子が822.msg-イドとして分析されないなら、ドメインMHSを加えるより822.phraseをむしろ発生させてください。
4.7.3.6. RFC 987 backwards compatibility
4.7.3.6. RFC987の遅れている互換性
The mapping proposed here is different to that used in RFC 987, as the RFC 987 mapping lead to changed message IDs in many cases. Fixing the problems is preferable to retaining backwards compatibility. An implementation of this standard is encouraged to recognise message IDs generated by RFC 987.
ここで提案されたマッピングはRFC987で使用されるそれに異なっています、多くの場合における変えられたメッセージIDへのRFC987マッピングリードとして。 問題を修正するのは後方に互換性を保有するより望ましいです。 この規格の実現がRFC987によって発生したメッセージIDを認識するよう奨励されます。
Chapter 5 -- Detailed Mappings
第5章--詳細なマッピング
This chapter gives detailed mappings for the functions outlined in Chapters 1 and 2. It makes extensive use of the notations and mappings defined in Chapters 3 and 4.
本章は第1章と第2章で概説された機能のための詳細なマッピングを与えます。 それで、第3章と第4章で記法とマッピングの大規模な使用を定義します。
5.1. RFC 822 -> X.400
5.1. RFC822->X.400
5.1.1. Basic Approach
5.1.1. 基本的なアプローチ
A single IP Message is generated. The RFC 822 headers are used to generate the IPMS.Heading. The IP Message will have one IA5 IPMS.BodyPart containing the RFC 822 message body.
独身のIP Messageは発生します。 RFC822ヘッダーは、IPMS.Headingを発生させるのに使用されます。 IP Messageには、RFC822メッセージボディーを含む1IA5 IPMS.BodyPartがあるでしょう。
Some RFC 822 fields cannot be mapped onto a standard IPM Heading field, and so an extended field is defined in Section 5.1.2. This is then used for fields which cannot be mapped onto existing services.
いくつかのRFC822分野を標準のIPM Headingフィールドに写像できないので、拡張分野はセクション5.1.2で定義されます。 そして、これは既存のサービスに写像できない分野に使用されます。
The message is submitted to the MTS, and the services required can be defined by specifying MTS.MessageSubmissionEnvelope. A few parameters of the MTA Abstract service are also specified, which are
MTSにメッセージを提出します、そして、MTS.MessageSubmissionEnvelopeを指定することによって、必要であるサービスは定義できます。 また、いくつかの抽象的にMTAサービスのパラメタ(そうする)が指定されます。
Kille [Page 52] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[52ページ]RFC1138
not in principle available to the MTS User. Use of these services allows RFC 822 MTA level parameters to be carried in the analogous X.400 service elements. The advantages of this mapping far outweigh the layering violation.
原則としてMTS Userに利用可能ではありません。 これらのサービスの使用は、RFC822のMTAの平らなパラメタが類似のX.400サービス要素で運ばれるのを許容します。 これが遠くに写像される利点はレイヤリング違反を十二分に補います。
5.1.2. X.400 Extension Field
5.1.2. X.400拡大分野
An IPMS Extension is defined:
IPMS Extensionは定義されます:
rfc-822-field HEADING-EXTENSION
VALUE RFC822Field
::= id-rfc-822-field
rfc822分野HEADING-EXTENSION VALUE RFC822Field:、:= rfc822がさばくイド
RFC822Field ::= IA5String
RFC822Field:、:= IA5String
The Object Identifier id-rfc-822-field is defined in Appendix D.
rfc822がさばくObject IdentifierイドはAppendix Dで定義されます。
To encode any RFC 822 Header using this extension, the RFC822Field should be set to the 822.field omitting the trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). Structured fields should be unfolded. There should be no space before the ":". The reverse mapping builds the RFC 822 field in a straightforward manner.
この拡張子を使用することでどんなRFC822Headerもコード化するために、RFC822Fieldは引きずっているCRLFを省略する822.fieldに用意ができるべきです(例えば、「1日の果物: キウイ果物」)。 構造化された分野は繰り広げられるべきです。 「以前そこでは、スペースであるべきでない、」、:、」 RFC822が正直な態度でさばく体格を写像する逆。
5.1.3. Generating the IPM
5.1.3. IPMを発生させます。
The IPM (IPMS Service Request) is generated according to the rules of this section. The IPMS.IPM.body usually consists of one IPMS.BodyPart of type IPMS.IA5TextbodyPart with IPMS.IA5TextBodyPart.parameters.repertoire set to the default (ia5) which contains the body of the RFC 822 message. The exception is where there is a "Comments:" field in the RFC 822 header.
このセクションの規則に従って、IPM(IPMS Service Request)は発生します。 通常、IPMS.IPM.bodyはRFC822メッセージのボディーを含むデフォルト(ia5)に用意ができているIPMS.IA5TextBodyPart.parameters.repertoireと共にタイプIPMS.IA5TextbodyPartの1IPMS.BodyPartから成ります。 例外はaがあるところで「以下について論評する」ということです。 RFCで822ヘッダーをさばいてください。
If no specific 1988 features are used, the IPM generated should be encoded as content type 2. Otherwise, it should be encoded as content type 22. The latter will always be the case if extension heading fields are generated.
特定のどんな1988の特徴も使用されていないなら、発生するIPMは満足しているタイプ2としてコード化されるべきです。 さもなければ、それは満足しているタイプ22としてコード化されるべきです。 拡大見出し分野が発生するなら、後者はいつもケースになるでしょう。
When generating the IPM, the issue of upper bounds must be considered. At the MTS and MTA level, this specification is strict about enforcing upper bounds. Three options are available at the IPM level. Use of any of these options conforms to this standard.
IPMを発生させるとき、上限の問題を考えなければなりません。 MTSとMTAレベルでは、この仕様は上限を実施することに関して厳しいです。 3つのオプションがIPMレベルで利用可能です。 これらのオプションのどれかの使用はこの規格に従います。
1. Ignore upper bounds, and generate messages in the natural
manner. This assumes that if any truncation is done, it
will happen at the recipient UA. This will maximise
transfer of information, but may break some recipient UAs.
1. 上限を無視してください、そして、生まれながらの方法によるメッセージを発生させてください。 これは、何かトランケーションが完了していると、それが受取人UAで起こると仮定します。 これは、情報の転送を最大にしますが、いくつかの受取人UAsを壊すかもしれません。
2. Reject any inbound message which would cause a message
2. メッセージを引き起こすあらゆる本国行きのメッセージを拒絶してください。
Kille [Page 53] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[53ページ]RFC1138
violating constraints to be generated. This will be robust,
but may prevent useful communication.
発生するという規制に違反します。 これは、強健ですが、役に立つコミュニケーションを防ぐかもしれません。
3. Truncate fields to the upper bounds specified in X.400.
This will prevent problems with UAs which enforce upper
bounds, but will sometimes discard useful information.
3. X.400で指定された上限に分野に先端を切らせてください。 これは、上限を実施するUAsに関する問題を防ぎますが、時々役に立つ情報を捨てるでしょう。
These choices have different advantages and disadvantages, and the choice will depend on the exact application of the gateway.
これらの選択には、異なった利点と損失があります、そして、この選択はゲートウェイの正確なアプリケーション次第でしょう。
The rest of this section concerns IPMS.IPM.heading (IPMS.Heading). The only mandatory component of IPMS.Heading is the IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default should be generated by the gateway. With the exception of "Received:", the values of multiple fields should be merged (e.g., If there are two "To:" fields, then the mailboxes of both should be used). Information should be generated from the standard RFC 822 Headers as follows:
このセクションの残りはIPMS.IPM.heading(IPMS.Heading)に関係があります。 IPMS.Headingの唯一の義務的な部品がIPMS.Heading.this-IPM(IPMS.IPMIdentifier)です。 デフォルトはゲートウェイで発生するべきです。 「受け取ったこと」を除いて、複数の分野の値は合併されるべきです(例えば、そこのIfが2つの「To:」分野である、次に、両方のメールボックスは使用されるべきです)。 情報は以下の標準のRFC822Headersから発生するべきです:
Date:
Ignore (Handled at MTS level)
日付: 無視します。(MTSレベルでは、扱われます)
Received:
Ignore (Handled at MTA level)
受け取られている: 無視します。(MTAレベルでは、扱われます)
Message-Id:
Mapped to IPMS.Heading.this-IPM. For these, and all other
fields containing 822.msg-id the mappings of Chapter 4 are
used for each 822.msg-id.
メッセージイド: IPMS.Heading.this-IPMに写像されます。 これら、および822.msg-イドを含む他のすべての分野において、第4章のマッピングは各822.msg-イドに使用されます。
From:
If Sender: is present, this is mapped to
IPMS.Heading.authorizing-users. If not, it is mapped to
IPMS.Heading.originator. For this, and other components
containing addresses, the mappings of Chapter 4 are used
for each address.
From: 送付者であるなら: 存在している、これはIPMS.Heading.authorizing-ユーザに写像されます。 そうでなければ、それはIPMS.Heading.originatorに写像されます。 これ、およびアドレスを含む他のコンポーネントにおいて、第4章のマッピングは各アドレスに使用されます。
Sender:
Mapped to IPMS.Heading.originator.
送付者: IPMS.Heading.originatorに写像されます。
Reply-To:
Mapped to IPMS.Heading.reply-recipients.
Reply-To IPMS.Heading.reply-受取人に写像されます。
To: Mapped to IPMS.Heading.primary-recipients
To: IPMS.Heading.primary-受取人に写像されます。
Cc: Mapped to IPMS.Heading.copy-recipients.
Cc: IPMS.Heading.copy-recipientsに写像されます。
Bcc: Mapped to IPMS.Heading.blind-copy-recipients.
Bcc: IPMS.Heading.blind-写し受信者に写像されます。
Kille [Page 54] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[54ページ]RFC1138
In-Reply-To:
If there is one value, it is mapped to
IPMS.Heading.replied-to-IPM, using the 822.phrase or
822.msg-id mapping as appropriate. If there are several
values, they are mapped to IPMS.Heading.related-IPMs, along
with any values from a "References:" field.
以下に対して 1つの値があれば、適宜822.phraseか822.msg-イドマッピングを使用して、それはIPMへのIPMS.Heading.repliedに写像されます。 いくつかの値があれば、それらは、IPMS.Heading.related-IPMsに写像されて、aからのどんな値と共にも「以下に参照をつけます」。 さばきます。
References:
Mapped to IPMS.Heading.related-IPMs.
参照: IPMS.Heading.related-IPMsに写像されます。
Keywords:
Mapped onto a heading extension.
キーワード: 見出し拡張子に写像されます。
Subject:
Mapped to IPMS.Heading.subject. The field-body uses the
human oriented mapping referenced in Chapter 3 from ASCII to
T.61.
Subject: IPMS.Heading.subjectに写像されます。 分野本体は第3ASCIIからT.61までの章で参照をつけられる人間の指向のマッピングを使用します。
Comments:
Generate an IPMS.BodyPart of type IPMS.IA5TextbodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the
default (ia5), containing the value of the fields, preceded
by the string "Comments: ". This body part should precede
the other one.
コメント: デフォルト(ia5)に用意ができているIPMS.IA5TextBodyPart.parameters.repertoireと共にタイプIPMS.IA5TextbodyPartのIPMS.BodyPartを発生させて、分野の値を含んでいて、先行されて、ストリングは「以下について論評します」。 ". この身体の部分はもう片方に先行するはずです。
Encrypted:
Mapped onto a heading extension.
コード化される: 見出し拡張子に写像されます。
Resent-*
Mapped onto a heading extension.
*に憤慨する、見出し拡張子に写像されます。
Note that it would be possible to use a ForwardedIPMessage
for these fields, but the semantics are (arguably) slightly
different, and it is probably not worth the effort.
しかし、これらの分野へのForwardedIPMessage、意味論が(論証上)わずかに異なっていて、それはたぶん努力の少しも価値があるのが、使用に可能でないことに注意してください。
Other Fields
In particular X-* fields, and "illegal" fields in common
usage (e.g., "Fruit-of-the-day:") are mapped onto a heading
extension, unless covered by another section or appendix of
this specification. The same treatment should be applied to
RFC 822 fields where the content of the field does not
conform to RFC 822 (e.g., a Date: field with unparsable
syntax).
フィールズIn特定のX-*がさばいて、「不法入国者」が一般的な用法でさばく(例えば、「1日に実を結ばせてください」)もう一方は見出し拡張子に写像されます、この仕様の別のセクションか付録で覆われない場合。 同じ処理は分野の内容がRFC822(例えば、「非-パー-可能」構文がある日付:分野)に従わないRFC822分野に適用されるべきです。
5.1.4. Mappings to the MTS Abstract Service
5.1.4. MTSの抽象的なサービスへのマッピング
The MTS.MessageSubmissionEnvelope comprises MTS.PerMessageSubmissionFields, and
そしてMTS.MessageSubmissionEnvelopeがMTS.PerMessageSubmissionFieldsを包括する。
Kille [Page 55] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[55ページ]RFC1138
MTS.PerRecipientMessageSubmissionFields. The mandatory parameters should be defaulted as follows.
MTS.PerRecipientMessageSubmissionFields。 義務的なパラメタはそうであるべきです。以下の通り、デフォルトとしました。
MTS.PerMessageSubmissionFields.originator-name
This is always generated from 822-MTS, as defined in
Chapter 4.
MTS.PerMessageSubmissionFields.originator-名前Thisは第4章で定義されるように822-MTSからいつも発生します。
MTS.PerMessageSubmissionFields.content-type
Set to the value implied by the encoding of the IPM (2 or
22).
IPM(2か22)のコード化で含意された値へのSetをMTS.PerMessageSubmissionFields.contentタイプしてください。
MTS.PerRecipientMessageSubmissionFields.recipient-name
These will always be supplied from 822-MTS, as defined in
Chapter 4.
第4章で定義されるように822-MTSからMTS.PerRecipientMessageSubmissionFields.recipient-名前Theseをいつも供給するでしょう。
Optional components should be left out, and default components defaulted, with two exceptions. For MTS.PerMessageSubmissionFields.per-message-indicators, the following settings should be made:
任意のコンポーネントは置かれるべきでした、そして、2つの例外に従って、デフォルトコンポーネントはデフォルトとしました。 MTS.PerMessageSubmissionFields.perメッセージインディケータにおいて、以下の設定は作られているべきです:
- Alternate recipient should be allowed, as it seems desirable
to maximise the opportunity for (reliable) delivery.
- (信頼できる)の配送の機会を最大にするのが望ましく思えるように交互の受取人は許容されるべきです。
- Content return request should be set according to the issues
discussed in Section 5.2.
- セクション5.2で議論した問題によると、満足している返送依頼は設定されるべきです。
MTS.PerMessageSubmissionFields.original-encoded-information-types should be made a set of one element BuiltInEncodedInformationTypes.ia5-text.
コード化された情報がタイプするMTS.PerMessageSubmissionFields.originalは1セットの人工の1つが要素BuiltInEncodedInformationTypes.ia5-テキストであるならそうするでしょうに。
The MTS.PerMessageSubmissionFields.content-correlator should be encoded as IA5String, and contain the Subject:, Message-ID:, Date:, and To: fields (if present). This should include the strings "Subject:", "Date:", "To:", "Message-ID:", and appropriate folding. This should be truncated to MTS.ub-content-correlator-length (512) characters. In addition, if there is a "Subject:" field, the MTS.PerMessageSubmissionFields.content-identifier, should be set to a printable string representation of the contents of it, truncated to MTS.ub-content-id-length (16). Both are used, due to the much larger upper bound of the content correlator, and that the content id is available in X.400(1984).
MTS.PerMessageSubmissionFields.content-相関器は、IA5Stringとしてコード化されて、Subject:、Message-IDを含むはずです:、日付:、およびTo: 分野(存在しているなら)。 これがストリング「Subject:」、「日付:」、「To:」を含むべきである、「Message ID: 」 折り重なりを当ててください。 これはMTS.ubの満足している相関器の長さの(512)キャラクタに先端を切られるべきです。 添加、a「Subject:」があります。 分野(MTS.PerMessageSubmissionFields.content-識別子)はMTS.ubの満足しているイドの長さの(16)に先端を切られたそれのコンテンツの印刷可能なストリング表現に設定されるべきです。 両方が満足している相関器のはるかに大きい上限のため使用されます、そして、満足しているイドはX.400(1984)で利用可能です。
5.1.5. Mappings to the MTA Abstract Service
5.1.5. MTAの抽象的なサービスへのマッピング
There is a need to map directly onto some aspects of the MTA Abstract service, for the following reasons:
直接いくつかの以下の理由のための抽象的にMTAサービスの局面に写像する必要があります:
- So the the MTS Message Identifier can be generated from the
- MTS Message Identifierが発生できるそう
Kille [Page 56] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[56ページ]RFC1138
RFC 822 Message-ID:.
RFC822Message ID:
- So that the submission date can be generated from the
822.Date.
- 服従日付が822.Dateから発生できるように。
- To prevent loss of trace information.
- トレース情報の損失を防ぐために。
- To prevent RFC 822/X.400 looping caused by distribution
lists or redirects.
- RFC822/X.400が輪にするのを防いでください。発送先リストで引き起こすか、または向け直します。
The following mappings are defined.
以下のマッピングは定義されます。
Message-Id:
If this is present, the
MTA.PerMessageTransferFields.message-identifier should be
generated from it, using the mappings described in
Chapter 4.
メッセージイド: これが存在しているなら、第4章で説明されたマッピングを使用して、MTA.PerMessageTransferFields.message-識別子はそれから発生するべきです。
Date:
This is used to set the first component of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement). The 822-MTS originator
should be mapped into an MTS.ORAddress, and used to derive
MTA.TraceInformationElement.global-domain-identifier. The
optional components of
MTA.TraceInformationElement.domain-supplied-information are
omitted, and the mandatory components are set as follows:
日付: これは、MTA.PerMessageTransferFields.trace-information(MTA.TraceInformationElement)の最初の部品を設定するのに使用されます。 822-MTS創始者は、MTS.ORAddressに写像されて、MTA.TraceInformationElement.globalドメイン識別子を引き出すのに使用されるべきです。 MTA.TraceInformationElement.domainが情報を提供していたことの任意のコンポーネントは省略されます、そして、義務的なコンポーネントは以下の通り設定されます:
MTA.DomainSuppliedInformation.arrival-time
This is set to the date derived from Date:
MTA.DomainSuppliedInformation.arrival-time Thisは日付:から引き出された日付に用意ができています。
MTA.DomainSuppliedInformation.routing-action
Set to relayed.
リレーされることへのMTA.DomainSuppliedInformation.routing-動作Set。
The first element of
MTA.PerMessageTransferFields.internal-trace-information
should be generated in an analogous manner, although this
may later be dropped (see the procedures for "Received:").
MTA.PerMessageTransferFields.internal-トレース情報の最初の要素は類似の方法で発生するべきです、これが後で落とされるかもしれませんが(「受け取った」ために手順を見てください)。
Received:
All RFC 822 trace is used to derive
MTA.PerMessageTransferFields.trace-information and
MTA.PerMessageTransferFields.internal-trace-information.
Processing of Received: lines should follow processing of
Date:, and should be done from the the bottom to the top of
the RFC 822 header (i.e., in chronological order). If other
trace elements are processed (Via:, X400-Received:), care
should be taken to keep the relative ordering correct. The
受け取られている: すべてのRFC822跡が、MTA.PerMessageTransferFields.trace-informationとMTA.PerMessageTransferFields.internal-トレース情報を引き出すのに使用されます。 受け取って、処理する、: 線に日付:の処理に続くべきであり、下部からRFC822ヘッダー(すなわち、年代順に)の先端までするべきです。 を通して他の微量元素が処理される、(: X400を受け取られていさせます:、)、相対的な注文を正しく続けるために注意するべきです。 The
Kille [Page 57] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[57ページ]RFC1138
initial element of
MTA.PerMessageTransferFields.trace-information will be
generated already (from Date:).
MTA.PerMessageTransferFields.trace-informationの初期の要素は既に(日付:から)発生するでしょう。
Consider the Received: field in question. If the "by" part
of the received is present, use it to derive an
MTS.GlobalDomainIdentifier. If this is different from the
one in the last element of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement.global-domain-identifier)
create a new MTA.TraceInformationElement, and optionally
remove
MTA.PerMessageTransferFields.internal-trace-information.
This removal should be done in cases where the message is
being transferred to another MD where there is no bilateral
agreement to preserve internal trace beyond the local MD.
The trace creation is as for internal trace described below,
except that no MTA field is needed.
受け取られているのを考えてください: 問題の分野。 受け取られていることの“by"部分が存在しているなら、それを使用して、MTS.GlobalDomainIdentifierを引き出してください。 これがMTA.PerMessageTransferFields.trace-information(MTA.TraceInformationElement.globalドメイン識別子)の最後の要素のものと異なるなら、新しいMTA.TraceInformationElementを作成してください、そして、任意にMTA.PerMessageTransferFields.internal-トレース情報を取り除いてください。 メッセージが地方のMDを超えて内部の跡を保持する二国間条約が全くない別のMDに移されている場合でこの取り外しをするべきです。 跡の創造はMTA分野が全く必要でないのを除いて、以下で説明された内部の跡に似ています。
Then add a new element (MTA.InternalTraceInformationElement)
to MTA.PerMessageTransferFields.internal-trace-information,
creating this if needed. This shall be done, even if
inter-MD trace is created. The
MTA.InternalTraceInformationElement.global-domain-identifier
should be set to the value derived. The
MTA.InternalTraceInformationElement.mta-supplied-information
(MTA.MTASuppliedInformation) should be set as follows:
その時、必要であるならこれを作成して、(MTA.InternalTraceInformationElement)は新しい要素にMTA.PerMessageTransferFields.internal-トレース情報に加えます。 相互MD跡を作成しても、これをするものとします。 MTA.InternalTraceInformationElement.globalドメイン識別子は引き出された値に設定されるべきです。 MTA.InternalTraceInformationElement.mtaが情報を提供していたのは(MTA.MTASuppliedInformation)以下の通り設定されるべきです:
MTA.MTASuppliedInformation.arrival-time
Derived from the date of the Received: line
Receivedの日付からのMTA.MTASuppliedInformation.arrival-time Derived: 線
MTA.MTASuppliedInformation.routing-action
Set to relayed
リレーされることへのMTA.MTASuppliedInformation.routing-動作Set
The MTA.InternalTraceInformationElement.mta-name should be
taken from the "by" component of the "Received:" field,
truncated to MTS.ub-mta-name-length (32). For example:
「受け取った」“by"の部品からMTA.InternalTraceInformationElement.mta-名前を取るべきです。 MTS.ub-mta名前の長さの(32)に先端を切られた分野。 例えば:
Received: from computer-science.nottingham.ac.uk by
vs6.Cs.Ucl.AC.UK via Janet with NIFTP id aa03794;
28 Mar 89 16:38 GMT
受け取られている: NIFTPイドaa03794をもっているジャネットを通したvs6.Cs.Ucl.AC.UKによるコンピュータ-science.nottingham.ac.ukから。 1989年3月28日のグリニッジ標準時16時38分
Generates the string:
ストリングを発生させます:
vs6.Cs.Ucl.AC.UK
vs6.Cs.Ucl.AC.UK
Note that before transferring the message to some ADMDs, additional trace stripping may be required, as the implied path through multiple
いくつかのADMDsにメッセージを移す前に追加跡のストリップが暗示している経路として倍数を通して必要であるかもしれないことに注意してください。
Kille [Page 58] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[58ページ]RFC1138
MDs would violate ADMD policy.
MDsはADMD方針に違反するでしょう。
Two extended fields must be mapped, in order to prevent looping. "DL-Expansion-History:" is mapped to MTA.PerMessageTransferFields.extensions.dl-expansion-history. "Redirection-History:" is mapped to MTA.PerRecipientMessageTransferFields.extensions.redirection-history.
輪にするのを防ぐために2つの拡張分野を写像しなければなりません。 「dl拡大歴史:」 MTA.PerMessageTransferFields.extensions.dl拡大歴史に写像されます。 「リダイレクション歴史:」 MTA.PerRecipientMessageTransferFields.extensions.redirection-歴史に写像されます。
5.1.6. Mapping New Fields
5.1.6. 新しい分野を写像します。
This specification defines a number of new fields for Reports, Notifications and IP Messages in Section 5.3. As this specification only aims to preserve existing services, a gateway conforming to this specification does not need to map these fields to X.400, with the exception of "DL-Expansion-History" and "Redirection-History" described in the previous section. However, it is usually desirable and beneficial to do so, particularly to facilitate support of a message traversing multiple gateways. These mappings may be onto MTA, MTS, or IPMS services.
この仕様はReports、Notifications、およびIP Messagesのためにセクション5.3で多くの新しい分野を定義します。 この仕様が、既存のサービスを保持することを目指すだけであるとき、この仕様に一致しているゲートウェイはこれらの分野をX.400に写像する必要はありません、「dl拡大歴史」と前項で説明された「リダイレクション歴史」を除いて。 しかしながら、そうして、特に複数のゲートウェイを横断するメッセージのサポートを容易にするのは、通常、望ましくて、有益です。 MTA、MTS、またはIPMSサービスにはこれらのマッピングがあるかもしれません。
5.2. Return of Contents
5.2. コンテンツの復帰
It is not clear how widely supported the X.400 return of contents service will be. Experience with X.400(1984) suggests that support of this service may not be universal. As this service is expected in the RFC 822 world, two approaches are specified. The choice will depend on the use of X.400 return of contents withing the X.400 community being serviced by the gateway.
どれくらい広く支持されていたか状態で、コンテンツサービスのX.400復帰がそうになるのは、明確ではありません。 X.400(1984)の経験は、このサービスのサポートが普遍的でないかもしれないと示唆します。 このサービスがRFC822世界で予想されるように、2つのアプローチが指定されます。 この選択はゲートウェイによってサービスを提供されるX.400共同体をふじづるで縛るコンテンツのX.400復帰の使用次第でしょう。
In environments where return of contents is widely supported, content return can be requested as a service. The content return service can then be passed back to the end (RFC 822) user in a straightforward manner.
コンテンツの復帰が広く支持される環境で、サービスとして満足しているリターンを要求できます。 そして、正直な態度で終わり(RFC822)のユーザに満足しているリターンサービスを戻すことができます。
In environments where return of contents is not widely supported, a gateway must make special provision to handle return of contents. For every message passing from RFC 822 -> X.400, content return request will not be requested, and report request always will be. When the delivery report comes back, the gateway can note that the message has been delivered to the recipient(s) in question. If a non-delivery report is received, a meaningful report (containing some or all of the original message) can be sent to the 822-MTS originator. If no report is received for a recipient, a (timeout) failure notice should be sent to the 822-MTS originator. The gateway may retransmit the X.400 message if it wishes. When this approach is taken, routing must be set up so that error reports are returned through the same MTA. This approach may be difficult to use in conjunction with some routing strategies.
コンテンツの復帰が広く支持されない環境で、ゲートウェイは、コンテンツの復帰を扱うために特別条項を作らなければなりません。 RFC822->X.400からのあらゆるメッセージ・パッシングのために、満足している返送依頼は要求されないで、レポート要求はいつも要求されるでしょう。 配送レポートが戻るとき、ゲートウェイは、問題の受取人にメッセージを送ることに注意できます。 非配送レポートが受け取られているなら、重要なレポート(オリジナルのメッセージのいくつかかすべてを含んでいる)を822-MTS創始者に送ることができます。 受取人のためにレポートを全く受け取らないなら、(タイムアウト)失敗通知を822-MTS創始者に送るべきです。 願うなら、ゲートウェイはX.400メッセージを再送するかもしれません。 このアプローチを取るとき、同じMTAを通してエラー・レポートを返すようにルーティングをセットアップしなければなりません。 このアプローチはいくつかのルーティング戦略に関連して使用するのが難しいかもしれません。
Kille [Page 59] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[59ページ]RFC1138
5.3. X.400 -> RFC 822
5.3. X.400->RFC822
5.3.1. Basic Approach
5.3.1. 基本的なアプローチ
A single RFC 822 message is generated from the incoming IP Message, Report, or IP Notification. All IPMS.BodyParts are mapped onto a single RFC 822 body. Other services are mapped onto RFC 822 header fields. Where there is no appropriate existing field, new fields are defined for IPMS, MTS and MTA services.
独身のRFC822メッセージは入って来るIPのMessage、Report、またはIP Notificationから発生します。 すべてのIPMS.BodyPartsが独身のRFC822ボディーに写像されます。 他のサービスはRFC822ヘッダーフィールドに写像されます。 どんな適切な既存の分野もないところでは、新しい分野はIPMS、MTS、およびMTAサービスのために定義されます。
The gateway mechanisms will correspond to MTS Delivery. As with submission, there are aspects where the MTA (transfer) services are also used. In particular, there is an optimisation to allow for multiple 822-MTS recipients.
ゲートウェイメカニズムはMTS Deliveryに対応するでしょう。 服従のように、局面がまたMTA(転送)サービスが利用されるところにあります。 複数の822-MTS受取人を考慮するために、特に、最適化があります。
5.3.2. RFC 822 Settings
5.3.2. RFC822設定
An RFC 822 Service requires to have a number of mandatory fields in the RFC 822 Header. Some 822-MTS services mandate specification of an 822-MTS Originator. Even in cases where this is optional, it is usually desirable to specify a value. The following defaults are defined, which should be used if the mappings specified do not derive a value:
ServiceがRFC822Headerに多くの義務的な分野を持っているのを必要とするRFC822。 いくつかの822-MTSが822-MTS Originatorの命令仕様を修理します。 これが任意である場合ではさえ、通常、値を指定するのは望ましいです。 以下のデフォルト(指定されたマッピングが値を引き出さないなら、使用されるべきである)は定義されます:
822-MTS Originator
If this is not generated by the mapping (e.g., for a
Delivery Report), a value pointing at a gateway
administrator should be assigned.
822-MTS Originator If、マッピング(例えば、Delivery Reportのための)(ゲートウェイ管理者を指し示すのが割り当てられるべきである値)でこれは発生しません。
Date:
A value will always be generated
日付: 値はいつも発生するでしょう。
From:If this is not generated by the mapping, it should be
assigned equal to the 822-MTS Originator. If this is
gateway generated, an appropriate 822.phrase should be
added.
From: これはマッピングによって発生させられないなら、それが822-MTS Originatorの同輩に割り当てられるべきです。 これが発生するゲートウェイであるなら、適切な822.phraseは加えられるべきです。
At least one recipient field
If no recipient fields are generated, a field "To: list:;",
should be added.
受取人がさばく少なくとも1受取人分野Ifノー、が発生して、分野は「To:」です。 「記載してください」;、加えられるべきです。
This will ensure minimal RFC 822 compliance. When generating RFC 822 headers, folding should be used in an appropriate manner.
これは最小量のRFC822コンプライアンスを確実にするでしょう。 RFC822ヘッダーを発生させるとき、折り重なりは適切な方法で使用されるべきです。
Kille [Page 60] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[60ページ]RFC1138
5.3.3. Basic Mappings
5.3.3. 基本のマッピング
5.3.3.1. Encoded Information Types
5.3.3.1. コード化された情報タイプ
This mapping from MTS.EncodedInformationTypes is needed in several disconnected places. EBNF is defined as follows:
MTS.EncodedInformationTypesからのこのマッピングがいくつかの外された場所で必要です。 EBNFは以下の通り定義されます:
encoded-info = 1#encoded-type
コード化されたインフォメーションは1つの#コード化されたタイプと等しいです。
encoded-type = built-in-eit / object-identifier
コード化されたタイプは物内蔵のeit/識別子と等しいです。
built-in-eit = "Undefined" ; undefined (0)
/ "Telex" ; tLX (1)
/ "IA5-Text" ; iA5Text (2)
/ "G3-Fax" ; g3Fax (3)
/ "TIF0" ; tIF0 (4)
/ "Teletex" ; tTX (5)
/ "Videotex" ; videotex (6)
/ "Voice" ; voice (7)
/ "SFD" ; sFD (8)
/ "TIF1" ; tIF1 (9)
内蔵のeit=「未定義」。 未定義の(0)/「テレックス」。 tLX(1)/「IA5テキスト」。 iA5Text(2)/「G3ファックス」。 g3Fax(3)/"TIF0""。 tIF0(4)/「テレテックス」。 tTX(5)/「ビデオテックス」。 ビデオテックス(6)/「声」。 声の(7)/"SFD"。 sFD(8)/"TIF1""。 tIF1(9)
MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info. MTS.EncodedInformationTypes.non-basic-parameters is ignored. Built in types are mapped onto fixed strings (compatible with X.400(1984) and RFC 987), and other types are mapped onto EBNF.object-identifier.
MTS.EncodedInformationTypesはEBNF.encoded-インフォメーションに写像されます。 MTS.EncodedInformationTypes.nonの基本のパラメタは無視されます。 内蔵型は固定ストリング(X.400(1984)とRFC987とのコンパチブル)に写像されます、そして、他のタイプはEBNF.object-識別子に写像されます。
5.3.3.2. Global Domain Identifier
5.3.3.2. グローバルなドメイン識別子
The following simple EBNF is used to represent MTS.GlobalDomainIdentifier:
以下の簡単なEBNFはMTS.GlobalDomainIdentifierを表すのに使用されます:
global-id = std-or-address
グローバルなイドはstdかアドレスと等しいです。
This is encoded using the std-or-address syntax, for the attributes within the Global Domain Identifier.
これは、属性にGlobal Domain Identifierの中でstdかアドレス構文を使用することでコード化されます。
5.3.4. Mappings from the IP Message
5.3.4. IPメッセージからのマッピング
Consider that an IPM has to be mapped to RFC 822. The IPMS.IPM comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is considered first. Some EBNF for new fields is defined:
IPMがRFC822に写像されなければならないと考えてください。 IPMS.IPMはIPMS.IPM.headingとIPMS.IPM.bodyを包括します。 見出しは最初に、考えられます。 新しい分野へのいくらかのEBNFが定義されます:
ipms-field = "Obsoletes" ":" 1#msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
「=が「時代遅れにする」ipms-分野」:、」 「1#msg-イド/「有効期限日」」:、」 「日付-時間/「近く、返答」」:、」 「日付-時間/「重要性」」:、」 「重要性/「感度」」:、」 感度
Kille [Page 61] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[61ページ]RFC1138
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Language" ":" language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#oid
「/は「Autoforwardedされた」」:、」 「論理演算子/「不完全なコピー」」:、」 「/「言語」」:、」 「言語/「メッセージタイプ」」:、」 「メッセージタイプ/「捨てられたX400-IPMS拡張子」」:、」 1#oid
importance = "low" / "normal" / "high"
重要性=「安値」/「標準」/「高値」
sensitivity = "Personal" / "Private" /
"Company-Confidential"
「個人的である」か「個人的な」/感度=「社内秘密」
language = 2*ALPHA [ language-description ]
language-description = printable-string
2*アルファー[言語記述]の言語言語=記述は印刷可能なストリングと等しいです。
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
メッセージタイプは「配送レポート」/「個人間の通知」/「複数の部分」と等しいです。
The mappings and actions for the IPMS.Heading is now specified for each element. Addresses, and Message Identifiers are mapped according to Chapter 4. Other mappings are explained, or are straightforward (algorithmic).
IPMS.Headingのためのマッピングと動作は現在、各要素に指定されます。 アドレス、およびMessage Identifiersはそうです。第4章に従って、写像されます。 他のマッピングは、説明されるか、または簡単です(アルゴリズムの)。
IPMS.Heading.this-IPM
Mapped to "Message-ID:".
IPMS.Heading.this-IPM、写像される、「Message ID:」
IPMS.Heading.originator
If IPMS.Heading.authorizing-users is present this is mapped
to Sender:, if not to "From:".
プレゼントはSenderに写像されます。IPMS.Heading.originator If IPMS.Heading.authorizing-ユーザ、: 「From:」に。
IPMS.Heading.authorizing-users
Mapped to "From:".
「From:」に写像されたIPMS.Heading.authorizing-ユーザ。
IPMS.Heading.primary-recipients
Mapped to "To:".
「To:」に写像されたIPMS.Heading.primary-受取人。
IPMS.Heading.copy-recipients
Mapped to "Cc:".
「Cc:」に写像されたIPMS.Heading.copy-recipients。
IPMS.Heading.blind-copy-recipients
Mapped to "Bcc:".
「Bcc:」に写像されたIPMS.Heading.blind-写し受信者。
IPMS.Heading.replied-to-ipm
Mapped to "In-Reply-To:".
「以下に対して」写像されたIPMS.Heading.repliedからipm。
Kille [Page 62] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[62ページ]RFC1138
IPMS.Heading.obsoleted-IPMs
Mapped to the extended RFC 822 field "Obsoletes:"
拡張RFC822分野へのIPMS.Heading.obsoleted-IPMs Mappedは「以下を時代遅れにします」。
IPMS.Heading.related-IPMs
Mapped to "References:".
IPMS.Heading.related-IPMs、写像される、「以下に参照をつけます」。
IPMS.Heading.subject
Mapped to "Subject:". The contents are converted to ASCII
(as defined in Chapter 3). Any CRLF are not mapped, but
are used as points at which the subject field must be
folded.
「Subject:」に写像されたIPMS.Heading.subject。 内容はASCIIに変換されます(第3章で定義されるように)。 どんなCRLFも写像されませんが、対象の分野を折り重ねなければならないポイントとして使用されます。
IPMS.Heading.expiry-time
Mapped to the extended RFC 822 field "Expiry-Date:".
拡張RFC822分野へのIPMS.Heading.expiry-時間Mappedは「以下と満期でデートします」。
IPMS.Heading.reply-time
Mapped to the extended RFC 822 field "Reply-By:".
拡張RFC822分野へのMappedをIPMS.Heading.reply調節してください。「返答してください。」
IPMS.Heading.reply-recipients
Mapped to "Reply-To:".
「Reply-To」に写像されたIPMS.Heading.reply-受取人。
IPMS.Heading.importance
Mapped to the extended RFC 822 field "Importance:".
拡張RFC822分野へのIPMS.Heading.importance Mapped、「重要性:」
IPMS.Heading.sensitivity
Mapped to the extended RFC 822 field "Sensitivity:".
拡張RFC822分野へのIPMS.Heading.sensitivity Mapped、「感度:」
IPMS.Heading.autoforwarded
Mapped to the extended RFC 822 field "Autoforwarded:".
拡張RFC822分野へのIPMS.Heading.autoforwarded Mapped、「Autoforwarded:」
The standard extensions (Annex H of X.420 / ISO 10021-7) are mapped as follows:
標準の拡大(X.420 / ISO10021-7の別館H)は以下の通り写像されます:
incomplete-copy
Mapped to the extended RFC 822 field "Incomplete-Copy:".
拡張RFC822分野への不完全なコピーMapped、「不完全なコピー:」
language
Mapped to the extended RFC 822 field "Language:", filling in
the two letter code. If possible, the language-description
should be filled in with a human readable description of the
language.
拡張RFC822分野への言語Mapped、「言語:」 2レター・コードでは、腹を満たします。 できれば、言語記述は言語の人間の読み込み可能な記述で記入されるべきです。
If the RFC 822 extended header is found, this should be mapped onto an RFC 822 header, as described in Section 5.1.2.
RFC822の拡張ヘッダーが見つけられるなら、これはRFC822ヘッダーに写像されるべきです、セクション5.1.2で説明されるように。
If a non-standard extension is found, it should be discarded, unless the gateway understands the extension and can perform an appropriate mapping onto an RFC 822 header field. If extensions are discarded,
標準的でない拡大が見つけられるなら、それは捨てられるべきです、ゲートウェイが拡大を理解して、RFC822ヘッダーフィールドに適切なマッピングを実行できないなら。 拡大が捨てられるなら
Kille [Page 63] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[63ページ]RFC1138
the list should be indicated in the extended RFC 822 field "Discarded-X400-IPMS-Extensions:".
リストが拡張RFC822分野で示されるべきである、「捨てられたX400-IPMS拡張子:」
The IPMS.Body is mapped into the RFC 822 message body. Each IPMS.BodyPart is converted to ASCII as follows:
IPMS.BodyはRFC822メッセージボディーに写像されます。 各IPMS.BodyPartは以下のASCIIに変換されます:
IPMS.IA5Text
The mapping is straightforward (see Chapter 3).
IPMS.IA5Text、マッピングは簡単です(第3章を参照してください)。
IPMS.MessageBodyPart
The X.400 -> RFC 822 mapping should be recursively applied,
to generate an RFC 822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope should be
used for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time should be
mapped to the extended RFC 822 field "Delivery-Date:".
RFC822Messageを発生させるように再帰的に適用されていて、->RFC822マッピングがそうするべきであるIPMS.MessageBodyPart X.400。 存在しているなら、IPMS.MessageBodyPart.parameters.delivery-封筒はMTSの抽象的なService Mappingsに使用されるべきです。 存在しているなら、IPMS.MessageBodyPart.parameters.delivery-timeが拡張RFC822分野に写像されるべきである、「納品日:」
Other
If other body parts can be mapped to IA5, either by use of
mappings defined in X.408 [CCITT88a], or by other reasonable
mappings, this should be done unless content conversion is
prohibited.
他のIf他の身体の部分をIA5に写像できます、どちらかX.408[CCITT88a]で定義されたマッピングの使用で、または、他の妥当なマッピングで、内容変換を禁止しない場合、これをするべきです。
If some or all of the body parts cannot be converted there are three options. All of these conform to this standard. A different choice may be made for the case where no body part can be converted:
身体の部分のいくつかかすべてを変換できないなら、3つのオプションがあります。 これらはすべて、この規格に従います。 身体の部分を全く変換できないケースのために異なった選択をするかもしれません:
1. The first option is to reject the message, and send a non-
delivery notification. This must always be done if
conversion is prohibited.
1. 第1の選択は、メッセージを拒絶して、非配送している通知を送ることです。 変換を禁止するなら、いつもこれをしなければなりません。
2. The second option is to map a missing body part to something
of the style:
2. 2番目のオプションはなくなった身体の部分をスタイルについて何かに写像することです:
*********************************
*********************************
There was a foobar here
foobarがここにありました。
The widget gateway ate it
ウィジェットゲートウェイはそれを食べました。
*********************************
*********************************
This will allow some useful information to be transferred.
As the recipient is a human (IPMS), then suitable action
should be available.
これは、何らかの役に立つ情報が移されるのを許容するでしょう。 受取人が人間(IPMS)であるので、その時、適当な動作は利用可能であるべきです。
3. Finally both can be done. In this case, the supplementary
information in the (positive) Delivery Report should make
3. 最終的に両方ができます。 この場合Reportがするはずである(積極的)の配送における補助情報
Kille [Page 64] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[64ページ]RFC1138
clear that something was sent on to the recipient with
substantial loss of information.
はっきりと、情報のかなりの損失はその何かを受取人に送りました。
Where there is more than one IPMS.BodyPart, the mapping defined by Rose and Stefferud in [Rose85a], should be used to map the separate IPMS.BodyParts in the single RFC 822 message body. If this is done, a "Message-Type:" field with value "Multiple part" should be added, which will indicate to a receiving gateway that the message may be unfolded according to RFC 934.
[Rose85a]の1IPMS.BodyPartがどこにあるか、そして、ローズによって定義されたマッピングとStefferudは、単一のRFC822メッセージボディーで別々のIPMS.BodyPartsを写像するのに使用されるべきです。 これが完了しているなら、aは「以下をメッセージでタイプします」。 値の「倍数部分」がある分野(RFC934によると、メッセージが繰り広げられるかもしれないのを受信ゲートウェイに示す)は加えられるべきです。
For backwards compatibility with RFC 987, the following procedures should also be followed. If there are two IA5 body parts, and the first starts with the string "RFC-822-Headers:" as the first line, then the remainder of this body part should be appended to the RFC 822 header.
また、RFC987との遅れている互換性において、以下の手順は従われるべきです。 2つのIA5身体の部分、およびひもによる最初の始めがある、「RFC822ヘッダー:」 そして、最初の線として、この身体の部分の残りをRFC822ヘッダーに追加するべきです。
5.3.5. Mappings from an IP Notification
5.3.5. IP通知からのマッピング
A message is generated, with the following fields:
メッセージは以下の分野で発生します:
From:
Set to the MTS.MessageDeliveryEnvelope.other-
fields.originator-name.
From: MTS.MessageDeliveryEnvelope.other fields.originator-名にセットしてください。
To: Set to the IPMS.IPN.ipm-originator.
To: IPMS.IPN.ipm-創始者にセットしてください。
Subject:
Set to something of the form "X.400 Inter-Personal Receipt
Notification".
Subject: 「X.400の相互個人的な領収書通知」をフォームについて何かに設定してください。
Message-Type:
Set to "InterPersonal Notification"
メッセージタイプ: 「個人間の通知」に、セットします。
References:
Set to IPMS.IPN.subject-ipm
参照: IPMS.IPN.subject-ipmに、セットします。
The following EBNF is defined for the body of the Message. This format is defined to ensure that all information from an interpersonal notification is available to the end user in a uniform manner.
以下のEBNFはMessageのボディーのために定義されます。 この書式は、エンドユーザには、個人間の通知からのすべての情報が一定の方法で利用可能であることを保証するために定義されます。
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
ipn-content-return
ipn-記述<CRLF>[ipn-その他の情報<CRLF>]のipnの満足しているipnボディー形式=リターン
ipn-description = ipn-receipt / ipn-non-receipt
ipn-記述はipn非ipn-領収書/領収書と等しいです。
ipn-receipt = "Your message to:" preferred-recipient <CRLF>
ipn-領収書=「以下へのあなたのメッセージ」 都合のよい受取人<CRLF>。
Kille [Page 65] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[65ページ]RFC1138
"was received at" receipt-time <CRLF> <CRLF>
"This notification was generated"
acknowledgement-mode <CRLF>
"The following extra information was given:" <CRLF>
ipn-suppl <CRLF>
「「以下のその他の情報を与えた」」領収書時間<CRLF><CRLF>「この通知は発生した」承認モード<CRLF>のときに、受け取りました。 <CRLF>ipn-suppl<CRLF>。
ipn-non-receipt "Your message to:"
preferred-recipient <CRLF>
ipn-reason
ipn非領収書、「以下のことのためのあなたのメッセージ」 都合のよい受取人<CRLF>ipn-理由
ipn-reason = ipn-discarded / ipn-auto-forwarded
=がipnに自動進めた状態でipnしていた状態で/を捨てたipn-理由
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipnによって捨てられる、=は「以下が以下を推論するので、捨てられました」。 理由を捨てている<CRLF>。
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
自動進めた状態でipnしている=を「自動的に、進めました」。 <CRLF>。[「以下のコメントをした」という自動コメント]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-その他の情報=「以下の情報タイプは変換されました」。 コード化されたインフォメーション
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
ipn満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。 <CRLF><CRLF>メッセージ
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
日付-時間自動都合のよい受取人=メールボックス領収書時間=コメント=printablestring ipn-supplはprintablestringと等しいです。
non-receipt-reason = "Discarded" / "Auto-Forwarded"
=が「自動進められた」状態で/を「捨てた」非領収書の理由
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated"
破棄して推論している=は、「ユーザ購読は終えた」/を「吐き出す」か、または「時代遅れにしました」。
acknowledgement-mode = "Manually" / "Automatically"
承認モードは「自動的に」「手動」という/と等しいです。
The mappings for elements of the common fields of IPMS.IPN (IPMS.CommonFields) onto this structure and the message header are:
この構造とメッセージヘッダーへのIPMS.IPN(IPMS.CommonFields)の共同耕地の要素のためのマッピングは以下の通りです。
subject-ipm
Mapped to "References:"
ipm Mappedをかける、「参照:」
Kille [Page 66] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[66ページ]RFC1138
ipm-originator
Mapped to "To:".
「To:」へのipm-創始者Mapped。
ipm-preferred-recipient
Mapped to EBNF.preferred-recipient
EBNF.preferred-受取人へのipmの都合のよい受取人Mapped
conversion-eits
Mapped to EBNF.encoded-info in EBNF.ipn-extra-information
EBNF.ipn-その他の情報のEBNF.encoded-インフォメーションへの変換-eits Mapped
The mappings for elements of IPMS.IPN.non-receipt-fields
(IPMS.NonReceiptFields) are:
IPMS.IPN.non領収書分野(IPMS.NonReceiptFields)の要素のためのマッピングは以下の通りです。
non-receipt-reason
Used to select between EBNF.ipn-discarded and
EBNF.ipn-auto-forwarded
そして、非領収書の理由Used、EBNF.ipnによって捨てられることの間で選択する、EBNF.ipn、自動進められる。
discard-reason
Mapped to EBNF.discard-reason
EBNF.discard-理由への理由を捨てているMapped
auto-forward-comment
Mapped to EBNF.auto-comment
EBNF.auto-コメントへの自動前進のコメントMapped
returned-ipm
If present, the second option of EBNF.ipn-content-return
should be chosen, and an RFC 822 mapping of the message
included. Otherwise the first option should be chosen.
現在の返されたipm If、EBNF.ipnの満足しているリターンの2番目のオプションは、選ばれていて、メッセージに関するRFC822マッピングを含むことであるべきです。 さもなければ、第1の選択は選ばれるべきです。
The mappings for elements of IPMS.IPN.receipt-fields
(IPMS.ReceiptFields) are:
IPMS.IPN.receipt-分野(IPMS.ReceiptFields)の要素のためのマッピングは以下の通りです。
receipt-time
Mapped to EBNF.receipt-time
領収書時間MappedからEBNF.receipt-時間
acknowledgement-mode
Mapped to EBNF.acknowledgement-mode
EBNF.acknowledgement-モードへの承認モードMapped
suppl-receipt-info
Mapped to EBNF.ipn-suppl
EBNF.ipn-supplへのsuppl領収書インフォメーションMapped
An example notification is:
例の通知は以下の通りです。
From: Steve Kille <steve@cs.ucl.ac.uk>
To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
Subject: X400 Inter-personal Receipt Notification
Message-Type: InterPersonal Notification
References: <1229.614418325@UK.AC.NOTT.CS>
Date: Wed, 21 Jun 89 08:45:25 +0100
From: スティーブ Kille <steve@cs.ucl.ac.uk 、gt;、To: ジュリアン Onions <jpo@computer-science.nottingham.ac.uk 、gt;、Subject: X400の相互個人的な領収書通知メッセージタイプ: 個人間の通知参照: <1229.614418325@UK.AC.NOTT.CS>日付: 水曜日、1989年6月21日の08:45:25+0100
Kille [Page 67] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[67ページ]RFC1138
Your message to: Steve Kille <steve@cs.ucl.ac.uk>
was automatically forwarded.
The following comment was made:
Sent on to a random destination
以下へのあなたのメッセージ スティーブ Kille <steve@cs.ucl.ac.uk 、gt;、自動的に、進めました。 以下のコメントをしました: 無作為の目的地に発信します。
The following information types were converted: g3fax
以下の情報タイプは変換されました: g3fax
The Original Message is not available
Original Messageは利用可能ではありません。
5.3.6. Mappings from the MTS Abstract Service
5.3.6. MTSの抽象的なサービスからのマッピング
This section describes the MTS mappings for User Messages (IPM and IPN). This mapping is defined by specifying the mapping of MTS.MessageDeliveryEnvelope. The following extensions to RFC 822 are defined to support this mapping:
このセクションはUser Messages(IPMとIPN)のためのMTSマッピングについて説明します。 このマッピングは、MTS.MessageDeliveryEnvelopeに関するマッピングを指定することによって、定義されます。 RFC822への以下の拡大はこのマッピングを支持するために定義されます:
mts-field = "X400-MTS-Identifier" ":" mts-msg-id
/ "X400-Originator" ":" mailbox
/ "X400-Recipients" ":" 1#mailbox
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Content-Type" ":" mts-content-type
/ "Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"
/ "Redirection-History" ":" redirection
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Requested-Delivery-Method" ":"
1*( labelled-integer )
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( oid / labelled-integer )
「mts-分野=「X400-MTS-識別子」」:、」 「mts-msg-イド/「X400創始者」」:、」 「メールボックス/「X400受取人」」:、」 「1#メールボックス/「元のコード化された情報タイプ」」:、」 「コード化されたインフォメーション/「X400コンテントタイプ」」:、」 「mtsの満足しているタイプ/「満足している識別子」」:、」 「printablestring/「優先権」」:、」 「優先権/「創始者返送先」」:、」 「1#メールボックス/「dl拡大歴史」」:、」 「メールボックス」;、」 「日付-時間」;、」 「/「リダイレクション歴史」」:、」 「リダイレクション/「変換」」:、」 「禁止/「損失との変換」」:、」 「禁止/「要求された発送方法」」:、」 「1*(ラベルされた整数)の/「納品日」」:、」 「日付-時間/「捨てられたX400-MTS拡張子」」:、」 1#(ラベルされたoid/整数)
prohibition = "Prohibited" / "Allowed"
=が「禁止する」か、または「許容した」禁止
mts-msg-id = "[" global-id ";" *text "]"
「mts-msg-イド=、「[「グローバルなイド」;、」 *テキスト、」、]、」
mts-content-type = "P2" / labelled-integer
/ object-identifer
mtsの満足しているタイプは「物ラベルされたP2"/整数/identifer」と等しいです。
priority = "normal" / "non-urgent" / "urgent"
優先権は「正常である」か「不急」の/と「緊急」の状態で等しいです。
redirection = mailbox ";" "reason" "="
redirection-reason
";" date-time
「リダイレクション=メールボックス」;、」 「「理由」は「」 リダイレクション理由と等しいです」」 日付-時間
Kille [Page 68] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[68ページ]RFC1138
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
リダイレクション理由は「受取人の割り当てられた交互の受取人」/「創始者の要求された交互の受取人」/「受取人のMdの割り当てられた交互の受取人」と等しいです。
These elements are only appropriate for physical delivery. They
are represented as comments in the "X400-Recipients:" field, as
described in Section 4.6.2.2.
物理的な配送だけに、これらの要素は適切です。 それらがコメントとして中に表される、「X400-受取人:」 分野セクション4.6.2で.2に説明されて、
originator-certificate message-token content-confidentiality-algorithm-identifier content-integrity-check message-origin-authentication-check message-security-label proof-of-delivery-request
配送要求の創始者証明書メッセージ象徴満足している秘密性アルゴリズム識別子満足している保全チェックメッセージ起源認証チェックメッセージ機密保護ラベル証拠
These elements imply use of security services not available in the
RFC 822 environment. If they are marked as critical for transfer
or delivery, then the message should be rejected. Otherwise they
should be discarded.
これらの要素はRFC822環境で利用可能でないセキュリティー・サービスの使用を含意します。 それらが転送か配送に重要であるとしてマークされるなら、メッセージは拒絶されるべきです。 さもなければ、それらは捨てられるべきです。
redirection-history
Each element is mapped to an extended RFC 822 field
"Redirection-History:". They should be ordered in the
message header, so that the most recent redirection comes
first (same order as trace).
リダイレクション歴史Each要素が拡張RFC822分野に写像される、「リダイレクション歴史:」 それらがメッセージヘッダーで注文されるべきであるので、その最新のリダイレクションは一番になります(跡と同じオーダー)。
dl-expansion-history
Each element is mapped to the extended RFC 822 field
"DL-Expansion-History:". They should be ordered in the
message header, so that the most recent expansion comes
first (same order as trace).
dl拡大歴史Each要素が拡張RFC822分野に写像される、「dl拡大歴史:」 それらがメッセージヘッダーで注文されるべきであるので、最新の拡大は一番になります(跡と同じオーダー)。
If any MTS (or MTA) Extensions not specified in X.400 are present, and they are marked as critical for transfer or delivery, then the message should be rejected. If they are not so marked, they can safely be discarded. The list of discarded fields should be indicated in the extended header "Discarded-X400-MTS-Extensions:".
X.400で指定されなかった少しのMTS(または、MTA)拡張子も存在していて、それらが転送か配送に重要であるとしてマークされるなら、メッセージは拒絶されるべきです。 それらがそのようにマークされないなら、安全にそれらを捨てることができます。 捨てられた分野のリストが拡張ヘッダーで示されるべきである、「捨てられたX400-MTS拡張子:」
5.3.7. Mappings from the MTA Abstract Service
5.3.7. MTAの抽象的なサービスからのマッピング
There are some mappings at the MTA Abstract Service level which are done for IPM and IPN. These can be derived from MTA.MessageTransferEnvelope. The reasons for the mappings at this level, and the violation of layering are:
MTAの抽象的なServiceレベルにおけるIPMとIPNのために行われるいくつかのマッピングがあります。 MTA.MessageTransferEnvelopeからこれらを得ることができます。 このレベルにおけるマッピングの理由、およびレイヤリングの違反は以下の通りです。
Kille [Page 69] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[69ページ]RFC1138
- Allowing for multiple recipients to share a single RFC 822
message.
- 複数の受取人が独身のRFC822メッセージを共有するのを許容します。
- Making the X.400 trace information available on the RFC 822
side.
- X.400をRFC822側で利用可能なトレース情報にします。
- Making any information on deferred delivery available.
- 延期した納入のどんな情報も利用可能にします。
The 822-MTS recipients should be calculated from the full list of X.400 recipients. This is all of the members of MTA.MessageTransferEnvelope.per-recipient-fields being passed through the gateway, where the responsibility bit is set. In some cases, a different RFC 822 message would be calculated for each recipient. If this is due to differing service requests for each recipient, then a different message should be generated. If it is due only to the request for non-disclosure of recipients, then the "X400-Recipients:" field should be omitted, and only one message sent.
822-MTS受取人はX.400受取人の完全リストから計算されるべきです。 ゲートウェイ(責任ビットは設定される)を通り抜けながら、これはMTA.MessageTransferEnvelope.per受取人分野のメンバーのすべてです。 いくつかの場合、異なったRFC822メッセージは各受取人のために計算されるでしょう。 これが各受取人への異なったサービスのリクエストのためであるなら、異なったメッセージは発生するべきです。 次に、それが受取人の非公開を求める要求だけのためである、「X400-受取人:」 分野は省略されるべきでした、そして、1つのメッセージだけが発信しました。
The following EBNF is defined for extended RFC 822 headers:
以下のEBNFは拡張RFC822ヘッダーのために定義されます:
mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
/ "Latest-Delivery-Time" ":" date-time
「mta-分野=は「X400受信」だった」:、」 「x400-跡/「延期した納入」」:、」 「日付-時間/「最新の納期」」:、」 日付-時間
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-and-mta ";" ]
action-list
";" arrival-time
「x400-跡=“by"Mdとmta」、;、」 [「「」日付-時間まで延期される」;、」、]、[「変換される」、「(「コード化されたインフォメーション」)」という」、;、」、]、[「」 Mdとmtaを試みる」;、」、]、動作リスト、」、;、」 到着時間
md-and-mta = [ "mta" mta "in" ] global-id
mta = word
arrival-time = date-time
Mdとmta=["mta"mta “in"]グローバルなイドmta=単語到着時間=日付-時間
action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
「向け直される」か、「広げられる」、「リレーされる」、または「別ルートで送られた」動作リスト=1#動作動作=
If MTA.PerMessageTransferFields.deferred-delivery-time is present, use it to generate a Deferred-Delivery: field. For some reason, X.400 does not make this information available at the MTS level on
MTA.PerMessageTransferFields.deferred-納期が存在しているなら、それを使用して、Deferred-配送を発生させてください: さばきます。 ある理由で、X.400はMTSレベルで利用可能なこの情報をオンにしません。
Kille [Page 70] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[70ページ]RFC1138
delivery. X.400 profiles, and in particular the CEN/CENELEC profile for X.400(1984) [Systems85a], specify that this element must be supported at the first MTA. If it is not, the function may optionally be implemented by the gateway: that is, the gateway should hold the message until the time specified in the protocol element. Thus, it is expected that the value of this element will often be in the past. For this reason, the extended RFC 822 field is primarily for information.
配送。 X.400プロフィール、およびX.400(1984)[Systems85a]のための特にCEN/CENELECプロフィールは、最初のMTAでこの要素を支えなければならないと指定します。 それがそうでないなら、機能はゲートウェイによって任意に実行されるかもしれません: 時間がプロトコル要素で指定するまで、すなわち、ゲートウェイはメッセージを保持するはずです。 したがって、この要素の価値が過去にしばしばあると予想されます。 この理由で、拡張RFC822分野は主として情報のためのものです。
Merge MTA.PerMessageTransferFields.trace-information, and MTA.PerMessageTransferFields.internal-trace-information to produce a single ordered trace list. If Internal trace from other management domains has not been stripped, this may require complex interleaving. Use this to generate a sequence of "X400-Received:" fields. The only difference between external trace and internal trace will be the extra MTA information in internal trace elements.
MTA.PerMessageTransferFields.trace-information、およびMTA.PerMessageTransferFields.internal-トレース情報を合併して、ただ一つの規則正しい跡のリストを作り出してください。 他の管理ドメインからのInternal跡が剥取られていないなら、これは複雑なインターリービングを必要とするかもしれません。 系列を発生させるのにこれを使用する、「X400が受け取られている:、」 分野。 外部の跡と内部の跡の唯一の違いが内部の微量元素の中に余分なMTA情報になるでしょう。
When generating an RFC 822 message all trace fields (X400- Received and Received) should be at the beginning of the header, before any other fields. Trace should be in chronological order, with the most recent element at the front of the message. A simple example trace (external) is:
ヘッダーの始めにRFC822メッセージを発生させるとき、すべての跡の分野(受け取られたX400とReceived)がそうあるべきです、いかなる他の分野の前にも。 跡が年代順にメッセージの前部における最新の要素であるべきです。 簡単な例の跡(外部の)は以下の通りです。
X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ;
Tue, 20 Jun 89 19:25:11 +0100
X400が受け取られている: /PRMD=UK.AC/ADMD=で、金400/CはGB/と等しいです。 リレーされます。 火曜日、1989年6月20日の19:25:11+0100
A more complex example (internal):
より複雑な例(内部の):
X400-Received: by mta UK.AC.UCL.CS in
/PRMD=UK.AC/ADMD=Gold 400/C=GB/ ;
deferred until Tue, 20 Jun 89 14:24:22 +0100 ;
converted (undefined, g3fax) ";" attempted /ADMD=Foo/C=GB/ ;
Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100
X400が受け取られている: /PRMD=UK.AC/ADMD=のmta UK.AC.UCL.CSで、金400/CはGB/と等しいです。 火曜日、1989年6月20日の14:24:22+0100まで延期されます。 「変換、(未定義である、g3fax)、」、;、」 試みられた/ADMD=Foo/CはGB/と等しいです。 リレーされて、広げられて、向け直される。 火曜日、1989年6月20日の19:25:11+0100
5.3.8. Mappings from Report Delivery
5.3.8. レポート配送からのマッピング
Delivery reports are mapped at the MTS service level. This means that only reports destined for the MTS user will be mapped. Some additional services are also taken from the MTA service.
配送レポートはMTSサービスレベルで写像されます。 これは、MTSユーザのために運命づけられたレポートだけが写像されることを意味します。 また、MTAサービスからいくつかの追加サービスを取ります。
5.3.8.1. MTS Mappings
5.3.8.1. MTSマッピング
A Delivery Report service will be represented as MTS.ReportDeliveryEnvelope, which comprises of per-report-fields (MTS.PerReportDeliveryFields) and per-recipient-fields.
Delivery ReportサービスがMTS.ReportDeliveryEnvelopeとして表される、どれ、包括、レポート分野、(MTS.PerReportDeliveryFields)と受取人分野単位で。
A message should be generated with the following fields:
メッセージは以下の分野で発生するべきです:
Kille [Page 71] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[71ページ]RFC1138
From:
An administrator at the gateway system. This is also the
822-MTS originator.
From: ゲートウェイシステムの管理者。 また、これは822-MTS創始者です。
To: A mapping of the
MTA.ReportTransferEnvelope.report-destination-name. This is
also the 822-MTS recipient.
To: MTA.ReportTransferEnvelope.report目的地名に関するマッピング。 また、これは822-MTS受取人です。
Message-Type:
Set to "Delivery Report".
メッセージタイプ: 「配送レポート」にセットしてください。
Subject:
Something of the form "X.400 Delivery Report".
Subject: フォーム「X.400配送レポート」について何か。
The format of the body of the message is defined to ensure that all information is conveyed to the RFC 822 user in a consistent manner. This gives a summary of critical information, and then a full listing of all parameters:
メッセージ欄の書式は、すべての情報が一貫した方法でRFC822ユーザに伝えられるのを保証するために定義されます。 これは、重要情報の概要をして、次に、すべてのパラメタの詳細な一覧表をします:
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-extra-information <CRLF>
dr-content-return
drボディー形式はdr-概要の<のCRLFの>のdrの満足している<CRLF>dr-受取人<CRLF>dr-その他の情報リターンと等しいです。
dr-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
dr満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。 <CRLF><CRLF>メッセージ
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
"It was generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"It was later converted to RFC 822 by:" mailbox <CRLF>
"at" date-time <CRLF> <CRLF>
dr-概要=「このレポートはあなたのメッセージに関連します」。 「以下で発生した」<CRLF>満足している相関器<CRLF><CRLF>“of"日付-時間<CRLF><CRLF>。 「それは後で以下によってRFC822に変換された」レポートポイント<CRLF>“at"日付-時間<CRLF><CRLF>。 メールボックス<CRLF>“at"日付-時間<CRLF><CRLF>。
dr-recipients = *(dr-recipient <CRLF> <CRLF>)
dr-受取人は*と等しいです。(dr-受取人<CRLF><CRLF>)
dr-recipient = dr-recip-success / dr-recip-failure
dr-recip dr-受取人=dr-recip-成功/故障
dr-recip-success =
"Your message was successfully delivered to:"
mailbox "at" date-time
dr-recip-成功=「以下のことのために首尾よくあなたのメッセージを送りました」。 メールボックス“at"日付-時間
Kille [Page 72] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[72ページ]RFC1138
dr-recip-failure = "Your message was not delivered to:"
mailbox <CRLF>
"for the following reason:" *word
dr-recip-失敗=「あなたのメッセージは以下のことのために送られませんでした」。 メールボックス<CRLF>、「以下に関して、推論してください」 *単語
dr-extra-information =
"-----------------------------------------------" <CRLF> <CRLF>
"The following information is derived from the Report" <CRLF>
"It may be useful for problem diagnosis:" <CRLF> <CRLF>
drc-field-list
「dr-その他の情報=」-----------------------------------------------「<CRLF><CRLF>「Reportから以下の情報を得る」<CRLF>、「それは問題診断の役に立つかもしれない」、」 <CRLF><CRLF>drc分野リスト
drc-field-list = *(drc-field <CRLF>)
drc分野リスト=*(drc-分野<CRLF>)
drc-field = "Subject-Submission-Identifier" ":"
mts-msg-id
/ "Content-Identifier" ":" printablestring
/ "Content-Type" ":" mts-content-type
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "Originator-and-DL-Expansion-History" ":"
dl-history
/ "Reporting-DL-Name" ":" mailbox
/ "Content-Correlator" ":" content-correlator
/ "Recipient-Info" ":" recipient-info
/ "Subject-Intermediate-Trace-Information" ":"
x400-trace
「drc-分野は「対象の服従識別子」と等しい」:、」 「mts-msg-イド/「満足している識別子」」:、」 「printablestring/「コンテントタイプ」」:、」 「mtsの満足しているタイプ/「元のコード化された情報タイプ」」:、」 「コード化されたインフォメーション/「創始者とdl拡大歴史」」、:、」 「dl歴史/「報告しているdl名」」:、」 「メールボックス/「満足している相関器」」:、」 「満足している相関器/「受取人インフォメーション」」:、」 「受取人インフォメーション/「対象の中間的トレース情報」」:、」 x400-跡
recipient-info = mailbox "," std-or ";"
report-type
[ "converted eits" encoded-info ";" ]
[ "originally intended recipient"
mailbox "," std-or ";" ]
[ "last trace" [ encoded-info ] date-time ";" ]
[ "supplementary info" <"> printablestring <"> ";" ]
[ "redirection history" 1#redirection ";"
[ "physical forwarding address"
printablestring ";" ]
または、「受取人インフォメーションはメールボックスと等しい」、」、std、-、」、;、」 report-type [ "converted eits" encoded-info ";" ] [ "originally intended recipient" mailbox "," std-or ";" ] [ "last trace" [ encoded-info ] date-time ";" ] [ "supplementary info" <"> printablestring <"> ";" ] [ "redirection history" 1#redirection ";" [「「物理的な推進は」 printablestringを記述する」;、」、]
report-type = "SUCCESS" drc-success
/ "FAILURE" drc-failure
レポートタイプは「成功」drc-成功/「失敗」drc-失敗と等しいです。
drc-success = "delivered at" date-time ";"
[ "type of MTS user" labelled-integer ";" ]
「drc-成功=は「」日付-時に配送されました」」 [「「」 ラベルされた整数をMTSユーザにタイプしてください」;、」、]
drc-failure = "reason" labelled-integer ";"
[ "diagnostic" labelled-integer ";" ]
「drc-失敗=は「」 ラベルされた整数を推論します」」 「[ラベルされた「診断している」整数、」、;、」、]
Kille [Page 73] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[73ページ]RFC1138
report-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#( mailbox "(" date-time ")")
レポートポイントはグローバルなイド満足している相関器=*単語dl歴史=1#、と等しいです["mta"単語“in"]。(「(「日付-時間」)」というメールボックス)
The format is defined as a fixed definition. The only exception is that the EBNF.drc-fields should follow RFC 822 folding rules.
書式は固定定義と定義されます。 唯一の例外はEBNF.drc-分野がRFC822折り尺に従うべきであるということです。
The elements of MTS.ReportDeliveryEnvelope.per-report-fields are mapped as follows onto extended RFC 822 fields:
MTS.ReportDeliveryEnvelope.perレポート分野の要素は以下の通り拡張RFC822フィールドに写像されます:
subject-submission-identifier
Mapped to EBNF.drc-field (Subject-Submission-Identifier)
EBNF.drc-分野への対象の服従識別子Mapped(対象の服従識別子)
content-identifier
Mapped to EBNF.drc-field (Content-Identifier)
EBNF.drc-分野への満足している識別子Mapped(満足している識別子)
content-type
Mapped to EBNF.drc-field (Content-Type)
EBNF.drc-分野への満足しているタイプMapped(コンテントタイプ)
original-encoded-information-types
Mapped to EBNF.drc-field (Encoded-Info)
EBNF.drc-分野への元のコード化された情報タイプMapped(コード化されたインフォメーション)
The extensions from MTS.ReportDeliveryEnvelope.per-report-fields.extensions are mapped as follows:
MTS.ReportDeliveryEnvelope.perレポートfields.extensionsからの拡大は以下の通り写像されます:
originator-and-DL-expansion-history
Mapped to EBNF.drc-field (Originator-and-DL-Expansion-
History)
EBNF.drc-分野に写像された創始者とdl拡大歴史そして、(創始者、-、-、dl拡大歴史)
reporting-DL-name
Mapped to EBNF.drc-field (Reporting-DL-Name)
EBNF.drc-分野に写像された報告しているdl名(報告しているdl名)
content-correlator
Mapped to EBNF.content-correlator, provided that the
encoding is IA5String (this should always be the case).
This is used in EBNF.dr-summary and EBNF.drc-field-list.
In the former, LWSP may be added, in order to improve the
layout of the message.
EBNF.content-相関器への満足している相関器Mappedコード化がIA5String(いつもこれはそうであるべきである)であれば。 これはEBNF.dr-概要とEBNF.drc分野リストで使用されます。 前者では、LWSPは、メッセージのレイアウトを改良するために加えられるかもしれません。
message-security-label reporting-MTA-certificate report-origin-authentication-check
メッセージ機密保護ラベルMTAが証明する報告レポート起源認証チェック
These security parameters should not be present. If they are,
they should be discarded in preference to discarding the whole
report.
これらのセキュリティパラメタは存在しているべきではありません。 そうなら、全体のレポートを捨てることに優先してそれらは捨てられるべきです。
Kille [Page 74] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[74ページ]RFC1138
For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields, a value of EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info) should be generated. The components are mapped as follows.
MTS.ReportDeliveryEnvelope.per受取人分野の各要素、EBNF.dr-受取人の値、およびEBNF.drc-分野において、(受取人インフォメーション)は発生するべきです。 コンポーネントは以下の通り写像されます。
actual-recipient-name
Used to generate the first EBNF.mailbox and EBNF.std-or in
EBNF.recipient-info. Both RFC 822 and X.400 forms are
given, as there may be a problem in the mapping tables. It
also generates the EBNF.mailbox in EBNF.dr-recip-success or
EBNF.dr-recip-failure.
または、そして、最初のEBNF.mailboxを発生させる実際の受取人名のUsed、EBNF.std、-、EBNF.recipient-インフォメーションで。 問題がマッピングテーブルにあるかもしれないので、RFC822とX.400用紙の両方を与えます。 また、それはEBNF.dr-recip-成功かEBNF.dr-recip-失敗でEBNF.mailboxを発生させます。
report
If it is MTS.Report.delivery, then set EBNF.dr-recipient to
EBNF.dr-recip-success, and similarly set EBNF.report-type,
filling in EBNF.drc-success. If it is a failure, set
EBNF.dr-recipient to EBNF.dr-recip-failure, making a human
interpretation of the reason and diagnostic codes, and
including any supplementary information. EBNF.drc-failure
should be filled in systematically.
それがMTS.Report.deliveryであるというレポートIf、次に、EBNF.dr-recip-成功にEBNF.dr-受取人を設定してください、そして、EBNF.drc-成功に記入して、同様にEBNF.report-タイプを設定してください。 それが失敗であるなら、EBNF.dr-recip-失敗にEBNF.dr-受取人を設定してください、理由と診断コードの人間の解釈をして、どんな補助情報も含んでいて。 EBNF.drc-失敗は系統的に記入されるべきです。
converted-encoded-information-types
Set EBNF.drc-field ("converted eits")
変換されたコード化された情報タイプSet EBNF.drc-分野(「変換されたeits」)
originally-intended-recipient
Set the second ("originally intended recipient") mailbox
元々意図した受取人Setは2(「元々意図した受取人」)番目のメールボックスです。
and
そして
std-or in EBNF.drc-field.
または、std、-、EBNF.drc-分野で。
supplementary-info
Set EBNF.drc-field ("supplementary info"), and include this
information in EBNF.dr-recip-failure.
補っているインフォメーションは、EBNF.dr-recip-失敗にこの情報をSet EBNF.drcさばいて(「補っているインフォメーション」)、含んでいます。
redirection-history
Set EBNF.drc-field ("redirection history")
リダイレクション歴史Set EBNF.drc-分野(「リダイレクション歴史」)
physical-forwarding-address
Set ENBF.drc-field ("physical forwarding address")
物理的なフォーワーディング・アドレスSet ENBF.drc-分野(「物理的なフォーワーディング・アドレス」)
recipient-certificate
Discard
受取人証明書Discard
proof-of-delivery
Discard
配達証明Discard
Any unknown extensions should be discarded, irrespective of criticality.
どんな未知の拡大も臨界の如何にかかわらず捨てられるべきです。
Kille [Page 75] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[75ページ]RFC1138
The original message should be included in the delivery port. The original message will usually be available at the gateway, as discussed in Section 5.2.
オリジナルのメッセージは配送ポートに含まれるべきです。 通常、オリジナルのメッセージはセクション5.2で議論するようにゲートウェイで利用可能になるでしょう。
5.3.8.2. MTA Mappings
5.3.8.2. MTAマッピング
The single 822-MTS recipient is constructed from MTA.ReportTransferEnvelope.report-destination-name, using the mappings of Chapter 4. Unlike with a user message, this information is not available at the MTS level.
第4章のマッピングを使用して、独身の822-MTS受取人はMTA.ReportTransferEnvelope.report目的地名から組み立てられます。 ユーザメッセージなどと異なって、この情報はMTSレベルで利用可能ではありません。
The following additional mappings should be made:
以下の追加マッピングは作られているべきです:
MTA.ReportTransferEnvelope.report-destination-name
This should be used to generate the To: field.
MTA.ReportTransferEnvelope.report目的地名のThisは、To:を発生させるのに使用されるべきです。 さばきます。
MTA.ReportTransferEnvelope.identifier
Mapped to the extended RFC 822 field "X400-MTS-Identifier:".
It may also be used to derive a "Message-Id:" field.
拡張RFC822分野へのMTA.ReportTransferEnvelope.identifier Mapped、「X400-MTS-識別子:」 また、それがaを引き出すのに使用されるかもしれない、「メッセージイド:」 さばきます。
MTA.ReportTransferEnvelope.trace-information
and
そしてMTA.ReportTransferEnvelope.trace-information。
MTA.ReportTransferEnvelope.internal-trace-information
Mapped onto the extended RFC 822 field "X400-Received:", as
described in Section 5.3.7. The first element should also
be used to generate the "Date:" field, and the
EBNF.failure-point.
拡張RFC822フィールドへのMTA.ReportTransferEnvelope.internal-トレース情報Mapped、「X400が受け取られている:、」、セクション5.3では、.7に説明されます。 また、最初の要素は、「日付:」を発生させるのに使用されるべきです。 分野、およびEBNF.failure-ポイント。
MTA.PerRecipientReportTransferFields.last-trace-information
Mapped to EBNF.recipient-info (last trace)
MTA.PerReportTransferFields.subject-intermediate-trace-information
Mapped to EBNF.drc-field (subject-Intermediate-Trace-Information).
These fields should be ordered so that the most recent trace element
comes first.
EBNF.drc-分野(対象の中間的跡の情報)へのEBNF.recipient-インフォメーション(跡を持続する)のMTA.PerReportTransferFields.subjectの中間的トレース情報MappedへのMTA.PerRecipientReportTransferFields.last-トレース情報Mapped。 これらの分野が命令されるべきであるので、最新の微量元素は一番になります。
5.3.8.3. Example Delivery Report
5.3.8.3. 例の配送レポート
This is an example, of a moderately complex report.
これは適度に複雑なレポートに関する例です。
From: The Postmaster <postmaster@cs.ucl.ac.uk> To: jpo@computer-science.nottingham.ac.uk Subject: X.400 Delivery Report Message-Type: Delivery Report Date: Wed, 21 Jun 89 08:45:25 +0100 X400-MTS-Identifier: /PRMD=UK.AC/ADMD=Gold 400/C=GB/;13412345235
From: Postmaster <postmaster@cs.ucl.ac.uk 、gt;、To: jpo@computer-science.nottingham.ac.uk Subject: X.400配送レポートメッセージタイプ: 配送レポート日付: 水曜日、1989年6月21日の08:45:25+0100X400-MTS-識別子: /PRMD=UK.AC/ADMD=金400/C=GB/; 13412345235
Kille [Page 76] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[76ページ]RFC1138
This report relates to your message:
Date: Wed, 21 Jun 89 06:15:43 +0000
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
Subject: Now it's the fine tuning .... !
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
このレポートはあなたのメッセージに関連します: 日付: 水曜日、1989年6月21日の06:15:43+0000Message ID: <8907140715.aa09015@CS.Nott.AC.UK>Subject: 現在、それは微調整です… ! To: Pieteブルックス(郵便局長) <pb@computer-lab.cambridge.ac.uk 、gt。
of Wed, 21 Jun 89 06:15:43 +0000
水曜日、1989年6月21日の06:15:43+0000について
It was generated by mta PK in /PRMD=UK/ADMD=DBP/C=DE/ at Wed, 21 Jun 89 08:45:25 +0100
それは水曜日、1989年6月21日の08:45:25+0100にmta PKによって/PRMD=イギリス/ADMD=DBP/C=DE/で発生しました。
It was later converted to RFC 822 by: Mail-Gateway@oxbridge.ac.uk at Wed, 21 Jun 89 08:45:26 +0100
それは後で以下によってRFC822に変換されました。 水曜日の Mail-Gateway@oxbridge.ac.uk 、1989年6月21日の08:45:26+0100
Your message was not delivered to: bad-user@nowhere
for the following reason: Rendition problem with punctuation
(Umlaut failure)
あなたのメッセージは以下のことのために送られませんでした。 以下の理由による bad-user@nowhere : 句読に関する表現問題(ウムラウト符号失敗)
-----------------------------------------------
-----------------------------------------------
The following information is derived from the Report It may be useful for problem diagnosis:
以下の情報はReport Itから派生して、問題診断の役に立つかもしれないということです:
Subject-Submission-Identifier:
[/PRMD=UK.AC/ADMD=Gold 400/C=GB/;148996]
Content-Identifier: X.400 Delivery Report
Content-Type: P2-1988 (22)
Original-Encoded-Information-Types: ia5
Content-Correlator: Date: Wed, 21 Jun 89 06:15:43 +0000
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
Subject: Now it's the fine tuning .... !
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
Recipient-Info:
bad-user@nowhere, /S=bad-user/PRMD=nowhere/ADMD=DBP/C=DE/ ;
FAILURE reason Physical-Rendition-Not-Performed (3) ;
diagnostic Punctuation-Symbol-Loss (23) ;
supplementary info Umlaut failure
The Original Message follows:
Subject: Now it's the fine tuning .... ! Date: Wed, 21 Jun 89 06:15:43 +0000 From: Julian Onions <jpo@computer-science.nottingham.ac.uk> To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk> Cc: bad-user@nowhere Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
A short test
Kille [Page 77] RFC 1138 Mapping X.400(88) and 822 December 1989
5.3.9. Probe
This is an MTS internal issue. Any probe should be serviced by the gateway, as there is no equivalent RFC 822 functionality. The value of the reply is dependent on whether the gateway could service an MTS Message with the values specified in the probe. The reply should make use of MTS.SupplementaryInformation to indicate that the probe was serviced by the gateway.
Appendix A - Differences with RFC 987
This appendix summarises changes between this document and RFC 987/RFC 1026.
1. Introduction
The model has shifted from a protocol based mapping to a service based mapping. This has increased the generality of the specification, and improved the model. This change affects the entire document.
A restriction on scope has been added.
2. Service Elements
- The new service elements of X.400 are dealt with.
- A clear distinction is made between origination and
reception.
3. Basic Mappings
- Add teletex support.
- Add object identifier support.
- Add labelled integer support.
- Make PrintableString <-> ASCII mapping reversible.
- The printable string mapping is aligned to the NBS mapping
derived from RFC 987.
4. Addressing
- Support for new addressing attributes.
- The message ID mapping is changed to not be table driven.
Kille [Page 78] RFC 1138 Mapping X.400(88) and 822 December 1989
5. Detailed Mappings
- Define extended IPM Header, and use instead of second body
part for RFC 822 extensions.
- Realignment of element names.
- New syntax for reports, simplifying the header and
introducing a mandatory body format (the RFC 987 header
format was unusable).
- Drop complex autoforwarded mapping.
- Add full mapping for IP Notifications, defining a body
format.
- Adopt an MTS Identifier syntax in line with the O/R Address
syntax.
- A new format for X400 Trace representation on the RFC 822
side.
6. Appendices
- Move Appendix on restricted 822 mappings to a separate RFC.
- Delete Phonenet and SMTP Appendixes.
Appendix B - Mappings specific to the JNT Mail
This Appendix is specific to the JNT Mail Protocol. It describes specific changes in the context of this protocol.
1. Introduction
There are five aspects of a gateway which are JNT Mail Specific. These are each given a section of this appendix.
2. Domain Ordering
When interpreting and generating domains, the UK NRS domain ordering must be used.
3. Acknowledge-To:
This field has no direct functional equivalent in X.400. However, it can be supported to an extent, and can be used to improve X.400 support.
Kille [Page 79] RFC 1138 Mapping X.400(88) and 822 December 1989
If an Acknowledge-To: field is present when going from JNT Mail to X.400, MTS.PerRecipientSubmissionFields.originator-request- report.report shall be set for each recipient. If there is more that one address in the Acknowledge-To: field, or if the one address is not equivalent to the 822-MTS return address, then:
1. Acknowledgement(s) should be generated by the gateway. The
text of these acknowledgements should indicate that they are
generated by the gateway.
2. The Acknowledge-To: field should also be passed as an
extension heading.
When going from X.400 to JNT Mail, in cases where MTA.PerRecipientMessageTransferFields.per-recipient-indicators. originator-report is set, the copy of the message to that recipient should have an Acknowledge-To: field containing the MTS.OtherMessageDeliveryFields.originator-name. No special treatment should be given when MTA.PerRecipientMessageTransferFields.per- recipient-indicators. originating-MTA-report is set. No attempt should be made to map Receipt notification requests onto Acknowledge-To:, as no association can be guaranteed between IPMS and MTS level addressing information.
4. Trace
JNT Mail trace uses the Via: syntax. When going from JNT Mail to X.400, a mapping similar to that for Received: is used. No MTS.GlobalDomainIdentifier of the site making the trace can be derived from the Via:, so a value for the gateway should be used. The trace text, including the "Via:", should be unfolded, truncated to MTS.ub-mta-name-length (32), and mapped to MTA.InternalTraceInformationElement.mta-name. There is no JNT Mail specific mapping for the reverse direction.
5. Timezone specification
The extended syntax of zone defined in the JNT Mail Protocol should be used in the mapping of UTCTime defined in Chapter 3.
6. Lack of 822-MTS originator specification
In JNT Mail the default mapping of the MTS.OtherMessageDeliveryFields.originator-name is to the Sender: field. This can cause a problem when going from X.400 to JNT Mail if the mapping of IPMS.Heading has already generated a Sender: field. To overcome this, new extended JNT Mail field is defined. This is chosen to align with the JNT recommendation for interworking with
Kille [Page 80] RFC 1138 Mapping X.400(88) and 822 December 1989
full RFC 822 systems [Kille84b].
original-sender = "Original-Sender" ":" mailbox
If an IPM has no IPMS.Heading.authorising-users component and IPMS.Heading.originator.formal-name is different from MTS.OtherMessageDeliveryFields.originator-name, map MTS.OtherMessageDeliveryFields.originator-name, onto the Sender: field.
If an IPM has a IPMS.Heading.authorising-users component, and IPMS.Heading.originator.formal-name is different from MTS.OtherMessageDeliveryFields.originator-name, MTS.OtherMessageDeliveryFields.originator-name should be mapped onto the Sender: field, and IPMS.Heading.originator mapped onto the Original-Sender: field.
In other cases the MTS.OtherMessageDeliveryFields.originator-name, is already correctly represented.
Appendix C - Mappings specific to UUCP Mail
Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP address into RFC 822 syntax (using RFC 976) and then gatewaying the resulting RFC 822 address into X.400. For example, an X.400 address:
Country US
Organisation Xerox
Personal Name John Smith
might be expressed from UUCP as
inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/
(assuming gate is a UUCP-Internet gateway and gatehost.COM is an Internet-X.400 gateway) or
inthop!gate!Xerox.COM!John.Smith
(assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)
In the other direction, a UUCP address Smith@ATT.COM, integrated into 822, would be handled as any other 822 address. A non-integrated address such as inthop!dest!user might be handled through a pair of gateways:
Country US
ADMD ATT
Kille [Page 81] RFC 1138 Mapping X.400(88) and 822 December 1989
PRMD Internet
Organisation GateOrg
RFC-822 inthop!dest!user@gatehost.COM
or through a single X.400 to UUCP gateway:
Country US
ADMD ATT
PRMD UUCP
Organisation GateOrg
RFC-822 inthop!dest!user
Appendix D - Object Identifier Assignment
An object identifier is needed for the extension IPMS element. The following value should be used.
rfc-987-88 OBJECT IDENTIFIER ::=
{ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)}
id-rfc-822-field OBJECT IDENTIFIER ::= {rfc987-88 field(0)}
Appendix E - BNF Summary
boolean = "TRUE" / "FALSE"
numericstring = *DIGIT
printablestring = *( ps-char )
ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
ps-delim = "(" / ")"
ps-char = ps-delim / ps-restricted-char
ps-encoded = *( ps-restricted-char / ps-encoded-char )
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(l)" ; "("
/ "(r)" ; ")"
/ "(" 3DIGIT ")"
Kille [Page 82] RFC 1138 Mapping X.400(88) and 822 December 1989
teletex-string = *( ps-char / t61-encoded )
t61-encoded = "{" 1* t61-encoded-char "}"
t61-encoded-char = 3DIGIT
teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]
labelled-integer ::= [ key-string ] "(" numericstring ")"
key-string = *key-char key-char = <a-z, A-Z, 1-9, and "-">
object-identifier ::= [ defined-value ] oid-comp-list
oid-comp-list ::= oid-comp oid-comp-list
| oid-comp
defined-value ::= key-string
oid-comp ::= [ key-string ] "(" numericstring ")"
encoded-info = 1#encoded-type
encoded-type = built-in-eit / object-identifier
built-in-eit = "Undefined" ; undefined (0)
/ "Telex" ; tLX (1)
/ "IA5-Text" ; iA5Text (2)
/ "G3-Fax" ; g3Fax (3)
/ "TIF0" ; tIF0 (4)
/ "Teletex" ; tTX (5)
/ "Videotex" ; videotex (6)
/ "Voice" ; voice (7)
/ "SFD" ; sFD (8)
/ "TIF1" ; tIF1 (9)
encoded-pn = [ given "." ] *( initial "." ) surname
given = 2*<ps-char not including ".">
initial = ALPHA
surname = printablestring
Kille [Page 83] RFC 1138 Mapping X.400(88) and 822 December 1989
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ registered-dd-type
/ dd-key "." std-printablestring
standard-type = key-string
registered-dd-type
= key-string
dd-key = key-string
value = std-printablestring
std-printablestring
= *( std-char / std-pair )
std-char = <"{", "}", "*", and any ps-char
except "/" and "=">
std-pair = "$" ps-char
dmn-or-address = dmn-part *( "." dmn-part )
dmn-part = attribute "$" value
attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
/ "@"
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "."
global-id = std-or-address
mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
/ "Latest-Delivery-Time" ":" date-time
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-and-mta ";" ]
action-list
";" arrival-time
Kille [Page 84] RFC 1138 Mapping X.400(88) and 822 December 1989
md-and-mta = [ "mta" mta "in" ] global-id mta = word arrival-time = date-time
action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-extra-information <CRLF>
dr-content-return
dr-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
dr満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。 <CRLF><CRLF>メッセージ
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
"It was generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"It was later converted to RFC 822 by:" mailbox <CRLF>
"at" date-time <CRLF> <CRLF>
dr-概要=「このレポートはあなたのメッセージに関連します」。 「以下で発生した」<CRLF>満足している相関器<CRLF><CRLF>“of"日付-時間<CRLF><CRLF>。 「それは後で以下によってRFC822に変換された」レポートポイント<CRLF>“at"日付-時間<CRLF><CRLF>。 メールボックス<CRLF>“at"日付-時間<CRLF><CRLF>。
dr-recipients = *(dr-recipient <CRLF> <CRLF>)
dr-受取人は*と等しいです。(dr-受取人<CRLF><CRLF>)
dr-recipient = dr-recip-success / dr-recip-failure
dr-recip dr-受取人=dr-recip-成功/故障
dr-recip-success =
"Your message was successfully delivered to:"
mailbox "at" date-time
dr-recip-成功=「以下のことのために首尾よくあなたのメッセージを送りました」。 メールボックス“at"日付-時間
dr-recip-failure = "Your message was not delivered to:"
mailbox <CRLF>
"for the following reason:" *word
dr-recip-失敗=「あなたのメッセージは以下のことのために送られませんでした」。 メールボックス<CRLF>、「以下に関して、推論してください」 *単語
dr-extra-information =
"-----------------------------------------------" <CRLF> <CRLF>
"The following information is derived from the Report" <CRLF>
「dr-その他の情報=」-----------------------------------------------「<CRLF><CRLF>「Reportから以下の情報を得る」<CRLF>」
Kille [Page 85] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[85ページ]RFC1138
"It may be useful for problem diagnosis:" <CRLF> <CRLF>
drc-field-list
「それは問題診断の役に立つかもしれません」 <CRLF><CRLF>drc分野リスト
drc-field-list = *(drc-field <CRLF>)
drc分野リスト=*(drc-分野<CRLF>)
drc-field = "Subject-Submission-Identifier" ":"
mts-msg-id
/ "Content-Identifier" ":" printablestring
/ "Content-Type" ":" mts-content-type
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "Originator-and-DL-Expansion-History" ":"
dl-history
/ "Reporting-DL-Name" ":" mailbox
/ "Content-Correlator" ":" content-correlator
/ "Recipient-Info" ":" recipient-info
「drc-分野は「対象の服従識別子」と等しい」:、」 「mts-msg-イド/「満足している識別子」」:、」 「printablestring/「コンテントタイプ」」:、」 「mtsの満足しているタイプ/「元のコード化された情報タイプ」」:、」 「コード化されたインフォメーション/「創始者とdl拡大歴史」」、:、」 「dl歴史/「報告しているdl名」」:、」 「メールボックス/「満足している相関器」」:、」 「満足している相関器/「受取人インフォメーション」」:、」 受取人インフォメーション
recipient-info = mailbox "," std-or ";"
report-type
[ "converted eits" encoded-info ";" ]
[ "originally intended recipient"
mailbox "," std-or ";" ]
[ "supplementary info" <"> printablestring <"> ";" ]
[ "redirection history" 1#redirection ";"
[ "physical forwarding address"
printablestring ";" ]
または、「受取人インフォメーションはメールボックスと等しい」、」、std、-、」、;、」 または、「レポートタイプ、[「変換されたeits」コード化されたインフォメーション、」、;、」、]、[「元々意図した受取人」メールボックス、」、」、std、-、」、;、」、]、[「補っているインフォメーション」<「>のprintablestring<">"」]、[「リダイレクション歴史」1#リダイレクション、」、;、」[「「物理的な推進は」 printablestringを記述する」;、」、]
report-type = "SUCCESS" drc-success
/ "FAILURE" drc-failure
レポートタイプは「成功」drc-成功/「失敗」drc-失敗と等しいです。
drc-success = "delivered at" date-time ";"
[ "type of MTS user" labelled-integer ";" ]
「drc-成功=は「」日付-時に配送されました」」 [「「」 ラベルされた整数をMTSユーザにタイプしてください」;、」、]
drc-failure = "reason" labelled-integer ";"
[ "diagnostic" labelled-integer ";" ]
「drc-失敗=は「」 ラベルされた整数を推論します」」 「[ラベルされた「診断している」整数、」、;、」、]
report-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#( mailbox "(" date-time ")")
レポートポイントはグローバルなイド満足している相関器=*単語dl歴史=1#、と等しいです["mta"単語“in"]。(「(「日付-時間」)」というメールボックス)
mts-field = "X400-MTS-Identifier" ":" mts-msg-id
/ "X400-Originator" ":" mailbox
/ "X400-Recipients" ":" 1#mailbox
/ "Original-Encoded-Information-Types" ":"
「mts-分野=「X400-MTS-識別子」」:、」 「mts-msg-イド/「X400創始者」」:、」 「メールボックス/「X400受取人」」:、」 「1#メールボックス/「元のコード化された情報タイプ」」:、」
Kille [Page 86] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[86ページ]RFC1138
encoded-info
/ "X400-Content-Type" ":" mts-content-type
/ "Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"
/ "Redirection-History" ":" redirection
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Requested-Delivery-Method" ":"
1*( labelled-integer )
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( oid / labelled-integer )
「コード化されたインフォメーション/「X400コンテントタイプ」」:、」 「mtsの満足しているタイプ/「満足している識別子」」:、」 「printablestring/「優先権」」:、」 「優先権/「創始者返送先」」:、」 「1#メールボックス/「dl拡大歴史」」:、」 「メールボックス」;、」 「日付-時間」;、」 「/「リダイレクション歴史」」:、」 「リダイレクション/「変換」」:、」 「禁止/「損失との変換」」:、」 「禁止/「要求された発送方法」」:、」 「1*(ラベルされた整数)の/「納品日」」:、」 「日付-時間/「捨てられたX400-MTS拡張子」」:、」 1#(ラベルされたoid/整数)
prohibition = "Prohibited" / "Allowed"
=が「禁止する」か、または「許容した」禁止
mts-msg-id = "[" global-id ";" *text "]"
「mts-msg-イド=、「[「グローバルなイド」;、」 *テキスト、」、]、」
mts-content-type = "P2" / labelled-integer
/ object-identifer
mtsの満足しているタイプは「物ラベルされたP2"/整数/identifer」と等しいです。
priority = "normal" / "non-urgent" / "urgent"
優先権は「正常である」か「不急」の/と「緊急」の状態で等しいです。
redirection = mailbox ";" "reason" "="
redirection-reason
";" date-time
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
「リダイレクション=メールボックス」;、」 「「理由」は「」 リダイレクション理由と等しいです」」 日付-時間リダイレクション理由は「受取人の割り当てられた交互の受取人」/「創始者の要求された交互の受取人」/「受取人のMdの割り当てられた交互の受取人」と等しいです。
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
ipn-content-return
ipn-記述<CRLF>[ipn-その他の情報<CRLF>]のipnの満足しているipnボディー形式=リターン
ipn-description = ipn-receipt / ipn-non-receipt
ipn-記述はipn非ipn-領収書/領収書と等しいです。
ipn-receipt = "Your message to:" preferred-recipient <CRLF>
"was received at" receipt-time <CRLF> <CRLF>
"This notification was generated"
acknowledgement-mode <CRLF>
"The following extra information was given:" <CRLF>
ipn-suppl <CRLF>
ipn-領収書=「以下へのあなたのメッセージ」 「以下のその他の情報を与えた」<CRLF>が「受け取られていた」都合のよい受取人領収書時間<CRLF><CRLF>「この通知は発生した」承認モード<CRLF>。 <CRLF>ipn-suppl<CRLF>。
ipn-non-receipt "Your message to:"
ipn非領収書、「以下のことのためのあなたのメッセージ」
Kille [Page 87] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[87ページ]RFC1138
preferred-recipient <CRLF>
ipn-reason
都合のよい受取人<CRLF>ipn-理由
ipn-reason = ipn-discarded / ipn-auto-forwarded
=がipnに自動進めた状態でipnしていた状態で/を捨てたipn-理由
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipnによって捨てられる、=は「以下が以下を推論するので、捨てられました」。 理由を捨てている<CRLF>。
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
自動進めた状態でipnしている=を「自動的に、進めました」。 <CRLF>。[「以下のコメントをした」という自動コメント]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-その他の情報=「以下の情報タイプは変換されました」。 コード化されたインフォメーション
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
ipn満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。 <CRLF><CRLF>メッセージ
preferred-recipient = mailbox receipt-time = date-time auto-comment = printablestring ipn-suppl = printablestring
日付-時間自動都合のよい受取人=メールボックス領収書時間=コメント=printablestring ipn-supplはprintablestringと等しいです。
non-receipt-reason = "Discarded" / "Auto-Forwarded"
=が「自動進められた」状態で/を「捨てた」非領収書の理由
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated"
破棄して推論している=は、「ユーザ購読は終えた」/を「吐き出す」か、または「時代遅れにしました」。
acknowledgement-mode = "Manually" / "Automatically"
承認モードは「自動的に」「手動」という/と等しいです。
ms-field = "Obsoletes" ":" 1#msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Language" ":" language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#oid
「=が「時代遅れにする」ms-分野」:、」 「1#msg-イド/「有効期限日」」:、」 「日付-時間/「近く、返答」」:、」 「日付-時間/「重要性」」:、」 「重要性/「感度」」:、」 「感度/"Autoforwarded"」:、」 「論理演算子/「不完全なコピー」」:、」 「/「言語」」:、」 「言語/「メッセージタイプ」」:、」 「メッセージタイプ/「捨てられたX400-IPMS拡張子」」:、」 1#oid
Kille [Page 88] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[88ページ]RFC1138
importance = "low" / "normal" / "high"
重要性=「安値」/「標準」/「高値」
sensitivity = "Personal" / "Private" /
"Company-Confidential"
「個人的である」か「個人的な」/感度=「社内秘密」
language = 2*ALPHA [ language-description ] language-description = printable-string
2*アルファー[言語記述]の言語言語=記述は印刷可能なストリングと等しいです。
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
メッセージタイプは「配送レポート」/「個人間の通知」/「複数の部分」と等しいです。
Appendix F - Format of address mapping tables
付録F--アドレス変換テーブルの形式
There is a need to specify the association between the domain and X.400 namespaces described in Chapter 4. The use of this association leads to a better service on both sides of the gateway, and so defining mappings and distributing them in the form defined in this appendix is strongly encouraged.
第4章で説明されたドメインとX.400名前空間との協会を指定する必要があります。 この協会の使用はゲートウェイの両側におけるより良いサービスにつながって、この付録で定義された書式でしたがって、マッピングを定義して、それらを分配するのは強く奨励されます。
This syntax defined is initially in table form, but the syntax is defined in a manner which makes it suitable for use with domain nameservices (such as the Internet Domain nameservers or the UK NRS). The mapping is not symmetric, and so a separate table is specified for each direction. If multiple matches are possible, the longest possible match should be used.
初めは、定義されたこの構文はテーブルフォームにありますが、構文はそれをドメインnameservices(インターネットDomainネームサーバかUK NRSなどの)との使用に適するようにする方法で定義されます。 マッピングが左右対称でないので、別々のテーブルは各方向に指定されます。 複数のマッチが可能であるなら、可能な限り長いマッチは使用されるべきです。
First, an address syntax is defined, which is compatible with the syntax used for 822.domains. It is intended that this syntax may be used in conjunction with systems which support this form of name.
まず最初に、アドレス構文(822.domainsに使用される構文と互換性がある)は定義されます。 この構文がこのフォームの名前をサポートするシステムに関連して使用されるかもしれないことを意図します。
To allow the mapping of null attributes to be represented, the pseudo-value "@" (not a printable string character) is used to indicate omission of a level in the hierarchy. This is distinct from the form including the element with no value, although a correct X.400 implementation will interpret both in the same manner.
ヌル属性に関するマッピングが表されるのを許容するなら、疑似価値の"@"(印刷可能なストリングキャラクタでない)は、階層構造における、レベルの省略を示すのに使用されます。 これは値なしで要素を含むフォームと異なっています、正しいX.400実現が同じ方法で両方を解釈するでしょうが。
This syntax is not intended to be handled by users.
この構文はユーザによって扱われることを意図しません。
dmn-or-address = dmn-part *( "." dmn-part )
dmn-part = attribute "$" value
attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
/ "@"
dmnかアドレスがdmn-部分*と等しい、(「属性「$」値属性=標準体型/「~」dmn-printablestring. 」 dmn-部分) dmn-部分=価値はdmn-printablestring/"@"と等しいです。
Kille [Page 89] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[89ページ]RFC1138
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "."
「dmn-printablestring==*(dmn dmn-炭/対にしている)dmn-炭は<と等しい」、「」、」、「*」 . 「>dmn-組=」を除いて、」 いずれもps焦げます」。
An example usage:
例の用法:
~ROLE$Big.Chief.ADMD$ATT.C$US
PRMD$DEC.ADMD$@.C$US
~役割の$Big.Chief.ADMD$ATT.C$米国 PRMD$DEC.ADMD$@.C$US
The first example illustrates quoting of a ".", and the second omission of the ADMD level.
「最初の例はa」の引用を例証する」、およびADMDレベルの2番目の省略。
Various further restrictions are placed on the usage of dmn-or- address:
さらなる様々な制限がdmnの使用法に関して課される、-、-以下を記述してください。
1. Only C, ADMD, PRMD, O, and OU may be used.
1. C、ADMD、PRMD、O、およびOUだけを使用してもよいです。
2. There must be a strict ordering of all components, with the
most significant components on the RHS.
2. RHSで最も重要なコンポーネントによるすべてのコンポーネントの厳しい注文があるに違いありません。
3. No components may be omitted from the hierarchy, although
the hierarchy may terminate at any level. If the mapping is
to an omitted component, the "@" syntax is used.
3. 階層構造はどんなレベルでも終わるかもしれませんが、コンポーネントは全く階層構造から省略されないかもしれません。 省略されたコンポーネントにマッピングがあるなら、"@"構文は使用されています。
For domain -> X.400:
ドメイン->X.400に:
domain-syntax "#" dmn-or-address "#"
ドメイン構文「#」dmnかアドレス「#」
Note that the trailing "#" is used for clarity, as the dmn-or- address syntax can lead to values with trailing blanks. Lines staring with "#" are comments.
または、引きずっている「#」が明快にdmnとして使用されることに注意してください、-、-アドレス構文は引きずっている空白がある値につながることができます。 「#」で見つめられる線はコメントです。
For example:
例えば:
AC.UK#PRMD$UK.AC.ADMD$GOLD 400.C$GB#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE#
AC.UK#PRMD$UK.AC.ADMD$金の400.C$GB#XEROX.COM#O$Xerox.ADMD$ATT.C$U.S.#GMD.DE# O$@.PRMD$GMD.ADMD$DBP.C$DE #
For X.400 -> domain:
X.400->ドメインに:
dmn-or-address "#" domain-syntax "#"
dmnかアドレス「#」ドメイン構文「#」
For example:
例えば:
#
# Mapping table
# # マッピングテーブル
Kille [Page 90] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[90ページ]RFC1138
#
PRMD$UK.AC.ADMD$GOLD 400.C$GB#AC.UK#
# PRMD$UK.AC.ADMD$金の400.C$GB#AC.UK#
References
参照
[Braden89a] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989.
[Braden89a]ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123、科学が設けるUSC/情報、10月1989日
[CCITT88a] CCITT, "CCITT Recommendations X.408", Message Handling Systems: Encoded Information Type Conversion Rules, CCITT, December 1988.
[CCITT88a]CCITT、「CCITT推薦X.408」メッセージハンドリングシステム: 1988年12月に情報型変換規則、CCITTをコード化しました。
[CCITT/ISO88a] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message Handling: System and Service Overview, CCITT/ISO, December 1988.
[CCITT/ISO88a] CCITT/ISO、「CCITT推薦X.400/ ISOがそうである、100211インチ、メッセージハンドリング:、」 システムとサービス概観、CCITT/ISO、1988年12月。
[CCITT/ISO88b] CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7", Message Handling Systems: Interpersonal Messaging System, CCITT/ISO, December 1988.
[CCITT/ISO88b] CCITT/ISO、「CCITT推薦X.420/ ISOがそうである、100217インチ、メッセージハンドリングシステム:、」 個人間のメッセージシステム、CCITT/ISO、1988年12月。
[CCITT/ISO88c] CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4", Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures, CCITT/ISO, December 1988.
[CCITT/ISO88c] CCITT/ISO、「CCITT推薦X.411/ ISOがそうである、100214インチ、メッセージハンドリングシステム:、」 メッセージ転送システム: 抽象的なサービス定義と手順、CCITT/ISO、1988年12月。
[CCITT/ISO88d] CCITT/ISO, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208 / ISO IS 8824, CCITT/ISO, December 1988.
[CCITT/ISO88d] CCITT/ISO、「抽象構文記法1の仕様(ASN.1)」、X.208 / ISOが8824、CCITT/ISO、1988年12月というCCITT推薦。
[Crocker82a] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[Crocker82a] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、1982年8月。
[Horton86a] Horton, M., "UUCP Mail Interchange Format Standard", RFC 976, February 1986.
[Horton86a] ホートン、M.、「UUCPは置き換え形式規格を郵送する」RFC976、1986年2月。
[Kille84b] Kille, S., "Gatewaying between RFC 822 and JNT Mail", JNT Mailgroup Note 15, May 1984.
[Kille84b]Kille(S.、「RFC822とJNTメールの間のGatewaying」JNT Mailgroup注意15)は1984がそうするかもしれません。
[Kille84a] Kille, S., Editor, "JNT Mail Protocol (revision 1.0)", Joint Network Team, Rutherford Appleton Laboratory, March 1984.
[Kille84a] Kille、S.、エディタ、「JNTメールプロトコル(改正1.0)」、共同ネットワークチーム、ラザフォードアップルトーン研究所、1984年3月。
[Kille86a] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic Community Report (MG.19) / RFC 987, June 1986.
[Kille86a] Kille、S.、「X.400とRFC822の間のマッピング」、イギリス学界レポート(mg.19)/RFC987、1986年6月。
[Kille87a] Kille, S., "Addendum to RFC 987", UK Academic Community Report (MG.23) / RFC 1026, August 1987.
[Kille87a] Kille、S.、「RFC987への付加物」、イギリス学界レポート(mg.23)/RFC1026、1987年8月。
[Kille89a] Kille, S., "A String Encoding of Presentation Address",
[Kille89a] Kille、S.、「プレゼンテーションアドレスをコード化するストリング」
Kille [Page 91] RFC 1138 Mapping X.400(88) and 822 December 1989
1989年12月にX.400(88)と822を写像するKille[91ページ]RFC1138
UCL Research Note 89/14, March 1989.
UCLは注意89/14、1989年3月について研究します。
[Kille89b] Kille, S., "Mapping Between Full RFC 822 and RFC 822 with Restricted Encoding", RFC 1137, December 1989.
[Kille89b] Kille、S.、「完全なRFC822と部外秘なコード化があるRFC822の間のマッピング」、RFC1137、1989年12月。
[Larmouth83a] Larmouth, J., "JNT Name Registration Technical Guide", Salford University Computer Centre, April 1983.
[Larmouth83a] Larmouth、J.、「JNT名前の登録の技術ガイド」、ソルフォード大学コンピュータセンター、1983年4月。
[Mockapetris87a] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987.
[Mockapetris87a]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、科学が設けるUSC/情報、11月1987日
[Postel82a] Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1982.
[Postel82a] ポステル、J.、「簡単なメール転送プロトコル」、RFC821、科学が1982年8月に設けるUSC/情報。
[Rose85a] Rose M., and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, January 1985.
[Rose85a] ローズM.、およびE.Stefferud、「メッセージカプセル化の提案された標準」、RFC934、1985年1月。
[Systems85a] CEN/CENELEC/Information Technology/Working Group on Private Message Handling Systems, "FUNCTIONAL STANDARD A/3222", CEN/CLC/IT/WG/PMHS N 17, October 1985.
[Systems85a]CEN/CENELEC/情報技術/作業部会は1985年10月に兵士の上で取り扱いシステム、「機能標準A/3222」、CEN/CLC/IT/WG/PMHS N17を通信させます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Steve Kille University College London Gower Street WC1E 6BT England
スティーブKilleユニバーシティ・カレッジロンドンWC1E 6BTイギリスガウアー・ストリート
Phone: +44-1-380-7294
以下に電話をしてください。 +44-1-380-7294
EMail: S.Kille@Cs.Ucl.AC.UK
メール: S.Kille@Cs.Ucl.AC.UK
Kille [Page 92]
Kille[92ページ]
一覧
スポンサーリンク
