RFC1327 日本語訳
1327 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.Hardcastle-Kille. May 1992. (Format: TXT=228598 bytes) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148) (Obsoleted by RFC2156) (Updates RFC0822) (Updated by RFC1495) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Hardcastle-Kille Request for Comments: 1327 University College London Obsoletes: RFCs 987, 1026, 1138, 1148 May 1992 Updates: RFC 822
Hardcastle-Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: ロンドンが時代遅れにする1327年のユニバーシティ・カレッジ: RFCs987、1026、1138、1992年5月がアップデートする1148: RFC822
Mapping between X.400(1988) / ISO 10021 and RFC 822
X.400(1988)/ISO10021とRFC822の間のマッピング
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document 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. This document is a revision based on RFCs 987, 1026, 1138, and 1148 [Kille86a,Kille87a] which it obsoletes.
このドキュメントはCCITT X.400 1988)を操作するシステムの間の織り込むことを可能にする1セットのマッピングについて説明します。 メッセージハンドリングシステム/ISO IEC10021のメッセージの指向のテキスト置き換えシステム(MOTIS)における推薦 [CCITT/ISO88a]と、RFC822メールプロトコル[Crocker82a]を使用するシステムかRFC822から得られたプロトコル。 アプローチは、過度に複雑なマッピングを必要としていない間に境界の向こう側に提供されたサービスを最大にすることを目指します。 マッピングは、どんな変化もシステムを終わらせるのを必要とするべきではありません。このドキュメントはそれが時代遅れにするRFCs987、1026、1138、および1148[Kille86a、Kille87a]に基づいた改正です。
This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA 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つのプロトコルの間のマッピングを指定します。 このマッピングがDARPAインターネットの上、または、イギリスのAcademic Communityで実行されるとき、この仕様は使用されるべきです。 この仕様は実現経験の見地から変更されるかもしれませんが、大きな変化は全く予想されません。
Table of Contents
目次
1 - Overview ...................................... 3 1.1 - X.400 ......................................... 3 1.2 - RFC 822 ....................................... 3 1.3 - The need for conversion ....................... 4 1.4 - General approach .............................. 4 1.5 - Gatewaying Model .............................. 5 1.6 - X.400 (1984) .................................. 8 1.7 - Compatibility with previous versions .......... 8 1.8 - Aspects not covered ........................... 8 1.9 - Subsetting .................................... 9 1.10 - Document Structure ............................ 9
1--、概観… 3 1.1--、X.400… 3 1.2--RFC822… 3 1.3--変換の必要性… 4 1.4--一般アプローチ… 4 1.5--モデルをGatewayingします… 5 1.6--X.400(1984)… 8 1.7--、旧バージョンとの互換性… 8 1.8--、カバーされなかった局面… 8 1.9--Subsettingします… 9 1.10--構造を記録してください… 9
Hardcastle-Kille [Page 1] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[1ページ]RFC1327マッピング
1.11 - Acknowledgements .............................. 9 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 ................................. 26 3.3 - Standard Types ................................ 26 3.4 - Encoding ASCII in Printable String ............ 28 4 - Addressing .................................... 30 4.1 - A textual representation of MTS.ORAddress ..... 30 4.2 - Basic Representation .......................... 31 4.3 - EBNF.822-address <-> MTS.ORAddress ............ 36 4.4 - Repeated Mappings ............................. 48 4.5 - Directory Names ............................... 50 4.6 - MTS Mappings .................................. 50 4.7 - IPMS Mappings ................................. 55 5 - Detailed Mappings ............................. 59 5.1 - RFC 822 -> X.400 .............................. 59 5.2 - Return of Contents ............................ 67 5.3 - X.400 -> RFC 822 .............................. 67 Appendix A - Mappings Specific to SMTP ..................... 91 Appendix B - Mappings specific to the JNT Mail ............. 91 1 - Introduction .................................. 91 2 - Domain Ordering ............................... 91 3 - Addressing .................................... 91 4 - Acknowledge-To: .............................. 91 5 - Trace ......................................... 92 6 - Timezone specification ........................ 92 7 - Lack of 822-MTS originator specification ...... 92 Appendix C - Mappings specific to UUCP Mail ................ 93 Appendix D - Object Identifier Assignment .................. 94 Appendix E - BNF Summary ................................... 94 Appendix F - Format of address mapping tables .............. 101 1 - Global Mapping Information .................... 101 2 - Syntax Definitions ............................ 102 3 - Table Lookups ................................. 103 4 - Domain -> O/R Address format .................. 104 5 - O/R Address -> Domain format .................. 104 6 - Domain -> O/R Address of Gateway table ........ 104 Appendix G - Mapping with X.400(1984) ...................... 105 Appendix H - RFC 822 Extensions for X.400 access ........... 106 Appendix I - Conformance ................................... 106 Appendix J - Change History: RFC 987, 1026, 1138, 1148 ..... 107 1 - Introduction .................................. 108 2 - Service Elements .............................. 108 3 - Basic Mappings ................................ 108
1.11--、承認… 9 2--Elementsにサービスを提供してください… 10 2.1--ゲートウェイの向こう側のサービスの概念… 10 2.2--RFC822… 11 2.3--、X.400… 15 3--基礎マッピング… 24 3.1--、記法… 24 3.2--、ASCIIとIA5… 26 3.3--標準のタイプ… 26 3.4--印刷可能なストリングのASCIIをコード化します… 28 4--記述します。 30 4.1--MTS.ORAddressの原文の表現… 30 4.2--基本的な表現… 31 4.3--EBNF.822-アドレス<->MTS.ORAddress… 36 4.4--マッピングを繰り返します… 48 4.5--、ディレクトリ名… 50 4.6 --MTSマッピング… 50 4.7 --IPMSマッピング… 55 5--マッピングを詳しく述べます… 59 5.1--RFC822->X.400… 59 5.2--コンテンツの復帰… 67 5.3--X.400->RFC822… 67 付録A(SMTPに特定のマッピング)… 91 付録B--JNTメールへのマッピング詳細… 91、1--、序論… 91 2--ドメイン注文… 91 3--記述します。 91、4--、To:を承認します。 .............................. 91 5--跡… 92 6--タイムゾーン仕様… 92 7--822-MTS創始者仕様の不足… 92 付録C--UUCPメールへのマッピング詳細… 93 付録D--物の識別子課題… 94 付録E--BNF概要… 94 付録F--アドレス変換テーブルの形式… 101 1--地球地図情報… 101 2--構文定義… 102 3--ルックアップを見送ってください… 103 4--ドメイン->O/R Address形式… 104 5--O/Rアドレス->Domain形式… 104 6--ゲートウェイテーブルのドメイン->O/R Address… 104 付録G--X.400(1984)と共に写像します。 105 付録H--X.400アクセスのためのRFC822Extensions… 106 付録I(順応)… 106 付録J--歴史を変えてください: RFC987、1026、1138、1148… 107、1--、序論… 108 2--Elementsにサービスを提供してください… 108 3--基礎マッピング… 108
Hardcastle-Kille [Page 2] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[2ページ]RFC1327マッピング
4 - Addressing .................................... 108 5 - Detailed Mappings ............................. 109 6 - Appendices .................................... 109 Appendix K - Change History: RFC 1148 to this Document ..... 109 1 - General ....................................... 109 2 - Basic Mappings ................................ 110 3 - Addressing .................................... 110 4 - Detailed Mappings ............................. 110 5 - Appendices .................................... 110 References ................................................. 111 Security Considerations .................................... 113 Author's Address ........................................... 113
4--記述します。 108 5--マッピングを詳しく述べます… 109、6--、付録… 109 付録K--歴史を変えてください: このDocumentへのRFC1148… 109、1--、一般… 109 2--基礎マッピング… 110 3--記述します。 110 4--マッピングを詳しく述べます… 110、5--、付録… 110の参照箇所… 111 セキュリティ問題… 113作者のアドレス… 113
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 (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.
このドキュメントはMessage Oriented Text Interchange Service(MOTIS)の上のCCITT1988X.400 Series Recommendations / ISO IEC10021に関連します。 この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 evolved as a messaging standard on the DARPA (the US Defense Advanced Research Projects Agency) Internet. It specifies and end to end message format. It is used in conjunction with a number of different message transfer protocol environments.
RFC822はメッセージングとしてDARPAの標準(米国国防高等研究計画庁)のインターネットを発展しました。 それを指定します、そして、終わって、メッセージ・フォーマットを終わらせてください。 それは多くの異なったメッセージ転送プロトコル環境に関連して使用されます。
SMTP Networks
On the DARPA 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 920 which is a Specification for domains and a
distributed name service [Postel84a].
インターネットと他のTCP/IPがネットワークでつなぐSMTP Networks On DARPAであり、RFC822は他の2つの規格に関連して使用されます: また、シンプルメールトランスファプロトコル(SMTP)として知られているRFC821[Postel82a]、およびドメインへのSpecificationと分配された名前サービスであるRFC920[Postel84a]。
UUCP Networks
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 920, but not the corresponding domain
nameservers [Horton86a].
UUCP Networks UUCPはUNIX CoPyプロトコルへのUNIXです。(通常、そのUNIXは、簡単なメッセージトランスファ・メカニズムを提供するのにダイアルアップ電話網の上で使用されます)。 RFC822と、特にアドレシングにはいくつかの拡大があります。 彼らは対応するドメインネームサーバ[Horton86a]ではなく、RFC920に従うドメインを使用します。
Hardcastle-Kille [Page 3] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[3ページ]RFC1327マッピング
Bitnet
Some parts of Bitnet and related networks use RFC 822
related protocols, with EBCDIC encoding.
Bitnetと関連するネットワークのBitnet Some部分はEBCDICコード化があるRFC822関連するプロトコルを使用します。
JNT Mail Networks
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ネットワークのJNTメールNetworks A番号(特にイギリスの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)を条件として、ゲートウェイの向こう側の機能性はできるだけ高いはずです。
Hardcastle-Kille [Page 4] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[4ページ]RFC1327マッピング
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
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
3. いつもどんな変化の結果、情報を失うのは、悪い考えです。 したがって、ゲートウェイがそれが処理する物で情報を捨てるのは、悪い考えです。 これは完全に写像できるというわけではない要求されたサービスを含んでいます。
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. Subject to 1), the specification should be reversible. That
is, a double transformation should bring you back to where
you started.
5. 1)を条件として、仕様はリバーシブルであるべきです。 すなわち、二重変化はあなたが出発したところにあなたを返すべきです。
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サービスは、物である徹底的調査の創作がテストされるのを許容します。
Hardcastle-Kille [Page 5] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[5ページ]RFC1327マッピング
The Reception service also allows for receipt of Delivery Reports DR), which indicate delivery success or failure.
またサービスがDelivery Reports DRの領収書のために許容するReception)、配送成否を示す。
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 defines 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です、分配された操作のための手順と共に。(サービスは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
RFC822ヘッダーの中に2を)達成するのは可能です。 いくつかの822-MTSプロトコル(特にSMTP)がこれらとして追加機能性を提供できますが、SMTPで義務的でなくて、また他の822-MTSプロトコルでは利用可能でない、それらはここで考えられません。 2つの822-MTSプロトコルに特定の局面の詳細はAppendices Bで明らかにされます、そして、C.An RFC822メッセージは非解釈されたASCIIテキストであるヘッダー、および内容から成ります。 ヘッダーは分野に分割されます。(分野はプロトコル要素です)。 これらの分野の大部分は、或るものがMTS Service Elementsに類似していますが、P2見出し分野に類似しています。
Hardcastle-Kille [Page 6] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[6ページ]RFC1327マッピング
or MTA Service Elements.
または、MTAはElementsにサービスを提供します。
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 primary goal of this specification is to support single mappings, so that X.400 and RFC 822 users can communicate with maximum functionality.
この仕様の第一の目標はただ一つのマッピングを支持することです、X.400とRFC822人のユーザが最大の機能性で交信できるように。
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).
ここで指定されたマッピングは、メッセージがX.400とRFC822の間で複数の回を横断するところで働くように設計されています。 これは特に発送先リストの場合でしばしば不可欠です。 しかしながら、一般に、これは最小公分母(RFC822によって提供されたおよそサービス)であるサービスのレベルに通じるでしょう。
Some RFC 822 networks may wish to use X.400 as an interconnection mechanism (typically for policy reasons), and this is fully supported.
RFC822がネットワークでつなぐ或るものはインタコネクトメカニズム(通常方針理由による)としてX.400を使用したがっているかもしれません、そして、これは完全に支持されます。
Hardcastle-Kille [Page 7] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[7ページ]RFC1327マッピング
Where an X.400 messages transfers to RFC 822 and then back to X.400, there is no expectation of X.400 services which do not have an equivalent service in standard RFC 822 being preserved - although this may be possible in some cases.
そこのメッセージがRFC822と、そして、そして、X.400に移して戻すX.400がそうでは、そうしないX.400サービスへのどんな期待もこれがいくつかの場合可能であるかもしれませんが、保存される標準のRFC822に同等なサービスを持っていません。
1.6. X.400 (1984)
1.6. X.400(1984)
Much of this work is based on the initial specification of RFC 987 and in its addendum RFC 1026, which defined a mapping between X.400(1984) and RFC 822. A basic decision is that the mapping defined in this document is to the full 1988 version of X.400, and not to a 1984 compatible subset. New features of X.400(1988) can be used to provide a much cleaner mapping than that defined in RFC 987. This is important, to give good support to communities which will utilise full X.400 at an early date. To interwork with 1984 systems, Appendix G shall be followed.
この仕事の多くがRFC987の初期の仕様に基づいたその付加物RFC1026にあります。(それは、X.400(1984)とRFC822の間のマッピングを定義しました)。 基本的な決定は1984年のコンパチブル部分集合ではなく、1988年のX.400の完全なバージョンには本書では定義されたマッピングがあるということです。 RFC987で定義されたそれよりはるかに清潔なマッピングを提供するのにX.400(1988)に関する新機能を使用できます。 これは、期日前半に完全なX.400を利用する共同体に良いサポートを与えるために重要です。 1984でシステムを織り込むために、Appendix Gは続かれるものとします。
If a message is being transferred to an X.400(1984) system by way of X.400(1988) MTA it will give a slightly better service to follow the rules of Appendix G.
X.400(1988)MTAを通してX.400(1984)システムにメッセージを移していると、それは、Appendix Gの規則に従うためにわずかに良いサービスを与えるでしょう。
1.7. Compatibility with previous versions
1.7. 旧バージョンとの互換性
The changes between this and older versions of the document are given in Appendices I and J. These are RFCs 987, 1026, 1138, and 1148. This document is a revision of RFC 1148 [Kille90a]. As far as possible, changes have been made in a compatible fashion.
ドキュメントのこれと旧式のバージョンの間の変化はAppendices私とJ.Theseで与えているのが、RFCs987、1026と、1138と、1148であるということです。 このドキュメントはRFC1148[Kille90a]の改正です。 できるだけ、変更はコンパチブルファッションで行われました。
1.8. Aspects not covered
1.8. カバーされなかった局面
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ユーザーインタフェース定義
- Mapping X.400 to extended versions of RFC 822, with support
for multimedia content.
- マルチメディアコンテントのサポートでRFC822の拡張版にX.400を写像します。
The first two of 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
これら最初の2つは本当に結合されます。 X.400サービスを写像するために、この仕様は多くの拡大をRFC822と定義します。 副作用として、これらはSOME X.400サービスへの822ユーザアクセスを与えます。 しかしながら、RFC822側の上の目的が当期の勤務を保持すること的であり、アクセスが与えられていないのは、意図的です。
Hardcastle-Kille [Page 8] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[8ページ]RFC1327マッピング
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 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. Some optional and limited extensions in this area have proved useful, and are defined in Appendix H.
すべてのX.400サービス。 したがって、X.400作成者がインタフェースとしてRFC 987(88)を使用するのは、不十分な選択でしょう--それを通してアクセスできないX.400のあまりに多くの局面があります。 テキストインタフェースが望まれているなら、RFC822制限なしでX.400をターゲットにした仕様は、より適切でしょう。 この領域でのいくつかの任意の、そして、限られた拡大が、有用であることが分かって、Appendix Hで定義されます。
1.9. Subsetting
1.9. 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.10. Document Structure
1.10. ドキュメント構造
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 eleven appendices.
また、11個の付録があります。
WARNING:
THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED.
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.11. Acknowledgements
1.11. 承認
The work in this specification was substantially based on RFC 987 and RFC 1148, which had input from many people, who are credited in the respective documents.
この仕様に基づく仕事は実質的にRFC987とRFC1148に基づきました。(RFCは多くの人々からの入力を持っていました)。(その人々は、それぞれのドキュメントで掛け売りされます)。
Hardcastle-Kille [Page 9] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[9ページ]RFC1327マッピング
A number of comments from people on RFC 1148 lead to this document. In particular, there were comments and suggestions from: Maurice Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen (X-Tel); Jim Craigie (JNT); Ella Gardener (MITRE); Christian Huitema (Inria); Erik Huizer (SURFnet); Neil Jones DEC); Ignacio Martinez (IRIS); Julian Onions (X-Tel); Simon Poole (SWITCH); Clive Roberts (Data General); Pete Vanderbilt SUN); Alan Young (Concurrent).
RFC1148の上の人々からの多くのコメントがこのドキュメントにつながります。 特に、コメントと提案は以下から来ていました。 モーリス・アブラハム(hp)。 ハラルドAlvestrand(Sintef)。 ピーター・カウエン(X-Tel)。 ジム・クレーギー(JNT)。 エラ庭師(斜め継ぎ)。 クリスチャンのHuitema(Inria)。 エリックHuizer(SURFnet)。 ニールジョーンズ12月)、。 イグナシオ・マルチネス(虹彩)。 ジュリアンOnions(X-Tel)。 サイモン・プール(スイッチ)。 クライヴ・ロバーツ(データゼネラル)。 ピートバンダービルト太陽)、。 アラン・ヤング(同時発生の)。
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.
よく、サービスを完全に提供できるように対応するプロトコル要素地図をサポートしました。
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
「最初の2つの場合では、サービスはSupportedとして単にマークされる」か、または「支持されませんでした」。 または、追加含意があれば何らかの説明をするかもしれない、(非、)、サポートは直感的ではありません。 for
Hardcastle-Kille [Page 10] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[10ページ]RFC1327マッピング
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.
部分的なサポート、部分的なサポートのレベルについて略言します。 部分的なサポートがいいぞ、これが句によって説明されるということであるところ、「使用で支持される、」、… このよくある例はサービスがゲートウェイの反対側の上で非標準のサービスに写像されるところです、そして、これには、支持するリードがそれが標準のサービスであったならあるでしょう。 多くの場合、これは、支持するために同等です。 部分的なサポートにおいて、メカニズムのしるしを与えます、提供されたサポート水準の感じを与えるために。 これが第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受取人が対象の指示を得るとき、これが支持されると考えられます。
In many cases, the required action will simply be to make the information available to the end user. In other cases, actions may imply generating a delivery report.
多くの場合、必要な動作は単に情報をエンドユーザにとって利用可能にすることでしょう。 他の場合では、動作は、配送を発生させて、報告するように含意するかもしれません。
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 RFC 822 service elements.
RFC822は明らかにサービス要素をプロトコル要素と異なると定義しません。 しかしながら、跡以外の822ヘッダーがさばくRFCのすべてを内在している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).
いろいろな場合に使用されるマッピングのメカニズムはIPM(InterPersonal Message)の見出し拡張子にRFC822ヘッダーを写像することです。
Hardcastle-Kille [Page 11] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[11ページ]RFC1327マッピング
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 are recommended to require that their X.400 User Agents are able to display these heading extensions. Support for the various service elements (headers) is now listed.
これを部分的なサポートと見なすことができます、情報をこれらのサービスに興味を持っているどんな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.
キーワード: 見出し拡張子の使用で、支持されます。
Subject:
Supported.
Subject: 支持にされる。
Comments:
Supported by use of an extra body part.
コメント: 余分な身体の部分の使用で、支持されます。
Hardcastle-Kille [Page 12] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[12ページ]RFC1327マッピング
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:
参照:
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):
Hardcastle-Kille [Page 13] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[13ページ]RFC1327マッピング
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:
優先権:
Reply-By:
返答してください:
Requested-Delivery-Method:
要求された発送方法:
Sensitivity:
感度:
X400-Content-Type:
X400-コンテントタイプ:
X400-MTS-Identifier:
X400-MTS-識別子:
Hardcastle-Kille [Page 14] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[14ページ]RFC1327マッピング
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個のヘッダーが定義されます。 これらの分野が示されて、RFCを共同操作して、822台のシステムがそれらを使用するかもしれないことを意図します。 これらの新しい分野が使用されていて、システム動作が全く含意されないところでは、サービスを部分的に支持されると見なすことができます。 第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ストア(すなわち、ローカル・サービス)に適切です。
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-
最終的に、いくつかのサービス要素は支えられません。 特に、新しいセキュリティー・サービスはRFC822に写像されません。 別の方法で示されないと、支持されないようにマークされたサービス要素のふるまいはユーザによって供給された臨界マークであることによるでしょう。 要素が転送か配送、aに重要であるとしてマークされる、非
Hardcastle-Kille [Page 15] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[15ページ]RFC1327マッピング
delivery notification will be generated. Otherwise, the service request will be ignored.
配送通知は発生するでしょう。 さもなければ、サービスのリクエストは無視されるでしょう。
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.
タイムスタンプ指示が支持した服従。
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
タイプされたBody Someは支持されていた状態でタイプします。 IA5は完全に支持されます。 ForwardedIPMessageは情報のいくらかの損失で支持されます。 他のタイプはIA5への変換において、X.400施設に依存するサポートの何らかの手段を得ます。 これ
Hardcastle-Kille [Page 16] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[16ページ]RFC1327マッピング
will only be done where content conversion is not
prohibited.
内容変換が禁止されていないところでするだけでしょう。
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
cases it will not be possible to map the body part in
question.
問題の身体の部分を写像するのが多くの場合可能ではありませんが、新しいRFC822ヘッダー(オリジナルは情報タイプをコード化した:)の使用によるボディーPart Encryption Indication Supported。
Content Confidentiality
Not supported.
支持された内容Confidentiality Not。
Hardcastle-Kille [Page 17] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[17ページ]RFC1327マッピング
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-配送:、)、受取人に対するこのサービスの情報を移すために、提供します。
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).
ディレクトリ名による受取人の名称、なし、(ローカル。)
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ではありません。
Hardcastle-Kille [Page 18] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[18ページ]RFC1327マッピング
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:)
is provided, which may be used by the recipient.
支持された最新のDelivery Designation Not。 新しいRFC822ヘッダー(最も遅い配送時間:)を提供します。(ヘッダーは受取人によって使用されるかもしれません)。
Message Flow Confidentiality
Not supported.
Flow Confidentiality Notが支持したメッセージ。
Hardcastle-Kille [Page 19] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[19ページ]RFC1327マッピング
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。)
Physical Delivery Notification by PDS
N/A (PDAU).
PDSによる物理的な配送通知、なし、(PDAU。)
Hardcastle-Kille [Page 20] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[20ページ]RFC1327マッピング
Physical Forwarding Allowed
Supported by use of a comment in a new RFC 822 header
X400-Recipients:), associated with the recipient in
question.
新しいRFC822ヘッダーX400-受取人におけるコメントの使用による物理的なForwarding Allowed Supported:、)、受取人がはっきりしていなく、関連しています。
Physical Forwarding Prohibited
Supported by use of a comment in a new RFC 822 header
X400-Recipients:), associated with the recipient in
question.
新しいRFC822ヘッダーX400-受取人におけるコメントの使用による物理的なForwarding Prohibited Supported:、)、受取人がはっきりしていなく、関連しています。
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にメッセージを送るでしょう。 理論的に、それが支持されないように実際には見えるかもしれませんが、したがって、このサービスは支持されます。
Registered Mail
N/A (PDAU).
なし、書留(PDAU。)
Hardcastle-Kille [Page 21] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[21ページ]RFC1327マッピング
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)を格納しました。
Subject Indication
Supported.
支持された対象の指示。
Hardcastle-Kille [Page 22] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[22ページ]RFC1327マッピング
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 are 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 are 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
創始者指示
Primary and Copy Recipients Indication
予備選挙と写し受信者指示
Hardcastle-Kille [Page 23] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[23ページ]RFC1327マッピング
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 shall 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.importance).
1. RFC822メッセージ(または822-MTSの部品について)の成分について説明するために。 この場合、RFC822のセクション3で定義された字句解析は使用されるものとします。 EBNF定義の外でこれらの新しいEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、EBNF.importance)にされるのであるストリング"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, except for the
following cases, where LWSP may be inserted according to RFC
822 rules.
2. RFC822メッセージでないところのIA5かASCII情報の構造について説明するために。 これらの場合では、象徴は、自己の区切りである、または象徴を区切る自己によって区切られるでしょう。 コメントとLWSPはデリミタとして使用されません、以下のケースを除いて。そこでは、RFC822規則に従って、LWSPが挿入されるかもしれません。
Hardcastle-Kille [Page 24] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[24ページ]RFC1327マッピング
- Around the ":" in all headers
- 「」、:、」 すべてのヘッダーで
- EBNF.labelled-integer
- EBNF.labelled-整数
- EBNF.object-identifier
- EBNF.object-識別子
- EBNF.encoded-info
- EBNF.encoded-インフォメーション
RFC 822 folding rules are applied to all headers.
RFC822折り尺はすべてのヘッダーに適用されます。
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,
例えば、IPMS.Heading.subjectはIPMS見出しの対象の要素を定義します。 また、同じ構文は、要素値について言及するのに使用されます。 例えば
MTS.EncodedInformationTypes.[0].g3Fax refers to a value of MTS.EncodedInformationTypes.[0] .
MTS.EncodedInformationTypes.[0].g3FaxはMTS.EncodedInformationTypes.[0]の値について言及します。
Hardcastle-Kille [Page 25] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[25ページ]RFC1327マッピング
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. All EBNF syntax definitions of ASN.1 types are in lower case, whereas ASN.1 types are referred to with the first letter in upper case. Except as noted, all mappings are symmetrical.
ASCIIテキストと、ASN.1[CCITT/ISO88d]で定義されたタイプの何人かの間で変換する必要があります。 各ケースにおいて、EBNF構文定義を与えます、ASN.1と、EBNF構造物の間のマッピングにつながるこの仕様のすべてにおける使用のために。 小文字にはASN.1タイプのすべてのEBNF構文定義がありますが、大文字における最初の手紙で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 is 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) shall be used [CCITT/ISO88a]. These will then be encoded in ASCII.
T.61ストリングが人間の解釈された情報を伝えるのに使用されるだけである場合では、マッピングの目的はリバーシブルを最大にするというよりむしろ適切にキャラクタをリモート文字の組にすることです。 これらのケースのために、CCITT Recommendation X.408(1988)で定義されたIA5へのマッピングは使用されるものとします[CCITT/ISO88a]。 そして、これらはASCIIでコード化されるでしょう。
Hardcastle-Kille [Page 26] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[26ページ]RFC1327マッピング
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 Printable String representation. The following BNF is used to represent this.
多くの場所がストリングがTeletex、そして/または、Printable 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が翻訳時点で値に用意ができているのは、お勧めです。
When mapping to X.400, the UTCTime format which specifies the timezone offset shall be used.
X.400に写像するとき、タイムゾーンオフセットを指定するUTCTime形式は使用されるものとします。
When mapping to RFC 822, the 822.date-time format shall include a numeric timezone offset (e.g., +0000).
RFC822に写像するとき、822.date-時間形式は数値タイムゾーンオフセット(例えば、+0000)を含んでいるものとします。
When mapping time values, the timezone shall be preserved as specified. The date shall not be normalised to any other timezone.
時間的価値を写像するとき、タイムゾーンは指定されるとして保存されるものとします。 いかなる他のタイムゾーンにも日付を正常にしないものとします。
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.1IntegerはEBNF.numericstringに写像されるでしょう。 多くの場合、ASN.1はInteger値を列挙するか、またはENUMERATEDを使用するでしょう。 ラベルされた整数をコード化するEBNFを提供します。 EBNFから、写像します。
Hardcastle-Kille [Page 27] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[27ページ]RFC1327マッピング
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.1、整数値だけが写像されます、そして、関連テキストは捨てられます。 ASN.1からEBNFまで写像するとき、適切なテキストラベルの添加は強く奨励されます。
labelled-integer ::= [ key-string ] "(" numericstring ")"
ラベルされた整数:、:= [主要なストリング]の「(「numericstring」)」
key-string = *key-char
key-char = <a-z, A-Z, 0-9, and "-">
そして、主要なストリング=*主要な炭キー炭が<a-z、A-Z、0-9と等しい、「-、">"
3.3.7. Object Identifier
3.3.7. 物の識別子
Object identifiers are represented in a form similar to that given in ASN.1. The order is the same as for ASN.1 (big-endian). The numbers are mandatory, and used when mapping from the ASCII to ASN.1. The key-strings are optional. It is recommended that as many strings as possible are generated when mapping from ASN.1 to ASCII, to facilitate user recognition.
物の識別子はASN.1で与えられたそれと同様のフォームに表されます。 オーダーはASN.1(ビッグエンディアン)のように同じです。 数は、義務的であって、ASCIIからASN.1まで写像すると、使用されています。 主要なストリングは任意です。 ASN.1からASCIIまで写像するとき、できるだけ多くのストリングが発生するのは、ユーザ認識を容易にするためにお勧めです。
object-identifier ::= oid-comp object-identifier
| oid-comp
物識別子:、:= oid-コンピュータ物識別子| oid-コンピュータ
oid-comp ::= [ key-string ] "(" numericstring ")"
oid-コンピュータ:、:= [主要なストリング]の「(「numericstring」)」
An example representation of an object identifier is:
物の識別子の例の表現は以下の通りです。
joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0)
共同iso-ccitt(2) mhs(6)ipms(1)ep(11)ia5-テキスト(0)
or
または
(2) (6) (1)(11)(0)
(2) (6) (1)(11)(0)
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 shall be used to encode ASCII in the PrintableString character set.
EBNF.printablestringの構造化された部分集合は現在、定義されます。 これは、PrintableString文字の組のASCIIをコード化するのに使用されるものとします。
Hardcastle-Kille [Page 28] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[28ページ]RFC1327マッピング
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 shall be
interpreted in a case insensitive manner, but always 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(そして、したがって、制限されたドメインを持つ)から得られるだけであるかもしれない場合にこのマッピングを使用するだけでよいです。 例えば、この仕様では、それがこの仕様の使用で発生してしまうだろうDomain Defined Attributeに適用されるだけであり、aがそのようなものを評価する、「(「可能でないでしょう」。
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 shall 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を分析できないなら、マッピングで不適当な値に適用しています、そして、マッピングをする手順に誤りを与えるものとします。 いくつかの場合、非変更にされるを通して印刷可能なストリングを渡すのは望ましいかもしれません。
Hardcastle-Kille [Page 29] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[29ページ]RFC1327マッピング
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 are 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 IPMS.ORDescriptor.
ルーティングにMTSによって使用された基本的なX.400O/R AddressはMTS.ORAddressによって定義されます。 IPMSでは、MTS.ORAddressは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 components shall be encoded, in order to guarantee return of error messages, and to optimise third party replies.
1セットの属性値が対にされるとき、MTS.ORAddressは構造化されます。 gatewaying目的のためのASCIIでこれをコード化できるのが明確に必要です。 すべてのコンポーネントが、エラーメッセージの復帰を保証して、第三者回答を最適化するためにコード化されるものとします。
Hardcastle-Kille [Page 30] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[30ページ]RFC1327マッピング
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 P 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 P18.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
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.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.TeletexPersonalName.initials I P/T18.3.12 4MTS.TeletexPersonalName .generation-資格を与える人GQ P/T18.3.12 4MTS.TeletexOrganizationalUnitNames .value OU P/、T18.3.10 5MTS.TeletexDomainDefinedAttribute .value DD P/T18.1 6
Hardcastle-Kille [Page 31] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[31ページ]RFC1327マッピング
MTS.PDSName PD-SERVICE P 18.3.11 7 MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 MTS.PostalCode PD-CODE 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-ADDRESS P/T 18.3.4 12 MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13 MTS.PhysicalDeliveryOrganizationName PD-O P/T 18.3.16 14 MTS.ExtensionPhysicalDelivery AddressComponents PD-EXT-DELIVERY P/T 18.3.5 15 MTS.UnformattedPostalAddress PD-ADDRESS P/T 18.3.25 16 MTS.StreetAddress PD-STREET P/T 18.3.22 17 MTS.PostOfficeBoxAddress PD-BOX P/T 18.3.18 18 MTS.PosteRestanteAddress PD-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 T-TY I 18.3.24 23
MTS.PDSName PD-サービスP18.3.11 7MTS.PhysicalDeliveryCountryName PD-C P18.3.13 8MTS.PostalCode PD-コードP18.3.19 9MTS.PhysicalDeliveryOfficeName PD-オフィスT18.3.14 10MTS.PhysicalDeliveryOfficeNumber PDオフィスP/NUM P/T18.3.15 11MTS.ExtensionORAddressComponents PD-EXT-アドレスP/T18.3.4 12MTS.PhysicalDeliveryPersonName PD-PN P/T18.3.17 13MTS.PhysicalDeliveryOrganizationName PD-O P/T18.3.16 14MTS.ExtensionPhysicalDelivery AddressComponents PD-EXT-配送P/T18.3.5 15MTS; UnformattedPostalAddress PD-アドレスP/T18.3.25 16MTS.StreetAddress PD-通りのP/T18.3.22 17MTS.PostOfficeBoxAddress PD-箱のP/T18.3.18 18MTS.PosteRestanteAddress PD-RESTANTE P/T18.3.20 19MTS.UniquePostalName PDユニークなP/T18.3.26 20MTS.LocalPostalAttributes PD地方のP/T18; 3.6 21MTS.ExtendedNetworkAddress .e163-4-address.numberネットのNUM N18.3.7 22MTS.ExtendedNetworkAddress .e163-4-address.sub-アドレスネットの潜水艦N18.3.7 22MTS.ExtendedNetworkAddress .psap-アドレスネットのPSAP X18.3.7 22MTS.TerminalType T-TY 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
P/T teletex-and-or-ps
I labelled-integer
X presentation-address
TテレテックスストリングP/TをnumericstringしながらNをprintablestringするP、テレテックス、または、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 is mapped into the BNF. When generating ASN.1, the NumericString encoding shall 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,
件数がそこでは、どこであるか、P/T、(テレテックス、または、psする、)、表現が使用されています。 キーが属性をシングルに写像するところ
Hardcastle-Kille [Page 32] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[32ページ]RFC1327マッピング
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.
この選択は属性(属性10-21)のコード化に反映されます。 1984の属性と一般名の大部分のために、printablestringとテレテックス異形があります。 属性のこの組はここでただ一つのコンポーネントに写像されます。 これは名前の1つのフォームだけが使用されているよくある例のための清潔なマッピングを与えるでしょう。
Recently, ISO has undertaken work to specify a string form of O/R Address [CCITT/ISO91a]. This has specified a number of string keywords for attributes. As RFC 1148 was an input to this work, many of the keywords are the same. To increase compatability, the following alternative values shall be recognised when mapping from RFC 822 to X.400. These shall not be generated when mapping from X.400 to RFC 822.
最近、ISOは、O/R Address[CCITT/ISO91a]のストリングフォームを指定するために仕事を引き受けました。 これは属性のための多くのストリングキーワードを指定しました。 RFC1148がこれへの入力であったように、働いてください、そして、キーワードの多くが同じです。 RFC822からX.400まで写像するとき、compatabilityを増加させるように、以下の代替の値は認識されるものとします。 X.400からRFC822まで写像するとき、これらを発生させないものとします。
Keyword Alternative
キーワード代替手段
ADMD A
PRMD P
GQ Q
X121 X.121
UA-ID N-ID
PD-OFFICE-NUMBER PD-OFFICE NUMBER
ADMDはPRMD P GQ Q X121 X.121Ua-ID N-ID PD-局番号PD-局番号です。
When mapping from RFC 822 to X.400, the keywords: OU1, OU2, OU3, and OU4, shall be recognised. If these are present, no keyword OU shall be present. These will be treated as ordered values of OU.
RFCからX.400への822、キーワードを写像するとき: OU1(OU2、OU3、およびOU4)は認識されるものとします。 これらが存在していると、キーワードがないOUは存在するでしょう。 これらはOUの命令された値として扱われるでしょう。
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 Address仕様のよくある例のための清潔なコード化にどこを提供するように設計されている)は定義されます:
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. Surname does not contain full stop in the first two
characters.
4. 姓は最初の2つのキャラクタにおける終止符を含んでいません。
5 If Surname is the only component, it does not contain full
stop.
5 Surnameが唯一のコンポーネントであるなら、それは終止符を含んでいません。
Hardcastle-Kille [Page 33] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[33ページ]RFC1327マッピング
The following EBNF is defined:
以下のEBNFは定義されます:
encoded-pn = [ given "." ] *( initial "." ) surname
「コード化されたpnが等しい、[付与、」、」、]、*、(初期、」、」、)、姓
given = 2*<ps-char not including ".">
. 「包含ではなく、与えられた=2*<ps-炭」">"
initial = ALPHA
初期の=アルファー
surname = printablestring
姓=printablestring
This is used to map from any string containing only printable string characters to an O/R address personal name. To map from a string to O/R Address components, 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 component.
これはO/Rアドレスに個人的な印刷可能なストリング性格だけが命名するどんなストリング含有からも写像するのにおいて使用されています。 ストリングからO/RまでAddressの部品を写像するには、EBNFに従って、ストリングを分析してください。 名と姓は直接割り当てられます。 すべてのEBNF.initial象徴が、イニシャルコンポーネントを発生させるように介入している終止符なしで連結されます。
For an O/R address which follows the above restrictions, a string is 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 defined 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表現を指定できます。
Hardcastle-Kille [Page 34] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[34ページ]RFC1327マッピング
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*(「/」属性「=」価値)」/タイプ/キー
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 BNF leads to a set of attribute/value pairs. The value is interpreted according to the EBNF encoding defined in the table.
標準体型はPN、およびDDを除いて、セクション4.2でテーブルで定義されたあらゆるキーです。 BNFは1セットの属性/値の組に通じます。 テーブルで定義されたEBNFコード化に従って、値は解釈されます。
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 are interpreted according to the syntax implied from the encoding, and aligned to either the teletex or printable string form. Key and value shall 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 shall be done in a case-independent manner.
ケースから独立している方法ですべてのキーワードのマッチングをするものとします。
EBNF.std-or-address uses the characters "/" and "=" as delimiters. Domain Defined Attributes and any value may contain these characters. A quoting mechanism, using the non-printable string "$" is used to allow these characters to be represented.
「EBNF.stdかアドレスがキャラクタを使用する」という/、」 デリミタとしての「=。」 ドメインDefined Attributesとどんな値もこれらのキャラクタを含むかもしれません。 引用メカニズムであり、非印刷可能なストリング「$」を使用するのは、これらのキャラクタが代理をされるのを許容するのに使用されます。
If the value is registered-dd-type, and the value is registered at the Internet Assigned Numbers Authority (IANA) as an accepted Domain Defined Attribute type, then the value shall be interpreted
値が登録されたddタイプであり、値が受け入れられたDomain Defined AttributeタイプとしてインターネットAssigned民数記Authority(IANA)に示されるなら、値は解釈されるものとします。
Hardcastle-Kille [Page 35] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[35ページ]RFC1327マッピング
accordingly. This restriction maximises the syntax checking which can be done at a gateway.
それに従って。 この制限はどれがゲートウェイにできるかをチェックする構文を最大にします。
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. 構文はこれを無器用にすることができるくらい異なっています。
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. In some cases, further O/R Address information is associated with the 822.domain component. This cannot be used in the general case, due to character set problems, and to the variants of X.400 O/R Addresses which use different attribute types. 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, and by restrictions in RFC 821.
stdかアドレス構文が、EBNF.822-アドレスの822.local-部分でO/R Address情報をコード化するのに使用されます。 いくつかの場合、一層のO/R Address情報は822.domainの部品に関連しています。 一般的なケースと、文字の組問題と、異なった属性タイプを使用するX.400O/R Addressesの異形にこれを使用できません。 ドメインで完全なPrintableString文字の組をコード化する唯一の方法は822.domain-審判構文(すなわち、822.atom)を使用します。 これは多くのシステムの上で問題を起こしそうです。ドメインの有効な文字の組が実際にはRFC822セットから減少するあります、ドメインコンベンションと方針、およびRFC821での制限で課された制限で。
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) are 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世界からゲートウェイを特定したかもしれませんが)。
The 822.domain associated with the 822.local-part identifies the gateway from within the RFC 822 world. This final 822.domain may be used to determine some number of O/R Address attributes, where this does not conflict with the first role. RFC 822 routing to gateways will usually be set up to facilitate the 822.domain being used for both purposes. The following O/R Address attributes are considered
822.local-部分に関連している822.domainはRFC822世界からゲートウェイを特定します。 この最終的な822.domainは、何らかの数のO/R Address属性を決定するのに使用されるかもしれません。(そこでは、これが最初の役割と衝突しません)。 通常、ゲートウェイへのRFC822ルーティングは、両方の目的に使用される822.domainを容易にするためにセットアップされるでしょう。 以下のO/R Address属性は考えられます。
Hardcastle-Kille [Page 36] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[36ページ]RFC1327マッピング
as a hierarchy, and may be specified by the domain. They are (in order of hierarchy):
階層構造、ドメインによって指定されるかもしれません。 それらはこと(階層構造の順に)です:
Country, ADMD, PRMD, Organisation, Organisational Unit
国、ADMD、PRMD、機構、Organisationalユニット
There may be multiple Organisational Units.
複数のOrganisational Unitsがあるかもしれません。
A global mapping is 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"と等しいです。
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 shall 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". Attributes may have null
values, and this is treated separately from omitted
attributes (whilst it would be bad practice to treat these
3. 階層構造でなくなった要素に対処するために。 ドメインはいくつかの現在のものに関連して省略された属性に関連しているかもしれません。 階層構造で、より低くコンポーネントのアルゴリズムの挿入を実行するとき、省略された値はスキップされるものとします。 例えば、"HNE.EGM"が「CはTcと等しい」、"ADMD=ECQ"、"PRMD=HNE"、および省略された機構に関連しているなら、"ZI.HNE.EGM"は「CはTcと等しい」"ADMD=ECQ"、"PRMD=HNE""OU=ZI"と共に写像されます。 ヌル値が属性にあるかもしれなくて、これが別々に省略された属性から扱われる、(これらを扱うのは、悪い習慣でしょう。
Hardcastle-Kille [Page 37] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[37ページ]RFC1327マッピング
two cases differently, they must be allowed for).
それらを異なって、許容しなければならない2つのケース)
This set of mappings needs be known by the gateways relaying between the RFC 822 world, and the O/R Address space associated with the mapping in question. There needs to be a single global definition of this set of mappings. A mapping implies an adminstrative equivalence between the two parts of the namespaces which are mapped together. To correctly route in all cases, it is necessary for all gateways to know the mapping. To facilitate distribution of a global set of mappings, a format for the exchange of this information is defined in Appendix F.
これはセットしました。マッピングの必要性では、RFC822世界と、O/R Addressの間で関連しているマッピングがはっきりしていなかった状態でスペースをリレーしながら、ゲートウェイによって知られてください。 このセットのマッピングのただ一つのグローバルな定義があるのが必要です。 マッピングは一緒に写像される名前空間の2つの部品の間のadminstrativeの等価性を含意します。 すべてで正しくケースを発送するために、マッピングを知るのがすべてのゲートウェイに必要です。 グローバルなセットのマッピングの分配を容易にするために、この情報の交換のための書式は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をコード化します。
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 is 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 in the previous example O/R Address, it would map with the RFC 822 address: J.Linnimouth@Marketing.Widget.COM.
唯一のLHSでコード化されるべき属性が.1に4.2の制限に従う(非テレテックス)の個人的なName属性であるよくある例のコード化を簡素化するために、さらなるメカニズムがあります。 これを達成するために、822.local-部分はEBNF.encoded-pnとしてコード化されるものとします。 前の例では、GenerationQualifierが前の例のO/R Addressに存在していないなら、それはRFC822アドレスで以下を写像するでしょうに。 J.Linnimouth@Marketing.Widget.COM 。
Hardcastle-Kille [Page 38] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[38ページ]RFC1327マッピング
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 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ストリングの解釈はゲートウェイの文脈によります。
1. In the context of RFC 822, and RFC 920
[Crocker82a,Postel84a], the string can be used directly.
1. RFC822、およびRFC920[Crocker82a、Postel84a]の文脈では、直接ストリングを使用できます。
2. In the context of the JNT Mail protocol, and the NRS
[Kille84a,Larmouth83a], the string shall 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 shall 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"と等しいこと」と等しいです。
Hardcastle-Kille [Page 39] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[39ページ]RFC1327マッピング
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協力と共にこの計画を使用できます。
There is a limit of 128 characters in the length of value of a domain defined attribute, and an O/R Address can have a maxmimum of four domain defined attributes. Where the printable string generated from the RFC 822 address exceeeds this value, additional domain defined attributes are used to enable up to 512 characters to be encoded. These attributes shall be filled completely before the next one is started. The DDA keywords are: RFC822C1; RFC822C2; RFC822C3. Longer addresses cannot be encoded.
ドメインの定義された属性の価値の長さにおける、128のキャラクタの限界があります、そして、O/R Addressは4つのドメインの定義された属性のmaxmimumを持つことができます。 印刷可能なストリングがRFC822アドレスexceeedsからこの値を発生させたところでは、追加ドメイン定義された属性は、最大512のキャラクタがコード化されるのを可能にするのに使用されます。 次のものが始められる完全に前にこれらの属性はいっぱいにされるものとします。 DDAキーワードは以下の通りです。 RFC822C1。 RFC822C2。 RFC822C3。 より長いアドレスをコード化できません。
There is, analagous with 4.3.1, a means to associate parts of the O/R Address hierarchy with domains. There is an analogous global mapping, which in most cases will be the inverse of the domain to O/R address mapping. The mapping is maintained separately, as there may be differences (e.g., two alternate domain names map to the same set of O/R address components).
そこ、あって、analagousする、4.3、.1、O/R Address階層構造の部分をドメインに関連づける手段。 類似のグローバルなマッピングがあります。(多くの場合、それは、O/Rアドレス・マッピングへのドメインの逆になるでしょう)。 マッピングは別々に維持されます、違い(例えば、同じセットのO/Rアドレス構成要素への2の交互のドメイン名地図)があるかもしれないので。
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. 複数のマッピングの上の秩序の維持を確実にするために。
There are three places where an order is 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属性の右にはもそれがあるものとします。 これらの要件が以下の理由であります:
Hardcastle-Kille [Page 40] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[40ページ]RFC1327マッピング
- 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. When generating
822.msg-id, this order shall be followed.
さらに、この注文に応じて他のすべての属性が発生するのは、お勧めです、そのようにコード化されたすべての属性が一貫した階層構造に従うように。 822.msg-イドを発生させるとき、このオーダーは従われるものとします。
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
First Domain Defined Attribute in the SEQUENCE is the most
significant.
3. MTS.ORAddressのDomain Defined Attributesに関しては、SEQUENCEのFirst 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 shall 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
地方の部分"@"ドメイン
take the domain which will be routed on and apply step 2 of
stage 1 to derive (a possibly null) set of attributes. Then
ステップ2を意志に発送されて、適用するドメインは引き出す1を上演します。撮影、(ことによるとヌル) セットの属性。 その時
Hardcastle-Kille [Page 41] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[41ページ]RFC1327マッピング
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 the
set of globally defined mappings (see Appendix F). If this
fails, and the EBNF.domain does not explicitly identify the
local gateway, go to stage II. If the domain explicitly
identifies the gateway, allocate no attributes. Otherwise,
allocate the attributes associated with EBNF.known-domain.
For each component, systematically allocate the attribute
implied by each EBNF.domain-syntax component in the order:
C, ADMD, PRMD, O, OU. Note that if the mapping used
identifies an "omitted attribute", then this attribute
should be omitted in the systematic allocation. If this new
component exceed an upper bound (ADMD: 16; PRMD: 16; O: 64;
OU: 32) or it would lead to more than four OUs, then go to
stage II with the attributes derived.
EBNF.known-ドメインがグローバルに定義されたマッピングのセットで可能な限り長いマッチ(Appendix Fを見る)であるところ。 これが失敗して、EBNF.domainが明らかに地方のゲートウェイを特定しないなら、ステージIIまで行ってください。 ドメインが明らかにゲートウェイを特定するなら、属性を全く割り当てないでください。 さもなければ、EBNF.known-ドメインに関連している属性を割り当ててください。 各コンポーネントには、オーダーに系統的にそれぞれのEBNF.domain-構文コンポーネントによって含意された属性を割り当ててください: C、ADMD、PRMD、O、OU。 使用されるマッピングが「省略された属性」を特定するならこの属性が系統的な配分で省略されるべきであることに注意してください。 この新しいコンポーネントであるなら上限(ADMD: 16; PRMD: 16; O: 64; OU: 32)を超えてくださいか、それは、4OUsに通じて、次に、属性が引き出されている状態で、ステージIIまで行くでしょう。
At this stage, a set of attributes has been derived, which
will give appropriate routing within X.400. If any of the
later steps of Stage I force use of Stage II, then these
attributes should be used in Stage II.
現在のところ、1セットの属性(X.400の中で適切なルーティングを与える)は引き出されました。 Stageの後のステップのどれかであるなら、私はStage IIの使用を強制して、次に、これらの属性はStage IIで使用されるべきです。
3. If the 822.local-part uses the 822.quoted-string encoding,
remove this quoting. If this unquoted 822.local-part has
leading space, trailing space, or two adjacent space go to
stage II.
3. 822.local-部分が822.quoted-stringコード化を使用するなら、この引用を取り除いてください。 これが引用を終わったなら、822.local-部分には、スペースを引きずって、主なスペースがあるか、またはスペースに隣接した2はステージIIまで行きます。
4. If the unquoted 822.local-part contains any characters not
in PrintableString, go to stage II.
4. 引用を終わっている822.local-部分がどんなPrintableStringにも何かキャラクタを含まないなら、ステージIIまで行ってください。
5. Parse the (unquoted) 822.local-part according to the EBNF
EBNF.std-or-address. Checking of upper bounds should not be
5. EBNF EBNF.stdかアドレスに従って、(引用を終わられます)822.local-部分を分析してください。 上限の照合はそうであるべきではありません。
Hardcastle-Kille [Page 42] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[42ページ]RFC1327マッピング
done at this point. If this parse fails, parse the local-
part according to the EBNF EBNF.encoded-pn. If this parse
fails, go to stage II. The result is a set of type/value
pairs. If the set of attributes leads to an address of any
form other than mnemonic form, then only these attributes
should be taken. If (for mnemonic form) the values generated
conflict with those derived in step 2 (e.g., a duplicated
country attribute), the domain is assumed to be a remote
gateway. In this case, take only the LHS derived
attributes, together with any RHS dericed attributes which
are more significant thant the most signicant attribute
which is duplicated (e.g., if there is a duplicate PRMD, but
no LHS derived ADMD and country, then the ADMD and country
should be taken from the RHS). therwise add LHS and RHS
derived attributes together.
ここに、します。 これであるなら、やり損ないを分析してください、そして、EBNF EBNF.encoded-pnに従って、地方の部分を分析してください。 これであるなら、やり損ないを分析してください、そして、ステージIIまで行ってください。 結果は1セットのタイプ/値の組です。 属性のセットが簡略記憶フォーム以外のどんなフォームのアドレスにもつながるなら、これらの属性だけを取るべきです。 (簡略記憶フォームのための)値がステップ2(例えば、コピーされた国の属性)で引き出されるそれらとの闘争を発生させたなら、ドメインはリモートゲートウェイであると思われます。 この場合大部分がsignicantに結果と考えるコピーされるより重要なthantであるあらゆるRHS dericed属性と共にLHSの引き出している属性だけを取ってください、(例えば、LHSの引き出しているADMDと写しPRMDではなく、国があれば、RHSからADMDと国を取るべきです)therwiseする、LHSとRHSが属性を一緒に引き出したと言い足してください。
6. 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.
6. EBNF.attribute-value構文(特定されたタイプから断固とした)を各値に関連づけてください、そして、それが従うのをチェックしてください。そうでなければ、ステージIIまで行ってください。
7. Ensure that the set of attributes conforms both to the
MTS.ORAddress specification and to the restrictions on this
set given in X.400, and that no upper bounds are exceeded
for any attribute. If not go to stage II.
7. 属性のセットがX.400で与えられているこのセットでMTS.ORAddress仕様と、そして、制限に一致していて、上限が全くどんな属性のためにも超えられていないのを確実にしてください。 そうでなければ、ステージIIまで行ってください。
8. Build the O/R Address from this information.
8. この情報から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. This implies that the address must refer to a recipient on an RFC 822 system. Such addresses shall be encoded in an X.400 O/R Address using a domain defined attribute.
これにRFC822EBNF.822-アドレスが有効なX.400コード化でない場合にだけ達するでしょう。 これは、アドレスがRFC822システムの上の受取人について言及しなければならないのを含意します。 そのようなアドレスは、X.400O/R Addressでドメインの定義された属性を使用することでコード化されるものとします。
1. Convert the EBNF.822-address to PrintableString, as
specified in Chapter 3.
1. 第3章で指定されるようにEBNF.822-アドレスをPrintableStringに変換してください。
2. Generate the "RFC-822" domain defined attribute from this
string.
2. このストリングから"RFC-822"ドメインの定義された属性を発生させてください。
3. Build the rest of the O/R Address in the manner described
below.
3. 以下で説明された方法における、O/R Addressの残りを築き上げてください。
It may not be possible to encode the domain defined attribute due to length restrictions. If the limit is exceeded by a mapping at the MTS level, then the gateway shall reject the message in question. If this occurs at the IPMS level, then the action will depend on the policy being taken for IPMS encoding, which is discussed in Section
長さの制限のためドメインの定義された属性をコード化するのは可能でないかもしれません。 限界がMTSレベルにおけるマッピングによって超えられているなら、ゲートウェイは問題のメッセージを拒絶するものとします。 これがIPMSレベルで起こると、動作はセクションで議論するIPMSコード化に取られた方針存在によるでしょう。
Hardcastle-Kille [Page 43] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[43ページ]RFC1327マッピング
5.1.3.
5.1.3.
If Stage I has identified a set of attributes, use these to build the remainder of the address. The administrative equivalence of the mappings will ensure correct routing throug X.400 to a gateway back to RFC 822.
Stageであるなら、私は、アドレスの残りを築き上げるのに1セットの属性を特定して、これらを使用します。 マッピングの管理等価性はRFC822へのゲートウェイに正しいルーティングthroug X.400を確実にするでしょう。
If Stage I has not identified a set of attributes, the remainder of the O/R address effectively identifies a source route to a gateway from the X.400 side. There are three cases, which are handled differently:
Stageであるなら、私は1セットの属性を特定していなくて、事実上、O/Rアドレスの残りはX.400側からゲートウェイに送信元経路を特定します。 3つのケースがあります:(ケースは異なって扱われます)。
822-MTS Return Address
This shall be set up so that errors are returned through the
same gateway. Therefore, the O/R Address of the local
gateway shall be used.
822-MTS Return Address Thisがセットアップされるものとするので、誤りは同じゲートウェイを通して返されます。 したがって、地方のゲートウェイのO/R Addressは使用されるものとします。
IPMS Addresses
These are optimised for replying. In general, the message
may end up anywhere within the X.400 world, and so this
optimisation identifies a gateway appropriate for the RFC
822 address being converted. The 822.domain to which the
address would be routed is used to select an appropriate
gateway. A globally defined set of mappings is used, which
identifies (the O/R Address components of) appropriate
gateways for parts of the domain namespace. The longest
possible match on the 822.domain defines which gateway to
use. The table format for distribution of this information
is defined in Appendix F.
IPMS Addresses Theseは、返答するために最適化されます。 一般に、メッセージがX.400世界の中でどこでも終わるかもしれないので、この最適化は変換されるRFC822アドレスに、適切なゲートウェイを特定します。 アドレスが発送される822.domainは、適切なゲートウェイを選択するのに使用されます。 グローバルに定義されたセットのマッピングが使用されている、どれ、特定、(O/R Addressの部品、)、ドメイン名前空間の部品にゲートウェイを当ててくださいか。 822.domainにおける可能な限り長いマッチは、どのゲートウェイを使用したらよいかを定義します。 この情報の分配のためのテーブル書式はAppendix Fで定義されます。
This global mapping is used for parts of the RFC 822
namespace which do not have an administrative equivalence
with any part of the X.400 namespace, but for which it is
desirable to identify a preferred X.400 gateway in order to
optimise routing.
ルーティングを最適化して、このグローバルなマッピングは持っていませんが、都合のよいX.400ゲートウェイを特定するのがX.400名前空間のどんな部分がある管理等価性も望ましいRFC822名前空間の部品に使用されます。
If no mapping is found for the 822.domain, a default value
(typically that of the local gateway) is used. It is never
appropriate to ignore the globally defined mappings. In
some cases, it may be appropriate to locally override the
globally defined mappings (e.g., to identify a gateway close
to a recipient of the message). This is likely to be where
the global mapping identifies a public gateway, and the
local gateway has an agreement with a private gateway which
it prefers to use.
写像でないのが822.domainに関して見つけられるなら、デフォルト値(通常地方のゲートウェイのもの)は使用されています。 グローバルに定義されたマッピングを無視するのは決して適切ではありません。 いくつかの場合、局所的にグローバルに定義されたマッピング(例えばメッセージの受取人の近くでゲートウェイを特定する)に優越するのは適切であるかもしれません。 これはグローバルなマッピングが公共のゲートウェイを特定するところのである傾向があります、そして、地方のゲートウェイには、それが使用するのを好む個人的なゲートウェイとの協定があります。
822-MTS Recipient
As the RFC 822 and X.400 worlds are fully connected, there
822-MTS Recipient As RFC822とX.400世界はそこに完全につなげられます。
Hardcastle-Kille [Page 44] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[44ページ]RFC1327マッピング
is no technical reason for this situation to occur. In some
cases, routing may be configured to connect two parts of the
RFC 822 world using X.400. The information that this part
of the domain space should be routed by X.400 rather than
remaining within the RFC 822 world will be configured
privately into the gateway in question. The O/R address
shall then be generated in the same manner as for an IPMS
address, using the globally defined mappings. It is to
support this case that the definition of the global domain
to gateway mapping is important, as the use of this mapping
will lead to a remote X.400 address, which can be routed by
X.400 routing procedures. The information in this mapping
shall not be used as a basis for deciding to convert a
message from RFC 822 to X.400.
どんな技術的な理由もこの状況を生じることになっていませんか? いくつかの場合、ルーティングは、RFC822世界の2つの地域を接続するためにX.400を使用することで構成されるかもしれません。 ドメインスペースのこの部分がRFC822世界に残っているよりX.400によってむしろ発送されるはずであるという情報は問題のゲートウェイに個人的に構成されるでしょう。 次に、O/RアドレスはIPMSアドレスのように同じ方法で作られるものとします、グローバルに定義されたマッピングを使用して。 それはゲートウェイへのグローバルなドメインの定義が写像されて、重要な本件を支えることになっています、このマッピングの使用がリモートX.400アドレス(X.400ルーティング手順で発送できる)につながるとき。 RFC822からX.400までメッセージを変換すると決める基礎としてこのマッピングの情報を使用しないものとします。
4.3.4.1. Heuristics for mapping RFC 822 to X.400
4.3.4.1. RFC822をX.400に写像するための発見的教授法
RFC 822 users will often use an LHS encoded address to identify an X.400 recipient. Because the syntax is fairly complex, a number of heuristics may be applied to facilitate this form of usage. A gateway should take care not to be overly "clever" with heuristics, as this may cause more confusion than a more mechanical approach. The heuristics are as follows:
RFC822ユーザはしばしばLHSが特定するためにアドレスをコード化した使用にX.400受取人を望んでいます。 構文がかなり複雑であるので、多くの発見的教授法がこのフォームの使用法を容易にするために適用されるかもしれません。 ゲートウェイは発見的教授法にひどく「賢明でなく」なるように注意されるはずです、これが、より機械的なアプローチより多くの混乱を引き起こすとき。 発見的教授法は以下の通りです:
1. Ignore the omission of a trailing "/" in the std-or syntax.
1. または、中の「」 /を引きずるaの省略を無視してください」、std、-、構文。
2. If there is no ADMD component, and both country and PRMD are
present, the value of /ADMD= / (single space) is assumed.
2. ADMDの部品が全くなくて、国とPRMDの両方が存在しているなら、/ADMD=/(シングルスペース)の値は想定されます。
3. Parse the unquoted local part according to the EBNF colon-
or-address. This may facilitate users used to this
delimiter.
3. または、EBNFコロンに従って引用を終わっている地方の部分を分析してください、-、アドレス これはこのデリミタに慣れているユーザを容易にするかもしれません。
colon-or-address = 1*(attribute "=" value ";" *(LWSP-char))
コロンかアドレス=1*「(属性は「」 値と等しい」; 」 *(LWSP-炭))
The remaining heuristic relates to ordering of address components. The ordering of attributes may be inverted or mixed. For this reason, the following heuristics may be applied:
残っているヒューリスティックはアドレス構成要素の注文に関連します。 属性の注文を逆にするか、または混ぜるかもしれません。 この理由で、以下の発見的教授法は適用されるかもしれません:
4. If there is an Organisation attribute to the left of any Org
Unit attribute, assume that the hierarchy is inverted.
4. どんなOrg Unit属性の左へのOrganisation属性もあれば、階層構造が逆さであると仮定してください。
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アドレス。
Hardcastle-Kille [Page 45] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[45ページ]RFC1327マッピング
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 is a single "RFC-822" domain defined attribute present and the local gateway is identified by the remainder of the O/R Address. In this case, use mapping A. For other O/R Addresses which
MTS Recipient O/R Addressが解釈されるとき、存在しているただ一つの"RFC-822"ドメイン定義された属性があると、gatewayingは選択されるでしょう、そして、地方のゲートウェイはO/Rアドレスの残りによって特定されます。 この場合マッピング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. Use of this approach is
conformant to this specification.
以下に注意してください。 実際的なアプローチは特別なドメイン定義された属性があるどんなO/R AddressもRFC822アドレスを特定すると仮定するだろうことです。 これは、通常正しく働きますが、原則として正しくはありません。 このアプローチの使用はこの仕様へのconformantです。
Mapping A
Aを写像します。
1. Map the domain defined attribute value to ASCII, as defined
in Chapter 3.
1. 第3章で定義されるようにドメインの定義された属性値をASCIIに写像してください。
Mapping B
Bを写像します。
This is 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. すべてに関しては、コード化された属性を結んでください、そして、あらゆる主であるか引きずっている空間を移してください、そして、隣接している空間をシングルスペースに取り替えてください。
The only attribute which is permitted to have zero length is
the ADMD. This should be mapped onto a single space.
ゼロ・レングスを持っていることが許可されている唯一の属性がADMDです。 これはシングルスペースに写像されるべきです。
These transformations are for lookup only. If an
EBNF.std-or-address mapping is used as in 4), then the
orginal values should be used.
これらの変化はルックアップだけのためのものです。 EBNF.stdかアドレス・マッピングが4のように)使用されているなら、orginal値は使用されるべきです。
2. Map numeric country codes to the two letter values.
2. 2つの手紙値に数値国名略号を写像してください。
Hardcastle-Kille [Page 46] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[46ページ]RFC1327マッピング
3. Noting the hierarchy specified in 4.3.1 and including
omitted attributes, determine the maximum set of attributes
which have an associated domain specification in the
globally defined mapping. If no match is found, allocate
the domain as the domain specification of the local gateway,
and go to step 5.
3. 階層構造が4.3の.1と包含の省略された属性で指定したことに注意して、グローバルに定義されたマッピングの関連ドメイン仕様を持っている最大のセットの属性を決定してください。 マッチが全く見つけられないなら、地方のゲートウェイのドメイン仕様としてドメインを割り当ててください、そして、ステップ5に行ってください。
Note: It might be appropriate to use a non-local domain.
This would be selected by a global mapping analagous to
the one described at the end of 4.3.4. This is not
done, primarily because use of RFC 822 to connect X.400
systems is not expected to be significant.
以下に注意してください。 非局所領域を使用するのは適切であるかもしれません。 これはグローバルなマッピングanalagousによって4.3の終わりで.4に説明されたものに選択されるでしょう。 主としてX.400システムを接続するRFC822の使用が重要でないと予想されるので、これをしません。
In cases where the address refers to an X.400 UA, it is
important that the generated domain will correctly route to
a gateway. In general, this is achieved by carefully co-
ordinating RFC 822 routing with the definition of the global
mappings, as there is no easy way for the gateway to make
this check. One rule that shall be used is that domains
with only one component will not route to a gateway. If the
generated domain does not route correctly, the address is
treated as if no match is found.
アドレスがX.400 UAについて言及する場合では、発生しているドメインが正しくゲートウェイにルートを望んでいるのは、重要です。 一般に、これは慎重に達成されます。ゲートウェイがこのチェックをするどんな簡単な方法もグローバルなマッピングないので定義で掘られるordinating RFCの共同822。 ゲートウェイへのルートではなく、使用されているのが、1つのコンポーネントだけがあるドメインがそうするということであるということである1つの規則。 発生しているドメインが正しくどんなルートもしないなら、まるでマッチが全く見つけられないかのようにアドレスは扱われます。
4. The mapping identified in 3) gives a domain, and an O/R
address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU.
For each successive component below the O/R address prefix,
which 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 shall not be mapped onto
subdomain, as 822.local-part cannot be null. If there are
omitted attributes in the O/R address prefix, these will
have correctly and uniquely mapped to a domain component.
Where there is an attribute omitted below the prefix, all
attributes remaining in the O/R address shall be encoded on
the LHS. This is to ensure a reversible mapping. For
example, if the is an addres /S=XX/O=YY/ADMD=A/C=NN/ and a
mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is
encoded on the LHS.
4. 3で)特定されたマッピングはドメイン、およびO/Rアドレス接頭語を与えます。 階層構造に従ってください: C、ADMD、PRMD、O、OU。 O/Rアドレス接頭語の下におけるそれぞれの連続したコンポーネントのために、どれが構文EBNF.domain-構文に従うか、(中で定義される、4.3、.1、)、次のサブドメインを割り当ててください。 822.local-部分がヌルであるはずがないので、X.400アドレスの少なくとも1つの属性をサブドメインに写像しないものとします。 O/Rアドレス接頭語の属性が省略されると、ドメインコンポーネントに写像されて、これらは正しく唯一持つでしょう。 接頭語の下で省略された属性があるところでは、O/Rアドレスに残っているすべての属性がLHSでコード化されるものとします。 これは、リバーシブルのマッピングを確実にするためのものです。 例えば、/ADMD=A/Cであることのマッピング=NN/が使用されている、addres/S=XX/O=YY/ADMD=A/C=はNN/であり、次に、/S=XX/O=YY/はLHSでコード化されます。
5. If the address is not mnemonic form (form 1 variant 1),
then all of the attributes in the address should be encoded
on the LHS in EBNF.std-or-address syntax, as described
below.
5. アドレスが簡略記憶フォーム(1つの異形1を形成する)でないなら、アドレスの属性のすべてがLHSでEBNF.stdかアドレス構文でコード化されるべきです、以下で説明されるように。
For addresses of mnemonic form, if the remaining components
are personal-name components, conforming to the restrictions
of 4.2.1, then EBNF.encoded-pn is derived to form
822.local-part. In other cases the remaining components are
簡略記憶フォームのアドレスにおいて、残っているコンポーネントが個人名コンポーネントであるなら.1、当時のEBNF.encoded-pnを4.2の制限に従わせるのは、822.local-部分を形成するために引き出されます。 他の場合では、残っているコンポーネントはそうです。
Hardcastle-Kille [Page 47] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[47ページ]RFC1327マッピング
simply encoded as 822.local-part using the
EBNF.std-or-address syntax. If necessary, the
822.quoted-string encoding is used. The following are
examples of legal quoting: "a b".c@x; "a b.c"@x. Either
form may be generated, but the latter is preferred.
822.local-部分としてEBNF.stdかアドレス構文を使用することで単にコード化されています。 必要なら、822.quoted-stringコード化は使用されています。 ↓これは法的な引用に関する例です: "a b" .c@x; 「b.c」@x。 どちらのフォームも作られるかもしれませんが、後者は好まれます。
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. 繰り返されたマッピング
There are two types of repeated mapping:
繰り返されたマッピングの2つのタイプがあります:
1. A recursive mapping, where the repeat is within one gateway
1. 再帰的なマッピング。(そこに、1門の中に反復があります)。
2 A source route, where the repetition occurs across multiple
gateways
2 送信元経路。(そこでは、反復が複数のゲートウェイの向こう側に起こります)。
4.4.1. Recursive Mappings
4.4.1. 再帰的なマッピング
It is possible to supply an address which is recurive at a single gateway. For example:
1門でrecuriveであるアドレスを供給するのは可能です。 例えば:
C = "XX"
ADMD = "YY"
O = "ZZ"
"RFC-822" = "Smith(a)ZZ.YY.XX"
"ZZ""XX"C=ADMD="YY"O="RFC-822"は"Smith(a)ZZ.YY.XX"と等しいです。
This is mapped first to an RFC 822 address, and then back to the X.400 address:
これは最初にRFC822アドレスと、そして、そして、X.400アドレスに写像して戻されます:
C = "XX"
ADMD = "YY"
O = "ZZ"
Surname = "Smith"
"ZZ""XX"C=ADMD="YY"O=姓は「スミス」と等しいです。
In some situations this type of recursion may be frequent. It is important that where this occurs, that no unnecessary protocol conversion occurs. This will minimise loss of service.
このタイプの再帰はいくつかの状況が頻繁であるかもしれません。 これが起こるところにそのいいえ不要なプロトコル変換が起こるのは、重要です。 これはサービスの損失を最小とならせるでしょう。
4.4.2. Source Routes
4.4.2. 送信元経路
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
定義されたマッピングは、1門の向こう側に対称であってリバーシブルです。 対称は(メール発破器タイプ)発送先リスト拡大の場合で特に役に立ちます。 例えば、X.400ユーザは彼が属すRFC822システムの上のリストに発信します。 The
Hardcastle-Kille [Page 48] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[48ページ]RFC1327マッピング
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.
受信されたメッセージは正しい形式(二倍コード化されているよりむしろ)で創始者とどんな第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
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
これはX.400によって任意のイギリスのAcademic Communityゲートウェイに送られるでしょう。 そして、JNTメールはドメインInria.ATLAS.FR(FR.ATLAS.Inria)のそばで断固としたもう1つの門にそれを送るでしょう。 これはそうするでしょう。
Hardcastle-Kille [Page 49] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[49ページ]RFC1327マッピング
then derive the X.400 O/R Address:
次に、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 PRMD by X.400, and then to jj@seismo.css.gov by RFC 822.
これはRFC822によってmonet.berkeley.eduに送られるでしょう、そして、X.400と、そして、RFC822による jj@seismo.css.gov へのAC 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 is 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に、完全なマッピングを加える重要な余分な複雑さより望ましく見えるところにあるかもしれません。
Note:There is ongoing work on specification of a "user friendly"
format for directory names. If this is adopted as an
internet standard, it will be recommended, but not required,
for use here.
注意: ディレクトリ名のための「ユーザフレンドリーな」形式の仕様に対する進行中の仕事があります。 これがインターネット規格として採用されると、それは、推薦されますが、使用にここで必要でないでしょう。
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-
822-MTS受取人と返送先がEBNF.822としてコード化される、-
Hardcastle-Kille [Page 50] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[50ページ]RFC1327マッピング
address.
アドレス。
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 are made for each component of MTS.PerRecipientMessageSubmissionFields.
受取人に関しては、以下の設定はMTS.PerRecipientMessageSubmissionFieldsの各部品のために作られています。
recipient-name
This is derived from the 822-MTS recipient by the basic
ORAddress mapping.
基本のORAddressマッピングは822-MTS受取人から受取人名のThisを得ます。
originator-report-request
This is be set according to content return policy, as
discussed in Section 5.2.
満足している返品条件によると、Thisがあることであるという創始者レポート要求はセクション5.2で議論するようにセットしました。
explicit-conversion
This optional component is omitted, as this service is not
needed
このサービスは必要でないように明白な変換のThisの任意の部品が省略されます。
extensions
The default value (no extensions) is 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 will be present in these fields. In some cases a (positive) delivery report will be generated.
基本機能は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 is discarded. (Note that it will be presented to the user, as described in 4.6.2.2).
基本のORAddressマッピングを使用して、MTS.OtherMessageDeliveryFields.originator-名前(MTS.ORName)から822-MTS創始者(返送先)を発生させてください。 MTS.ORName.directory-nameが存在しているなら、捨てられます。 それがユーザ4.6で説明されるように提示されることに注意してください。(.2 .2)。
Hardcastle-Kille [Page 51] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[51ページ]RFC1327マッピング
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 is set to the same value as the 822-MTS originator. In addition, if MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) contains MTS.ORName.directory-name then this Directory Name shall be represented in an 822.comment.
「X400-創始者:」 分野は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 are 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. However, this conflicts with a desire to optimise mail transfer. There is no problem when disclosure of recipients is allowed. Similarly, there is no problem if there is only one RFC 822 recipient, as the "X400-Recipients field is only given one address.
MTS.OtherMessageDeliveryFields.this受取人名とMTS.OtherMessageDeliveryFields.other受取人名の値がRFC822ユーザにとって使用で利用可能にされるそれぞれから取られた受取人名、「X400-受取人:」 さばきます。 MTSレベルで受取人を連れて行くことによって、受取人の公開は正しく対処されるでしょう。 しかしながら、これは郵便為替を最適化する願望と衝突します。 受取人の公開が許されているとき、問題が全くありません。 同様に、1RFCだけの822受取人がいれば、問題が全くありません、「野原が与えられるだけであるX400-受取人1つのアドレス」として。
There is a problem if there are multiple RFC 822 recipients, and disclosure of recipients is prohibited. Two options are allowed:
複数のRFC822受取人がいれば、問題があります、そして、受取人の公開は禁止されています。 2つのオプションが許容されています:
1. Generate one copy of the message for each RFC 822 recipient,
with the "X400-Recipients field correctly set to the
recipient of that copy. This is functionally correct, but
is likely to be more expensive.
1. それぞれのRFC822受取人のためにメッセージのコピー1部を発生させてください、「X400-受取人分野は正しくそのコピーの受取人にセットしたこと」で。 これは、機能上正しいのですが、より高価である傾向があります。
2. Discard the per-recipient information, and insert a field:
2. 1受取人あたりの情報を捨ててください、そして、野原を挿入してください:
X400-Recipients: non-disclosure:;
X400-受取人: 非公開:、。
Hardcastle-Kille [Page 52] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[52ページ]RFC1327マッピング
This is the recommended option.
これはお勧めのオプションです。
A third option of ignoring the disclosure flag is not allowed. If any MTS.ORName.directory-name is present, it shall be represented in an 822.comment.
公開旗を無視する3番目のオプションは許容されていません。 どれかMTS.ORName.directory-nameが存在しているなら、それは822.commentに表されるものとします。
If MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name is present, then there has been redirection, or there has been distribution list expansion. Distribution list expansion is a per- message option, and the information associated with this is represented by the "DL-Expansion-History:" field descrined in Section 5.3.6. Other information is represented in an 822.comment associated associated with MTS.OtherMessageDeliveryFields.this-recipient-name, The message may be delivered to different RFC 822 recipients, and so several addresses in the "X400-Recipients:" field may have such comments. The non-commented recipient is the RFC 822 recipient. The EBNF of the comment is:
MTS.OtherMessageDeliveryFields.orignallyが受取人名を意図したなら、リダイレクションが、存在していて、あったか、または発送先リスト拡大がありました。 発送先リスト拡大がaである、-、オプション、およびこれが交際する状態で表されるという情報を通信させてください、「dl拡大歴史:」 分野はセクション5.3.6でdescrinedされました。 中、MTS.OtherMessageDeliveryFields.this受取人名に関連していた状態で関連づけられた822.commentに他の情報を表して、異なったRFCにメッセージを渡すかもしれない、数個が演説する822人の受取人、およびそう、「X400-受取人:」 分野には、そのようなコメントがあるかもしれません。 非論評された受取人はRFC822受取人です。 コメントのEBNFは以下の通りです。
redirect-comment =
[ "Originally To:" ] mailbox "Redirected"
[ "Again" ] "on" date-time
"To:" redirection-reason
再直接のコメントはメールボックスの「向け直された」[「再び」]“on"日付-時間「To:」と等しいです[「元々のTo:」]。 リダイレクション理由
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
リダイレクション理由は「受取人の割り当てられた交互の受取人」/「創始者の要求された交互の受取人」/「受取人のMdの割り当てられた交互の受取人」と等しいです。
It is derived from MTA.PerRecipientMessageTransferFields.extension.redirection-history. An example of this is:
MTA.PerRecipientMessageTransferFields.extension.redirection-歴史からそれを得ます。 この例は以下の通りです。
X400-Recipients: postmaster@widget.com (Originally To:
sales-manager@sales.widget.com Redirected
on Thu, 30 May 91 14:39:40 +0100 To: Originator Assigned
Alternate Recipient postmaster@sales.widget.com Redirected
Again on Thu, 30 May 91 14:41:20 +0100 To: Recipient MD
Assigned Alternate Recipient)
X400-受取人: postmaster@widget.com (To: 元々の木曜日に向け直された sales-manager@sales.widget.com 、To:創始者が交互の受取人 postmaster@sales.widget.com を割り当てた1991年5月30日の14:39:40+0100は木曜日、1991年5月30日の14:41:20+0100に再びTo: 交互の受取人に割り当てられた受取人MDを向け直しました)
In addition, the following per-recipient services from MTS.OtherMessageDeliveryFields.extensions are 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 shall be chosen by the implementor. If the parameter has a default value, then no comment shall be inserted when the parameter has that default value.
さらに、それらが使用されているなら、MTS.OtherMessageDeliveryFields.extensionsからの以下の1受取人あたりのサービスはコメントで表されます。 RFC822ネットワークでこれらのサービスのどれかを提供できないので、一般に、これらは他のMTS受取人に関連している有益なストリングになるでしょう。 いくつかの場合、ストリング値は定義されます。 残りにおいて、ストリング値は作成者によって選ばれるものとします。 パラメタにデフォルト値があるなら、パラメタにそのデフォルト値があると、ノーコメントは挿入されるものとします。
Hardcastle-Kille [Page 53] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[53ページ]RFC1327マッピング
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)".
「(要求された配達証明)」という配送要求の証拠。
4.6.2.3. Delivery Report Generation
4.6.2.3. 配送レポート作成
If MTA.PerRecipientMessageTransferFields.per-recipient-indicators requires a positive delivery notification, this shall be generated by the gateway. Supplementary Information shall be set to indicate that the report is gateway generated. This information shall include the name of the gateway generating the report.
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 are used to generate MTS.MTSIdentifier.global- domain-identifier. MTS.MTSIdentifier.local-identifier is set to the 822.msg-id, including the braces "<" and ">". If this string is longer than MTS.ub-local-id-length (32), then it is 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を特定します。
Hardcastle-Kille [Page 54] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[54ページ]RFC1327マッピング
4.7. IPMS Mappings
4.7. IPMSマッピング
All RFC 822 addresses are assumed to use the 822.mailbox syntax. This includes 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 shall be built consisting of (if present):
2. 成ることが五弦に建てられるものとする、(存在しているなら):
- 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 is then encoded into T.61 use a human oriented
mapping (as described in Chapter 3). If the string is not
null, it is assigned to IPMS.ORDescriptor.free-form-name.
そして、このストリングは、写像しながら(第3章で説明されるように)、人間が適応させたT.61使用にコード化されます。 ストリングがヌルでないなら、それはIPMS.ORDescriptor.freeフォーム名に割り当てられます。
3. IPMS.ORDescriptor.telephone-number is omitted.
3. IPMS.ORDescriptor.telephone-numberは省略されます。
If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier, IPMS.RecipientSpecifier.reply-request and IPMS.RecipientSpecifier.notification-requests are 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 is encoded as above to generate a separate IPMS.ORDescriptor. The 822.group is 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
1. IPMS.ORDescriptor.formal-name(MTS.ORName)をコード化します。
Hardcastle-Kille [Page 55] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[55ページ]RFC1327マッピング
EBNF.822-address.
EBNF.822-アドレス。
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 is 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 is
placed in an 822.comment, with the string "Tel ". The
normal international form of number is used. For example:
3. IPMS.ORDescriptor.telephone-numberが存在しているなら、これはストリング"Tel"と共に822.commentに置かれます。 正常な国際的なフォームの数は使用されています。 例えば:
(Tel +44-1-387-7050)
(Tel+44-1-387-7050)
4. If IPMS.ORDescriptor.formal-name.directory-name is present,
then a text representation is 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)" is appended to the address.
If both receipt and non-receipt notfications are requested,
the comment relating to the latter may be omitted, to make
the RFC 822 address cleaner. 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リターン)」をアドレスに追加します。 領収書と非領収書notficationsの両方が要求されるなら、後者に関連するコメントは、アドレスクリーナーにRFC822を作るために省略されるかもしれません。 P1とP2情報を関連させる努力はゲートウェイがReceipt Notificationsを送るのを正当化できないくらい大きいです。
6. If IPMS.RecipientSpecifier.reply-request is True, an
822.comment "(Reply requested)" is appended to the address.
6. IPMS.RecipientSpecifier.reply-要求がTrueであるなら、「(要求された回答)」という822.commentをアドレスに追加します。
If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free- form-name is 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 are then 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,
822.msg-イドとIPMS.IPMIdentifierの間には、両方の道を写像する必要があります。 これはX.400 Receipt Notificationsを考慮します。
Hardcastle-Kille [Page 56] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[56ページ]RFC1327マッピング
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.
回答であり、参照RFC822Message IDへのCross Referencesでありどれがゲートウェイより望ましいかが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に答えることができることに関する問題が全くありません。 (アドレスにおいて、働いているリターンパスを作成するのは対称であるより重要です。)
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. The upper
bound on this component is 64. The options for handling this are
discussed in Section 5.1.3.
IPMS.IPMIdentifier.userは省略されます。 IPMS.IPMIdentifier.userの相対的な識別子は角度支柱("<"と">")による822.msg-イドのコード化が取り除いた印刷可能なストリングに設定されます。 このコンポーネントの上の上限は64です。 セクション5.1.3でこれを扱うためのオプションについて議論します。
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>。
Hardcastle-Kille [Page 57] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[57ページ]RFC1327マッピング
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 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:
さもなければ、IDは発生するX.400です。 IPMS.IPMIdentifier.userを使用して、EBNF.stdかアドレスフォームストリングを発生させてください。 構文で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 "InReply-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 "In-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.
「InReply-To:」で そして、「以下に参照をつける」、コード化している822.phraseは822.msg-イドに代わる手段として使用されるかもしれません。 822.phraseから句へのIPMS.IPMIdentifier.user相対的な識別子のIPMS.IPMIdentifier、案配まで写像するために。 IPMS.IPMIdentifierから、「以下に対して」のために写像します。 そして、「参照:」 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 defined 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
ここで定義されたマッピングはRFC987で使用されるそれに異なっています、多くの場合における変えられたメッセージIDへのRFC987マッピングリードとして。 問題を修正するのは後方に互換性を保有するより望ましいです。 1
Hardcastle-Kille [Page 58] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[58ページ]RFC1327マッピング
implementation of this standard is encouraged to recognise message IDs generated by RFC 987. This is not required.
この規格の実現がRFC987によって発生したメッセージIDを認識するよう奨励されます。 これは必要ではありません。
RFC 987 generated encodings may be recognised as follows. When mapping from X.400 to RFC 822, if the IPMS.IPMIdentifier.user- relative-identifier is "RFC-822" the id is RFC 987 generated. When mapping from RFC 822 to X.400, if the 822.domain is not "MHS", and the 822.local-part can be parsed as
RFCの987の発生しているencodingsは以下の通り認識されるかもしれません。 X.400からRFC822まで写像するとき、IPMS.IPMIdentifier.userの相対的な識別子が"RFC-822"であるなら、イドは発生するRFC987です。 RFC822からX.400までのマッピング、822.domainが「MHS」でないかどうか、および822.local-部分を分析できる時
[ printablestring ] "*" [ std-or-address ]
[printablestringします] 「*」[stdかアドレス]
then it is RFC 987 generated. In each of these cases, it is recommended to follow the RFC 987 rules.
そして、それは発生するRFC987です。 それぞれのこれらの場合では、RFC987規則に従うのはお勧めです。
Chapter 5 - Detailed Mappings
第5章--詳細なマッピング
This chapter specifies 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 from an RFC 822 message 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は822個のヘッダーが慣れているRFCがIPMS.Headingを発生させるというRFC822メッセージから発生します。 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 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にメッセージを提出します、そして、MTS.MessageSubmissionEnvelopeを指定することによって、必要であるサービスは定義できます。 また、いくつかの抽象的にMTAサービスのパラメタ(原則として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 RFC822FieldList
::= id-rfc-822-field-list
rfc822分野HEADING-EXTENSION VALUE RFC822FieldList:、:= イドrfc822分野リスト
Hardcastle-Kille [Page 59] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[59ページ]RFC1327マッピング
RFC822FieldList ::= SEQUENCE OF RFC822Field
RFC822FieldList:、:= RFC822Fieldの系列
RFC822Field ::= IA5String
RFC822Field:、:= IA5String
The Object Identifier id-rfc-822-field-list is defined in Appendix D.
Object Identifierイドrfc822分野リストはAppendix Dで定義されます。
To encode any RFC 822 Header using this extension, an RFC822Field element is built using the 822.field omitting the trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). Structured fields shall be unfolded. There shall be no space before the ":". The reverse mapping builds the RFC 822 field in a straightforward manner. This RFC822Field is appended to the RFC822FieldList, which is added to the IPM Heading as an extension field.
この拡張子を使用することでどんなRFC822Headerもコード化するために、引きずっているCRLFを省略する822.fieldを使用するのはRFC822Field要素に建てられます(例えば、「1日の果物: キウイ果物」)。 構造化された分野は繰り広げられるものとします。 「そこ、以前スペースでない、」、:、」 RFC822が正直な態度でさばく体格を写像する逆。 このRFC822FieldをRFC822FieldListに追加します。(RFC822FieldListは拡大分野としてIPM Headingに加えられます)。
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 is encoded as content type 2. Otherwise, it is 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 is likely break some recipient
UAs.
1. 上限を無視してください、そして、生まれながらの方法によるメッセージを発生させてください。 これは、何かトランケーションが完了していると、それが受取人UAで起こると仮定します。 これは、情報の転送を最大にしますが、おそらくいくつかの受取人UAsを壊すことです。
2. Reject any inbound message which would cause a message
violating constraints to be generated. This will be robust,
but may prevent useful communication.
2. 発生するという規制に違反するメッセージを引き起こすあらゆる本国行きのメッセージを拒絶してください。 これは、強健ですが、役に立つコミュニケーションを防ぐかもしれません。
3. Truncate fields to the upper bounds specified in X.400.
3. X.400で指定された上限に分野に先端を切らせてください。
This will prevent problems with UAs which enforce upper
bounds, but will sometimes discard useful information.
これは、上限を実施するUAsに関する問題を防ぎますが、時々役に立つ情報を捨てるでしょう。
Hardcastle-Kille [Page 60] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[60ページ]RFC1327マッピング
If the Free Form name is truncated, it may lead to breaking
RFC 822 comments, which will cause an awkward reverse
mapping.
Free Form名が端が欠けているなら、それは壊れているRFC822コメントに通じるかもしれません。(コメントは厄介な逆のマッピングを引き起こすでしょう)。
These options 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 is generated by the gateway. With the exception of "Received:", the values of multiple fields are merged (e.g., If there are two "To:" fields, then the mailboxes of both are merged to generate a single list which is used in the IPMS.Heading.primary-recipients. Information shall 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:」分野である、次に、両方のメールボックスがIPMS.Heading.primary-recipientsで使用されるただ一つのリストを発生させるように合併されている、情報は以下の標準の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 if there is at
least one BCC: recipient. If there are no recipients in
this field, it should be mapped to a zero length sequence.
Bcc: 少なくとも1つBCC:があれば、IPMS.Heading.blind-写し受信者に写像されます。 受取人。 受取人が全くこの分野になければ、それはゼロ・レングス系列に写像されるべきです。
Hardcastle-Kille [Page 61] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[61ページ]RFC1327マッピング
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 shall 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 is applied to RFC
822 fields where the content of the field does not conform
to RFC 822 (e.g., a Date: field with unparseable syntax).
特定の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を包括する。
Hardcastle-Kille [Page 62] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[62ページ]RFC1327マッピング
MTS.PerRecipientMessageSubmissionFields. The mandatory parameters are 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 are omitted, and default components defaulted. This means that disclosure of recipients is prohibited and conversion is allowed. There are two exceptions to the defaulting. For MTS.PerMessageSubmissionFields.per-message-indicators, the following settings are made:
任意のコンポーネントは省略されました、そして、デフォルトコンポーネントはデフォルトとしました。 これは、受取人の公開が禁止されていて、変換が許されていることを意味します。 デフォルトへの2つの例外があります。 MTS.PerMessageSubmissionFields.perメッセージインディケータにおいて、以下の設定は作られています:
- Alternate recipient is allowed, as it seems desirable to
maximise the opportunity for (reliable) delivery.
- (信頼できる)の配送の機会を最大にするのが望ましく思えるように交互の受取人は許容されています。
- Content return request is set according to the issues
discussed in Section 5.2.
- セクション5.2で議論した問題によると、満足している返送依頼は設定されます。
MTS.PerMessageSubmissionFields.original-encoded-information-types is a set of one element BuiltInEncodedInformationTypes.ia5-text.
コード化された情報がタイプするMTS.PerMessageSubmissionFields.originalは1セットの1つの要素のBuiltInEncodedInformationTypes.ia5-テキストです。
The MTS.PerMessageSubmissionFields.content-correlator is encoded as IA5String, and contains the Subject:, Message-ID:, Date:, and
MTS.PerMessageSubmissionFields.content-相関器は、IA5Stringとしてコード化されて、Subject:、Message-IDを含んでいます:、日付:
To: fields (if present). This includes the strings "Subject:", "Date:", "To:", "Message-ID:", and appropriate folding. This shall be truncated to MTS.ub-content-correlator-length (512) characters. In addition, if there is a "Subject:" field, the MTS.PerMessageSubmissionFields.content-identifier, is set to a printable string representation of the contents of it. If the length of this string is greater than MTS.ub-content-id-length (16), it should be truncated to 13 characters and the string "..." appended. 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).
To: 分野(存在しているなら)。 これがストリング「Subject:」、「日付:」、「To:」を含んでいる、「Message ID: 」 折り重なりを当ててください。 これはMTS.ubの満足している相関器の長さの(512)キャラクタに先端を切られるものとします。 添加、a「Subject:」があります。 分野(MTS.PerMessageSubmissionFields.content-識別子)はそれのコンテンツの印刷可能なストリング表現に設定されます。 「このストリングの長さはMTS.ubの満足しているイドの長さの(16)よりすばらしいです、それが13のキャラクタに先端を切られるべきであるということであるかどうか、そして、ストリング」… 」 追加しています。 両方が満足している相関器のはるかに大きい上限のため使用されます、そして、満足しているイドは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
直接MTA要約のいくつかの局面に写像する必要があります。
Hardcastle-Kille [Page 63] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[63ページ]RFC1327マッピング
service, for the following reasons:
以下の理由のためのサービス:
- So the the MTS Message Identifier can be generated from the
RFC 822 Message-ID:.
- それで、MTS Message Identifierは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 is 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 is
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 is
generated in an analogous manner, although this can be
dropped later in certain circumstances (see the procedures
for "Received:"). The
MTA.InternalTraceInformationElement.mta-name is derived from
the 822.domain in the 822 MTS Originator address.
MTA.PerMessageTransferFields.internal-トレース情報の最初の要素は類似の方法で発生します、後である特定の状況ではこれを落とすことができますが(「受け取った」ために手順を見てください)。 822MTS Originatorアドレスで822.domainからMTA.InternalTraceInformationElement.mta-名前を得ます。
Received:
All RFC 822 trace is used to derive
MTA.PerMessageTransferFields.trace-information and
MTA.PerMessageTransferFields.internal-trace-information.
受け取られている: すべてのRFC822跡が、MTA.PerMessageTransferFields.trace-informationとMTA.PerMessageTransferFields.internal-トレース情報を引き出すのに使用されます。
Hardcastle-Kille [Page 64] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[64ページ]RFC1327マッピング
Processing of Received: lines follows processing of Date:,
and is be done from the the bottom to the top of the RFC 822
header (i.e., in chronological order). When other trace
elements are processed (X400-Received: in all cases and Via:
if Appendix B is supported), the relative ordering shall be
retained correctly. The initial element of
MTA.PerMessageTransferFields.trace-information will be
generated already (from Date:), unless the message has
previously been in X.400, when it will be derived from the
X.400 trace information.
受け取って、処理する、: 線は、日付:の処理に続いて、あります。下部からRFC822ヘッダー(すなわち、年代順に)の先端までしてください。 他の微量元素が処理される、(X400が受け取られている:、すべてのケースとViaで: BがAppendixであるなら支持される、)、相対的な注文は正しく保有されるものとします。 MTA.PerMessageTransferFields.trace-informationの初期の要素は既に(日付:から)発生するでしょう、以前に、メッセージがX.400になかった場合、X.400トレース情報からそれを得るとき。
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 shall 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
is set to the value derived. The
MTA.InternalTraceInformationElement.mta-supplied-information
(MTA.MTASuppliedInformation) is 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 is 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分
Hardcastle-Kille [Page 65] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[65ページ]RFC1327マッピング
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 MDs would violate ADMD policy. This will depend on bilateral agreement with the ADMD.
いくつかのADMDsにメッセージを移す前に追加跡のストリップが必要であるかもしれないことに注意してください、複数のMDsを通した暗示している経路がADMD方針に違反するだろうというとき。 これはADMDと共に二国間条約によるでしょう。
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 all of these fields to X.400.
この仕様はReports、Notifications、およびIP Messagesのためにセクション5.3で多くの新しい分野を定義します。 この仕様が、既存のサービスを保持することを目指すだけであるとき、この仕様に一致しているゲートウェイはこれらの分野のすべてをX.400に写像する必要はありません。
Two extended fields must be mapped, in order to prevent looping. "DL-Expansion-History:" is mapped to
輪にするのを防ぐために2つの拡張分野を写像しなければなりません。 「dl拡大歴史:」 写像されます。
MTA.PerMessageTransferFields.extensions.dl-expansion-history X400- Received: must be mapped to MTA.PerMessageTransferFields.trace- information and MTA.PerMessageTransferFields.internal-trace- information. In cases where X400-Received: is present, the usual mapping of Date: to generate the first element of trace should not be done. This is because the message has come from X.400, and so the first element of trace can be taken from the first X400-Received:.
MTA.PerMessageTransferFields.extensions.dl拡大歴史X400は受信しました: MTA.PerMessageTransferFields.trace情報とMTA.PerMessageTransferFields.internal-跡情報に写像しなければなりません。 場合では、どこがX400受信されたか: 日付:がプレゼント、普通のマッピングがありますか? 跡の最初の要素を発生させるのは完了しているべきではありません。 これがメッセージがX.400から来たからであるX400を受け取られていさせた状態で、1日から跡の最初の要素を取ることができます:
Some field that shall not be mapped, and should be discarded. The following cannot be mapped back:
写像しないで、捨てられるべきである何らかの分野。 以下を写像し返すことができません:
- Discarded-X400-MTS-Extensions:
- 捨てられたX400-MTS拡張子:
- Message-Type:
- メッセージタイプ:
- Discarded-X400-IPMS-Extensions:
- 捨てられたX400-IPMS拡張子:
If Message-Type: is set to "Multiple Part", then the messge is encoded according to RFC 934, and this may be mapped on to the corresponding X.400 structures.
メッセージタイプであるなら: 「複数の部分」にはセットがあります、そして、次に、RFC934によると、messgeはコード化されます、そして、これは対応するX.400構造に写像されるかもしれません。
The following may cause problems, due to other information not being mapped back (e.g., extension numbers), or due to changes made on the RFC 822 side due to list expansion:
以下は写像し返されない他の情報(例えば、内線電話番号)のため、またはリスト拡大のためRFC822側で行われた変更のため問題を起こすかもしれません:
- X400-Content-Type:
- X400-コンテントタイプ:
- X400-Originator:
- X400-創始者:
Hardcastle-Kille [Page 66] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[66ページ]RFC1327マッピング
- X400-Recipients:
- X400-受取人:
- X400-MTS-Identifier:
- X400-MTS-識別子:
Other fields may be either discarded or mapped to X.400. It is usually desirable and beneficial to do map, particularly to facilitate support of a message traversing multiple gateways. These mappings may be onto MTA, MTS, or IPMS services. The level of support for this reverse mapping should be indicated in the gateway conformace statement.
他の分野は、X.400に捨てられるか、または写像されるかもしれません。 それは、複数のゲートウェイを横断するメッセージのサポートを容易にするために特に写像するのに通常、望ましくて、有益です。 MTA、MTS、またはIPMSサービスにはこれらのマッピングがあるかもしれません。 この逆のマッピングのためのサポート水準はゲートウェイconformace声明で示されるべきです。
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 shall 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を通してエラー・レポートを返すようにルーティングをセットアップしなければなりません。 このアプローチはいくつかのルーティング戦略に関連して使用するのが難しいかもしれません。
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
独身のRFC822メッセージは入って来るIPのMessage、Report、またはIP Notificationから発生します。 すべてのIPMS.BodyPartsが独身のRFC822ボディーに写像されます。 他のサービスはRFC822ヘッダーフィールドに写像されます。 どんな適切な既存の分野もないところに、新しい分野はあります。
Hardcastle-Kille [Page 67] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[67ページ]RFC1327マッピング
defined for IPMS, MTS and MTA services.
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 shall 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 shall 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 is assigned
equal to the 822-MTS Originator. If this is gateway
generated, an appropriate 822.phrase shall be added.
From: これはマッピングによって発生させられないなら、それが822-MTS Originatorの同輩に割り当てられます。 これが発生するゲートウェイであるなら、適切な822.phraseは加えられるものとします。
At least one recipient field
If no recipient fields are generated, a field "To: list:;",
shall be added.
受取人がさばく少なくとも1受取人分野Ifノー、が発生して、分野は「To:」です。 「記載してください」;、加えられるでしょう。
This will ensure minimal RFC 822 compliance. When generating RFC 822 headers, folding may be used. It is recommended to do this, following the guidelines of RFC 822.
これは最小量のRFC822コンプライアンスを確実にするでしょう。 RFC822ヘッダーを発生させるとき、折り重なりは使用されるかもしれません。 RFC822のガイドラインに従って、これをするのはお勧めです。
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)
内蔵のeit=「未定義」。 未定義(0)
Hardcastle-Kille [Page 68] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[68ページ]RFC1327マッピング
/ "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)
/「テレックス」。 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
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Language" ":" language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#oid
「=が「時代遅れにする」ipms-分野」:、」 「1#msg-イド/「有効期限日」」:、」 「日付-時間/「近く、返答」」:、」 「日付-時間/「重要性」」:、」 「重要性/「感度」」:、」 「感度/"Autoforwarded"」:、」 「論理演算子/「不完全なコピー」」:、」 「/「言語」」:、」 「言語/「メッセージタイプ」」:、」 「メッセージタイプ/「捨てられたX400-IPMS拡張子」」:、」 1#oid
importance = "low" / "normal" / "high"
重要性=「安値」/「標準」/「高値」
sensitivity = "Personal" / "Private" /
感度は「個人的である」か「個人的な」/と等しいです。
Hardcastle-Kille [Page 69] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[69ページ]RFC1327マッピング
"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). If a field with addresses contains zero elements, it should be discarded, execpt for IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC: (the only RFC 822 field which allows zero recipients).
IPMS.Headingのためのマッピングと動作は現在、各要素に指定されます。 アドレス、およびMessage Identifiersはそうです。第4章に従って、写像されます。 他のマッピングは、説明されるか、または簡単です(アルゴリズムの)。 アドレスがある分野が零元を含んでいるなら、それは捨てられるべきです、IPMS.Heading.blind-写し受信者のためのexecpt、BCC:に写像できるどれ (受取人を全く許容しない唯一のRFC822分野。)
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。
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、写像される、「以下に参照をつけます」。
Hardcastle-Kille [Page 70] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[70ページ]RFC1327マッピング
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. The language-description may filled in
with a human readable description of the language, and it is
recommended to do this.
拡張RFC822分野への言語Mapped、「言語:」 2レター・コードでは、腹を満たします。 言語の人間の読み込み可能な記述で記入されて、言語記述はお勧めであるかもしれません、そして、これをするのはお勧めです。
If the RFC 822 extended header is found, this shall 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 shall be discarded, unless the gateway understands the extension and can perform an appropriate mapping onto an RFC 822 header field. If extensions are discarded, the list is indicated in the extended RFC 822 field "Discarded-X400- IPMS-Extensions:".
標準的でない拡大が見つけられるなら、それは捨てられるものとします、ゲートウェイが拡大を理解して、RFC822ヘッダーフィールドに適切なマッピングを実行できないなら。 拡大が捨てられるなら、リストが拡張RFC822分野で示される、「捨てられたX400IPMS-拡張子:」
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に変換されます:
Hardcastle-Kille [Page 71] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[71ページ]RFC1327マッピング
IPMS.IA5Text
The mapping is straightforward (see Chapter 3).
IPMS.IA5Text、マッピングは簡単です(第3章を参照してください)。
IPMS.MessageBodyPart
The X.400 -> RFC 822 mapping is recursively applied, to
generate an RFC 822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope is used
for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time is mapped to
the extended RFC 822 field "Delivery-Date:".
IPMS.MessageBodyPart、X.400->RFC822マッピングは、RFC822Messageを発生させるように再帰的に適用されます。 存在しているなら、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 shall 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 foobarhere
foobarhereがありました。
The widget gateway ate it
ウィジェットゲートウェイはそれを食べました。
*********************************
*********************************
This will allow some useful information to be transferred.
As the recipient is likely to be a human (IPMS), then
suitable action will usually be possible.
これは、何らかの役に立つ情報が移されるのを許容するでしょう。 受取人が人間(IPMS)である傾向があるときに、その時、通常、適当な動作は可能になるでしょう。
3. Finally both may be done. In this case, the supplementary
information in the (positive) Delivery Report shall make
clear that something was sent on to the recipient with
substantial loss of information.
3. 最終的に両方が完了しているかもしれません。 この場合、(積極的)の配送Reportの補助情報は、何かが情報のかなりの損失によって受取人に送られたことを明らかにするものとします。
Where there is more than one IPMS.BodyPart, the mapping defined by Rose and Stefferud in [Rose85a], is used to map the separate IPMS.BodyParts in the single RFC 822 message body. If this is done,
[Rose85a]の1IPMS.BodyPartがどこにあるか、そして、ローズによって定義されたマッピングとStefferudは、単一のRFC822メッセージボディーで別々のIPMS.BodyPartsを写像するのに使用されます。 これが完了しているなら
Hardcastle-Kille [Page 72] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[72ページ]RFC1327マッピング
a "Message-Type:" field with value "Multiple part" shall be added, which will indicate to a receiving gateway that the message may be unfolded according to RFC 934.
aは「以下をメッセージでタイプします」。 値の「倍数部分」がある分野(RFC934によると、メッセージが繰り広げられるかもしれないのを受信ゲートウェイに示す)は加えられるものとします。
Note:There is currently work ongoing to produce an upgrade to RFC
934, which also allows for support of body parts with non-
ASCII content (MIME). When this work is released as an RFC,
this specification will be updated to refer to it instead
for RFC 934.
注意: 現在、また、非ASCIIの内容(MIME)がある身体の部分のサポートを考慮するRFC934にアップグレードを起こすことにおける進行中の仕事があります。 RFCとしてこの仕事をリリースするとき、代わりにRFC934についてそれについて言及するためにこの仕様をアップデートするでしょう。
For backwards compatibility with RFC 987, the following procedures shall 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 shall be appended to the RFC 822 header.
また、RFC987との遅れている互換性において、以下の手順は従われるものとします。 2つのIA5身体の部分、およびひもによる最初の始めがある、「RFC822ヘッダー:」 そして、最初の線として、この身体の部分の残りをRFC822ヘッダーに追加するものとします。
An example message, illustrating a number of aspects is given below.
例のメッセージであり、多くの局面を例証するのを以下に与えます。
Return-Path:<@mhs-relay.ac.uk:stephen.harrison@gosip-uk.hmg.gold-400.gb>
Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET
with NIFTP id <7906-0@bells.cs.ucl.ac.uk>;
Thu, 30 May 1991 18:24:55 +0100
X400-Received: by mta "mhs-relay.ac.uk" in
/PRMD=uk.ac/ADMD= /C=gb/; Relayed;
Thu, 30 May 1991 18:23:26 +0100
X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed;
Thu, 30 May 1991 18:20:27 +0100
Message-Type: Multiple Part
Date: Thu, 30 May 1991 18:20:27 +0100
X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
X400-MTS-Identifier:
[/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8]
Original-Encoded-Information-Types: ia5, undefined
X400-Content-Type: P2-1984 (2)
Content-Identifier: Email Problems
From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487)
Message-ID: <PC1000-910530172027-57D8*@MHS>
To: Jim Craigie <NTIN36@gec-b.rutherford.ac.uk>
(Receipt Notification Requested) (Non Receipt Notification Requested),
Tony Bates <tony@ean-relay.ac.uk> (Receipt Notification Requested),
Steve Kille <S.Kille@cs.ucl.ac.uk> (Receipt Notification Requested)
Subject: Email Problems
Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
Return-Path:<@mhs-relay.ac.uk : >が受けたstephen.harrison@gosip-uk.hmg.gold-400.gb: NIFTP id <7906-0@bells.cs.ucl.ac.uk をもっているジャネットを通したbells.cs.ucl.ac.ukによるmhs-relay.ac.uk、gt;、。 木曜日に、1991年5月30日の18:24:55+0100はX400受信されました: mtaで、/PRMD=uk.ac/ADMD=/Cの"mhs-relay.ac.uk"はgb/と等しいです。 リレーされます。 木曜日に、1991年5月30日の18:23:26+0100はX400受信されました: /PRMD=HMG/ADMD=で、金400/CはGB/と等しいです。 リレーされます。 木曜日に、1991年5月30日の18:20:27+0100はメッセージでタイプされます: 複数の部分日付: 木曜日、1991年5月30日の18:20: 27 +0100 X400-創始者: Stephen.Harrison@gosip-uk.hmg.gold-400.gb X400-MTS-識別子: [/PRMD=HMG/ADMD=金400/C=GB/; PC1000-910530172027-57D8] オリジナルは情報タイプをコード化しました: ia5、未定義のX400-コンテントタイプ: P2-1984の(2)の満足している識別子: メール問題From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 、(3487年の)Tel+44 71 217Message ID: <PC1000-910530172027-57D8*@MHS> To: ジム Craigie <NTIN36@gec-b.rutherford.ac.uk 、gt;、(通知が要求した非領収書)、(通知が要求した領収書)トニー Bates <tony@ean-relay.ac.uk 、gt;、(通知が要求した領収書)、スティーブ Kille <S.Kille@cs.ucl.ac.uk 、gt;、(通知が要求した領収書)Subject: 問題送付者にメールしてください: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
------------------------------ Start of body part 1
------------------------------ ボディー第1部の始まり
Hope you gentlemen.......
あなた方紳士は望んでいます…
Hardcastle-Kille [Page 73] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[73ページ]RFC1327マッピング
Regards,
敬具
Stephen Harrison UK GOSIP Project
スティーブンハリソンイギリスのGOSIPプロジェクト
------------------------------ Start of forwarded message 1
------------------------------ 転送されたメッセージ1の始まり
From: Urs Eppenberger <Eppenberger@verw.switch.ch> Message-ID: <562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: "Stephen.Harrison" <Stephen.Harrison@gosip-uk.hmg.gold-400.gb> Cc: kimura@bsdarc.bsd.fc.nec.co.jp Subject: Response to Email link
From: ウルス Eppenberger <Eppenberger@verw.switch.ch 、gt;、Message ID: スイッチ/PRMD<562*/S=Eppenberger/OU=verw/O==スイッチ/ADMD=ARCOM/Cが CH/@MHS と等しい、gt;、To: 「Stephen.Harrison、「 <Stephen.Harrison@gosip-uk.hmg.gold-400.gb 、gt;、Cc:、」 kimura@bsdarc.bsd.fc.nec.co.jp Subject: リンクをメールする応答
- ------------------------------ Start of body part 1
- ------------------------------ ボディー第1部の始まり
Dear Mr Harrison......
親愛なるハリソンさん…
- ------------------------------ End of body part 1
- ------------------------------ ボディー第1部の終わり
------------------------------ End of forwarded message 1
------------------------------ 転送されたメッセージ1の終わり
5.3.5. Mappings from an IP Notification
5.3.5. IP通知からのマッピング
A message is generated, with the following fields:
メッセージは以下の分野で発生します:
From:
Set to the IPMS.IPN.ipn-originator.
From: IPMS.IPN.ipn-創始者にセットしてください。
To: Set to the recipient from MTS.MessageSubmissionEnvelope.
If there have been redirects, the original address should be
used.
To: MTS.MessageSubmissionEnvelopeから受取人にセットしてください。 あった、向け直す、オリジナルのアドレスは使用されるべきです。
Subject:
Set to the string "X.400 Inter-Personal Notification" for a
receipt notification and to "X.400 Inter-Personal
Notification (failure)" for a non-receipt notification.
Subject: 領収書通知と非領収書通知のための「X.400の相互個人的な通知(失敗)」への「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
以下のEBNFはMessageのボディーのために定義されます。 この書式がそれを確実にするために定義される、すべての情報
Hardcastle-Kille [Page 74] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[74ページ]RFC1327マッピング
interpersonal notification is available to the end user in a uniform manner.
エンドユーザには、個人間の通知は一定の方法で利用可能です。
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
[ ipn-content-return ]
ipnボディー形式はipn-記述<CRLF>[ipn-その他の情報<CRLF>]と等しいです。[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:"
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と等しいです。
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated"
破棄して推論している=は、「ユーザ購読は終えた」/を「吐き出す」か、または「時代遅れにしました」。
Hardcastle-Kille [Page 75] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[75ページ]RFC1327マッピング
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をかける、「参照:」
ipn-originator
Mapped to "From:".
「From:」へのipn-創始者Mapped。
ipn-preferred-recipient
Mapped to EBNF.preferred-recipient
EBNF.preferred-受取人へのipnの都合のよい受取人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
This applies only to non-receipt notifications.
EBNF.ipn-content-return should always be omitted for receipt
notifications, and always be present in non-receipt
notifications. If present, the second option of
EBNF.ipn-content-return is chosen, and an RFC 822 mapping of
the message included. Otherwise the first option is chosen.
返されたipm Thisは非領収書通知だけに適用します。 EBNF.ipnの満足しているリターンは、領収書通知のためにいつも省略されて、非領収書通知にいつも存在しているべきです。 プレゼント、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
Hardcastle-Kille [Page 76] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[76ページ]RFC1327マッピング
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: X.400 Inter-personal 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: X.400の相互個人的な通知メッセージタイプ: 個人間の通知参照: <1229.614418325@UK.AC.NOTT.CS>日付: 水曜日、1989年6月21日の08:45:25+0100
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
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 ";"
/ "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-イド=、「[「グローバルなイド」;、」 *テキスト、」、]、」
Hardcastle-Kille [Page 77] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[77ページ]RFC1327マッピング
mts-content-type = "P2" / labelled-integer
/ object-identifer
mtsの満足しているタイプは「物ラベルされたP2"/整数/identifer」と等しいです。
priority = "normal" / "non-urgent" / "urgent"
優先権は「正常である」か「不急」の/と「緊急」の状態で等しいです。
The mappings for each element of MTS.MessageDeliveryEnvelope can now be considered.
現在、MTS.MessageDeliveryEnvelopeの各要素のためのマッピングを考えることができます。
MTS.MessageDeliveryEnvelope.message-delivery-identifier
Mapped to the extended RFC 822 field "X400-MTS-Identifier:".
拡張RFC822分野へのMTS.MessageDeliveryEnvelope.message配送識別子Mapped、「X400-MTS-識別子:」
MTS.MessageDeliveryEnvelope.message-delivery-time
Discarded, as this time will be represented in an
appropriate trace element.
MTS.MessageDeliveryEnvelope.message-納期Discarded、今回が表すように、適切な微量元素の中に表されてください。
The mappings for elements of MTS.MessageDeliveryEnvelope.other-fields (MTS.OtherMessageDeliveryFields) are:
MTS.MessageDeliveryEnvelope.other-分野(MTS.OtherMessageDeliveryFields)の要素のためのマッピングは以下の通りです。
content-type
Mapped to the extended RFC 822 field "X400-Content-Type:".
The string "P2" is retained for backwards compatibility with
RFC 987. This shall not be generated, and either the
EBNF.labelled-integer or EBNF.object-identifier encoding
used.
拡張RFC822分野への満足しているタイプMapped、「X400-コンテントタイプ:」 ストリング、「P2"はRFC987との遅れている互換性のために保有されます」。 これは発生しないで、EBNF.labelled-整数かEBNF.object-識別子コード化のどちらかが使用されています。
originator-name
Mapped to the 822-MTS originator, and to the extended RFC
822 field "X400-Originator:". This is described in
Section 4.6.2.
822-MTS創始者と、そして、拡張RFC822分野への創始者名のMapped、「X400-創始者:」 これはセクション4.6.2で説明されます。
original-encoded-information-types
Mapped to the extended RFC 822 field
"Original-Encoded-Information-Types:".
拡張RFC822分野「オリジナルは情報タイプをコード化したこと」への元のコード化された情報タイプMapped。
priority
Mapped to the extended RFC 822 field "Priority:".
拡張RFC822分野への優先権Mapped、「優先権:」
delivery-flags
If the conversion-prohibited bit is set, add an extended RFC
822 field "Conversion:".
変換によって禁止にされるのが噛み付いた配送旗のIfが設定していて、拡張RFC822分野を加えてください、「変換:」
this-recipient-name and other-recipient-names
この受取人名と他の受取人名
originally-intended-recipient-name
The handling of these elements is described in
Section 4.6.2.
これらの要素の取り扱いが説明される元々意図した受取人名のセクション4.6.2。
Hardcastle-Kille [Page 78] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[78ページ]RFC1327マッピング
converted-encoded-information-types
Discarded, as it will always be IA5 only.
変換されたコード化された情報タイプDiscarded、いつもそうするようにIA5専用になってください。
message-submission-time
Mapped to Date:.
日付:へのメッセージ服従時間Mapped。
content-identifier
Mapped to the extended RFC 822 field "Content-Identifier:".
拡張RFC822分野への満足している識別子Mapped、「満足している識別子:」
If any extensions (MTS.MessageDeliveryEnvelope.other- fields.extensions) are present, and they are marked as critical for transfer or delivery, then the message shall be rejected. The extensions (MTS.MessageDeliveryEnvelope.other-fields.extensions) are mapped as follows.
どんな拡大(MTS.MessageDeliveryEnvelope.other fields.extensions)も存在していて、それらが転送か配送に重要であるとしてマークされるなら、メッセージは拒絶されるものとします。 拡大(MTS.MessageDeliveryEnvelope.other-fields.extensions)は以下の通り写像されます。
conversion-with-loss-prohibited
If set to
MTS.ConversionWithLossProhibited.conversion-with-loss-prohibited,
then add the extended RFC 822 field "Conversion-With-Loss:".
損失が禁止されている変換Ifが損失が禁止されているMTS.ConversionWithLossProhibited.conversionにセットして、次に、拡張RFC822分野を加える、「損失との変換:」
requested-delivery-method
Mapped to the extended RFC 822 field
"Requested-Delivery-Method:".
拡張RFC822分野への要求された発送方法Mapped、「要求された発送方法:」
originator-return-address
Mapped to the extended RFC 822 field
"Originator-Return-Address:".
拡張RFC822分野への創始者返送先Mapped、「創始者返送先:」
physical-forwarding-address-request physical-delivery-modes registered-mail-type recipient-number-for-advice physical-rendition-attributes physical-delivery-report-request physical-forwarding-prohibited
禁止された物理的な推進アドレス要求の登録されたメールタイプのアドバイスの受取人番号の物理的な表現属性の物理的な配送レポート要求の物理的な物理的な配送モード推進
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
配送要求の創始者証明書メッセージ象徴満足している秘密性アルゴリズム識別子満足している保全チェックメッセージ起源認証チェックメッセージ機密保護ラベル証拠
Hardcastle-Kille [Page 79] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[79ページ]RFC1327マッピング
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 shall be
rejected. Otherwise they are discarded.
これらの要素はRFC822環境で利用可能でないセキュリティー・サービスの使用を含意します。 それらが転送か配送に重要であるとしてマークされるなら、メッセージは拒絶されるものとします。 さもなければ、それらは捨てられます。
redirection-history
This is described in Section 4.6.2.
リダイレクション歴史Thisはセクション4.6.2で説明されます。
dl-expansion-history
Each element is mapped to the extended RFC 822 field
"DL-Expansion-History:". They shall 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 shall be rejected. If they are not so marked, they can safely be discarded. The list of discarded fields shall 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からこれらを得ることができます。 このレベルにおけるマッピングの理由、およびレイヤリングの違反は以下の通りです。
- 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 are 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, due to differing service requests for each recipient. As discussed in 4.6.2..2, this specification allows either for multiple messages to be generated, or for the per- recipient information to be discarded.
822-MTS受取人はX.400受取人の完全リストから計算されます。 ゲートウェイ(責任ビットは設定される)を通り抜けながら、これはMTA.MessageTransferEnvelope.per受取人分野のメンバーのすべてです。 いくつかの場合、異なったRFC822メッセージは各受取人のために計算されるでしょう、各受取人への異なったサービスのリクエストのため。 4.6で.2について議論するので。または、2 この仕様が複数の発生するべきメッセージを考慮する、-、捨てられるべき受取人情報。
The following EBNF is defined for extended RFC 822 headers:
以下のEBNFは拡張RFC822ヘッダーのために定義されます:
mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
「mta-分野=は「X400受信」だった」:、」 「x400-跡/「延期した納入」」:、」 日付-時間
Hardcastle-Kille [Page 80] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[80ページ]RFC1327マッピング
/ "Latest-Delivery-Time" ":" date-time
「/「最新の納期」」:、」 日付-時間
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-or-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=単語到着時間=日付-時間
md-or-mta = "MD" global-id
/ "MTA" mta
「MD」グローバルなイド/"MTA"Mdかmta=mta
Action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
「向け直される」か、「広げられる」、「リレーされる」、または「別ルートで送られた」動作リスト=1#動作動作=
Note the EBNF.mta is encoded as 822.word. If the character set does no allow encoding as 822.atom, the 822.quoted-string encoding is used.
EBNF.mtaが822.wordとしてコード化されることに注意してください。 文字の組がいいえをするなら、822.atomとしてコード化するのを許容してください、そして、822.quoted-stringコード化は使用されています。
If MTA.PerMessageTransferFields.deferred-delivery-time is present, it is used to generate a Deferred-Delivery: field. For some reason, X.400 does not make this information available at the MTS level on 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 may hold the message until the time specified in the protocol element. Thus, the value of this element will usually be in the past. For this reason, the extended RFC 822 field is primarily for information.
MTA.PerMessageTransferFields.deferred-納期が存在しているなら、それはDeferred-配送を発生させるのに使用されます: さばきます。 ある理由で、X.400は配送のときにこの情報をMTSレベルで利用可能にしません。 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. Where an element of internal trace and external trace are identical, except for the MTA in the internal trace, only the internal trace element shall be presented. 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跡が剥取られていないなら、これは複雑なインターリービングを必要とするかもしれません。 内部の跡のMTAを除いて、跡と外部の跡が内部の要素に同じであるところでは、内部の微量元素だけが提示されるものとします。 系列を発生させるのにこれを使用する、「X400が受け取られている:、」 分野。 外部の跡と内部の跡の唯一の違いが内部の微量元素の中に余分なMTA情報になるでしょう。
Hardcastle-Kille [Page 81] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[81ページ]RFC1327マッピング
When generating an RFC 822 message all trace fields (X400-Received and Received) shall be at the beginning of the header, before any other fields. Trace shall be in chronological order, with the most recent element at the front of the message. This ordering is determined from the order of the fields, not from timestamps in the trace, as there is no guarantee of clock synchronisation. 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 is generated with the following fields:
メッセージは以下の分野で発生します:
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:
The EBNF for the subject line is:
Subject: 件名のためのEBNFは以下の通りです。
Hardcastle-Kille [Page 82] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[82ページ]RFC1327マッピング
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
「(「状態」)」という受けることがある線=「配送レポート」[“for"の目的地]
status = "success" / "failure" / "success and failures"
状態=「成功」/「失敗」/「成功と失敗」
destination = mailbox / "MTA" word
目的地=メールボックス/"MTA"単語
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. The format is structured as if it was a message coming from X.400, with the description in one body part, and a forwarded message (return of content) in the second. This structure is useful to the RFC 822 recipient, as it enables the original message to be extracted. The first body part is structured as follows:
メッセージ欄の書式は、すべての情報が一貫した方法でRFC822ユーザに伝えられるのを保証するために定義されます。 形式はまるでそれがX.400から来るメッセージであるかのように構造化されます、記述が1つの身体の部分にあって、転送されたメッセージ(内容の復帰)が2番目にある状態で。 抽出されるべきオリジナルのメッセージを可能にするとき、この構造はRFC822受取人の役に立ちます。 最初の身体の部分は以下の通り構造化されます:
1. A few lines giving keywords to indicate the original
message.
1. オリジナルのメッセージを示すためにキーワードを与えるいくつかの線。
2. A human summary of the status of each recipient being
reported on.
2. オンであると報告されるそれぞれの受取人の状態の人間の概要。
3. A clearly marked section which contains detailed information
extracted from the report. This is marked clearly, as it
will not be comprehensible to the average user. It is
retained, as it may be critical to diagnosing an obscure
problem.
3. レポートから抜粋された詳細な情報を含む明確にマークされたセクション。 これは、一般ユーザーにとって分かりやすくならないので、明確にマークされます。 不鮮明な問題を診断するのに重要であるときに、それは保有されます。
This section may be omitted in positive DRs, and it is
recommended that this is appropriate for most gateways.
このセクションは積極的なDRsで省略されるかもしれません、そして、ほとんどのゲートウェイに、これが適切であることは、お勧めです。
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-administrator-info-envelope <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:"
dr満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
dr-概要=「このレポートはあなたのメッセージに関連します」。 <CRLF>満足している相関器<CRLF><CRLF>“of"日付-時間<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-成功/故障
Hardcastle-Kille [Page 83] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[83ページ]RFC1327マッピング
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-administrator-info-envelope = 3*( "*" text <CRLF> )
dr管理者インフォメーション封筒=3*(「*」テキスト<CRLF>)
dr-administrator-info =
"**** The following information is directed towards"
"the local administrator" <CRLF>
"**** and is not intended for the end user" <CRLF> <CRLF>
"DR generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"Converted to RFC 822 at" mta <CRLF>
"at" date-time <CRLF> <CRLF>
"Delivery Report Contents:" <CRLF> <CRLF>
drc-field-list <CRLF>
"***** End of administration information"
「dr管理者インフォメーションは等しい」、****以下の情報が、」 「」 地元の管理者<CRLF>」****に向けられて、」 「DRを以下は発生させた」エンドユーザ<CRLF><CRLF>のために意図しません。 レポートポイント<CRLF>“at"日付-時間<CRLF><CRLF>では、「配送はコンテンツを報告する」mta<CRLF>“at"日付-時間<CRLF><CRLF>が「RFC822に変換されました」。 「」 *****が終わらせる管理情報の<CRLF><CRLF>drc分野リスト<CRLF>」
drc-field-list = *(drc-field <CRLF>)
drc分野リスト=*(drc-分野<CRLF>)
drc-field = "Subject-Submision-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-分野は「対象のSubmision識別子」と等しい」:、」 「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 ";" ]
または、「受取人インフォメーションはメールボックスと等しい」、」、std、-、」、;、」 または、「レポートタイプ、[「変換されたeits」コード化されたインフォメーション、」、;、」、]、[「元々意図した受取人」メールボックス、」、」、std、-、」、;、」、][「「最後に」[コード化されたインフォメーション]の日付-時間をたどってください」;、」、]
Hardcastle-Kille [Page 84] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[84ページ]RFC1327マッピング
[ "supplementary info" <"> printablestring <"> ";" ]
[ "redirection history" 1#redirection ";"
[ "physical forwarding address"
printablestring ";" ]
「[「補っているインフォメーション」<「>の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"]。(「(「日付-時間」)」というメールボックス)
The format is defined as a fixed definition of an the outer level (EBNF.dr-body-format). The element EBNF.dr-administrator-info- envelope, provides a means of encapsulating a section of the header in a manner which is clear to the end user. Each line of this section begins with "*". Each element of EBNF.text within %EBNF.dr- administrator-info-envelope must not contain <CRLF>. This is used to wrap up EBNF.dr-administrator-info, which will generate a sequenece of lines not starting with "*". EBNF.drc-fields may be folded using the RFC 822 folding rules.
書式が固定定義と定義される、外側のレベル(EBNF.drボディー形式)。 要素EBNF.dr-管理者インフォメーション封筒、エンドユーザにとって、明確な方法でヘッダーのセクションを要約する手段を提供します。 このセクションの各線は「*」で始まります。 %EBNF.drの中のEBNF.textの各要素、-管理者インフォメーション封筒は<CRLF>を含んではいけません。 これは、EBNF.dr管理者インフォメーションを包むのに使用されます。(「*」から始めないで、インフォメーションは線のsequeneceを発生させるでしょう)。 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). This should
also be used in EBNF.dr-summary if there is no Content
Correlator present.
EBNF.drc-分野(満足している識別子の)への満足している識別子Mapped。 また、どんな存在しているContent Correlatorもなければ、これはEBNF.dr-概要で使用されるべきです。
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(コード化されたインフォメーション)
Hardcastle-Kille [Page 85] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[85ページ]RFC1327マッピング
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 will 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 will not be present unless there
is an error in a remote MTA. If they are present, they
shall be discarded in preference to discarding the whole
report.
誤りがリモートMTAにないと、これらのセキュリティパラメタは存在しないでしょう。 存在しているなら、全体のレポートを捨てることに優先してそれらは捨てられるものとします。
For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields, a value of EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info) is 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
is 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」)
Hardcastle-Kille [Page 86] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[86ページ]RFC1327マッピング
originally-intended-recipient
Set the second ("originally intended recipient") mailbox and
std-or in EBNF.drc-field.
または、そして、元々意図した受取人Set、2(「元々意図した受取人」)番目のメールボックス、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 shall be discarded, irrespective of criticality.
どんな未知の拡大も臨界の如何にかかわらず捨てられるものとします。
The original message, or an extract from it, shall be included in the delivery port if it is available. The original message will usually be available at the gateway, as discussed in Section 5.2. If the original message is available, but of erroneous format, a dump of the ASN.1 may be included. This is recommended, but not required.
それが利用可能であるなら、オリジナルのメッセージ、またはそれからの抽出が配送ポートに含まれているものとします。 通常、オリジナルのメッセージはセクション5.2で議論するようにゲートウェイで利用可能になるでしょう。 オリジナルのメッセージが利用可能ですが、誤った形式では、ASN.1のダンプが含まれるかもしれないなら。 これは、推薦されますが、必要ではありません。
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 are made:
以下の追加マッピングは作られています:
MTA.ReportTransferEnvelope.report-destination-name
This is 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。
Hardcastle-Kille [Page 87] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[87ページ]RFC1327マッピング
MTA.ReportTransferEnvelope.internal-trace-information
Mapped onto the extended RFC 822 field "X400-Received:", as
described in Section 5.3.7. The first element is also used
to generate the "Date:" field, and the EBNF.report-point.
拡張RFC822フィールドへのMTA.ReportTransferEnvelope.internal-トレース情報Mapped、「X400が受け取られている:、」、セクション5.3では、.7に説明されます。 また、最初の要素は、「日付:」を発生させるのに使用されます。 分野、およびEBNF.report-ポイント。
MTA.PerRecipientReportTransferFields.last-trace-information
Mapped to EBNF.recipient-info (last trace)
EBNF.recipient-インフォメーションに写像されたMTA.PerRecipientReportTransferFields.last-トレース情報(最後の跡)
MTA.PerReportTransferFields.subject-intermediate-trace-
information Mapped to EBNF.drc-field (Subject-Intermediate-
Trace-Information). These fields are ordered so that the
most recent trace element comes first.
EBNF.drc-分野(対象中間的に情報をたどっている)へのMTA.PerReportTransferFields.subject中間的な跡情報Mapped。 これらの分野が命令されるので、最新の微量元素は一番になります。
5.3.8.3. Example Delivery Reports
5.3.8.3. 例の配送レポート
Example Delivery Report 1:
例の配送レポート1:
Return-Path: <postmaster@cs.ucl.ac.uk>
Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk
via Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk>;
Thu, 7 Feb 1991 15:48:39 +0000
From: UCL-CS MTA <postmaster@cs.ucl.ac.uk>
To: S.Kille@cs.ucl.ac.uk
Subject: Delivery Report (failure) for H.Hildegard@bbn.com
Message-Type: Delivery Report
Date: Thu, 7 Feb 1991 15:48:39 +0000
Message-ID: <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk>
Content-Identifier: Greetings.
リターンパス: <郵便局長@cs.ucl.ac.uk>は受信されました: Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk を通したbells.cs.ucl.ac.ukによるcs.ucl.ac.uk、gt;、。 木曜日、1991年2月7日の15:48:39+0000From: UCL-Cs MTA <postmaster@cs.ucl.ac.uk 、gt;、To: S.Kille@cs.ucl.ac.uk Subject: H.Hildegard@bbn.com メッセージタイプへの配送レポート(失敗): 配送レポート日付: 木曜日、1991年2月7日の15:48:39+0000Message ID: <、「bells.cs.u.694: 07.01 .91 .15 .48の0.34インチ@cs.ucl.ac.ukの>の満足している識別子:、」 こんにちは。
------------------------------ Start of body part 1
------------------------------ ボディー第1部の始まり
This report relates to your message: Greetings.
of Thu, 7 Feb 1991 15:48:20 +0000
このレポートはあなたのメッセージに関連します: 挨拶木曜日、1991年2月7日の15:48:20+0000について
Your message was not delivered to
H.Hildegard@bbn.com for the following reason:
Bad Address
MTA 'bbn.com' gives error message (USER) Unknown user
name in "H.Hildegard@bbn.com"
あなたのメッセージは以下の理由で H.Hildegard@bbn.com に渡されませんでした: 悪いAddress MTA'bbn.com'は" H.Hildegard@bbn.com "のエラーメッセージ(USER)の未知のユーザ名を与えます。
***** The following information is directed towards the local ***** administrator and is not intended for the end user * * DR generated by mta bells.cs.ucl.ac.uk * in /PRMD=uk.ac/ADMD=gold 400/C=gb/ * at Thu, 7 Feb 1991 15:48:34 +0000
***** 以下の情報は、地元の*****管理者に向けられて、木曜日、1991年2月7日の15:48:34+0000にmta bells.cs.ucl.ac.uk*によって/PRMD=uk.ac/ADMD=金の400/C=gb/*で発生したエンドユーザ**DRのために意図しません。
Hardcastle-Kille [Page 88] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[88ページ]RFC1327マッピング
* * Converted to RFC 822 at bells.cs.ucl.ac.uk * at Thu, 7 Feb 1991 15:48:40 +0000 * ..... continued on next page
* * 木曜日、1991年2月7日の15:48:40+0000*でbells.cs.ucl.ac.uk*でRFC822に変換されました… 次のページでは、続けられています。
* Delivery Report Contents:
*
* Subject-Submission-Identifier:
* [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1803.665941698@UK.AC.UCL.CS>]
* Content-Identifier: Greetings.
* Subject-Intermediate-Trace-Information:
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
* arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed
* 配送レポートコンテンツ: * * 対象の服従識別子: * [/PRMD=uk.ac/ADMD=金400/Cが gb/;<1803.665941698@UK.AC.UCL.CS と等しい、gt;、]、*満足している識別子: こんにちは。 * 対象の中間的トレース情報: /PRMD=uk.ac/ADMD=金400/Cはgb/と等しいです。 * 到着、木曜日、1991年2月7日15:48:20+0000動作Relayed
* Subject-Intermediate-Trace-Information:
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
* arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed
* Recipient-Info: H.Hildegard@bbn.com,
* /RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
* FAILURE reason Unable-To-Transfer (1);
* diagnostic Unrecognised-ORName (0);
* last trace (ia5) Thu, 7 Feb 1991 15:48:18 +0000;
* supplementary info "MTA 'bbn.com' gives error message (USER)
* Unknown user name in "H.Hildegard@bbn.com"";
****** End of administration information
* 対象の中間的トレース情報: /PRMD=uk.ac/ADMD=金400/Cはgb/と等しいです。 * 到着、木曜日、1991年2月7日の15:48: 18+0000動作Relayed*受取人インフォメーション: H.Hildegard@bbn.com 、*/RFC-822=H.Hildegard(a)bbn.com/OU=Cs/O=ucl/PRMD=uk.ac/ADMD=金400/Cはgb/と等しいです。 * FAILUREはUnableから転送への(1)を推論します。 * 診断Unrecognised-ORName(0)。 * 最後に、(ia5)木曜日、1991年2月7日の15:48:18+0000をたどってください。 * 補っているインフォメーション「MTA'bbn.comは'" H.Hildegard@bbn.com "のエラーメッセージ(USER)*未知のユーザ名を与えます」。 ****** 管理情報の終わり
The Original Message follows:
Original Messageは続きます:
------------------------------ Start of forwarded message 1
------------------------------ 転送されたメッセージ1の始まり
Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <27689-0@bells.cs.ucl.ac.uk>; Thu, 7 Feb 1991 15:48:21 +0000 To: H.Hildegard@bbn.com Subject: Greetings. Phone: +44-71-380-7294 Date: Thu, 07 Feb 91 15:48:18 +0000 Message-ID: <1803.665941698@UK.AC.UCL.CS> From: Steve Kille <S.Kille@cs.ucl.ac.uk>
受け取られている: SMTPの本国行きの id <27689-0@bells.cs.ucl.ac.uk とbells.cs.ucl.ac.ukによるglenlivet.cs.ucl.ac.uk、gt;、。 木曜日、1991年2月7日の15:48:21+0000To: H.Hildegard@bbn.com Subject: こんにちは。 以下に電話をしてください。 +44-71-380-7294 日付: 木曜日、1991年2月7日の15:48:18+0000Message ID: <1803.665941698@UK.AC.UCL.CS>From: スティーブ Kille <S.Kille@cs.ucl.ac.uk 、gt。
Steve
スティーブ
------------------------------ End of forwarded message 1 Example Delivery Report 2:
------------------------------ 転送されたメッセージ1Example Delivery Report2の端:
Hardcastle-Kille [Page 89] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[89ページ]RFC1327マッピング
Return-Path: <postmaster@cs.ucl.ac.uk>
Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk
via Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk>;
Thu, 7 Feb 1991 15:49:11 +0000
X400-Received: by mta bells.cs.ucl.ac.uk in
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
Relayed; Thu, 7 Feb 1991 15:49:08 +0000
X400-Received: by /PRMD=DGC/ADMD=GOLD 400/C=GB/; Relayed;
Thu, 7 Feb 1991 15:48:40 +0000
From: UCL-CS MTA <postmaster@cs.ucl.ac.uk>
To: S.Kille@cs.ucl.ac.uk
Subject: Delivery Report (failure) for
j.nosuchuser@dle.cambridge.DGC.gold-400.gb
Message-Type: Delivery Report
Date: Thu, 7 Feb 1991 15:49:11 +0000
Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk>
Content-Identifier: A useful mess...
リターンパス: <郵便局長@cs.ucl.ac.uk>は受信されました: Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk を通したbells.cs.ucl.ac.ukによるcs.ucl.ac.uk、gt;、。 木曜日に、1991年2月7日の15:49:11+0000はX400受信されました: /PRMD=uk.ac/ADMD=のmta bells.cs.ucl.ac.ukで、金400/Cはgb/と等しいです。 リレーされます。 木曜日に、1991年2月7日の15:49:08+0000はX400受信されました: /PRMD=DGC/ADMD=で、金400/CはGB/と等しいです。 リレーされます。 木曜日、1991年2月7日の15:48:40+0000From: UCL-Cs MTA <postmaster@cs.ucl.ac.uk 、gt;、To: S.Kille@cs.ucl.ac.uk Subject: j.nosuchuser@dle.cambridge.DGC.gold-400.gb メッセージタイプへの配送レポート(失敗): 配送レポート日付: 木曜日、1991年2月7日の15:49:11+0000Message ID: <、「0インチ@cs.ucl.ac.ukの>の満足しているDLE/910207154840Z/識別子:」 役に立つ混乱…
This report relates to your message: A useful mess...
Your message was not delivered to
j.nosuchuser@dle.cambridge.DGC.gold-400.gb
for the following reason:
Bad Address
DG 21187: (CEO POA) Unknown addressee.
このレポートはあなたのメッセージに関連します: 役に立つ混乱… あなたのメッセージは以下の理由で j.nosuchuser@dle.cambridge.DGC.gold-400.gb に渡されませんでした: 悪いアドレスDG21187: (最高経営責任者POA) 未知の受け取り人。
***** The following information is directed towards the local ***** administrator and is not intended for the end user * * DR generated by /PRMD=DGC/ADMD=GOLD 400/C=GB/ * at Thu, 7 Feb 1991 15:48:40 +0000 * * Converted to RFC 822 at bells.cs.ucl.ac.uk * at Thu, 7 Feb 1991 15:49:12 +0000 * * Delivery Report Contents: * * Subject-Submission-Identifier: * [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>] * Content-Identifier: A useful mess... * Recipient-Info: j.nosuchuser@dle.cambridge.DGC.gold-400.gb, * /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/; * FAILURE reason Unable-To-Transfer (1); * diagnostic Unrecognised-ORName (0); * supplementary info "DG 21187: (CEO POA) Unknown addressee."; ****** End of administration information
***** 以下の情報は、地元の*****管理者に向けられて、木曜日に/PRMD=DGC/ADMD=GOLDによって400/C=GB/*発生したエンドユーザ**DRのために意図しないで、1991年2月7日の15:48:40+0000**は木曜日にbells.cs.ucl.ac.uk*でRFC822に変えました、1991年2月7日の15:49:12+0000**配送Report Contents: * * 対象の服従識別子: * [/PRMD=uk.ac/ADMD=金400/Cが gb/;<1796.665941626@UK.AC.UCL.CS と等しい、gt;、]、*満足している識別子: 役に立つ混乱… * 受取人インフォメーション: j.nosuchuser@dle.cambridge.DGC.gold-400.gb 、*/I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=金400/CはGB/と等しいです。 * FAILUREはUnableから転送への(1)を推論します。 * 診断Unrecognised-ORName(0)。 * 補っているインフォメーション、「DG21187:」 (最高経営責任者POA) 「未知の受け取り人。」 ****** 管理情報の終わり
The Original Message is not available
Original Messageは利用可能ではありません。
Hardcastle-Kille [Page 90] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[90ページ]RFC1327マッピング
5.3.9. Probe
5.3.9. 徹底的調査
This is an MTS internal issue. Any probe shall 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 shall make use of MTS.SupplementaryInformation to indicate that the probe was serviced by the gateway.
これはMTSの内部の問題です。 どんな同等なRFC822の機能性もなくて、どんな徹底的調査もゲートウェイによって修理されるものとします。 回答の値は値が徹底的調査で指定されている状態でゲートウェイがMTS Messageを調整できたかどうかに依存しています。 回答は、徹底的調査がゲートウェイによって修理されたのを示すのにMTS.SupplementaryInformationを利用するものとします。
Appendix A - Mappings Specific to SMTP
付録A--SMTPに特定のマッピング
This Appendix is specific to the Simple Mail Transfer Protocol (RFC 821). It describes specific changes in the context of this protocol. When servicing a probe, as described in section 5.3.9, use may be made of the SMTP VRFY command to increase the accuracy of information contained in the delivery report.
このAppendixはシンプルメールトランスファプロトコル(RFC821)に特定です。 それはこのプロトコルの文脈における特定の変化について説明します。 セクション5.3.9で説明されるように徹底的調査を修理するとき、配送レポートに含まれた情報の精度を増加させるSMTP VRFYコマンドで使用をするかもしれません。
Appendix B - Mappings specific to the JNT Mail
付録B--JNTメールに特定のマッピング
This Appendix is specific to the JNT Mail Protocol. It describes specific changes in the context of this protocol.
このAppendixはJNTメールプロトコルに特定です。 それはこのプロトコルの文脈における特定の変化について説明します。
1. Introduction
1. 序論
There are five aspects of a gateway which are JNT Mail Specific.
These are each given a section of this appendix.
JNTメールSpecificであるゲートウェイの5つの局面があります。 この付録のセクションを考えて、これらはそれぞれです。
2. Domain Ordering
2. ドメイン注文
When interpreting and generating domains, the UK NRS domain
ordering shall be used, both in headers, and in text generated for
human description.
ドメインを解釈して、発生させるとき、UK NRSドメイン注文はヘッダー、および人間の記述のために作られたテキストで使用されるものとします。
3. Addressing
3. アドレシング
A gateway which maps to JNT Mail should recognise the Domain
Defined Attribute JNT-MAIL. The value associated with this
attribute should be interpreted according to the JNT Mail
Specification. This DDA shall never be generated by a gateway.
For this reason, the overflow mechanism is not required.
JNTメールへのそれの地図がDomain Defined Attribute JNT-メールを認識するはずであるゲートウェイ。 JNTメールSpecificationによると、この属性に関連している値は解釈されるべきです。 このDDAはゲートウェイで決して発生しないものとします。 この理由で、オーバーフローメカニズムは必要ではありません。
4. Acknowledge-To:
4. 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.
この分野はX.400にどんなダイレクト機能的な同等物も持っていません。 しかしながら、それを程度まで支持できて、X.400サポートを改良するのに使用できます。
If an Acknowledge-To: field is present when going from JNT Mail to
To:を承認します。 JNTメールから行くと、分野は現在です。
Hardcastle-Kille [Page 91] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[91ページ]RFC1327マッピング
X.400, there are two different situations. The first case is
where there is one address in the Acknowledge-To: field, and it is
equal to the 822-MTS return address. In this case, the
MTS.PerRecipientSubmissionFields.originator-request-report.report
shall be set for each recipient, and the Acknowledge-To: field
discarded. Here, X.400 can provide the equivalent service.
X.400、2つの異なった状況があります。 最初のケースは1つのアドレスがAcknowledge-To:にあるところです。 分野、およびそれはそうです。822-MTS返送先と等しいです。 この場合、MTS.PerRecipientSubmissionFields.originatorがreport.reportを要求しているのは各受取人、およびAcknowledge-To:に設定されるものとします。 分野は捨てられました。 ここに、X.400は同等なサービスを提供できます。
In all other cases two actions are taken.
全部で、他のケースtwo行動を取ります。
1. Acknowledgement(s) may be generated by the gateway. The
text of these acknowledgements shall indicate that they are
generated by the gateway, and do not correspond to delivery.
1. 承認はゲートウェイで発生するかもしれません。 これらの承認のテキストはゲートウェイによって発生されて、配送に対応しないのを示すものとします。
2. The Acknowledge-To: field shall be passed as an extension
heading.
2. To:を承認します。 野原は拡大見出しとして通り過ぎられるものとします。
When going from X.400 to JNT Mail, in cases where
MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
originator-report bit is set for all recipients (i.e., there is a
user request for a positive delivery report for every recipeint),
generate an Acknowledge-To: field containing the
MTS.OtherMessageDeliveryFields.originator-name. Receipt
notification requests are not mapped onto Acknowledge-To:, as no
association can be guaranteed between IPMS and MTS level
addressing information.
X.400からJNTメールまで行くときには、MTA.PerRecipientMessageTransferFields.per受取人インディケータ創始者レポートビットがすべての受取人に設定される(すなわち、あらゆるrecipeintに、積極的な配送レポートに関するユーザ要求があります)場合では、Acknowledge-To:を発生させてください。 MTS.OtherMessageDeliveryFields.originator-名前を含む分野。 領収書通知要求はAcknowledge-To:に写像されません、情報を記述するIPMSとMTSレベルの間で協会を全く保証できないとき。
5. Trace
5. 跡
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 is used. The
trace text, including the "Via:", is 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.
JNTメール跡はViaを使用します: 構文。 JNTメールからReceivedに、それと同様のX.400、マッピングまで行くとき: 使用されます。 Viaから跡を作るサイトのMTS.GlobalDomainIdentifierを全く得ることができません:、したがって、ゲートウェイへの値は使用されています。 「以下を通って」を含む跡のテキストは、繰り広げられて、MTS.ub-mta名前の長さの(32)に先端を切られて、MTA.InternalTraceInformationElement.mta-名前に写像されます。 反対の方向のためのどんなJNTのメールの特定のマッピングもありません。
6. Timezone specification
6. タイムゾーン仕様
The extended syntax of zone defined in the JNT Mail Protocol shall
be used in the mapping of UTCTime defined in Chapter 3.
JNTメールプロトコルで定義されたゾーンの拡張構文は第3章で定義されたUTCTimeに関するマッピングで使用されるものとします。
7. Lack of 822-MTS originator specification
7. 822-MTS創始者仕様の不足
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:
JNTメールには、SenderにはMTS.OtherMessageDeliveryFields.originator-名前に関するデフォルトマッピングがあります: さばきます。 IPMS.Headingに関するマッピングがSenderを既に発生させたならX.400からJNTメールまで行くとき、これは問題を引き起こす場合があります:
Hardcastle-Kille [Page 92] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[92ページ]RFC1327マッピング
field. To overcome this, new extended JNT Mail field is defined.
This is chosen to align with the JNT recommendation for
interworking with full RFC 822 systems [Kille84b].
さばきます。 これに打ち勝つために、新しい拡張JNTメール分野は定義されます。 これは、完全なRFC822と共にシステムが[Kille84b]であると織り込むためのJNT推薦に並ぶために選ばれています。
original-sender = "Original-Sender" ":" mailbox
「元の送り主は「元の送り主」と等しい」:、」 メールボックス
If an IPM has no IPMS.Heading.authorizing-users component and
IPMS.Heading.originator.formal-name is different from
MTS.OtherMessageDeliveryFields.originator-name, map
MTS.OtherMessageDeliveryFields.originator-name, onto the Sender:
field.
IPMにはIPMS.Heading.authorizing-ユーザコンポーネントが全くなくて、IPMS.Heading.originator.formal-nameがMTS.OtherMessageDeliveryFields.originator-名前と異なるなら、MTS.OtherMessageDeliveryFields.originator-名前をSenderに写像してください: さばきます。
If an IPM has a IPMS.Heading.authorizing-users component, and
IPMS.Heading.originator.formal-name is different from
MTS.OtherMessageDeliveryFields.originator-name,
MTS.OtherMessageDeliveryFields.originator-name is mapped onto the
Sender: field, and IPMS.Heading.originator mapped onto the
Original-Sender: field.
IPMにはIPMS.Heading.authorizing-ユーザコンポーネントがあって、IPMS.Heading.originator.formal-nameがMTS.OtherMessageDeliveryFields.originator-名前と異なるなら、MTS.OtherMessageDeliveryFields.originator-名前はSenderに写像されます: 分野、およびOriginal-送付者に写像されたIPMS.Heading.originator: さばきます。
In other cases the MTS.OtherMessageDeliveryFields.originator-name,
is already correctly represented.
他の場合では、正しく表されて、MTS.OtherMessageDeliveryFields.originator-名前は既にそうです。
Appendix C - Mappings specific to UUCP Mail
付録C--UUCPメールに特定のマッピング
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
UUCPとX.400のGatewayingは、RFC822構文(RFC976を使用する)にUUCPアドレスをgatewayingして、次に、結果として起こるRFC822アドレスをX.400にgatewayingしながら、最初にによって扱われます。 例えば、X.400アドレス
Country US
Organisation Xerox
Personal Name John Smith
国の米国機構のゼロックスの個人名ジョン・スミス
might be expressed from UUCP as
UUCPから言い表されるかもしれません。
inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/
inthop!ゲート!gatehost.COM!/Cは米国/O=Xerox/PN=John.Smith/と等しいです。
(assuming gate is a UUCP-ARPA gateway and gatehost.COM is an ARPA- X.400 gateway) or
または(ゲートがUUCP-ARPAゲートウェイであり、gatehost.COMがARPA X.400ゲートウェイであると仮定します)。
inthop!gate!Xerox.COM!John.Smith
inthop!ゲート!Xerox.COM!John.Smith
(assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)
(Xerox.COMと/C=米国/O=ゼロックス/が同等であると仮定します。)
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:
もう片方の方向に、822と統合されたUUCPアドレス Smith@ATT.COM はいかなる他の822アドレスとしても扱われるでしょう。 inthop!dest!ユーザなどの非統合しているアドレスは1組のゲートウェイを通して扱われるかもしれません:
Hardcastle-Kille [Page 93] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[93ページ]RFC1327マッピング
Country US
ADMD ATT
PRMD ARPA
Organisation GateOrg
RFC-822 inthop!dest!user@gatehost.COM
国の米国ADMD ATT PRMDアルパ機構GateOrg RFC-822 inthop!dest!user@gatehost.COM
or through a single X.400 to UUCP gateway:
または、aを通して、UUCPゲートウェイにX.400を選抜してください:
Country US
ADMD ATT
PRMD UUCP
Organisation GateOrg
RFC-822 inthop!dest!user
国のUS ADMD ATT PRMD UUCP Organisation GateOrg RFC-822 inthop!dest!ユーザ
Appendix D - Object Identifier Assignment
付録D--物の識別子課題
An object identifier is needed for the extension IPMS element. The following value shall be used.
物の識別子が拡大IPMS要素に必要です。 以下の値は使用されるものとします。
rfc-987-88 OBJECT IDENTIFIER ::=
{ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)}
rfc-987-88 OBJECT IDENTIFIER:、:= ccittデータ(9)pss(2342)ucl(234219200300) rfc-987-88(200)
id-rfc-822-field-list OBJECT IDENTIFIER ::= {rfc987-88 field(1)}
イドrfc822分野リストOBJECT IDENTIFIER:、:= rfc987-88分野(1)
Appendix E - BNF Summary
付録E--BNF概要
boolean = "TRUE" / "FALSE"
論理演算子=「本当」/「誤っています」。
numericstring = *DIGIT
numericstringは*DIGITと等しいです。
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-炭の=と等しいです。
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")」
Hardcastle-Kille [Page 94] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[94ページ]RFC1327マッピング
teletex-string = *( ps-char / t61-encoded )
t61-encoded = "{" 1* t61-encoded-char "}"
t61-encoded-char = 3DIGIT
t61が炭をコード化しているテレテックスストリング=*(t61によってps-炭/コード化された)t61によってコード化された=「「1 *t61は炭をコード化」だった」=3DIGIT
teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]
テレテックス、または、psする、=[printablestring][「*」テレテックスストリング]
labelled-integer ::= [ key-string ] "(" numericstring ")"
ラベルされた整数:、:= [主要なストリング]の「(「numericstring」)」
key-string = *key-char
key-char = <a-z, A-Z, 0-9, and "-">
そして、主要なストリング=*主要な炭キー炭が<a-z、A-Z、0-9と等しい、「-、">"
object-identifier ::= oid-comp object-identifier
| oid-comp
物識別子:、:= oid-コンピュータ物識別子| oid-コンピュータ
oid-comp ::= [ key-string ] "(" numericstring ")"
oid-コンピュータ:、:= [主要なストリング]の「(「numericstring」)」
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)
encoded-pn = [ given "." ] *( initial "." ) surname
「コード化されたpnが等しい、[付与、」、」、]、*、(初期、」、」、)、姓
given = 2*<ps-char not including ".">
. 「包含ではなく、与えられた=2*<ps-炭」">"
initial = ALPHA
初期の=アルファー
surname = printablestring
姓=printablestring
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ registered-dd-type
」 属性=標準体型/"RFC-822"/登録されたdd「stdかアドレス=1*(「/」属性「=」価値)」/タイプ
Hardcastle-Kille [Page 95] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[95ページ]RFC1327マッピング
/ dd-key "." std-printablestring
standard-type = key-string
「/dd-キー」 」 std-printablestring標準体型は主要なストリングと等しいです。
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-炭」
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 = "\."
「dmn-printablestring/"@"属性「$」値属性=標準体型/「~」dmn-printablestring dmnかアドレス=dmn-部分*(「.」 dmn-部分)dmn-部分=価値=dmn-printablestring=は*(dmn dmn-炭/対にしている)dmn-炭=<と等しい」、「」、」、「*」、および」 . 「>dmn-組は」 \と等しいこと」を除いたどんなps-炭
global-id = std-or-address
グローバルなイドはstdかアドレスと等しいです。
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-or-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=単語到着時間=日付-時間
Hardcastle-Kille [Page 96] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[96ページ]RFC1327マッピング
md-or-mta = "MD" global-id
/ "MTA" mta
「MD」グローバルなイド/"MTA"Mdかmta=mta
Action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
「向け直される」か、「広げられる」、「リレーされる」、または「別ルートで送られた」動作リスト=1#動作動作=
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-administrator-info-envelope <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:"
dr満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
dr-概要=「このレポートはあなたのメッセージに関連します」。 <CRLF>満足している相関器<CRLF><CRLF>“of"日付-時間<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-administrator-info-envelope = 3*( "*" text <CRLF> )
dr管理者インフォメーション封筒=3*(「*」テキスト<CRLF>)
dr-administrator-info =
"**** The following information is directed towards"
"the local administrator" <CRLF>
"**** and is not intended for the end user" <CRLF> <CRLF>
"DR generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"Converted to RFC 822 at" mta <CRLF>
"at" date-time <CRLF> <CRLF>
「dr管理者インフォメーションは等しい」、****以下の情報が、」 「」 地元の管理者<CRLF>」****に向けられて、」 「DRを以下は発生させた」エンドユーザ<CRLF><CRLF>のために意図しません。 <CRLF><CRLF>が「RFC822に変換した」レポートポイント<CRLF>“at"日付-時間mta<CRLF>“at"日付-時間<CRLF><CRLF>。
Hardcastle-Kille [Page 97] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[97ページ]RFC1327マッピング
"Delivery Report Contents:" <CRLF> <CRLF>
drc-field-list <CRLF>
"***** End of administration information"
「配送レポートコンテンツ:」 「」 *****が終わらせる管理情報の<CRLF><CRLF>drc分野リスト<CRLF>」
drc-field-list = *(drc-field <CRLF>)
drc分野リスト=*(drc-分野<CRLF>)
drc-field = "Subject-Submision-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-field = "Subject-Submision-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
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 ";" ]
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 ";" ]
report-type = "SUCCESS" drc-success
/ "FAILURE" drc-failure
report-type = "SUCCESS" drc-success / "FAILURE" drc-failure
drc-success = "delivered at" date-time ";"
[ "type of MTS user" labelled-integer ";" ]
drc-success = "delivered at" date-time ";" [ "type of MTS user" labelled-integer ";" ]
drc-failure = "reason" labelled-integer ";"
[ "diagnostic" labelled-integer ";" ]
drc-failure = "reason" labelled-integer ";" [ "diagnostic" labelled-integer ";" ]
report-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#( mailbox "(" date-time ")")
report-point = [ "mta" word "in" ] global-id content-correlator = *word dl-history = 1#( mailbox "(" date-time ")")
Hardcastle-Kille [Page 98] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Hardcastle-Kille [Page 98] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
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 ";"
/ "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-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 ";" / "Conversion" ":" prohibition / "Conversion-With-Loss" ":" prohibition / "Requested-Delivery-Method" ":" 1*( labelled-integer ) / "Delivery-Date" ":" date-time / "Discarded-X400-MTS-Extensions" ":" 1#( oid / labelled-integer )
prohibition = "Prohibited" / "Allowed"
prohibition = "Prohibited" / "Allowed"
mts-msg-id = "[" global-id ";" *text "]"
mts-msg-id = "[" global-id ";" *text "]"
mts-content-type = "P2" / labelled-integer
/ object-identifer
mts-content-type = "P2" / labelled-integer / object-identifer
priority = "normal" / "non-urgent" / "urgent"
priority = "normal" / "non-urgent" / "urgent"
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
[ ipn-content-return ]
ipn-body-format = ipn-description <CRLF> [ ipn-extra-information <CRLF> ] [ ipn-content-return ]
ipn-description = ipn-receipt / ipn-non-receipt
ipn-description = ipn-receipt / ipn-non-receipt
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-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-non-receipt "Your message to:"
preferred-recipient <CRLF>
ipn-reason
ipn-non-receipt "Your message to:" preferred-recipient <CRLF> ipn-reason
ipn-reason = ipn-discarded / ipn-auto-forwarded
ipn-reason = ipn-discarded / ipn-auto-forwarded
Hardcastle-Kille [Page 99] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Hardcastle-Kille [Page 99] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipn-discarded = "was discarded for the following reason:" discard-reason <CRLF>
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
ipn-auto-forwarded = "was automatically forwarded." <CRLF> [ "The following comment was made:" auto-comment ]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-extra-information = "The following information types were converted:" encoded-info
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
ipn-content-return = "The Original Message is not available" / "The Original Message follows:" <CRLF> <CRLF> message
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
preferred-recipient = mailbox receipt-time = date-time auto-comment = printablestring ipn-suppl = printablestring
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated"
discard-reason = "Expired" / "Obsoleted" / "User Subscription Terminated"
acknowledgement-mode = "Manually" / "Automatically"
acknowledgement-mode = "Manually" / "Automatically"
ipms-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
ipms-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
importance = "low" / "normal" / "high"
importance = "low" / "normal" / "high"
sensitivity = "Personal" / "Private" /
"Company-Confidential"
sensitivity = "Personal" / "Private" / "Company-Confidential"
language = 2*ALPHA [ language-description ]
language = 2*ALPHA [ language-description ]
Hardcastle-Kille [Page 100] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Hardcastle-Kille [Page 100] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
language-description = printable-string
language-description = printable-string
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
message-type = "Delivery Report" / "InterPersonal Notification" / "Multiple Part"
redirect-comment =
[ "Originally To:" ] mailbox "Redirected"
[ "Again" ] "on" date-time
"To:" redirection-reason
redirect-comment = [ "Originally To:" ] mailbox "Redirected" [ "Again" ] "on" date-time "To:" redirection-reason
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
redirection-reason = "Recipient Assigned Alternate Recipient" / "Originator Requested Alternate Recipient" / "Recipient MD Assigned Alternate Recipient"
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
subject-line = "Delivery-Report" "(" status ")" [ "for" destination ]
status = "success" / "failure" / "success and failures"
status = "success" / "failure" / "success and failures"
destination = mailbox / "MTA" word
destination = mailbox / "MTA" word
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "Content-Return" ":" prohibition
extended-heading = "Prevent-NonDelivery-Report" ":" / "Generate-Delivery-Report" ":" / "Alternate-Recipient" ":" prohibition / "Disclose-Recipients" ":" prohibition / "Content-Return" ":" prohibition
Appendix F - Format of address mapping tables
Appendix F - Format of address mapping tables
1. Global Mapping Information
1. Global Mapping Information
The consistent operation of gateways which follow this
specification relies of the existence of three globally defined
mappings:
The consistent operation of gateways which follow this specification relies of the existence of three globally defined mappings:
1. Domain Name Space -> O/R Address Space
1. Domain Name Space -> O/R Address Space
2. O/R Address Space -> Domain Name Space
2. O/R Address Space -> Domain Name Space
3. Domain Name Space -> O/R Address of preferred gateway
3. Domain Name Space -> O/R Address of preferred gateway
Hardcastle-Kille [Page 101] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Hardcastle-Kille [Page 101] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
All gateways conforming to this specification shall have access to
these mappings. The gateway may use standardised or private
mechanisms to access this mapping information.
All gateways conforming to this specification shall have access to these mappings. The gateway may use standardised or private mechanisms to access this mapping information.
One means of distributing this information is in three files.
This appendix defines a format for these files. Other
standardised mechanisms to distribute the mapping information are
expected. In particular, mechanisms for using the Domain Name
Scheme, and X.500 are planned.
One means of distributing this information is in three files. This appendix defines a format for these files. Other standardised mechanisms to distribute the mapping information are expected. In particular, mechanisms for using the Domain Name Scheme, and X.500 are planned.
The definition of global mapping information is being co-
ordinated by the COSINE-MHS project, on behalf of the Internet and
other X.400 and RFC 822 users. For information on accessing this
information contact:
The definition of global mapping information is being co- ordinated by the COSINE-MHS project, on behalf of the Internet and other X.400 and RFC 822 users. For information on accessing this information contact:
COSINE MHS Project Team
SWITCH
Weinbergstrasse 18
8001 Zuerich
Switzerland
COSINE MHS Project Team SWITCH Weinbergstrasse 18 8001 Zuerich Switzerland
tel: +41 1 262 3143
fax: +41 1 262 3151
email:
C=ch;ADMD=arcom;PRMD=switch;O=switch;OU=cosine-mhs;
S=project-team
or
project-team@cosine-mhs.switch.ch
tel: +41 1 262 3143 fax: +41 1 262 3151 email: C=ch;ADMD=arcom;PRMD=switch;O=switch;OU=cosine-mhs; S=project-team or project-team@cosine-mhs.switch.ch
2. Syntax Definitions
2. Syntax Definitions
An address syntax is defined, which is compatible with the syntax
used for 822.domains. By representing the O/R addresses as
domains, all lookups can be mechanically implemented as domain ->
domain mappings. This syntax defined is initially for use in
table format, but the syntax is defined in a manner which makes it
suitable to be adapted for use with the Domain Name Service.
This syntax allows for a general representation of O/R addresses,
so that it can be used in other applications. Not all attributes
are used in the table formats defined.
An address syntax is defined, which is compatible with the syntax used for 822.domains. By representing the O/R addresses as domains, all lookups can be mechanically implemented as domain -> domain mappings. This syntax defined is initially for use in table format, but the syntax is defined in a manner which makes it suitable to be adapted for use with the Domain Name Service. This syntax allows for a general representation of O/R addresses, so that it can be used in other applications. Not all attributes are used in the table formats defined.
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.
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.
Hardcastle-Kille [Page 102] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Hardcastle-Kille [Page 102] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
This syntax is not intended to be handled by users.
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-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "\."
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 = "\."
An example usage:
An example usage:
~ROLE$Big\.Chief.ADMD$ATT.C$US
PRMD$DEC.ADMD$@.C$US
~ROLE$Big\.Chief.ADMD$ATT.C$US PRMD$DEC.ADMD$@.C$US
The first example illustrates quoting of a ".", and the second
omission of the ADMD level. There must be a strict ordering of all
components in this table, with the most significant components on
the RHS. This allows the encoding to be treated as a domain.
The first example illustrates quoting of a ".", and the second omission of the ADMD level. There must be a strict ordering of all components in this table, with the most significant components on the RHS. This allows the encoding to be treated as a domain.
Various further restrictions are placed on the usage of dmn-or-
address in the address space mapping tables.
Various further restrictions are placed on the usage of dmn-or- address in the address space mapping tables.
1. Only C, ADMD, PRMD, O, and up to four OUs may be used.
1. Only C, ADMD, PRMD, O, and up to four OUs may be used.
2. No components shall be omitted from this hierarchy, although
the hierarchy may terminate at any level. If the mapping is
to an omitted component, the "@" syntax is used.
2. No components shall be omitted from this hierarchy, although the hierarchy may terminate at any level. If the mapping is to an omitted component, the "@" syntax is used.
3. Table Lookups
3. Table Lookups
When determining a match, there are aspects which apply to all
lookups. Matches are always case independent. The key for all
three tables is a domain. The longest possible match shall be
obtained. Suppose the table has two entries with the following
keys:
When determining a match, there are aspects which apply to all lookups. Matches are always case independent. The key for all three tables is a domain. The longest possible match shall be obtained. Suppose the table has two entries with the following keys:
K.L
J.K.L
K.L J.K.L
Domain "A.B.C" will not return any matches. Domain "I.J.K.L" will
match the entry "J.K.L:.
Domain "A.B.C" will not return any matches. Domain "I.J.K.L" will match the entry "J.K.L:.
Hardcastle-Kille [Page 103] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Hardcastle-Kille [Page 103] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
4. Domain -> O/R Address format
4. Domain -> O/R Address format
The BNF is:
The BNF is:
domain-syntax "#" dmn-or-address "#"
domain-syntax "#" dmn-or-address "#"
Note that the trailing "#" is used for clarity, as the dmn-or-
address syntax might lead to values with trailing blanks. Lines
staring with "#" are comments.
Note that the trailing "#" is used for clarity, as the dmn-or- address syntax might lead to values with trailing blanks. Lines staring with "#" are comments.
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#
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#
A domain is looked up to determine the top levels of an O/R
Address. Components of the domain which are not matched are used
to build the remainder of the O/R address, as described in Section
4.3.4.
A domain is looked up to determine the top levels of an O/R Address. Components of the domain which are not matched are used to build the remainder of the O/R address, as described in Section 4.3.4.
5. O/R Address -> Domain format
5. O/R Address -> Domain format
The syntax of this table is:
The syntax of this table is:
dmn-or-address "#" domain-syntax "#"
dmn-or-address "#" domain-syntax "#"
For example:
For example:
#
# Mapping table
#
PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
# # Mapping table # PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
The O/R Address is used to generate a domain key. It is important
to order the components correctly, and to fill in missing
components in the hierarchy. Use of this mapping is described in
Section 4.3.2.
The O/R Address is used to generate a domain key. It is important to order the components correctly, and to fill in missing components in the hierarchy. Use of this mapping is described in Section 4.3.2.
6. Domain -> O/R Address of Gateway table
6. Domain -> O/R Address of Gateway table
This uses the same format as the domain -> O/R address mapping.
In this case, the two restrictions (omitted components and
restrictions on components) do not apply. Use of this mapping is
described in Section 4.3.4.
これはドメイン->O/Rアドレス・マッピングと同じ形式を使用します。 この場合、2つの制限(コンポーネントでコンポーネントと制限を省略する)は適用されません。 このマッピングの使用はセクション4.3.4で説明されます。
Hardcastle-Kille [Page 104] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[104ページ]RFC1327マッピング
Appendix G - Mapping with X.400(1984)
付録G--X.400があるマッピング(1984)
This appendix defines modification to the mapping for use with X.400(1984).
この付録はX.400(1984)との使用のためのマッピングへの変更を定義します。
The X.400(1984) protocols are a proper subset of X.400(1988). When mapping from X.400(1984) to RFC 822, no changes to this specification are needed.
X.400(1984)プロトコルはX.400(1988)の真部分集合です。 X.400(1984)からRFC822まで写像するとき、この仕様への変化は全く必要ではありません。
When mapping from RFC 822 to X.400(1984), no use can be made of 1988 specific features. No use of such features is made at the MTS level. One feature is used at the IPMS level, and this must be replaced by the RFC 987 approach. All header information which would usually be mapped into the rfc-822-heading-list extension, together with any Comments: field in the RFC 822 header is mapped into a single IA5 body part, which is the first body part in the message. This body part will start with the string "RFC-822-Headers:" as the first line. The headers then follow this line. This specification requires correct reverse mapping of this format, either from 1988 or 1984.
RFC822からX.400(1984)まで写像するとき、1988の特定の特徴で無駄をすることができます。 MTSレベルでそのような特徴の無駄をします。 IPMSレベルに1つの特徴を使用します、そして、これをRFC987アプローチに取り替えなければなりません。 通常、どんなCommentsと共にもrfc822見出しリスト拡張子に写像されるすべてのヘッダー情報: RFC822ヘッダーの分野はただ一つのIA5身体の部分に写像されます。(それは、メッセージで最初の身体の部分です)。 この身体の部分がストリングから始まる、「RFC822ヘッダー:」 1番目として、立ち並んでください。 そして、ヘッダーはこの系列の後をつけます。 この仕様は1988か1984年からこの形式の正しい逆のマッピングを必要とします。
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. The rfc-822-heading-list extension may be mapped according to this appendix.
RFC822が主要に重要である環境で、格下げに、メッセージがRFC822システムで溯源されて、この仕様通りに写像されたケースを考えるのは望ましいかもしれません。 この付録によると、rfc822見出しリスト拡張子は写像されるかもしれません。
When parsing std-or, the following restrictions must be observed:
または、分析する、std、-、以下の制限を観測しなければなりません:
- Only the 84/88 attributes identified in the table in
Section 4.2 are present.
- セクション4.2でテーブルで特定された84/88の属性だけが存在しています。
- No teletex encoding is allowed.
- テレテックスコード化は許されていません。
If an address violates this, it should be treated as an RFC 822 address, which will usually lead to encoding as a DDA "RFC-822".
アドレスがこれに違反するなら、それはRFC822アドレスとして扱われるべきです。(通常、それは、DDAとして"RFC-822"をコード化するのに通じるでしょう)。
It is possible that null attributes may be present in an O/R Address. This is not legal in 1988, except for ADMD where the case is explicitly described in Section 4.3.5. Null attributes are deprecated (the attribute should be omitted), and should therefore be unusual. However, some systems generate them and rely on them. Therefore, any null attribute shall be enoded using the std-or encoding (e.g., /O=/).
ヌル属性がO/R Addressに存在しているのは、可能です。 これはケースがセクション4.3.5で明らかに説明されるADMD以外の1988年に法的ではありません。 ヌル属性は、推奨しなく(属性は省略されるべきです)、したがって、珍しいはずです。 しかしながら、いくつかのシステムが、それらを生成して、それらを当てにします。 または、したがって、どんなヌル属性もenoded使用になる、std、-、(例えば、/o=/)をコード化します。
If a non-Teletex Common Name (CN) is present, it should be mapped onto a Domain Defined Attribute "Common". This is in line with RFC 1328 on X.400 1988 to 1984 downgrading [Hardcastle-K92].
非テレテックス俗称(CN)が存在しているなら、それはDomain Defined Attributeに「一般的に」写像されるべきです。 これは、[Hardcastle-K92]を格下げしながら、X.400 1988年から1984の上のRFC1328に沿ってあります。
Hardcastle-Kille [Page 105] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[105ページ]RFC1327マッピング
Appendix H - RFC 822 Extensions for X.400 access
付録H--X.400アクセスのためのRFC822Extensions
This appendix defines a number of optional mappings which may be provided to give access from RFC 822 to a number of X.400 services. These mappings are beyond the basic scope of this specification. There has been a definite demand to use extended RFC 822 as a mechanism to acccess X.400, and these extensions provide access to certain features. If this functionality is provided, this appendix shall be followed. The following headings are defined:
この付録はRFC822から多くのX.400サービスまでのアクセスを与えるために提供されるかもしれない多くの任意のマッピングを定義します。 これらのマッピングはこの仕様の基本的な範囲を超えています。 メカニズムとして拡張RFC822をacccess X.400に使用するという明確な要求がありました、そして、これらの拡大はある特徴へのアクセスを提供します。 この機能性を提供するなら、この付録に従うものとします。 以下の見出しは定義されます:
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "Content-Return" ":" prohibition
「敷衍された見出しは「不着損害レポートを防いでください」と等しい」:、」 「/、「配送がレポートであると生成してください」、」、:、」 「/「代替の受取人」」:、」 「禁止/、「受取人を明らかにする、」、」、:、」 「禁止/「満足しているリターン」」:、」 禁止
Prevent-NonDelivery-Report and Generate-Delivery-Report allow setting of MTS.PerRecipientSubmissionFields.originator-report-request. The setting will be the same for all recipients.
NonDeliveryレポートを防いでください。そうすれば、MTS.PerRecipientSubmissionFields.originatorが要求を報告していた状態で、Generate配送レポートは、セットするのを許容します。 設定はすべての受取人にとって同じになるでしょう。
Alternate-Recipient, Disclose-Recipients, and Content-Return allow for override of the default settings for MTS.PerMessageIndicators.
代替の受取人、Disclose-受取人、およびContent-リターンはMTS.PerMessageIndicatorsに関して既定の設定のオーバーライドを考慮します。
Appendix I - Conformance
付録I--順応
This appendix defines a number of options, which a conforming gateway should specify. Conformance to this specification shall not be claimed if any of the mandatory features are not implemented. In particular:
この付録は多くのオプションを定義します。(従うゲートウェイはオプションを指定するはずです)。 義務的な特徴のいずれも実装されないなら、この仕様への順応を要求しないものとします。 特に:
- Formats for all fields shall be followed.
- すべての分野への形式は続かれるものとします。
- Formats for subject lines, delivery reports and IPNs shall
be followed. A system which followed the syntax, but
translated text into a language other than english would be
conformant.
- 件名のための形式、配送レポート、およびIPNsは従われるものとします。 構文の、しかし、翻訳されたテキストに言語に従ったシステムはenglish以外のconformantでしょう。
- RFC 1137 shall not be followed when mapping to SMTP or to
JNT Mail
- SMTP、または、JNTメールに写像するとき、RFC1137に続かないものとします。
- All mappings of trace shall be implemented.
- 跡に関するすべてのマッピングが実装されるものとします。
- There must be a mechanism to access all three global
mappings.
- すべての3つのグローバルなマッピングにアクセスするメカニズムがあるに違いありません。
A gateway should specify:
ゲートウェイは指定するはずです:
Hardcastle-Kille [Page 106] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[106ページ]RFC1327マッピング
- Which 822-MTS protocols are supported. The relevant
appendices must be followed to claim support of a given
protocol: SMTP (A); JNT Mail (B); UUCP (C).
- 822-MTSプロトコルはサポートされます。 与えられたプロトコルのサポートを要求するために関連付録に従わなければなりません: SMTP(A)。 JNTは(B)を郵送します。 UUCP(C)。
- Which X.400 versions are supported (84 and/or 88).
- X.400バージョンはサポートされます(84、そして/または、88)。
- The means by which it can access the global mappings.
Currently, the tables of the formats define in Appendix F
is the only means available.
- それがグローバルなマッピングにアクセスできる手段。 現在、形式のテーブルは中でAppendixを定義します。Fによる唯一が利用可能であることを意味するということです。
- The approach taken when upper bounds are exceeded at the IPM
level (5.1.3)
- 上限がIPMレベルで超えられているとき取られたアプローチ(5.1.3)
- The approach taken to return of contents (5.2)
- コンテンツの復帰に取られたアプローチ(5.2)
- The approach taken to body parts which cannot be converted
(5.3.4)
- 変換できない身体の部分に取られたアプローチ(5.3.4)
- The approach taken to multiple copies vs non-disclosure
(4.6.2.2)
- 複本対非公開に取られたアプローチ(4.6.2.2)
The following are optional parts of this specification. A conforming implementation should specify which of these it supports.
↓これはこの仕様のオプショナル・パーツです。 従う実装は、それがこれらのどれをサポートするかを指定するべきです。
- Generation of extended RFC 822 fields is mandatory.
Optionally, they may be parsed and mapped back to X.400. A
gateway should should indicate if this is done.
- 拡張RFC822分野の世代は義務的です。 任意に、それらは、X.400に分析されて、写像して戻されるかもしれません。 ゲートウェイは示すべきです。これが完了しているかどうかを示すべきです。
- Support for the extension mappings of Appendix H.
- 拡大には、Appendix Hに関するマッピングをサポートしてください。
- Support for returning illegal format content in a delivery
report
- 配送レポートの戻っている不法な形式内容のサポート
- Which address interpretation heuristics are supported
(4.3.4.1)
- どのアドレス解釈発見的教授法がサポートされますか。(4.3.4.1)
- If RFC 987 generated message ids are handled in a backwards
compatible manner (4.7.3.6)
- メッセージイドであると生成されたRFC987が遅れているコンパチブル方法で扱われるなら(4.7.3.6)
Appendix J - Change History: RFC 987, 1026, 1138, 1148
付録J--歴史を変えてください: RFC987、1026、1138、1148
RFC 987 was the original document, and contained the key elements of this specification. It was specific to X.400(1984). RFC 1026 specified a small number of necessary changes to RFC 987.
RFC987は正本であり、この仕様の主要な要素を含みました。 それはX.400(1984)に特定でした。 RFC1026はRFC987への少ない数の必要な改革を指定しました。
RFC 1138 was based on the RFC 987 work. It contained an editorial error, and was reissued a few months later as RFC 1148. RFC 1148 will be referred to here, as it is the document which is widely
RFC1138はRFC987仕事に基づきました。 それは、編集の誤りを含んで、数カ月後にRFC1148として再発行されました。 RFC1148は、それが広くそうであるドキュメントであるので、ここと呼ばれるでしょう。
Hardcastle-Kille [Page 107] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[107ページ]RFC1327マッピング
referred to elsewhere. The major goal of RFC 1148 was to upgrade RFC 987 to X.400(1988). It did this, but did not obsolete RFC 987, which was recommended for use with X.400(1984). This appendix summarises the changes made in going from RFC 987 to RFC 1148.
ほかの場所に言及されます。 RFC1148の主要な目標はX.400(1988)にRFC987をアップグレードさせることでした。 RFC987(X.400(1984)との使用のために推薦されました)を時代遅れにしなかったのを除いて、それはこれをしました。 この付録はRFC987からRFC1148まで行く際に行われた変更について略言します。
RFC 1148 noted the following about its upgrade from RFC 987: 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.
RFC1148はアップグレードに関してRFC987から以下に注意しました: 通常、不要な変化は悪い考えです。 RFC822側の上の変化はできるだけ避けられます、822人のユーザがするRFCが、システムの任意の違いがこの仕様に従うことを確認して、ものがRFC987に続くことを確認しないように。 X.400側の上の変化は、最小となりますが、より許容できます、新しいサービスのセットへのマッピングとプロトコルのため。
1. Introduction
1. 序論
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
2. サービス要素
- The new service elements of X.400 are dealt with.
- X.400の新しいサービス要素は対処されています。
- A clear distinction is made between origination and
reception
- 創作とレセプションの間で明らかな区別をします。
3. Basic Mappings
3. 基本のマッピング
- Add teletex support
- テレテックスサポートを加えてください。
- Add object identifier support
- オブジェクト識別子サポートを加えてください。
- Add labelled integer support
- ラベルされた整数サポートを加えてください。
- Make PrintableString <-> ASCII mapping reversible
- PrintableString<->ASCIIマッピングをリバーシブルにしてください。
- The printable string mapping is aligned to the NBS mapping
derived from RFC 987.
- 印刷可能なストリングマッピングはRFC987から得られたNBSマッピングに並べられます。
4. Addressing
4. アドレシング
- Support for new addressing attributes
- 新しいアドレシング属性のサポート
- The message ID mapping is changed to not be table driven
- いずれテーブルの上に置くことであることのように動かされなかったなるようにメッセージIDマッピングを変えます。
Hardcastle-Kille [Page 108] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[108ページ]RFC1327マッピング
5. Detailed Mappings
5. 詳細なマッピング
- Define extended IPM Header, and use instead of second body
part for RFC 822 extensions
- 拡張IPM Header、および2番目の身体の部分の代わりにRFC822拡張子の使用を定義してください。
- Realignment of element names
- 要素名の再編成
- New syntax for reports, simplifying the header and
introducing a mandatory body format (the RFC 987 header
format was unusable)
- ヘッダーを簡素化して、義務的なボディー形式を導入するレポートのための新しい構文(RFC987ヘッダー形式は使用不可能でした)
- Drop complex autoforwarded mapping
- 複雑なautoforwardedマッピングを下げてください。
- Add full mapping for IP Notifications, defining a body
format
- IPのためにNotificationsを写像して、ボディー書式を定義して、いっぱいに加えてください。
- Adopt an MTS Identifier syntax in line with the O/R Address
syntax
- O/R Address構文に沿ってMTS Identifier構文を採用してください。
- A new format for X400 Trace representation on the RFC 822
side
- RFC822側におけるX400 Trace表現のための新しい形式
6. Appendices
6. 付録
- Move Appendix on restricted 822 mappings to a separate RFC
- 822の制限されたマッピングでAppendixを別々のRFCに動かしてください。
- Delete Phonenet and SMTP Appendixes
- PhonenetとSMTP付属物を削除してください。
Appendix K - Change History: RFC 1148 to this Document
付録K--歴史を変えてください: このDocumentへのRFC1148
1. General
1. 一般
- The scope of the document was changed to cover X.400(1984),
and so obsolete RFC 987.
- X.400(1984)、およびとても時代遅れのRFC987をカバーするためにドキュメントの範囲を変えました。
- Changes were made to allow usage to connect RFC 822 networks
using X.400
- 変更が、用法がRFC822ネットワークを接続するのをX.400を使用することで許容すると行われました。
- Text was tightened to be clear about optional and mandatory
aspects
- テキストは、任意の、そして、義務的な局面に関して明確になるようにきびしくされました。
- A good deal of clarification
- 多くの明確化
- A number of minor EBNF errors
- 多くの小さい方のEBNF誤り
- Better examples are given
- より良い例は出されます。
- Further X.400 upper bounds are handled correctly
- さらなるX.400上限は正しく扱われます。
Hardcastle-Kille [Page 109] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[109ページ]RFC1327マッピング
2. Basic Mappings
2. 基本のマッピング
- The encoding of object identifier is changed slightly
- オブジェクト識別子のコード化をわずかに変えます。
3. Addressing
3. アドレシング
- A global mapping of domain to preferred gateway is
introduced.
- 都合のよいゲートウェイへのドメインのグローバルなマッピングは紹介されます。
- An overflow mechanism is defined for RFC 822 addresses of
greater than 128 bytes.
- オーバーフローメカニズムは128バイト以上のRFC822アドレスのために定義されます。
- Changes were made to improve compatability with the PDAM on
writing O/R Addresses.
- 変更がO/R Addressesに書きながらPDAMとcompatabilityを改良すると行われました。
+ The PD and Terminal Type keywords were aligned to the
PDAM. It is believed that minimal use has been made of
the RFC 1148 keywords.
+ PDとTerminal TypeキーワードはPDAMに並べられました。 RFC1148キーワードで最小量の使用をしたと信じられています。
+ P and A are allowed as alternate keys for PRMD and ADMD
+ PとAはPRMDとADMDのための代替キーとして許容されています。
+ Where keywords are different, the PDAM keywords are
alternatives on input. This is mandatory.
キーワードが異なっている、PDAMキーワードが入力での代替手段である+。 これは義務的です。
4. Detailed Mappings
4. 詳細なマッピング
- The format of the Subject: lines is defined.
- Subject:の形式 系列は定義されます。
- Illegal use (repetition) of the heading EXTENSION is
corrected, and a new object identifier assigned.
- 見出しEXTENSIONの違法使用(反復)は直っていて、新しいオブジェクト識別子は割り当てられます。
- The Delivery Report format is extensively revised in light
of operational experience.
- Delivery Report形式は運用経験の観点から手広く改訂されます。
- The handling of redirects is significantly changed, as the
previous mechanism did not work.
- 取り扱い、向け直す、前のメカニズムが動作しなかったとき、かなり変えます。
5. Appendices
5. 付録
- An SMTP appendix is added, allowing optional use of the VRFY
command to improve probe information.
- 徹底的調査情報を改良するVRFYコマンドの任意の使用を許して、SMTP付録は加えられます。
- Handling of JNT Mail Acknowledge-To is changed slightly.
- JNTメールの取り扱い、Acknowledge、-、わずかに変えます。
- A DDA JNT-MAIL is allowed on input.
- DDA JNT-メールは入力のときに許容されています。
- The format definitions of Appendix F are explained further,
and a third table definition added.
- Appendix Fの形式定義はさらに説明されました、そして、3番目のテーブル定義は加えました。
Hardcastle-Kille [Page 110] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[110ページ]RFC1327マッピング
- An appendix on use with X.400(1984) is added.
- X.400(1984)と使用での付録は加えられます。
- Optional extensions are defined to give RFC 822 access to
further X.400 facilities.
- 任意の拡大は、X.400施設を促進するためにRFC822にアクセスを与えるために定義されます。
- An appendix on conformance is added.
- 順応での付録は加えられます。
References
参照
CCITT88a.
CCITT, "CCITT Recommendations X.408," Message Handling
Systems: Encoded Information Type Conversion Rules, December
1988.
CCITT88a。 CCITT、「CCITT推薦X.408」メッセージハンドリングシステム: コード化された情報型変換は1988年12月に統治されます。
CCITT/ISO88a.
CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
Message Handling: System and Service Overview , December
1988.
CCITT/ISO88a。 CCITT/ISO、「CCITT推薦X.400/ ISOは10021-1です」、メッセージハンドリング: システムとサービス概要、1988年12月。
CCITT/ISO88b.
CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7,"
Message Handling Systems: Interpersonal Messaging System,
December 1988.
CCITT/ISO88b。 CCITT/ISO、「CCITT推薦X.420/ ISOは10021-7です」、メッセージハンドリングシステム: 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, December 1988.
CCITT/ISO88c。 CCITT/ISO、「CCITT推薦X.411/ ISOは10021-4です」、メッセージハンドリングシステム: メッセージ転送システム: 抽象的なサービス定義と手順、1988年12月。
CCITT/ISO88d.
CCITT/ISO, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December
1988.
CCITT/ISO88d。 CCITT/ISO、「抽象構文記法1の仕様(ASN.1)」、X.208 / ISOが8824、1988年12月というCCITT推薦。
CCITT/ISO91a.
CCITT/ISO, "Representation of O/R Addresses for Human
Usage," PDAM to CCITT X.401 / ISO/IEC 10021-2, February
1991.
CCITT/ISO91a。 CCITT/ISO、「人間の用法のためのO/Rアドレスの表現」、CCITT X.401/ISO/IEC10021-2へのPDAM、1991年2月。
Crocker82a.
Crocker, D., "Standard of the Format of ARPA Internet Text
Messages," RFC 822, UDEL, August 1982.
Crocker82a。 クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、UDEL、1982年8月。
Hardcastle-K92.
Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
1328, UCL, May 1992.
Hardcastle-K92。 Hardcastle-Kille、S.、「X.400 1988年から1984格下げ」、RFC1328、UCL、1992年5月。
Hardcastle-Kille [Page 111] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[111ページ]RFC1327マッピング
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," UCL
Research Note 89/14, March 1989.
Kille89a。 Kille、S.、「プレゼンテーションアドレスをコード化するストリング」、UCL研究注意89/14、1989年3月。
Kille89b.
Kille, S., "Mapping between full RFC 822 and RFC 822 with
restricted encoding," RFC 1137, October 1989.
Kille89b。 Kille、S.、「完全なRFC822と部外秘なコード化があるRFC822の間のマッピング」、RFC1137、1989年10月。
Kille90a.
Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822," RFC 1148, March 1990.
Kille90a。 Kille、S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1148、3月1990日
Larmouth83a.
Larmouth, J., "JNT Name Registration Technical Guide,"
Salford University Computer Centre, April 1983.
Larmouth83a。 Larmouth、J.、「JNT名前の登録の技術ガイド」、ソルフォード大学コンピュータセンター、1983年4月。
Postel84a.
Postel J., and J. Reynolds, "Domain Requirements," RFC 920,
USC/Information Sciences Institute, October 1984.
Postel84a。 ポステルJ.、J.レイノルズ、「ドメイン要求性」、USC/情報科学が1984年10月に設けるRFC920。
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月。
Hardcastle-Kille [Page 112] RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
X.400(1988)とRFC822 1992年5月の間のHardcastle-Kille[112ページ]RFC1327マッピング
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。 1985年10月のプライベート・メッセージ取り扱いシステム、「機能標準A/3222」、CEN/CLC/IT/WG/PMHS N17のCEN/CENELEC/情報技術/作業部会。
SECURITY CONSIDERATIONS
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
AUTHOR'S ADDRESS
作者のアドレス
Steve Hardcastle-Kille Department of Computer Science University College London Gower Street WC1E 6BT England
スティーブHardcastle-Killeコンピュータサイエンス学部ユニバーシティ・カレッジロンドンWC1E 6BTイギリスガウアー・ストリート
Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK
以下に電話をしてください。 +44-71-380-7294 メールしてください: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille [Page 113]
Hardcastle-Kille[113ページ]
一覧
スポンサーリンク
