RFC2156 日本語訳
2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400and RFC 822/MIME. S. Kille. January 1998. (Format: TXT=280385 bytes) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) (Updates RFC0822) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kille Request for Comments: 2156 Isode Ltd. Obsoletes: 987, 1026, 1138, 1148, 1327, 1495 January 1998 Updates: 822 Category: Standards Track
Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2156Isode Ltd.は以下を時代遅れにします。 987、1026、1138、1148、1327、1495 1998年1月は以下をアップデートします。 822カテゴリ: 標準化過程
MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME
ミキサー(パントマイムインターネットX.400はリレーを機能アップしました): X.400とRFC822/MIMEの間のマッピング
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1 - Overview ...................................... 3 1.1 - X.400 ......................................... 3 1.2 - RFC 822 and MIME .............................. 3 1.3 - The need for conversion ....................... 4 1.4 - General approach .............................. 4 1.5 - Gatewaying Model .............................. 5 1.6 - Support of X.400 (1984) ....................... 8 1.7 - X.400 (1992) .................................. 8 1.8 - MIME .......................................... 8 1.9 - Body Parts .................................... 8 1.10 - Local and Global Scenarios .................... 9 1.11 - Compatibility with previous versions .......... 10 1.12 - Aspects not covered ........................... 10 1.13 - Subsetting .................................... 11 1.14 - Specification Language ........................ 11 1.15 - Related Specifications ........................ 11 1.16 - Document Structure ............................ 12 1.17 - Acknowledgements .............................. 12 2 - Service Elements .............................. 13 2.1 - The Notion of Service Across a Gateway ........ 13 2.2 - RFC 822 ....................................... 15 2.3 - X.400 ......................................... 18 3 - Basic Mappings ................................ 27 3.1 - Notation ...................................... 27
1--、概観… 3 1.1--、X.400… 3 1.2--RFC822とMIME… 3 1.3--変換の必要性… 4 1.4--一般アプローチ… 4 1.5--モデルをGatewayingします… 5 1.6--X.400(1984)のサポート… 8 1.7--X.400(1992)… 8 1.8--まねてください… 8 1.9--、ボディ・パーツ… 8 1.10(ローカルとグローバルなシナリオ)… 9 1.11--、旧バージョンとの互換性… 10 1.12--、カバーされなかった局面… 10 1.13--Subsettingします… 11 1.14--仕様言語… 11 1.15--仕様を話します… 11 1.16--構造を記録してください… 12 1.17--、承認… 12 2--Elementsにサービスを提供してください… 13 2.1--ゲートウェイの向こう側のサービスの概念… 13 2.2--RFC822… 15 2.3--、X.400… 18 3--基礎マッピング… 27 3.1--、記法… 27
Kille Standards Track [Page 1] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[1ページ]。
3.2 - ASCII and IA5 ................................. 29
3.3 - Standard Types ................................ 29
3.4 - Encoding ASCII in Printable String ............ 33
3.5 - RFC 1522 ...................................... 34
4 - Addressing and Message IDs .................... 35
4.1 - A textual representation of MTS.ORAddress ..... 36
4.2 - Global Address Mapping ........................ 43
4.3 - EBNF.822-address <-> MTS.ORAddress ............ 46
4.4 - Repeated Mappings ............................. 59
4.5 - Directory Names ............................... 62
4.6 - MTS Mappings .................................. 62
4.7 - IPMS Mappings ................................. 67
5 - Detailed Mappings ............................. 71
5.1 - RFC 822 -> X.400: Detailed Mappings ........... 71
5.2 - Return of Contents ............................ 86
5.3 - X.400 -> RFC 822: Detailed Mappings ........... 86
Appendix A - Mappings Specific to SMTP ..................... 114
1 - Probes ........................................ 114
2 - Long Lines .................................... 114
3 - SMTP Extensions ............................... 114
3.1 - SMTP Extension mapping to X.400 ............... 114
3.2 - X.400 Mapping to SMTP Extensions .............. 115
Appendix B - Mapping with X.400(1984) ...................... 116
Appendix C - RFC 822 Extensions for X.400 access ........... 118
Appendix D - Object Identifier Assignment .................. 119
Appendix E - BNF Summary ................................... 120
Appendix F - Text format for MCGAM distribution ............ 127
1 - Text Formats .................................. 127
2 - Mechanisms to register and to distribute
MCGAMs ........................................ 127
3 - Syntax Definitions ............................ 128
4 - Table Lookups ................................. 129
5 - Domain -> OR Address MCGAM format ............. 129
6 - OR Address -> Domain MCGAM format ............. 129
7 - Domain -> OR Address of Preferred Gateway
table ......................................... 130
8 - OR Addresss -> domain of Preferred Gateway
table ......................................... 130
Appendix G - Conformance ................................... 131
Appendix H - Change History: RFC 987, 1026, 1138, 1148
............................................... 133
1 - Introduction .................................. 133
2 - Service Elements .............................. 133
3 - Basic Mappings ................................ 133
4 - Addressing .................................... 134
5 - Detailed Mappings ............................. 134
6 - Appendices .................................... 134
Appendix I - Change History: RFC 1148 to RFC 1327 .......... 135
3.2--、ASCIIとIA5… 29 3.3--標準のタイプ… 29 3.4--印刷可能なストリングのASCIIをコード化します… 33 3.5--RFC1522… 34 4--アドレシングとメッセージID… 35 4.1--MTS.ORAddressの原文の表現… 36 4.2--グローバルアドレスマッピング… 43 4.3--EBNF.822-アドレス<->MTS.ORAddress… 46 4.4--マッピングを繰り返します… 59 4.5--、ディレクトリ名… 62 4.6 --MTSマッピング… 62 4.7 --IPMSマッピング… 67 5--マッピングを詳しく述べます… 71 5.1--RFC822->X.400: マッピングを詳しく述べます… 71 5.2--コンテンツの復帰… 86 5.3--X.400->RFC822: マッピングを詳しく述べます… 86 付録A(SMTPに特定のマッピング)… 114 1--調べます… 114 2--長い線… 114 3--SMTP拡張子… 114 3.1--X.400へのSMTP Extensionマッピング… 114 3.2--SMTP拡張子へのX.400マッピング… 115 付録B--X.400(1984)と共に写像します。 116 付録C--X.400アクセスのためのRFC822Extensions… 118 付録D--物の識別子課題… 119 付録E--BNF概要… 120 付録F--MCGAM分配のためのテキスト形式… 127 1--テキスト形式… 127、2--、登録して、MCGAMsを分配するメカニズム… 127 3--構文定義… 128 4--ルックアップを見送ってください… 129 5--ドメイン->OR Address MCGAM形式… 129 6--OR Address->Domain MCGAM形式… 129 7--Preferredゲートウェイテーブルのドメイン->OR Address… 130 8--PreferredゲートウェイテーブルのOR Addresss->ドメイン… 130付録G--、順応… 131 付録H--歴史を変えてください: RFC987、1026、1138、1148… 133、1--、序論… 133 2--Elementsにサービスを提供してください… 133 3--基礎マッピング… 133 4--記述します。 134 5--マッピングを詳しく述べます… 134、6--、付録… 134 付録I--歴史を変えてください: RFC1148からRFC1327… 135
Kille Standards Track [Page 2] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[2ページ]。
1 - General ....................................... 135
2 - Basic Mappings ................................ 135
3 - Addressing .................................... 135
4 - Detailed Mappings ............................. 135
5 - Appendices .................................... 136
Appendix J - Change History: RFC 1327 to this Document
............................................... 137
1 - General ....................................... 137
2 - Service Elements .............................. 137
3 - Basic Mappings ................................ 137
4 - Addressing .................................... 137
5 - Detailed Mappings ............................. 138
6 - Appendices .................................... 138
Appendix L - ASN.1 Summary ................................. 139
Security Considerations .................................... 141
Author's Address ........................................... 141
References ................................................. 141
Full Copyright Statement ................................... 144
1--、一般… 135 2--基礎マッピング… 135 3--記述します。 135 4--マッピングを詳しく述べます… 135、5--、付録… 136 付録J--歴史を変えてください: このDocumentへのRFC1327… 137、1--、一般… 137 2--Elementsにサービスを提供してください… 137 3--基礎マッピング… 137 4--記述します。 137 5--マッピングを詳しく述べます… 138、6--、付録… 138 付録L--ASN.1概要… 139 セキュリティ問題… 141作者のアドレス… 141の参照箇所… 141 完全な著作権宣言文… 144
Chapter 1 -- Overview
第1章--概観
1.1. X.400
1.1. X.400
This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. Any reference to the 1984 Recommendations will be explicit. Any mappings relating to elements which are in the 1992 version and not in the 1988 version will be noted explicitly. 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, such as EDI as defined in X.435.
このドキュメントは主としてITU-T1988と1992X.400 Series Recommendations / ISO IECに10021の国際Standardを関係づけます。 このITU ISO/T規格は本書では"X.400"と呼ばれます。(それは、便利な速記です)。 1984Recommendationsのどんな参照も明白になるでしょう。 どんなマッピングも、1992年のバージョンにある要素に関連して、1988年のバージョンに明らかに述べられないでしょう。 店と前進のMessage Transfer Systemを利用して、X.400はInterpersonal Messaging System(IPMS)を定義します。 このドキュメントはX.435で定義されるEDIなどのX.400の、より広いアプリケーションではなく、IPMSに関係します。
1.2. RFC 822 and MIME
1.2. RFC822とMIME
RFC 822 evolved as a messaging standard on the DARPA (the US Defense Advanced Research Projects Agency) Internet. RFC 822 specifies an end to end message format, consisting of a header and an unstructured text body. MIME (Multipurpose Internet Mail Extensions) specifies a structured message body format for use with RFC 822. The term "RFC 822" is used in this document to refer to the combination of MIME and RFC 822. RFC 822 and MIME are used in conjunction with a number of different message transfer protocol environments. The core of the MIXER specification is designed to work with any supporting message transfer protocol.
RFC822はメッセージングとしてDARPAの標準(米国国防高等研究計画庁)のインターネットを発展しました。 ヘッダーと不統一なテキスト本文から成って、RFC822は、メッセージ・フォーマットを終わらせるために終わりを指定します。 MIME(マルチパーパスインターネットメールエクステンション)はRFC822との使用のための構造化されたメッセージボディー形式を指定します。 「RFC822」という用語は、MIMEとRFC822の組み合わせについて言及するのに本書では使用されます。 RFC822とMIMEは多くの異なったメッセージ転送プロトコル環境に関連して使用されます。 MIXER仕様のコアは、いずれもメッセージ転送プロトコルをサポートしていて働くように設計されています。
Kille Standards Track [Page 3] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[3ページ]。
One transfer protocol, SMTP, is of particular importance and is covered in MIXER. On the Internet and other TCP/IP networks, RFC 822 is used in conjunction with RFC 821, also known as Simple Mail
1つの転送プロトコル(SMTP)が、特別の重要性があって、MIXERでカバーされています。 インターネットと他のTCP/IPネットワークでは、RFC822はRFC821に関連して使用されて、また、Simpleメールとして知られています。
Transfer Protocol (SMTP) [30], in a manner conformant with the host requirements specification [10]. Use of MIXER with SMTP is defined in Appendix A.
方法conformantでホスト要件仕様[10]でプロトコル(SMTP)[30]を移してください。 SMTPとのMIXERの使用はAppendix Aで定義されます。
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 between the different technologies, 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 mapping between RFC 822 and X.400. This is standard usage amongst mail implementors, but differs from that used by transport and network service implementors.
また、これはケースで中共同体が異なった技術の間で変遷をするつもりである要件になるでしょう、変換が滑らかなサービス変遷を確実にするのに必要であるときに。メールサービスにRFC822に基づいているプロトコルを使用する大きい共同体があります。(共同体はX.400システムによって提供されたIPMSのユーザとコミュニケートしたくなるでしょう)。 複数のゲートウェイがあると予想されて、この仕様は、彼らが一貫した態度で振る舞うのを可能にするでしょう。 用語ゲートウェイがRFC822とX.400の間のマッピングを実行するコンポーネントについて説明するのに使用されることに注意してください。 これは、メール作成者の中の標準的用法ですが、輸送とネットワーク・サービス作成者によって使用されたそれと異なっています。
Consistency between gateways is desirable to provide:
ゲートウェイの間の一貫性は提供するのにおいて望ましいです:
1. Consistent service to users.
1. ユーザに対する一貫したサービス。
2. The best service in cases where a message passes through
multiple gateways.
2. メッセージが複数のゲートウェイを通り抜ける場合で最も良いサービス。
1.4. General approach
1.4. 一般的方法
There are a number of basic principles underlying the details of the specification. These principles are goals, and are not achieved in all aspects of the specification.
仕様の細目の基礎となる多くの基本原理があります。 これらの原則は、目標であり、仕様の全面で達成されません。
1. The specification should be pragmatic. There should not be
a requirement for complex mappings for "Academic" reasons.
Complex mappings should not be required to support trivial
additional functionality.
1. 仕様は実践的であるべきです。 「アカデミックな」理由による複雑なマッピングのための要件があるべきではありません。 些細な追加機能性を支持するために複雑なマッピングを必要とするべきではありません。
2. Subject to 1), functionality across a gateway should be as
high as possible.
2. 1)を条件として、ゲートウェイの向こう側の機能性はできるだけ高いはずです。
3. It is always a bad idea to lose information as a result of
any transformation. Hence, it is a bad idea for a gateway
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
3. いつもどんな変化の結果、情報を失うのは、悪い考えです。 したがって、ゲートウェイがそれが処理する物で情報を捨てるのは、悪い考えです。 これは完全に写像できるというわけではない要求されたサービスを含んでいます。
Kille Standards Track [Page 4] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[4ページ]。
4. Mail gateways operate at a level above the layer on which
they perform mappings. This implies that the gateway shall
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. メール・ゲートウェイはそれらがマッピングを実行する層を超えたレベルで作動します。 これは、ゲートウェイが単にゲートウェイレベルにおいて物の意味論で認識力があるのではなく、より高い平らな意味論において認識力がありもするのを含意します。 ゲートウェイが作動させる物の重要な変化が起こるつもりであるなら、ゲートウェイは、物自体より分かる必要があります。
5. Subject to 1), the mapping 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 , [11] which comprises of three basic services:
X.400はX.420、3で基本サービスを包括する[11]で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 forwarded Interpersonal 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ファックス)身体の部分の系列として構造化するか、またはInterpersonal Messagesを進めます。 見出しはエンドユーザ情報の受けることがあって、第一の受取人などの終わり(To:)、および重要性を含む分野から成ります。
2. IPN (Inter Personal Notification). A notification about
receipt of a given IPM at the UA level.
2. IPN(間の個人的な通知)。 UAレベルにおける与えられたIPMの領収書に関する通知。
The Origination service also allows for origination of a probe, which is an object to test whether a given IPM could be correctly received.
また、正しく与えられたIPMを受け取ることができたか否かに関係なく、Originationサービスは、物である徹底的調査の創作がテストされるのを許容します。
The Reception service also allows for receipt of Delivery Reports (DR), which indicate delivery success or failure.
また、ReceptionサービスはDelivery Reports(DR)の領収書を考慮します。(Delivery Reportsは配送成否を示します)。
Kille Standards Track [Page 5] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[5ページ]。
These IPMS Services utilise the Message Transfer System (MTS) Abstract Service [12]. The MTS Abstract Service provides the following three basic services:
これらのIPMS ServicesはMessage Transfer System(MTS)の抽象的なService[12]を利用します。 MTSの抽象的な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). The Envelope includes a message identifier, an originator, and a list of recipients. Submission also includes the probe service, which supports the MTS Probe. Delivery also includes Reports, which indicate whether a given MTS Message has been delivered or not (or for a probe if delivery would have happened).
政権は、ローカルの問題であるのでこの規格に影響しません。 服従と配送は主としてMTS Message(Envelopeを包括して、Content)に関連します。(MTS MessageはIPMかIPN(または、他の非解釈されたコンテンツ)を運びます)。 Envelopeはメッセージ識別子、創始者、および受取人のリストを含んでいます。 また、服従は徹底的調査サービスを含んでいます。(それは、MTS Probeを支持します)。 また、配送はReportsを含んでいます(徹底的調査が配送であるなら起こったでしょう、したがって)。(Reportsは、与えられたMTS Messageが届けられたかどうかを示します)。
The MTS is provided by MTAs which interact using 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はMTAsの間の相互作用を定義するMTA(メッセージTransferエージェント)サービスを利用することで相互作用する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.
RFC822ヘッダーの中に2を)達成するのは可能です。
This specification will be used most commonly with SMTP as the 822- MTS service. The core MIXER specification is written so that it does not rely on non-basic 822-MTS services. Use of non-basic SMTP services is described in Appendix A. The core of this document is written using SMTP terminology for 822-MTS services.
この仕様はSMTPと共に822MTSサービスとして最も一般的に使用されるでしょう。 コアMIXER仕様が書かれているので、それは非基本的な822-MTSサービスに依存しません。 非基本的なSMTPサービスの使用は、このドキュメントのコアが書かれているAppendix A.で822-MTSサービスにSMTP用語を使用することで説明されます。
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 IPM
RFC822メッセージは非解釈されたASCIIテキストであるヘッダー、および内容から成ります。 ヘッダーは分野に分割されます。(分野はプロトコル要素です)。 これらの分野の大部分はIPMに類似しています。
Kille Standards Track [Page 6] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[6ページ]。
heading fields, although some are analogous to MTS Service Elements or MTA Service Elements.
或るものはMTS Service ElementsかMTA Service Elementsに類似していますが、分野の上に立ちます。
RFC 822 supports delivery status notifications by use of the NOTARY mechanisms [28].
RFC822はNOTARYメカニズム[28]の使用で配送状態通知を支持します。
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 SMTP (822-MTS) service mapping onto the MTS Service Elements and RFC 822 mapping onto an IPM, but there is a not a clear match between these services. Another elegant approach would be to treat this document as the definition of an X.400 Access Unit (AU). In this case, the abstraction level is too high, and some necessary mapping function is lost. 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 + SMTP 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つのサービスのこの機能的な記述を考えて、現在、ゲートウェイの機能的な自然を考えることができます。 SMTP(822-MTS)がサービス対応表であるとIPMへのMTS Service ElementsとRFC822マッピングと考えるのが上品でしょうが、これらのサービスの間の明確なマッチではなく、aがあります。 別の上品なアプローチはX.400 Access Unit(AU)の定義としてこのドキュメントを扱うだろうことです。 この場合、抽象度は高過ぎます、そして、何らかの必要なマッピング機能が無くなっています。 半面の上のIPM形式定義、IPMS Service Elements、MTS Service Elements、およびMTA Service Elementsがもう片方でわずかにもつれている方法でRFC822+SMTPに写像されると考えるのが必要です。 もつれの詳細は第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 SMTP information is always mapped into an IPM (MTA, MTS, and IPMS Services) and a Delivery Status Notification is mapped onto a Report. Going from X.400 to RFC 822, an RFC 822 message and the associated SMTP information may be derived from:
以下の基本のマッピングはこのようにして定義されます。 RFC822からX.400まで行くとき、RFC822メッセージと関連SMTP情報はいつもIPM(MTA、MTS、およびIPMS Services)に写像されます、そして、Delivery Status NotificationはReportに写像されます。 RFC822、RFC822メッセージ、およびX.400から関連SMTP情報まで行くのは以下から引き出されるかもしれません。
1. An IPN (MTA, MTS, and IPMS services)
1. IPN(MTA、MTS、およびIPMSサービス)
2. An IPM (MTA, MTS, and IPMS services)
2. IPM(MTA、MTS、およびIPMSサービス)
A Report (MTA, and MTS Services) is mapped onto a delivery status notification.
Report(MTA、およびMTS Services)は配送状態通知に写像されます。
Probes (MTA Service) shall 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 shall be rejected at the gateway if no other gatewaying procedure is defined.
徹底的調査(MTA Service)は第5章で議論するようにゲートウェイによって処理されるものとします。 IPMSによって定義されたもの以外のContent Typesを含むMTS Messagesはゲートウェイによって写像されないで、他のgatewaying手順が全く定義されないなら、ゲートウェイで拒絶されるものとします。
This specification is concerned with X.400 IPMS. Future specifications may defined mappings for other X.400 content types.
この仕様はX.400 IPMSに関係があります。将来の仕様は他のX.400の満足しているタイプへの定義されたマッピングがそうするかもしれません。
Kille Standards Track [Page 7] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[7ページ]。
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を使用したがっているかもしれません、そして、これは完全に支持されます。
Where an X.400 message 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.
X.400メッセージがRFC822と、そして、そして、X.400に移して戻られるところには、これがいくつかの場合可能であるかもしれませんが、保存される標準のRFC822に同等なサービスを持っていないX.400サービスへの期待が全くありません。
1.6. Support of X.400 (1984)
1.6. X.400のサポート(1984)
The MIXER definition 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. The core MIXER mapping is defined using 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. To interwork with 1984 systems, Appendix B shall be followed.
MIXER定義がRFC987の初期の仕様に基づいたその付加物RFC1026にあります。(それは、X.400(1984)とRFC822の間のマッピングを定義しました)。 コアMIXERマッピングは、1988年の1984年のコンパチブル部分集合ではなく、X.400の完全なバージョンを使用することで定義されます。 RFC987で定義されたそれよりはるかに清潔なマッピングを提供するのにX.400(1988)に関する新機能を使用できます。 1984でシステムを織り込むために、Appendix Bは続かれるものとします。
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 B, than to downgrade without this knowledge. Downgrading specifications which supplement those specified in X.400 (X.419) are given in RFC 1328 [22] and RFC 1496 (HARPOON) [5].
X.400(1988)MTAを通してX.400(1984)システムにメッセージを移していると、Appendix Bの規則に従うためにわずかに良いサービスを与えるでしょう、この知識なしで格下げするより。 ものがX.400でそれの補足を指定した仕様を格下げして、RFC1328[22]とRFC1496(HARPOON)[5]で(X.419)を与えます。
1.7. X.400 (1992)
1.7. X.400(1992)
X.400 (1992) features are not used by the core of this mapping, and so there is not an equivalent downgrade problem.
X.400(1992)の特徴がこのマッピングのコアによって使用されないので、そして、同等なダウングレード問題がありません。
1.8. MIME
1.8. MIME
MIME format messages are generated by this mapping. As MIME messages are fully RFC 822 compliant, this will not cause problems with systems which are not MIME capable.
MIME形式メッセージはこのマッピングで発生します。 MIMEメッセージが完全にRFC822対応であるときに、これはできるMIMEでないシステムで問題を起こさないでしょう。
Kille Standards Track [Page 8] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[8ページ]。
1.9. Body Parts
1.9. ボディ・パーツ
MIME and X.400 IPMS can both carry arbitrary body parts. MIME defines a mechanism for adding new body parts, and new body parts are registered with the IANA. X.400 defines a mechanism adding new body parts, usually referred to as Body Part 15. Extensions are defined by Object Identifiers, so there is no requirement for a central body part registration authority. The Electronic Messaging Association (EMA) maintains a list of some commonly used body parts. The EMA has specified a mechanism to use the File Transfer Body Part (FTBP) as a more generic means to support message attachments. This approach is gaining widespread commercial support.
MIMEとX.400 IPMSはともに任意の身体の部分を運ぶことができます。 MIMEは新しい身体の部分を加えるためにメカニズムを定義します、そして、新しい身体の部分はIANAに示されます。 X.400は通常、Body Part15と呼ばれた新しい身体の部分を加えるメカニズムを定義します。 拡大がObject Identifiersによって定義されるので、中央のボディー部分登録局のための要件が全くありません。 Electronic Messaging Association(EMA)は、いくつかのリストが一般的に身体の部分を使用したと主張します。 EMAは、メッセージ付属を支持するより一般的な手段としてFile Transfer Body Part(FTBP)を使用するためにメカニズムを指定しました。 このアプローチは広範囲の商業サポートを獲得しています。
The mapping between X.400 and MIME body parts is defined in the companion MIXER specification, referenced here as RFC 2157 [8]. This document is an update of RFC 1494 [6].
X.400とMIME身体の部分の間のマッピングはRFC2157[8]としてここで参照をつけられた仲間MIXER仕様に基づき定義されます。 このドキュメントはRFC1494[6]の最新版です。
Editor's Note:
References to 2157 will be resolved as these two
documents are expected to progress in parallel.
編集者注: これらの2通のドキュメントが平行で進歩をすると予想されるとき、2157の参照は決議されるでしょう。
These two specifications together form the complete MIXER Mapping.
一緒にこれらの2つの仕様が完全なMIXER Mappingを形成します。
1.10. Local and Global Scenarios
1.10. 地方の、そして、グローバルなシナリオ
There are two basic scenarios for X.400/MIME interworking:
X.400/MIMEの織り込む2つの基本的なシナリオがあります:
Global Scenario
グローバルなシナリオ
There are two global mail networks (Internet/MIME and X.400),
interconnected by multiple gateways. Objects may be transferred
over multiple gateways, and so it is important that gateways
behave in a coherent fashion. MIXER is critical to support this
scenario.
複数のゲートウェイによってインタコネクトされた2つのグローバルなメールネットワーク(インターネット/MIMEとX.400)があります。 複数のゲートウェイの上に物を移すかもしれないので、ゲートウェイが論理的なファッションで振る舞うのは、重要です。 MIXERは、このシナリオを支持するために重要です。
Local Scenario
ローカルのシナリオ
A gateway is used to connect a closed community to a global mail
network (this could be enforced by connectivity or gateway
authorisation policy). This is a common commercial scenario.
MIXER is useful to support this scenario, as it allows an industry
standard provision of service, but this could be supported by
something which was MIXER-like.
ゲートウェイは、グローバルなメールネットワークに閉じている共同体をつなげるのに使用されます(接続性かゲートウェイ認可方針でこれを実施できるでしょう)。 これは一般的な商業シナリオです。 サービスの業界基準支給を許すとき、MIXERはこのシナリオを支持するために役に立ちますが、MIXERの何かようであったものはこれを支持できました。
A solution for the global scenario will work for the local scenario. However, there are aspects of MIXER which have significant implementation or deployment effort (the global mapping is the major one, but there are other details too) which and are needed to support
グローバルなシナリオの解決はローカルのシナリオに効き目があるでしょう。 しかしながら、重要な実現か展開の努力を持っているMIXERの局面がある、(グローバルなマッピングは主要なものですが、他の詳細もあります)どれ、サポートに必要であるか。
Kille Standards Track [Page 9] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[9ページ]。
the global scenario, but are not needed in the local scenario.
グローバルなシナリオ、ローカルのシナリオでは、必要ではありません。
Note that the local scenario may be the driving force for most deployments, and support of the global scenario may be an important secondary goal.
ローカルのシナリオがほとんどの展開のための原動力であるかもしれないことに注意してください。そうすれば、グローバルなシナリオのサポートは重要な二次目標であってもよいです。
There is also a transition effect. Gateways which are initially deployed in a strict local scenario situation start to find themselves in a global scenario. A common case is ADMD provided gateways, which are targeted strictly at the local scenario. In practice they soon start to operate in the global scenario, because of distribution lists and messages exchanged with X.400 users that are not customers of the ADMD. At this point, users are hurt by the restrictions of a local scenario gateway.
また、変遷効果があります。 気付くと、初めは厳しい地方のシナリオ状況で配備されるゲートウェイがグローバルなシナリオにい始めます。 よくある例はADMDがゲートウェイを提供したということです。(ゲートウェイはローカルのシナリオで厳密に狙います)。 実際には、彼らはすぐグローバルなシナリオで作動し始めます、ADMDの顧客でないX.400ユーザと共に交換された発送先リストとメッセージのために。 ここに、ユーザは地方のシナリオゲートウェイの制限で傷ついています。
Note that conformance to MIXER applies to an instantiation of a gateway, not just an implementation (although clearly it is critical that the implementation is capable of being operated in a conformant manner).
MIXERへの順応が実現だけではなく、ゲートウェイの具体化に適用されることに注意してください(実現がconformant方法で操作できるのが、明確に批判的ですが)。
MIXER's conformance target is the global scenario, and the specification of MIXER defines operation in this way.
MIXERの順応目標はグローバルなシナリオです、そして、MIXERの仕様はこのように操作を定義します。
1.11. Compatibility with previous versions
1.11. 旧バージョンとの互換性
The changes between this and older versions of the document are given in Appendices H, I and J. These are RFCs 987, 1026, 1138, 1148 and 1327. This document is a revision of RFC 1327 [21]. As far as possible, changes have been made in a compatible fashion.
私とJ.TheseはAppendices Hでドキュメントのこれと旧式のバージョンの間の変化を与えて、RFCs987、1026と、1138と、1148と1327です。 このドキュメントはRFC1327[21]の改正です。 できるだけ、変更はコンパチブルファッションで行われました。
1.12. Aspects not covered
1.12. カバーされなかった局面
There have been a number of cases where previous versions of this document were 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:
件数がこのドキュメントの旧バージョンが意図しなかった方法で使用されたところにありました。 このセクションは範囲のいくつかの限界を明らかにすることになっています。 特に、この仕様は指定しません:
- Extensions of RFC 822 to provide access to all X.400
services
- 提供するRFC822の拡大はすべてのX.400にサービスにアクセスします。
- X.400 user interface definition
- X.400ユーザーインタフェース定義
These are really coupled. To map the X.400 services, this specification defines a number of extensions to RFC 822. As a side effect, these give the 822 user access to SOME X.400 services. However, the aim on the RFC 822 side is to preserve current service, and it is intentional that access is not given to all X.400 services. Thus, it will be a poor choice for X.400 implementors to use MIXER as
これらは本当に結合されます。 X.400サービスを写像するために、この仕様は多くの拡大をRFC822と定義します。 副作用として、これらはSOME X.400サービスへの822ユーザアクセスを与えます。 しかしながら、RFC822側の上の目的が当期の勤務を保持すること的であり、アクセスがすべてのX.400サービスに与えられていないのは、意図的です。 したがって、それはX.400作成者がMIXERを使用するように特選している貧乏人になるでしょう。
Kille Standards Track [Page 10] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[10ページ]。
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 C.
インタフェース--それを通してアクセスできないX.400のあまりに多くの局面があります。 テキストインタフェースが望まれているなら、RFC822制限なしでX.400をターゲットにした仕様は、より適切でしょう。 この領域でのいくつかの任意の、そして、限られた拡大が、有用であることが分かって、Appendix Cで定義されます。
1.13. Subsetting
1.13. 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 non-conformant and strongly discouraged.
この提案は既存のRFC822共同体にサービスを保持するのが適切なマッピングを指定します。 実現、仕様がどの部分集合をがっかりさせるか、この仕様は、非conformantであって強くがっかりしています。
1.14. Specification Language
1.14. 仕様言語
ISO and Internet standards have clear definitions as to the style of language used. This specification maps between ISO/ITU-T protocol and Internet protocols. This document uses ISO terminology for the following reasons:
ISOとインターネット標準で、言語のスタイルに関する明確な定義を使用します。 この仕様はITU ISO/Tプロトコルとインターネットの間でプロトコルを写像します。 このドキュメントは以下の理由にISO用語を使用します:
1. This was done in previous versions.
1. 旧バージョンではこれをしました。
2. ISO language may be mechanically converted to Internet
language, but not vice versa.
2. ISO言語は、機械的にインターネット言語に変換されますが、逆もまた同様に変換されるかもしれないというわけではありません。
The key elements of the ISO rules are:
ISO規則の主要な原理は以下の通りです。
1. All mandatory features shall clearly be indicated by
imperative statements or the word "shall" or "shall not".
1. すべての義務的な特徴が単語の無条件命令、“shall"または“shall not"によって明確に示されるものとします。
2. Optional features shall be indicated by the word "may".
2. オプション機能は“may"という単語によって示されるものとします。
3. The word "should" and the phrase "may not" shall not be
used.
3. 単語“should"と句の“may not"を使用しないものとします。
In some cases the specification issues guidance on use of optional features, by use of the the phrase word "recommended" or "not recommended".
いくつかの場合、仕様はオプション機能の使用のときに指導を発行します、「推薦される」か、または「推薦されない」という句転用語の使用で。
To interpet this document according to Internet rules, replace every occurrence of "shall" with "must".
interpetに、インターネットに従ったこのドキュメントは、“shall"のあらゆる発生を“must"に取り替えるように裁決します。
1.15. Related Specifications
1.15. 関連仕様
Mappings between Mail-11 and X.400 and Mail-11 and RFC 822 are described in RFC 2162, using mappings related to those defined here [2].
メール-11と、X.400と、メール-11とRFC822の間のマッピングはRFC2162で説明されて、それらに関連するマッピングを使用すると、[2]はここで定義されました。
Kille Standards Track [Page 11] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[11ページ]。
1.16. Document Structure
1.16. ドキュメント構造
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 OR
names and RFC 822 addresses, which is a fundamental gateway
component.
4. アドレシング--これはX.400 OR名とRFC822のアドレスの間のマッピングを考えます。(それは、基本的なゲートウェイの部品です)。
5. Detailed Mappings - This describes the details of all other
mappings.
5. 詳細なMappings--これは他のすべてのマッピングの詳細について説明します。
There are also ten appendices.
また、10個の付録があります。
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.17. Acknowledgements
1.17. 承認
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は多くの人々からの入力を持っていました)。(その人々は、それぞれのドキュメントで掛け売りされます)。
A number of comments from people on RFC 1148 lead to RFC 1327. In particular, there were comments and suggestions from: Maurice Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen (X-Tel); Jim Craigie (JNT); Ella Gardner (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の上の人々からの多くのコメントがRFC1327に通じます。 特に、コメントと提案は以下から来ていました。 モーリス・アブラハム(hp)。 ハラルドAlvestrand(Sintef)。 ピーター・カウエン(X-Tel)。 ジム・クレーギー(JNT)。 エラ・ガードナー(斜め継ぎ)。 クリスチャンのHuitema(Inria)。 エリックHuizer(SURFnet)。 ニール・ジョーンズ(12月)。 イグナシオ・マルチネス(虹彩)。 ジュリアンOnions(X-Tel)。 サイモン・プール(スイッチ)。 クライヴ・ロバーツ(データゼネラル)。 ピートバンダービルト(太陽)。 アラン・ヤング(同時発生の)。
RFC 1327 has been widely adopted, and a review team was formed. This comprised of: Urs Eppenberger (SWITCH)(Chair); Claudio Allocchio (INFN); Harald Alvestrand (UNINETT); Dave Crocker (Brandenburg); Ned Freed (Innosoft); Erik Huizer (SURFnet); Steve Kille (Isode); Peter Sylvester (GC Tech).
RFC1327は広く採用されました、そして、レビューチームは形成されました。 以下から成るこれ ウルスEppenberger(スイッチ)(議長)。 クラウディオAllocchio(INFN)。 ハラルドAlvestrand(UNINETT)。 デーヴ・クロッカー(ブランデンブルク)。 ネッドは(Innosoft)を解放しました。 エリックHuizer(SURFnet)。 スティーブKille(Isode)。 ピーター・シルベスター(GC技術者)。
Kille Standards Track [Page 12] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[12ページ]。
Harald Alvestrand also supplied the tables mapping DSN status codes with X.400 codes. Ned Freed defined parts of the File Transfer Body Part mapping.
また、ハラルドAlvestrandはDSNステータスコードを写像するテーブルにX.400コードを供給しました。 ネッド・フリードはFile Transfer Body Partマッピングの部分を定義しました。
Comment and input has also been received from: Bengt Ackzell (Generic Systems); Samir Albadine (Transpac); Mark Boyes (DEC); Larry Campbell (Boston Software Works); Jacqui Caren (Cray); Allan Cargille (MCI); Kevin Carrosso (Innosoft); Charlie Combs (OIW); Jim Craigie (Net- Tel); Eamon Doyle (Isocor); Efifion Edem (SITA); Jyrki Heikkinen (ICL); Edward Hibbert (DCL); Jeroun Houttin (Terena); Kevin Jordan (CDS); Paul Kingsnorth (DEC); Carl-Uno Manros (Manros Consulting); Suzan Mendes (Telis); Robert Miles (Softswitch); Roger Mizumorri (Enterprise Solutions Ltd); Keith Moore (University of Tennessee); Ruth Moulton (Net-Tel) Michel Musy (Bull); Kenji Nonaka (NTT): The OIW MHSIG; Tom Oliphant (SWITCH); Julian Onions (NEXOR); Jacob Palme (KTH); Olivier Paridaens (ULB); Mary la Roche (Citicorp); John Setsaas (Maxware); Russell Sharpe (DCL); Patrick Soulier (CCETT); Eftimios Tsigros (Universite Libre de Bruxelles); Sean Turner (IECA); Mark Wahl (Isode); David Wilson (Isode); Bill Wohler (Worldtalk); Alan Young (Isode); Alain Zahm (Telis).
また、以下からコメントと入力を受け取りました。 ベントAckzell(一般的なシステム)。 Samir Albadine(Transpac)。 Boyes(12月)をマークしてください。 ラリー・キャンベル(ボストンソフトウェアは動作します)。 Jacquiカレン(クレイ)。 アランCargille(MCI)。 ケビンCarrosso(Innosoft)。 チャーリーは(OIW)をとかします。 ジム・クレーギー(ネットTel)。 Eamonドイル(Isocor)。 Efifion Edem(サイタ)。 イルキ・ヘイッキネン(ICL)。 エドワード・ヒバート(DCL)。 Jeroun Houttin(Terena)。 ケビン・ジョーダン(CDS)。 ポールキングズノース(12月)。 カール-宇野Manros(Manrosコンサルティング)。 スーザン・メンデス(Telis)。 ロバートMiles(Softswitch)。 ロジャーMizumorri(エンタープライズソリューションLtd)。 キース・ムーア(テネシー大学)。 ルース・モールトン(ネット-Tel)ミシェルMusy(雄牛)。 Kenji Nonaka(NTT): OIW MHSIG。 トム・オリファント(スイッチ)。 ジュリアンOnions(NEXOR)。 ヤコブ・パルメ(KTH)。 オリビエParidaens(ULB)。 メアリ・laロッチェ(シティコープ)。 ジョンSetsaas(Maxware)。 ラッセル・シャープ(DCL)。 パトリックSoulier(CCETT)。 Eftimios Tsigros(大学Libre deブリュッセル)。 ショーン・ターナー(IECA)。 ウォール(Isode)をマークしてください。 デヴィッド・ウィルソン(Isode)。 ビル・ウェーラー(Worldtalk)。 アラン・ヤング(Isode)。 アランZahm(Telis)。
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つのレベルがあります:
Kille Standards Track [Page 13] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[13ページ]。
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 partial support, the level of partial support is summarised. Where partial support is good, this will be described by a phrase such as "Supported by use of.....". A common case of this is where the service is mapped onto a non-standard service on the other side of the gateway, and this would have lead to support if it had been a standard service. In many cases, this is equivalent to support. For partial support, an indication of the mechanism is given, in order to give a feel for the level of support provided. Note that this is not a replacement for Chapter 5, where the mapping is fully specified.
最初の2つの場合では、サービスは「支持される」か、または「支持されない」ように単にマークされます。 または、追加含意があれば何らかの説明をするかもしれない、(非、)、サポートは直感的ではありません。 部分的なサポートにおいて、部分的なサポートのレベルについて略言します。 部分的なサポートがいいぞ、これが句によって説明されるということであるところ、「使用で支持される、」、… このよくある例はサービスがゲートウェイの反対側の上で標準的でないサービスに写像されるところです、そして、これには、支持するリードがそれが標準のサービスであったならあるでしょう。 多くの場合、これは、支持するために同等です。 部分的なサポートにおいて、メカニズムのしるしを与えます、提供されたサポート水準の感じを与えるために。 これが第5章への交換でないことに注意してください。(そこでは、マッピングが完全に指定されます)。
If a service is described as supported, this implies:
サービスが支持されるように説明されるなら、これは以下を含意します。
- Semantic correspondence.
- 意味通信。
- No (significant) loss of information.
- 情報の(重要)の損失がありません。
- Any actions required by the service element.
- どんな動作もサービス要素が必要です。
An example of a service gaining full support: If an RFC 822 originator specifies a Subject: field, this is considered to be supported, as an X.400 recipient will get a subject indication.
全面的な支援を獲得するサービスの例: RFC822創始者がSubject:を指定するなら 分野、X.400受取人が対象の指示を得るとき、これが支持されると考えられます。
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
レセプションとして、要素がこのマッピングを支持するのを必要としたサービスのリストは指定されます。 これは本当に受取人が離れてそうであるメッセージで見ると予想するかもしれないもののしるしです。
Kille Standards Track [Page 14] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[14ページ]。
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). 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.
いろいろな場合に使用されるマッピングのメカニズムはIPM(InterPersonal Message)の見出し拡張子にRFC822ヘッダーを写像することです。 これを部分的なサポートと見なすことができます、情報をこれらのサービスに興味を持っているどんなX.400実現にも利用可能にするとき。 重要なRFC822の織り込むことを必要とする共同体が、彼らのX.400 Userエージェントがこれらの見出し拡張子を表示できるのを必要とするのが推薦されます。 様々なサービス要素(ヘッダー)のサポートは現在、記載されます。
Date:
Supported.
日付: 支持にされる。
From:
Supported. For messages where there is also a sender field,
the mapping is to "Authorising Users Indication", which has
subtly different semantics to the general RFC 822 usage of
From:.
From: 支持にされる。 また、送付者分野があって、「ユーザ指示を認可します」にはマッピングがある(From:の一般的なRFC822用法にかすかに異なった意味論を持っています)メッセージのために。
Sender: Supported.
送付者: 支持にされる。
Reply-To: Supported.
Reply-To 支持にされる。
To: Supported.
To: 支持にされる。
Cc: Supported.
Cc: 支持にされる。
Bcc: Supported.
Bcc: 支持にされる。
Message-Id: Supported.
メッセージイド: 支持にされる。
In-Reply-To:
Supported, for a single reference. Where multiple references are
given, partial support is given by mapping to "Cross Referencing
Indication". This gives similar semantics.
以下に対して ただ一つの参照のために、支持されます。 複数の参照が与えられているところに、マッピングで部分的なサポートを与えて、「指示に参照をつけて、交差します」。 これは同様の意味論を与えます。
References: Supported.
参照: 支持にされる。
Kille Standards Track [Page 15] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[15ページ]。
Keywords: Supported by use of a heading extension.
キーワード: 見出し拡張子の使用で、支持されます。
Subject: Supported.
Subject: 支持にされる。
Comments: Supported by use of a heading extension.
コメント: 見出し拡張子の使用で、支持されます。
Encrypted: Supported by use of a heading extension.
コード化される: 見出し拡張子の使用で、支持されます。
Content-Language: Supported.
満足している言語: 支持にされる。
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.
特定のX-*がさばいて、「不法入国者」が一般的な用法でさばく(例えば、「1日に実を結ばせてください」)コネは見出し拡張子の使用で支持されます。
MIME introduces a number of headings. Support is defined in RFC 2157.
MIMEは多くの見出しを紹介します。 サポートはRFC2157で定義されます。
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:
Kille Standards Track [Page 16] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[16ページ]。
Message-Id:
メッセージイド:
In-Reply-To:
以下に対して
References:
参照:
Subject:
Subject:
Content-Type: (See RFC 2157)
コンテントタイプ: (RFC2157を見ます)
Content-Transfer-Encoding: (See RFC 2157)
満足している転送コード化: (RFC2157を見ます)
MIME-Version: (See RFC 2157)
MIMEバージョン: (RFC2157を見ます)
The following services (headers) may be present in the header of a message. These are defined in more detail in Chapter 5 (5.3.4, 5.3.6, 5.3.7):
以下のサービス(ヘッダー)はメッセージのヘッダーに存在しているかもしれません。 これらがさらに詳細に第5章で定義される、(5.3 .4 5.3 .6、5.3、.7):
Autoforwarded:
Autoforwardedしました:
Autosubmitted:
Autosubmittedしました:
X400-Content-Identifier:
X400の満足している識別子:
Content-Language:
満足している言語:
Conversion:
変換:
Conversion-With-Loss:
損失との変換:
Delivery-Date:
納品日:
Discarded-X400-IPMS-Extensions:
捨てられたX400-IPMS拡張子:
Discarded-X400-MTS-Extensions:
捨てられたX400-MTS拡張子:
DL-Expansion-History:
dl拡大歴史:
Deferred-Delivery:
延期した納入:
Expires:
期限が切れます:
Importance:
重要性:
Incomplete-Copy:
不完全なコピー:
Latest-Delivery-Time:
最新の納期:
Kille Standards Track [Page 17] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[17ページ]。
Message-Type:
メッセージタイプ:
Original-Encoded-Information-Types:
オリジナルは情報タイプをコード化しました:
Originator-Return-Address:
創始者返送先:
Priority:
優先権:
Reply-By:
返答してください:
Sensitivity:
感度:
Supersedes:
Supersedes:
X400-Content-Type:
X400-コンテントタイプ:
X400-MTS-Identifier:
X400-MTS-識別子:
X400-Originator:
X400-創始者:
X400-Received:
X400が受け取られている:
X400-Recipients:
X400-受取人:
2.3. X.400
2.3. X.400
2.3.1. Origination in X.400
2.3.1. X.400での創作
When mapping services from X.400 to RFC 822 which are not supported by RFC 822, new RFC 822 headers are defined, and registered by publication in this standard. It is intended that co-operating RFC 822 systems may also 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.
サービスを写像するとき、822個のヘッダーが、この規格における公表によってX.400からRFC822、新しいRFCによって支持されないRFC822まで定義されて、登録されます。 また、協力RFC822システムがそれらを使用するかもしれないことを意図します。 これらの新しい分野が使用されていて、システム動作が全く含意されないところでは、サービスを部分的に支持されると見なすことができます。 第5章はこれらの新しいヘッダーにX.400サービスを写像する方法を説明します。 RFC822がそれらを提供できないようにゲートウェイは他の要素を一部提供します。
Some service elements are marked N/A (not applicable). There are five cases, which are marked with different comments:
いくつかのサービス要素がN/A(適切でない)であるとマークされます。 5つのケースがあります:(ケースは異なったコメントでマークされます)。
N/A (local)
These elements are only applicable to User Agent / Message
Transfer Agent interaction and so they cannot apply to RFC 822
recipients.
N/、これらの(地方の)要素が単にUserエージェント/メッセージTransferエージェント相互作用に適切であるので、それらは822人の受取人をRFCに適用できません。
Kille Standards Track [Page 18] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[18ページ]。
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 shall 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- delivery notification will be generated. Otherwise, the service request will be ignored.
最終的に、いくつかのサービス要素は支えられません。 特に、新しいセキュリティー・サービスはRFC822に写像されません。 別の方法で示されないと、支持されないようにマークされたサービス要素のふるまいはユーザによって供給された臨界マークであることによるでしょう。 要素が転送か配送に重要であるとしてマークされると、非配送している通知は発生するでしょう。 さもなければ、サービスのリクエストは無視されるでしょう。
2.3.1.1. Basic Interpersonal Messaging Service
2.3.1.1. 基本的な個人間のメッセージサービス
These are the mandatory IPM services as listed in Section 19.8 of X.400 / ISO/IEC 10021-1, listed here in the order given. Section 19.8 has cross references to short definitions of each service.
これらはX.400/ISO/IECのセクション19.8に10021-1に記載されているように義務的なIPMサービスです、ここ、与えられたオーダーでは、記載されています。 セクション19.8はそれぞれのサービスの短い定義に相互参照を持っています。
Access management
N/A (local).
(地方)で管理N/Aにアクセスしてください。
Content Type Indication
Supported by a new RFC 822 header (X400-Content-Type:).
新しいRFC822ヘッダーによる内容Type Indication Supported、(X400-コンテントタイプ:、)
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
新しいRFC822ヘッダー(X400-MTS-識別子)の使用によるメッセージIdentification Supported。 ところが、X.400に2つのメッセージイドがあるとき、この新しいヘッダーが必要です。
Kille Standards Track [Page 19] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[19ページ]。
RFC 822 has only one (see IP Message Identification
RFC822には1つしかない、(IP Message Identificationを見てください。
Non-delivery Notification
Not supported in all cases. Supported where the recipient system
supports NOTARY DSNs. In general all RFC 822 systems 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.
すべての場合で支持された非配送Notification Not。 受取人システムがNOTARY DSNsを支持するところで支持されます。 一般に、すべてのRFC822システムがIPメッセージの使用でエラー・レポートを返すでしょう。 他のサービス要素では、このサービス要素の有効なサポートとしてこの実践的な結果を扱うことができます。
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
Support is defined in RFC 2157.
タイプされたBody SupportはRFC2157で定義されます。
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). A MIXER gateway has two conformant options. The
first is not to gateway a message requesting prohibition of
alternate recipient, as this control cannot be guaranteed. This
option supports the service, but may cause unacceptable level of
message rejections. The second is to gateway the message on the
basis that there is no alternate recipient service in RFC 822. RFC
1327 allowed only the second option. If the first option is
shown to be operationally effective, it may be the only option in
future versions of MIXER.
支持されたRecipient Allowed Notを交替してください。 交互の受取人課題の禁止に同等などんなRFC822サービスもありません(例えば、RFC822システムは自由に「非-提出物」メッセージを地元の郵便局長に送るかもしれません)。 MIXERゲートウェイには、2つのconformantオプションがあります。 1番目はゲートウェイへのこのコントロールを保証できないので交互の受取人の禁止を要求するメッセージではありません。 このオプションは、サービスを支持しますが、容認できないレベルのメッセージ拒絶を引き起こすかもしれません。 2番目はゲートウェイへのどんな交互の受取人サービスもRFC822にないというベースに関するメッセージです。 RFC1327は2番目のオプションだけを許容しました。 第1の選択が操作上効果的になるように示されるなら、それはMIXERの将来のバージョンで唯一のオプションであるかもしれません。
Authorising User's Indication
Supported.
支持されたユーザの指示を認可します。
Kille Standards Track [Page 20] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[20ページ]。
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。
Content Integrity
Not supported.
支持された内容Integrity Not。
Conversion Prohibition
Supported. Operation defined in RFC 2157.
禁止が支持した変換。 RFC2157で定義された操作。
Conversion Prohibition in Case of Loss of Information
Supported. Operation defined in RFC 2157.
情報の損失の場合の禁止が支持した変換。 RFC2157で定義された操作。
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 shall always be provided by the MTS
prior to the gateway. A new RFC 822 header (Deferred-Delivery:)
is provided to transfer information on this service to the
recipient.
延期した納入、なし、(優先的に。) このサービスはいつもMTSによってゲートウェイの前に提供されるものとします。 受取人に対するこのサービスの情報を移すために、新しいRFC822ヘッダー(延期された配送:)を提供します。
Deferred Delivery Cancellation
N/A (local).
延期した納入キャンセル、なし、(ローカル。)
Delivery Notification
Supported. This is performed at the gateway, but may be performed
at the end system if the end system supports NOTARY. Thus, a
notification is sent by the gateway to the originator.
通知が支持した配送。 これは、ゲートウェイで実行されますが、エンドシステムがNOTARYを支持するなら、エンドシステムで実行されるかもしれません。 したがって、ゲートウェイは通知を創始者に送ります。
Kille Standards Track [Page 21] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[21ページ]。
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ではありません。
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, although RFC 822 supports distribution list functionality.
There is no SMTP leve control to prohibit distribution list
expansion. A MIXER gateway has two conformant options. The
first is not to gateway a message requesting DL expansion
prohibition, as this control cannot be guaranteed. This option
supports the service, but may cause unacceptable level of message
rejections. The second is to gateway the message on the basis that
there is no distribution list service in RFC 822. RFC 1327 allowed
only the second option. If the first option is shown to be
operationally effective, it may be the only option in future
versions of MIXER.
DL Expansion Prohibited Distribution Listは、MTSがX.400の方法で発送先リストを支持したことを意味します。 RFC822は発送先リストの機能性を支持しますが、このサービスはRFC822世界に存在していません。 発送先リスト拡大を禁止するために、SMTPルヴェコントロールは全くありません。 MIXERゲートウェイには、2つのconformantオプションがあります。 1番目はゲートウェイへのこのコントロールを保証できないのでDL拡大禁止を要求するメッセージではありません。 このオプションは、サービスを支持しますが、容認できないレベルのメッセージ拒絶を引き起こすかもしれません。 2番目はゲートウェイへの発送先リストサービスが全くRFC822にないというベースに関するメッセージです。 RFC1327は2番目のオプションだけを許容しました。 第1の選択が操作上効果的になるように示されるなら、それはMIXERの将来のバージョンで唯一のオプションであるかもしれません。
Express Mail Service
N/A (PDAU).
なし、メールサービス(PDAU)を言い表してください。
Expiry Date Indication
Supported as new RFC 822 header (Expires:). In general, no
automatic action can be expected.
新しいRFC822ヘッダー(期限が切れる:)としての満期Date Indication Supported。 一般に、どんな自動動作も予想できません。
Explicit Conversion
N/A (prior).
明白な変換、なし、(優先的に。)
Forwarded IP Message Indication
Supported.
指示が支持したIPメッセージを転送しました。
Grade of Delivery Selection
Not Supported. There is no equivalent service in RFC 822.
選択が支持しなかった配送のグレード。 どんな同等なサービスもRFC822にありません。
Importance Indication
Supported as new RFC 822 header (Importance:).
新しいRFC822ヘッダーとしての重要性Indication Supported、(重要性:、)
Kille Standards Track [Page 22] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[22ページ]。
Incomplete Copy Indication
Supported as new RFC 822 header (Incomplete-Copy:).
新しいRFC822ヘッダー(不完全なコピー:)としての不完全なCopy Indication Supported。
Language Indication
Supported as new RFC 822 header (Content-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 for general
information, but will not be acted on by the SMTP infrastrucuture.
支持された最新のDelivery Designation Not。 新しいRFC822ヘッダー(最も遅い配送時間:)を提供します。(一般情報に受取人によって使用されるかもしれませんが、ヘッダーはSMTP infrastrucutureによって影響されないでしょう)。
Message Flow Confidentiality
Not supported.
Flow Confidentiality Notが支持したメッセージ。
Message Origin Authentication
N/A (reception).
メッセージ起源認証、なし、(レセプション。)
Message Security Labelling
Not supported.
Security Labelling Notが支持したメッセージ。
Message Sequence Integrity
Not supported.
Sequence Integrity Notが支持したメッセージ。
Multi-Destination Delivery Supported.
配送が支持したマルチの目的地。
Multi-part Body
Supported.
支えられた複合ボディー。
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 (Supersedes:).
新しいRFC822ヘッダー(Supersedes:)としてIndication Supportedを時代遅れにします。
Ordinary Mail
N/A (PDAU).
なし、普通郵便(PDAU。)
Originator Indication
Supported.
指示が支持した創始者。
Kille Standards Track [Page 23] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[23ページ]。
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。)
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 where SMTP and NOTARY are available. In other cases
formally 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).
SMTPとNOTARYが利用可能である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を領収書を出させてください。
Kille Standards Track [Page 24] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[24ページ]。
Redirection Disallowed 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) is 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. In practice, control of this service is not supported.
Originator RedirectionによるリダイレクションDisallowedは、MTSがX.400の方法でリダイレクションを支持したことを意味します。 このサービスはRFC822世界に存在していません。 RFC822リダイレクション(例えば、エイリアシング)はこのコントロールの範囲を超えて非公式のリダイレクションメカニズムと見なされます。 このサービスが要求されているかどうかの如何にかかわらずRFC822にメッセージを送るでしょう。 実際には、このサービスのコントロールは支持されません。
Registered Mail
N/A (PDAU).
なし、書留(PDAU。)
Registered Mail to Addressee in Person
N/A (PDAU).
自分で、なし、受け取り人(PDAU)への書留。
Reply Request Indication
Supported as comment next to address.
アドレスの横のコメントとしての回答Request Indication Supported。
Replying IP Message Indication
Supported.
IPメッセージ指示が支持した返答。
Report Origin Authentication
N/A (reception).
起源認証を報告してください、なし、(レセプション。)
Request for Forwarding Address
N/A (PDAU).
フォーワーディング・アドレスには、なしよう要求してください(PDAU)。
Requested Delivery Method
N/A (local). The service request is 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
Supported where SMTP and NOTARY are used. In principle for other
situations, 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).
SMTPとNOTARYが使用されているContent Supportedの復帰。 原則として他の状況のために、非配送通知が支持されないとき、これは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)を格納しました。
Kille Standards Track [Page 25] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[25ページ]。
Stored Message Fetching
N/A (MS).
なし、(MS)をとって来ながら、メッセージを格納しました。
Stored Message Listing
N/A (MS).
なしと記載するメッセージ(MS)を格納しました。
Stored Message Summary
N/A (MS).
なし、メッセージ概要(MS)を格納しました。
Subject Indication
Supported.
支持された対象の指示。
Undeliverable Mail with Return of Physical Message
N/A (PDAU).
Undeliverableは物理メッセージの復帰でなし、(PDAU)に郵送します。
Use of Distribution List
In principle this applies only to X.400 supported distribution
lists (see DL Expansion Prohibited). Theoretically, this service
is N/A (prior). In practice, because of informal RFC 822 lists,
this service can be regarded as supported.
これがX.400だけに適用するDistribution List In原則の使用は発送先リストを支持しました(DL Expansion Prohibitedを見てください)。 理論的に、このサービスはN/A(優先的である)です。 非公式のRFC822リストのために、実際には、支持されるようにこのサービスを見なすことができます。
Auto-Submitted Indication
Supported
支持された自動提出された指示
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
タイプされたボディー
Kille Standards Track [Page 26] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[26ページ]。
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
予備選挙と写し受信者指示
Replying IP Message Indication
返答しているIPメッセージ指示
Subject Indication
対象の指示
2.3.2.3. New Services
2.3.2.3. 新種業務
A new X.400 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.
新しいX.400サービス「RFC822ヘッダーフィールド」は、拡大施設を使用することで定義されます。 これは、どんなRFC822ヘッダーフィールドも表されるのを許容します。 それはX.400 UAによって受け取られるRFC822の溯源されたメッセージに存在しているかもしれません。
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 [16]. 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[16]のセクション2で定義されたExtendedバッカスナウアForm(EBNF)に従って、構造化されたテキストは定義されます。 この仕様で使用されるEBNF定義では、RFC822のAppendix Dで与えられたシンタックス・ルールは想定されます。 EBNF定義の外でこれらのEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、822.addr-仕様)にされるのであるストリング「822」で特定されます。 追加シンタックス・ルールは、この仕様中で使用されるために本章で定義されます。
The EBNF is used in two ways.
EBNFは2つの方法で使用されます。
Kille Standards Track [Page 27] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[27ページ]。
1. To describe components of RFC 822 messages (or of SMTP
components). 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メッセージ(またはSMTPの部品について)の成分について説明するために。 EBNF定義の外でこれらの新しいEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、EBNF.importance)にされるのであるストリング"EBNF"によって特定されます。
2. To describe the structure of IA5 or ASCII information not in
an RFC 822 message.
2. RFC822メッセージでないところのIA5かASCII情報の構造について説明するために。
For all new EBNF, 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.
すべての新しいEBNFに関しては、象徴は、自己の区切りである、または象徴を区切る自己によって区切られるでしょう。 コメントとLWSPはデリミタとして使用されません、以下のケースを除いて。そこでは、RFC822規則に従って、LWSPが挿入されるかもしれません。
- 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. Comments are never used in these new headers.
RFC822折り尺はすべてのヘッダーに適用されます。 コメントはこれらの新しいヘッダーで決して使用されません。
This notation is used in a modified form to refer to NOTARY EBNF [28]. For this EBNF, the keyword EBNF it replaces with DSN, for example DSN.final-recipient-field fields.
この記法は、NOTARY EBNF[28]について言及するのに変更されたフォームで使用されます。 このEBNF、それがDSN、例えば、DSN.final-recipient-分野分野に取り替えるキーワードEBNFのために。
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。
TA MTAAbstractService defined in Section 13 of X.411 / ISO 10021-4.
X.411 / ISO10021-4のセクション13で定義されたTA MTAAbstractService。
Kille Standards Track [Page 28] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[28ページ]。
FTBP File Transfer Body Part, as defined in [27].
[27]で定義されるようなFTBP File Transfer Body Part。
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. For example, IPMS.Heading.subject defines the subject element of the IPMS heading. The same syntax is also used to refer to element values. For example, MTS.EncodedInformationTypes.[0].g3Fax refers to a value of MTS.EncodedInformationTypes.[0] .
最初のEBNF.identifierは定義されたサービス仕様の文脈で主要なタイプか値を特定します。 その後のEBNF.identifiersは値のラベルを特定するか、または最初の識別子(SETかSEQUENCE)の文脈をタイプします。 EBNF.contextは文脈タグを示して、唯一コンポーネントを特定するためにラベルなしかタイプがあるところで使用されます。 「値」という特別なEBNF.identifierキーワードは、系列の原理を指示するのに使用されます。 例えば、IPMS.Heading.subjectはIPMS見出しの対象の要素を定義します。 また、同じ構文は、要素値について言及するのに使用されます。 例えば、MTS.EncodedInformationTypes.[0].g3FaxはMTS.EncodedInformationTypes.[0]の値について言及します。
3.2. ASCII and IA5
3.2. ASCIIとIA5
A gateway will interpret all IA5 as ASCII. Thus, mapping between these forms is conceptual.
ゲートウェイはASCIIとしてすべてのIA5を解釈するでしょう。 したがって、これらのフォームの間のマッピングは概念的です。
3.3. Standard Types
3.3. 標準体型
There is a need to convert between ASCII text and some of the types defined in ASN.1 [14]. 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.
ASN.1[14]で定義されたASCIIテキストと何人かのタイプの間で変換する必要があります。 各ケースにおいて、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は*と等しいです。(ケタ/、「「)」
Kille Standards Track [Page 29] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[29ページ]。
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, there are two options, both of which are conformant to this specification:
T.61ストリングが人間の解釈された情報を伝えるのに使用されるだけである場合では、マッピングの目的はリバーシブルを最大にするというよりむしろ適切にキャラクタをリモート文字の組にすることです。 これらのケースのために、2つのオプションがあります:その両方がこの仕様へのconformantです。
1. The mappings to IA5 defined in ITU-T Recommendation X.408
(1988) may be used [13]. These will then be encoded in
ASCII. This is the approach mandated in RFC 1327.
1. ITU-T Recommendation X.408(1988)で定義されたIA5へのマッピングは中古の[13]であるかもしれません。 そして、これらはASCIIでコード化されるでしょう。 これはRFC1327で強制されたアプローチです。
2. This mapping may be used if the characters are not contained
within ASCII repertoire, but are all in an IANA-registered
character set. Use the encoding defined in RFC 1522 [9] to
generate appropriate encoded-words. If this mapping is
used, the character set ISO-8859-1 shall be used if all of
the characters needed are available in this repertoire. In
other cases, the character set TELETEX shall be used. The
details of this character set is defined in the Appendix C
of RFC 2157.
2. キャラクタはASCIIレパートリーの中に含まれていませんが、IANAによって登録された文字の組にすべて、あるなら、このマッピングは使用されるかもしれません。 適切なコード化された単語を発生させるようにRFC1522[9]で定義されたコード化を使用してください。 このマッピングが使用されているなら、必要であるキャラクタが皆、このレパートリーで利用可能であるなら、文字の組ISO-8859-1は使用されるものとします。 他の場合では、文字の組TELETEXは使用されるものとします。 この文字の組の詳細はRFC2157のAppendix Cで定義されます。
There is also a need to represent Teletex Strings in ASCII, for some aspects of OR Address. For these, the following encoding is used:
OR 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
Characters in EBNF.ps-char are mapped simply. Other octets,
including control characters, are mapped using a quoting mechanism
similar to the printable string mechanism. Each octet is represented
as 3 decimal digits. For example, the Yen character (hex A5) is
represented as {165}. As the three character string, a, yen
character, b, would be represented as either "a{165}b".
EBNF.ps-炭の中のキャラクターは単に写像されます。 制御文字を含む他の八重奏が、印刷可能なストリングメカニズムと同様の引用メカニズムを使用することで写像されます。 各八重奏は3つの10進数字として表されます。 例えば、Yenキャラクタ(十六進法A5)は165として代理をされます。 3文字列として、a(円キャラクタ、b)は「a165b」として表されるでしょう。
Kille Standards Track [Page 30] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[30ページ]。
The use of escape sequences follows that set down for ASN1. in ISO
8825-1, with the additional specifiction that the default G1 page is
ISO Latin 1. The page settings may be changed by escape sequences.
Changes of the settings hold within a pair of curly brackets ({}),
and the settings revert to the default after the right bracket (})
(i.e., they do not carry forward to subsequent T.61 encoding).
ASN1コネがデフォルトG1が呼び出す追加specifictionとISO8825-1であるとみなすエスケープシーケンス尾行の使用はISOラテン語1です。 エスケープシーケンスはページの設定内容を変えるかもしれません。 設定の変化がブレースの1組以内で成立する、()、設定が右のブラケットの後のデフォルトに戻る、()、(すなわち、それらはT.61コード化をその後に進展させません。)
There are a number of places where a string may have a Teletex and/or Printable String representation. The following EBNF is used to represent this.
多くの場所がストリングがTeletex、そして/または、Printable String表現を持っているかもしれないところにあります。 以下のEBNFは、これを表すのに使用されます。
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. An example is:
自然なマッピングは、完全なBNFを分析するのをより簡単にするようにEBNF.ps-焦げに制限されます。 例は以下の通りです。
"yen*{165}"
「円、*165、」
3.3.5. UTCTime
3.3.5. UTCTime
Both UTCTime and the RFC 822 822.date-time syntax contain: Year, Month, Day of Month, hour, minute, second (optional), and Timezone (technically a time differential in UTCTime). 822.date-time also contains an optional day of the week, but this is redundant. With the exception of Year, a symmetrical mapping can be made between these constructs.
UTCTimeとRFC 822 822.date-時間構文の両方が以下を含んでいます。 年、Month、Monthのデー、時間、分、2(任意の)番目、およびTimezone(技術的にUTCTimeの時間デフ装置)。 また、822.日付-時間は任意の曜日を含んでいますが、これは余分です。 Yearを除いて、これらの構造物の間で対称のマッピングを作ることができます。
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. Such errors may be noted in an RFC 822
comment, to aid detection and correction.
以下に注意してください。 実際には、ゲートウェイは、822.date-時に様々な不法な異形を分析する必要があるでしょう。 822.date-時間を分析できない場合では、派生しているUTCTimeが翻訳時点で値に用意ができているのは、お勧めです。 検出と修正を支援するためにRFC822コメントでそのような誤りに注意するかもしれません。
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., -0500).
RFC822に写像するとき、822.date-時間形式は数値タイムゾーンオフセット(例えば、-0500)を含んでいるものとします。
When mapping time values, the timezone shall be preserved as specified. The date shall not be normalised to any other timezone.
時間的価値を写像するとき、タイムゾーンは指定されるとして保存されるものとします。 いかなる他のタイムゾーンにも日付を正常にしないものとします。
Kille Standards Track [Page 31] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[31ページ]。
RFC 822, as modified by RFC 1123, requires use of a four digit year. Note that the original RFC 822 uses a two digit date, which is no longer legal. UTCTime uses a two digit date. To map a year from RFC 822 to X.400, simply use the last two digits. To map a year from X.400 to RFC 822, assume that the two digit year refers to a year in the 10 year epoch 1980-2079.
RFC1123によって変更されるRFC822は4ケタ年の使用を必要とします。 オリジナルのRFC822が2ケタ期日を使用することに注意してください。(期日はもう法的ではありません)。 UTCTimeは2ケタ日付を使用します。 RFC822からX.400までの1年を写像するには、単に下2ケタを使用してください。 X.400からRFC822までの1年を写像するには、2ケタ年が10年間の時代の1年に1980-2079について言及すると仮定してください。
3.3.6. Integer
3.3.6. 整数
A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In many cases ASN.1 will enumerate Integer values or use ENUMERATED. An EBNF encoding labelled-integer is provided. When mapping from EBNF to ASN.1, only the integer value is mapped, and the associated text is discarded. When mapping from ASN.1 to EBNF, a text label may be added. It is recommended that this is done wherever possible and that clear text labels are chosen.
基本的なASN.1IntegerはEBNF.numericstringに写像されるでしょう。 多くの場合、ASN.1はInteger値を列挙するか、またはENUMERATEDを使用するでしょう。 ラベルされた整数をコード化するEBNFを提供します。 EBNFからASN.1まで写像するとき、整数値だけが写像されます、そして、関連テキストは捨てられます。 ASN.1からEBNFまで写像するとき、テキストラベルは加えられるかもしれません。 どこでも、可能であるところでこれをして、クリアテキストラベルを選ぶのはお勧めです。
A second encoding labelled-integer-2 is provided. This is used in DSNs, where the parsing rules will treat the text as a comment. This definition was not present in RFC 1327.
ラベルされた整数2をコード化する1秒を提供します。 これはDSNsで使用されます。そこでは、構文解析規則がコメントとしてテキストを扱うでしょう。 この定義はRFC1327に存在していませんでした。
labelled-integer ::= [ key-string ] "(" numericstring ")"
ラベルされた整数:、:= [主要なストリング]の「(「numericstring」)」
labelled-integer-2 ::= [ numericstring ] "(" key-string ")"
ラベルされた整数2:、:= 「(「主要なストリング」の)」という[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」)」
Kille Standards Track [Page 32] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[32ページ]。
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)
Because of the use of brackets and the conflict with the RFC 822 comment convention, MIXER is defines so that the EBNFobject- identifier definition is not used in structured fields.
括弧の使用とRFC822注釈の便法との闘争のために、MIXERはそうです。EBNFobject識別子定義が構造化された分野で使用されないように、定義します。
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をコード化するのに使用されるものとします。
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 shall 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 shall only be used in cases where the printable strings have been derived from ASCII (and will therefore
現在、PrintableStringとASCIIの間のリバーシブルのマッピングを定義できます。 リバーシブルは、印刷可能なストリング(丸い支柱を含んでいる)のいくつかの値がASCIIから発生できないことを意味します。 したがって、このマッピングが印刷可能なストリングがASCIIから得られた場合に使用されるだけであるものとする、(したがって
Kille Standards Track [Page 33] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[33ページ]。
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.
制限されたドメイン) 例えば、この仕様では、それがこの仕様の使用で発生してしまうだろう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を分析できないなら、マッピングで不適当な値に適用しています、そして、マッピングをする手順に誤りを与えるものとします。 いくつかの場合、非変更にされるを通して印刷可能なストリングを渡すのは望ましいかもしれません。
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)<->、(
3.5. RFC 1522
3.5. RFC1522
RFC 1522 defines a mechanism for encoding other character set information into elements of RFC 822 Headers. A gateway may ignore this encoding and treat the elements as ASCII.
RFC1522は、RFC822Headersの要素に他の文字の組情報をコード化するためにメカニズムを定義します。 ゲートウェイは、このコード化を無視して、ASCIIとして要素を扱うかもしれません。
A preferred approach is for the gateway to interpret the RFC 1522 encoding. This will not always be straightforward, because:
RFC1522コード化を解釈するために、ゲートウェイには好ましい方法があります。 これがいつも簡単になるというわけではない、:
1. RFC 1522 permits an openly extensible character set choice,
which may be broader than T.61.
1. RFC1522はオープンに広げることができる文字の組選択を可能にします。(それは、T.61より広いかもしれません)。
2. It is not always possible to map all characters into the
equivalent X.400 field.
2. 同等なX.400分野にすべてのキャラクタを写像するのはいつも可能であるというわけではありません。
RFC 1522 is only applied to fields which are "for information only". A gateway which interprets header elements according to RFC 1522 may
RFC1522は「情報専用」のためにある分野に適用されるだけです。 RFC1522によると、ヘッダー要素を解釈するゲートウェイはそうするかもしれません。
Kille Standards Track [Page 34] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[34ページ]。
apply reasonable heuristics to minimise information loss.
合理的な発見的教授法を適用して、情報の損失を最小とならせてください。
Chapter 4 - Addressing and Message IDs
第4章--アドレシングとメッセージID
Addressing is the most complex aspect of X.400 <-> RFC 822 gateway and is therefore given a separate chapter. This chapter also discusses message identifiers, as they are closely linked to addresses. This chapter, as a side effect, also defines a textual representation of an X.400 OR Address. This specification has much similarity to the X.400(92) representation of addresses. This was because early versions of this specification were a major input to this work. This specification retains compatibility with earlier versions. The X.400 specification of address representation can be parsed but is not generated.
アドレシングをX.400<->RFC822ゲートウェイの最も複雑な局面であり、したがって、別々の章に与えます。 また、それらが密接にアドレスにリンクされるとき、本章はメッセージ識別子について議論します。 また、本章はX.400 OR Addressの原文の表現を副作用と定義します。 この仕様はアドレスのX.400(92)表現に多くの類似性を持っています。 これはこの仕様の早めのバージョンがこの仕事への主要な入力であったからです。 この仕様は以前のバージョンとの互換性を保有します。 アドレス表現のX.400仕様は、分析できますが、発生しません。
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-仕様と等しいです。
These definitions are taken from RFC 822. In SMTP (or another 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.
RFC822からこれらの定義を取ります。 SMTP(または、別の822MTSプロトコル)では、そのような構造物によって創始者と各受取人が定義されると考えられます。 RFC822ヘッダーでは、EBNF.822アドレスは822アドレス構文の規則で要約されます、そして、また、関連コメントがあるかもしれません。 このその他の情報のいずれにはも、エンドユーザ以外の少しの意味論もありません。
The basic X.400 OR Address, used by the MTS for routing, is defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is encapsulated within IPMS.ORDescriptor.
ルーティングにMTSによって使用された基本的なX.400 OR AddressはMTS.ORAddressによって定義されます。 IPMSでは、MTS.ORAddressはIPMS.ORDescriptorの中で要約されます。
The RFC 822 822.address is mapped with IPMS.ORDescriptor, and that RFC 822 EBNF.822-address is mapped with MTS.ORAddress.
RFC 822 822.addressはIPMS.ORDescriptorと共に写像されます、そして、そのRFC822EBNF.822-アドレスはMTS.ORAddressと共に写像されます。
Section 4.1 defines a textual representation of an OR Address, which is used throughout the rest of this specification. This text representation is designed to represent an X.400 address in the LHS (left hand side) or local part of an RFC 822 address, and so this representation gives a mechanism to represent X.400 addresses within RFC 822 addresses.
セクション4.1はOR Addressの原文の表現を定義します。(Addressはこの仕様の残りの間中使用されます)。 このテキスト表現がRFC822アドレスのLHS(左側)か地方の部分にX.400アドレスを表すように設計されているので、この表現はRFC822アドレスの中にX.400アドレスを表すためにメカニズムを与えます。
Section 4.2 describes global equivalence mapping between parts of the X.400 and RFC 822 name spaces, and defines the concept of a MIXER Conformant Global Address Mapping (MCGAM). Gateways conforming to this specification shall support MCGAMs.
セクション4.2は、X.400とRFC822名の部分の間で空間を写像するグローバルな等価性について説明して、MIXER Conformant Global Address Mapping(MCGAM)の概念を定義します。 この仕様に一致しているゲートウェイはMCGAMsを支持するものとします。
Kille Standards Track [Page 35] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[35ページ]。
Section 4.3 is the core part of this chapter, and defines the mapping mechanism.
セクション4.3は、本章のコア一部であり、マッピングメカニズムを定義します。
4.1. A textual representation of MTS.ORAddress
4.1. MTS.ORAddressの原文の表現
MTS.ORAddress is structured as an ordered set of attributes (type/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.
MTS.ORAddressは1つの順序集合の属性(タイプ/値の組)として構造化されます。 gatewaying目的のためのASCIIでこれをコード化できるのが明確に必要です。 すべてのコンポーネントが、エラーメッセージの復帰を保証して、第三者回答を最適化するためにコード化されるものとします。
4.1.1. Basic OR Address Representation
4.1.1. 基本的であるかアドレス表現
An OR 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 attribute key 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. The attribute key table follows:
OR 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.DomainDefineAttribute.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.DomainDefineAttribute.value DD P/T18.1
Kille Standards Track [Page 36] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[36ページ]。
88 Attributes
88の属性
MTS.CommonName CN P/T 18.3.2 1 MTS.TeletexCommonName CN P/T 18.3.2 2 MTS.TeletexOrganizationName O P/T 18.3.9 3 MTS.TeletexPersonalName PN P/T 18.3.12 4 MTS.TeletexPersonalName.surname S P/T 18.3.12 4 MTS.TeletexPersonalName.given-name G P/T 18.3.12 4 MTS.TeletexPersonalName.initials I P/T 18.3.12 4 MTS.TeletexPersonalName .generation-qualifier GQ P/T 18.3.12 4 MTS.TeletexOrganizationalUnitNames .value OU P/T 18.3.10 5 MTS.TeletexDomainDefinedAttribute .value DD P/T 18.1 6 MTS.PDSName PD-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 UPA 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.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 6MTS.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-アドレスUPA18.3.25 16 MTS.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
Kille Standards Track [Page 37] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[37ページ]。
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
UPA upa-string
I labelled-integer
X presentation-address
そして、TテレテックスストリングP/TをnumericstringしながらNをprintablestringするP、テレテックス、ps UPA upaストリング、Iラベルされた整数Xプレゼンテーションアドレス
The EBNF for presentation-address is taken from the specification RFC 1278 "A String Encoding of Presentation Address" [23].
仕様RFC1278「プレゼンテーションアドレスのAストリングコード化」[23]からプレゼンテーションアドレスのためのEBNFを取ります。
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 EBNF. When generating ASN.1, the NumericString encoding shall be used if the string contains digits and only digits.
多くの場合直接属性のASN.1コード化するのに地図をコード化するEBNF。 いくつかの例外があります。 PrintableStringかNumericStringのどちらかとして属性をコード化できる場合(国、ADMD、PRMD)では、どちらのフォームもEBNFに写像されます。 ASN.1を発生させるとき、ストリングがケタとケタだけを含んでいるなら、NumericStringコード化は使用されるものとします。
There are a number of cases where the P/T (teletex-and-or-ps) representation is used. Where the key maps to a single attribute, this choice is reflected in the encoding of the attribute (attributes 10-21). For example:
件数がそこでは、どこであるか、P/T、(テレテックス、または、psする、)、表現が使用されています。 ただ一つの属性への概念図でありこの選択が属性(属性10-21)のコード化に反映されるところ。 例えば:
/CN=yen*{165}/
/CNは円*165/と等しいです。
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. If there is teletex attribute or teletex component only, and it contains only characters in the printable string character set, it shall be represented in the EBNF as if it had been encoded as printable string. A single printable string representation shall also be done when both forms are present and they have the same printable string representation.
1984の属性と一般名の大部分のために、printablestringとテレテックス異形があります。 属性のこの組はここでただ一つのコンポーネントに写像されます。 これは名前の1つのフォームだけが使用されているよくある例のための清潔なマッピングを与えるでしょう。 テレテックス属性かテレテックスコンポーネントしかなくて、印刷可能なストリング文字の組にキャラクタだけを含んでいるなら、それはまるで印刷可能なストリングとしてコード化されたかのようにEBNFに表されるものとします。 また、両方のフォームが存在していて、それらに同じ印刷可能なストリング表現があると、ただ一つの印刷可能なストリング表現をするものとします。
The Unformatted Postal Address has a slightly more complex mapping onto a variant of (teletex-and-or-ps), defined as:
Unformatted Postal Addressがうっすら複雑なマッピングを異形に持っている、(テレテックス、または、psする、)、以下と定義されます。
upa-string = [ printable-upa ] [ "*" teletex-string ]
printable-upa = printablestring *( "|" printablestring )
upa-ストリング=[印刷可能なupa][「*」テレテックスストリング]印刷可能なupaは*をprintablestringするのと等しいです。(「|」 printablestring)
Kille Standards Track [Page 38] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[38ページ]。
The optional teletex part is straightforward. There is an (optional) sequence of printable strings which are mapped in order. For example:
任意のテレテックス部分は簡単です。 整然とした状態で写像される印刷可能なストリングの(任意)の系列があります。 例えば:
/PD-ADDRESS=The Dome|The Square|Richmond|England/
/PD-アドレスはドームと等しいです。|正方形|リッチモンド|イギリス/
X.400 (1992) has introduced a string representation of OR Addresses (see F.401, Annex B). This has specified a number of string keywords for attributes. As earlier versions of this specification were an input to this work, many of the keywords are the same. To increase compatibility, 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. The following keyword alternative table and the subsequent paragraph lists alternative keywords.
X.400(1992)はOR Addressesのストリング表現を紹介しました(F.401、Annex Bを見てください)。 これは属性のための多くのストリングキーワードを指定しました。 この仕様の以前のバージョンがこれへの入力であったように、働いてください、そして、キーワードの多くが同じです。 RFC822からX.400まで写像するとき、互換性を増加させるように、以下の代替の値は認識されるものとします。 X.400からRFC822まで写像するとき、これらを発生させないものとします。 以下のキーワード代替手段テーブルとその後のパラグラフは代替のキーワードをリストアップします。
Keyword Alternative
キーワード代替手段
ADMD A
PRMD P
GQ Q
X121 X.121
UA-ID N-ID
PD-OFFICE-NUM PD-OFFICE NUMBER
PD-OFFICE-NUM PD-OFN
PD-EXT-ADDRESS PD-EA
PD-EXT-DELIVERY PD-ED
PD-OFFICE PD-OF
PD-STREET PD-S
PD-UNIQUE PD-U
PD-LOCAL PD-L
PD-RESTANTE PD-R
PD-BOX PD-B
PD-CODE PD-PC
PD-SERVICE PD-SN
DD DDA
NET-NUM E.164
NET-PSAP PSAP
PD-ADDRESS PD-A
ADMD A PRMD P GQ Q X121 X.121Ua-ID N-ID PDオフィスヌムPD-局番号PDオフィスヌムPD-OFN PD-EXT-アドレスPD-EA PD-EXT-配送PD-エドPD-オフィス、PD、-、PD-S PDユニークなPD-U PD地方のPD-通りのPD-サービスPD-SN DD DDAネットのヌムE.164ネットのPSAP PSAP PDアドレスPD-L PD-RESTANTE PD-R PD-箱のPD-B PD-コードPD-PC PD-A
When mapping from RFC 822 to X.400, the keywords defined in this paragraph shall be recognized. The ordered 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. PD-A1, PD-A2, PD-A3, PD-A4, PD-A5, PD-A6 shall be treated as ordered lines. If present, these will be assembled with separating line feeds to form a single physical address. In
RFC822からX.400まで写像するとき、このパラグラフで定義されたキーワードは認識されるものとします。 規則正しいキーワード: OU1(OU2、OU3、およびOU4)は認識されるものとします。 これらが存在していると、キーワードがないOUは存在するでしょう。 これらはOUの命令された値として扱われるでしょう。 PD-A1、PD-A2、PD-A3、PD-A4、PD-A5、PD-A6は規則正しい線として扱われるものとします。 存在していると、これらは単一の物理アドレスを形成するために改行を切り離すのに組み立てられるでしょう。 コネ
Kille Standards Track [Page 39] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[39ページ]。
this case PD-ADDRESS (or PD-A) shall not be present. Similarly, there are ordered keywords for domain defined attributes: DD1, DD2, DD3, DD4,
または、本件PD-ADDRESS、(PD-a)がそうするのは、プレゼントではありません。 同様に、ドメインの定義された属性のための規則正しいキーワードがあります: DD1、DD2、DD3、DD4
If ISDN is present, it may be interpreted as an E.163/164 address, using local heuristics to parse the string. X.400 defines the key, but does not give an interpretation of the value.
ISDNが存在しているなら、ストリングを分析するのにローカルの発見的教授法を使用して、それはE.163/164アドレスとして解釈されるかもしれません。 X.400はキーを定義しますが、価値の解釈をしません。
For T-TY (Terminal Type), the X.400 recommended values are preferred, but other values are allowed. These values are: tlx (3); ttx (4); g3fax (5); g4fax (6); ia5 (7); and vtx (8).
T-TY(端末のType)に関しては、X.400推奨値は好まれますが、他の値は許容されています。 これらの値は以下の通りです。 tlx(3)。 ttx(4)。 g3fax(5)。 g4fax(6)。 ia5(7)。 そして、vtx(8)。
4.1.2. Encoding of Personal Name
4.1.2. 個人名のコード化
Handling of Personal Name and Teletex Personal Name is a common requirement. Therefore MIXER defines an alternative to the EBNF.standard-type syntax, which utilises the "human" conventions for encoding these components. A syntax is defined, which is designed to provide a clean encoding for the common cases of OR Address specification where:
パーソナルNameとTeletexパーソナルNameの取り扱いは一般的な要件です。 したがって、MIXERはEBNF.standard-type構文への代替手段を定義します。(構文は「人間」のコンベンションをこれらのコンポーネントをコード化するのに利用します)。 構文(OR Address仕様のよくある例のための清潔なコード化にどこを提供するように設計されている)は定義されます:
1. There is no generational qualifier
1. どんな世代の資格を与える人もいません。
2. Initials, if present, contain only letters
2. 存在しているなら、イニシャルは手紙だけを含んでいます。
3. Given Name, if present, 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が唯一のコンポーネントであるなら、それは終止符を含んでいません。
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
Kille Standards Track [Page 40] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[40ページ]。
This is used to map from any string containing only printable string characters to an OR address personal name. To map from a string to OR 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.
これはORアドレスに個人的な印刷可能なストリング性格だけが命名するどんなストリング含有からも写像するのにおいて使用されています。 ストリングからORまでAddressの部品を写像するには、EBNFに従って、ストリングを分析してください。 名と姓は直接割り当てられます。 すべてのEBNF.initial象徴が、イニシャルコンポーネントを発生させるように介入している終止符なしで連結されます。
For an OR address which follows the above restrictions, a string is derived in the natural manner. In this case, the mapping will be reversible.
上の制限に続くORアドレスにおいて、ストリングは生まれながらの方法で引き出されます。 この場合、マッピングはリバーシブルになるでしょう。
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 suggests that Initials is used to encode all initials except the surname (X.402 section 18.3.12). 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.
X.400が、Initialsが姓(X.402部18.3の.12)以外のすべてのイニシャルをコード化するのに使用されるのを示すことに注意してください。 したがって、両方ではなく、GivenNameかInitialsのどちらかが存在しているとき、定義されたコード化は「自然です」。 両方が出席しているケースをコード化できます。
4.1.3. Standard Encoding of MTS.ORAddress
4.1.3. MTS.ORAddressの標準のコード化
Given this structure, we can specify an EBNF representation of an OR Address. The output format of addresses is defined by EBNF.std-or- address. The more flexible input format is defined by EBNF.std-or- address-input. The input EBNF has been added subsequent to RFC 1327, to reflect the formal incorporation of a number of heuristics. The address element separator on input may be "/", ";", or a mixture of these. The output format is used in all examples.
この構造を考えて、私たちはOR AddressのEBNF表現を指定できます。 または、アドレスの出力書式がEBNF.stdによって定義される、-、-、アドレス。 または、 よりフレキシブルな入力フォーマットがEBNF.stdによって定義される、-、-、アドレス入力。 入力EBNFは、多くの発見的教授法の正式な編入を反映するためにRFC1327にその後で加えられます。 入力には、」 /があるかもしれません。「アドレス要素分離符、」 」 ; 」 これらの混合物。 出力形式はすべての例で使用されます。
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ dd-key "." std-printablestring
」 . 」 「stdかアドレス=1*(「/」属性「=」価値)」/」 dd属性=標準体型/"RFC-822"/キーstd-printablestring
Kille Standards Track [Page 41] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[41ページ]。
std-or-address-input = [ sep pair ] sep pair *( sep pair )
sep [ pair sep ]
stdかアドレス入力=[sep組]sep組*(sep組)sep[組sep]
sep = "/" / ";"
pair = input-attribute "=" value
input-attribute = attribute
/ dd-key ":" std-printablestring
「sepは」 /と等しい」という/、」、;、」 「組=入力属性は「」 値入力属性=dd属性/キーと等しいです」」 std-printablestring
standard-type = key-string
標準体型=の主要なストリング
dd-key = key-string
dd主要な=キーストリング
value = std-printablestring
値はstd-printablestringと等しいです。
std-printablestring
= *( std-char / std-pair )
std-printablestringは*と等しいです。(std std-炭/対にします)です。
std-char = <"{", "}", "*", and any ps-char
except "/" and "=" >
std-pair = "$" ps-char
「std-炭は<と等しい」、「」、」、「*」、および」 /」 「=」>std組=「$」ps-炭以外のどんなps-炭
For address generation, the standard-type is any key defined in the key table in Section 4.1, except PN, and DD. For address parsing, other key values from Section 4.1 are also valid. The EBNF leads to a set of attribute/value pairs. The value is interpreted according to the EBNF encoding defined in the table.
アドレス・ジェネレーションにおいて、標準体型はPN、およびDDを除いて、セクション4.1で主要なテーブルで定義されたあらゆるキーです。 また、アドレス解析において、セクション4.1からの他のキー値も有効です。 EBNFは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) or one of the alternatives defined in Section 4.1, 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)かセクション4.1で定義された代替手段の1つであるなら、タイプと値は、コード化によって暗示している構文によって解釈されて、テレテックスか印刷可能なストリングフォームに並べられます。 キーと値には、同じコード化があるものとします。
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とどんな値もこれらのキャラクタを含むかもしれません。 引用メカニズムであり、非印刷可能なストリング「$」を使用するのは、これらのキャラクタが代理をされるのを許容するのに使用されます。
Kille Standards Track [Page 42] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[42ページ]。
If an address of this syntax is parsed, and a country value is present, but no ADMD, the string shall be interpreted as if an ADMD value of single space had been specified.
国の値がこの構文のアドレスが分析されて、プレゼントにもかかわらず、ADMDでないなら、まるでシングルスペースのADMD値が指定されたかのようにストリングは解釈されるものとします。
4.2. Global Address Mapping
4.2. グローバルアドレスマッピング
From a user perspective, the ideal mapping 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
impossible.
1. 構文はこれを不可能にすることができるくらい異なっています。
2 There is insufficient administrative co-operation between
the X.400 and RFC 822 name registration authorities for this
to work.
2 これが働くように、X.400とRFC822名前登録局の間には、不十分な管理協力があります。
Another way to view this situation is to see that there is not a full global equivalence between X.400 and RFC 822 addressing. To meet user needs to the extent possible, this specification provides for equivalence where there is sufficient co-operation. To be useful, this equivalence shall be recognised and interpreted in the same way by all gateways. Therefore, an asymmetrical mapping is defined, which can be symmetrical where there is appropriate administrative co-operation. Section 4.3 describes the asymetrical aspects. This section describes a mechanism to enable the administrative co- ordination for symmetrical mappings.
この状況を見る別の方法はX.400とRFC822アドレシングの間には、完全なグローバルな等価性がないのがわかることです。 可能な範囲内でユーザ需要を満たすために、この仕様は十分な協力があるところに等価性に備えます。 同様に、この等価性は、役に立つように、すべてのゲートウェイによって認識されて、解釈されるものとします。 したがって、非対称的なマッピング(適切な管理協力があるところで対称である場合がある)は定義されます。 セクション4.3はasymetrical局面について説明します。 このセクションは、対称のマッピングのために管理共同叙階式を可能にするためにメカニズムについて説明します。
In order to achieve a symmetrical mapping there is a need to define an administrative equivalence between parts of the OR Address and Domain namespaces. Previous version of this specification did this by definition of a global set of mappings. MIXER defines the concept of a MIXER Conformant Global Address Mapping (MCGAM). This acronym is defined so that it is very clear what is being referenced.
対称のマッピングを達成するために、OR AddressとDomain名前空間の部品の間には、管理等価性を定義する必要があります。 この仕様の旧バージョンは定義上グローバルなセットのマッピングについてこれをしました。 MIXERはMIXER Conformant Global Address Mapping(MCGAM)の概念を定義します。 この頭文字語が定義されるので、何が参照をつけられているかは、非常に明確です。
The X.400 and Internet Mail address spaces are hierarchical. It is possible to define an equivalence between two points in the hierarchies, such that addresses below that point can be derived in an algorithmic manner. An MCGAM is a mapping from a point in one hierarchy to a point in the other hierarchy. An "MGGAM pair" is a pair of symmetrical mappings between two points. To define an MCGAM, the following shall apply:
X.400とインターネットメールアドレス空間は階層的です。 階層構造で2ポイントの間の等価性を定義するのは可能です、アルゴリズムの方法でそのポイントの下のアドレスを引き出すことができるように。 1つの階層構造のポイントからもう片方の階層構造のポイントまでMCGAMはマッピングです。 「MGGAM組」は2ポイントの間の1組の対称のマッピングです。 MCGAMを定義するために、以下は申し込まれるものとします:
1. The authority defining the MCGAM shall have responsibility
for BOTH of the namespaces between which the MCGAM is
defined.
1. MCGAMを定義する権威はMCGAMが定義される名前空間のBOTHへの責任を持っているものとします。
Kille Standards Track [Page 43] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[43ページ]。
2. The authority defining the MCGAM is responsible to ensure
that addresses allocated below the two equivalence points
conform to the rules set out below.
2. 2等価ポイント未満まで割り当てられたアドレスが以下から出された規則に従うのを保証するのにおいてMCGAMを定義する権威は原因となります。
3. The authority defining the MCGAM is responsible to ensure
that addresses which are generated according to the MCGAM
are routed correctly.
3. MCGAMによると、作られるアドレスが正しく発送されるのを保証するのにおいてMCGAMを定義する権威は原因となります。
In general, MCGAMs will be independent. In some cases, a set of MCGAMs may be related (e.g., where one MCGAM defines a mapping for an organization and a second MCGAM defines an excpetion for a subtree within the organization). In this case, the related set of MCGAMs shall be treated as a single MCGAM for distribution purposes.
一般に、MCGAMsは独立するでしょう。 いくつかの場合、MCGAMsの1セットは関係づけられるかもしれません(例えば、どこで、1MCGAMが組織のためのマッピングを定義して、第2のMCGAMは下位木のために組織の中でexcpetionを定義しますか)。 この場合、MCGAMsの関連するセットは分配目的のために独身のMCGAMとして扱われるものとします。
The existence of an MCGAM does not imply routability and access for all users.
MCGAMの存在はすべてのユーザのためにroutabilityとアクセスを含意しません。
The authority defining an MCGAM may simply use this mapping locally. This will often be the case in a "local scenario" gateway. Because of third party addressing, a MIXER gateway will work best with the maximum number of MCGAMs. Therefore, three mechanisms are defined to enable publication and exchange of MCGAMs:
MCGAMを定義する権威は単に局所的にこのマッピングを使用するかもしれません。 これは「ローカルのシナリオ」ゲートウェイでしばしばそうになるでしょう。 第三者アドレシングのために、MIXERゲートウェイはMCGAMsの最大数でうまくいくでしょう。したがって、3つのメカニズムがMCGAMsの公表と交換を可能にするために定義されます:
1. Distribution of text tables. This is described in Appendix
F of this specification.
1. テキストテーブルの分配。 これはこの仕様のAppendix Fで説明されます。
2. Distribution by Domain Name Service. This is described in
RFC 2163 [3].
2. ドメイン名サービスによる分配。 これはRFC2163[3]で説明されます。
3. Distribution by X.500 Directory Service. This is defined
in RFC 2164 [26].
3. X.500ディレクトリサービスによる分配。 これはRFC2164[26]で定義されます。
The following sections define how the MCGAM namespace equivalence is modelled. The Internet Domain Namespace defines a simple hierarchy. For the purposes of this mapping, only parts of the namespace where domains conform to the EBNF domain-syntax are allowed.
以下のセクションはMCGAM名前空間の等価性がどうモデル化されるかを定義します。 インターネットDomain Namespaceは簡単な階層構造を定義します。 このマッピングの目的のために、ドメインがEBNFドメイン構文に従う名前空間の唯一の部品が許容されています。
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 used in MIXER as it is the one chosen by the various domain service administrations. In practice, it reflects all RFC 822 usage.
RFC822は、より一般的な構文を考慮しますが、この制限された構文は、それが様々なドメインサービス運営によって選ばれたものであるので、MIXERで使用されます。 習慣に、それはすべてのRFC822用法を反映します。
Kille Standards Track [Page 44] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[44ページ]。
The following OR Address attributes are considered as a hierarchy, and may be specified by the domain. They are (in order of the hierarchy defined by MIXER):
以下のOR Address属性は、階層構造であるとみなされて、ドメインによって指定されるかもしれません。 それらはこと(MIXERによって定義された階層構造の順に)です:
Country, ADMD, PRMD, Organization, Organizational Units
国、ADMD、PRMD、組織、組織的なユニット
There may be up to four ordered Organizational Units. This hierarchy reflects most usage of X.400, although X.400 may be used in other ways. In particular, it covers the Mnemonic OR Address using a 1984 compatible encoding. This is seen as the dominant form of OR Address. MCGAMs may only be used when this hierarchy applies.
最大4命令されたOrganizational Unitsがあるかもしれません。 X.400は他の方法で使用されるかもしれませんが、この階層構造はX.400のほとんどの使用法を反映します。 特に、それは、1984年のコンパチブルコード化を使用することでMnemonic OR Addressを覆っています。 これはOR Addressの優位なフォームと考えられます。 この階層構造が適用されるときだけ、MCGAMsは使用されるかもしれません。
An equivalence mapping is defined between two nodes in the respective hierarchies. For example:
等価性マッピングは2つのノードの間でそれぞれの階層構造で定義されます。 例えば:
=> "AC.UK" might be mapped with
PRMD="UK.AC", ADMD="GOLD 400", C="GB"
=>"AC.UK"はPRMD="UK.AC"と共に写像されるかもしれなくて、ADMDは「金400」と等しく、Cは「GB」と等しいです。
The mapping identifies that the management of these points in the respective hierarchies is the same (or co-operate very closely). The equivalence means that the namespaces below this equivalence point map 1:1, except where the mapping is overridden by further equivalence mappings lower down the hierarchy. This equivalence may be achieved in three ways:
マッピングは、それぞれの階層構造におけるこれらのポイントの管理が同じであることを特定します(非常に密接に協力してください)。 等価性は、この等価ポイントの下の名前空間が1:1を写像することを意味します、マッピングがさらなる等価性マッピングロワー・ダウンによって優越されるところを除いて。階層構造。 この等価性は3つの方法で達成されるかもしれません:
1. All of the nodes below this point are RFC 822, and the MIXER
mapping defines the X.400 addresses for these nodes.
1. このポイントの下のノードのすべてがRFC822です、そして、MIXERマッピングはこれらのノードのためのX.400アドレスを定義します。
2. All of the nodes below this point are X.400, and the MIXER
mapping defines the RFC 822 addresses for these nodes.
2. このポイントの下のノードのすべてがX.400です、そして、MIXERマッピングはこれらのノードのためのRFC822アドレスを定義します。
3. There are X.400 and RFC 822 nodes below this point, and
addressing is managed in a manner which ensures the
equivalence. The rules to achieve this are defined by
MIXER.
3. このポイントの下にX.400とRFC822のノードがあります、そして、アドレシングは等価性を確実にする方法で管理されます。 これを達成する規則はMIXERによって定義されます。
Each of these ways gives a framework for MCGAM definition.
それぞれのこれらの道はMCGAM定義のために枠組みを与えます。
When an MCGAM is defined, a systematic mapping for the inferior nodes in the two hierarchies follows. This is a 1:1 mapping between the nodes in the subtrees. For example, given the MCGAM pair defined above:
MCGAMが定義されるとき、2つの階層構造の劣ったノードのための系統的なマッピングは従います。 これは下位木におけるノードの間の1:1マッピングです。 例えば、MCGAMを考えて、上と定義されていた状態で対にしてください:
the domain "R-D.Salford.AC.UK" algorithmically maps with
OU="R-D", O="Salford", PRMD="UK.AC", ADMD="GOLD 400", C="GB"
algorithmicallyがOU="R-D"、O=「ソルフォード」PRMD="UK.AC"、ADMD=「GOLD400」C=「GB」で写像するドメイン「R-D.Salford.AC.UK」
Kille Standards Track [Page 45] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[45ページ]。
Note that when an equivalence is defined, that this can be re-defined for lower points in the hierarchy. However, it is not possible to declare contained subtrees to be un-mappable.
これを階層構造の何下限も再定義できるという等価性であるときに定義されるメモ。 しかしながら、含まれた下位木が不-mappableであると宣言するのは可能ではありません。
The equivalence mapping also provides a mechanism to deal with missing elements in the X.400 hierarchy (most commonly the PRMD, which is the only element that may be ommitted when conforming to recent versions of X.400). 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:
また、等価性マッピングは、X.400階層構造(最も一般的にX.400の最近のバージョンに従うときommittedされるかもしれない唯一の要素であるPRMD)でなくなった要素に対処するためにメカニズムを提供します。 ドメインはいくつかの現在のものに関連して省略された属性に関連しているかもしれません。 階層構造で、より低くコンポーネントのアルゴリズムの挿入を実行するとき、省略された値はスキップされるものとします。 例えば:
If there is an MCGAM pair between domain HNE.EGM" and "O=HNE",
"ADMD=ECQ", "C=TC", and omitted PRMD
「ドメインHNE.EGMの間には、MCGAM組があるか」、そして、"O=HNE"、"ADMD=ECQ"、「CはTcと等しい」、および省略されたPRMD
then
その時
"ZI.HNE.EGM" is algorithmically mapped with "OU=I", "O=HNE",
"ADMD=ECQ", "C=TC"
"ZI.HNE.EGM"は"OU=I"、"O=HNE"、"ADMD=ECQ"「C=Tc」でalgorithmicallyに写像されます。
Attributes may have null values, and this is treated separately from omitted attributes (while it is not ideal to make this distinction, it is useful in practice).
属性に、ヌル値があるかもしれません、そして、これは別々に省略された属性から扱われます(この区別をするのが理想的ではありませんが、それは実際には役に立ちます)。
4.2.1. Directory and Nameserver Mappings
4.2.1. ディレクトリとネームサーバマッピング
When a set of MCGAMs are supported by X.500 or DNS, there is the possibility that results will be indeterminate due to timeout. Lookup shall be repeated until a value is determined, in order to maintain consistent gateway operation.
MCGAMsの1セットがX.500かDNSによって支えられるとき、結果がタイムアウトで不確定になる可能性があります。 値が決定するまで、ルックアップは、一貫したゲートウェイ操作を維持するために繰り返されるものとします。
Where the mapping relates to an envelope address, the gateway shall non-deliver messages according to the associated MTA's normal timeout policy. Where the mapping relates to addresses in the message header, there shall be a timeout in the range of 1-4 hours or shorter if this is required to maintain quality of service constraints. If a mapping cannot be done in this time, address encapsulation shall be used.
マッピングが封筒アドレスに関連するところでゲートウェイが関連する、非、配送、関連MTAの通常のタイムアウト方針に従ったメッセージ。 マッピングがメッセージヘッダーでアドレスに関連するところに、これがサービスの質規制を維持するのに必要であるなら、タイムアウトが1〜4時間か、より短いことの範囲にあるでしょう。 今回マッピングができないなら、アドレスカプセル化を使用するものとします。
4.3. EBNF.822-address <-> MTS.ORAddress
4.3. EBNF.822-アドレス<->MTS.ORAddress
This section defines the basic address mapping.
このセクションは基本のアドレス・マッピングを定義します。
4.3.1. X.400 encoded in RFC 822
4.3.1. RFC822でコード化されたX.400
This section defines how X.400 addresses are represented in RFC 822 addresses.
このセクションはX.400アドレスがRFC822アドレスにどう表されるかを定義します。
Kille Standards Track [Page 46] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[46ページ]。
The std-or-address syntax is used to encode OR Address information in the 822.local-part of EBNF.822-address. Where there is an applicable equivalence mapping, further OR 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 OR 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 [10], and by the EBNF definition in SMTP.
stdかアドレス構文が、EBNF.822-アドレスの822.local-部分でOR Address情報をコード化するのに使用されます。 適切な等価性マッピングがあるところでは、さらなるOR Address情報は822.domainの部品に関連しています。 一般的なケースと、文字の組問題と、異なった属性タイプを使用するX.400 OR Addressesの異形にこれを使用できません。 ドメインで完全なPrintableString文字の組をコード化する唯一の方法は822.domain-審判構文(すなわち、822.atom)を使用します。 これは多くのシステムの上で問題を起こしそうです。ドメインの有効な文字の組が実際にはRFC822セットから減少するあります、ドメインコンベンションと方針[10]、およびSMTPとのEBNF定義で課された制限で。
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 OR 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.
822.local-部分に関連している822.domainはRFC822世界からゲートウェイを特定します。 この最終的な822.domainは、何らかの数のOR Address属性を決定するのに使用されるかもしれません。(そこでは、これが最初の役割と衝突しません)。 通常、ゲートウェイへのRFC822ルーティングは、両方の目的に使用される822.domainを容易にするためにセットアップされるでしょう。
In the case that there is no applicable equivalence mapping, all of the X.400 address is encoded in the 822.local-part and the 822.domain identifies the gateway to which the message is being sent. This technique may be used by the RFC 822 user for any X.400 address where the equivalence mapping is not known.
どんな適切な等価性マッピングもなくて、X.400アドレスのすべてが822.local-部分でコード化されます、そして、822.domainはメッセージが送られるゲートウェイを特定します。 このテクニックは等価性マッピングが知られていないどんなX.400アドレスにもRFC822ユーザによって使用されるかもしれません。
In the case that there is an applicable MCGAM, the maximum number of attributes are encoded in the 822.domain. The remaining attributes are encoded on the LHS, using the EBNF.std-or-address syntax. For example:
適切なMCGAMがあって、属性の最大数は822.domainでコード化されます。 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"
「マーケティング」「ウィジェット」"BTT"「Tc」MTS.CountryName=MTS.AdministrationDomainName=MTS.OrganizationName=MTS.OrganizationalUnitNames.value=MTS.PersonalName.surnameは"Linnimouth"と等しいです。
Kille Standards Track [Page 47] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[47ページ]。
MTS.PersonalName.initials = "J"
MTS.PersonalName.generation-qualifier = "5"
MTS.PersonalName.initialsは「J」MTS.PersonalName.generation-資格を与える人と= 「5インチ」等しいです。
on the basis of an MCGAM pair between:
MCGAMに基づいて、以下の間で対にしてください。
Domain: Widget.COM
OR Address: O="Widget", ADMD="BTT", C="TC"
ドメイン: Widget.COMかアドレス: ○ = 「ウィジェット」、ADMD="BTT"Cは「Tc」と等しいです。
Given the OR address, the domain Widget.COM is determined from the equivalence mapping and the next component is determined algorithmically to give Marketing.Widget.COM. The remaining attributes are encoded on the LHS in 822.local-part.
ORアドレスを考えて、ドメインWidget.COMは等価性マッピングから決心しています、そして、algorithmicallyに、次のコンポーネントがMarketing.Widget.COMに与えることを決定します。 残っている属性は822.local-部分のLHSでコード化されます。
There is a further mechanism to simplify the encoding of common cases, where the only attributes to be encoded on the LHS are (non- Teletex) Personal Name attributes which comply with the restrictions of 4.1.2. 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 OR Address, it would map with the RFC 822 address: J.Linnimouth@Marketing.Widget.COM.
唯一のLHSでコード化されるべき属性が.2に4.1の制限に従う(非テレテックス)の個人的なName属性であるよくある例のコード化を簡素化するために、さらなるメカニズムがあります。 これを達成するために、822.local-部分はEBNF.encoded-pnとしてコード化されるものとします。 前の例では、GenerationQualifierがOR Addressに存在していないなら、それはRFC822アドレスで以下を写像するでしょうに。 J.Linnimouth@Marketing.Widget.COM 。
From the standpoint of the RFC 822 Message Transfer System, the domain specification is used to route the message in the standard manner. The standard domain mechanisms are used to select appropriate gateways for the corresponding OR Address space. It is the responsibility of the management that defines the equivalence mapping to define routing in the manner which will enable the message to be delivered.
RFC822Message Transfer Systemの見地から、ドメイン仕様は、標準の方法によるメッセージを発送するのに使用されます。 標準のドメインメカニズムは、対応するOR Addressスペースに適切なゲートウェイを選択するのに使用されます。 提供されるべきメッセージを可能にする方法でルーティングを定義するのは、等価性マッピングを定義する経営者側の責任です。
4.3.2. RFC 822 encoded in X.400
4.3.2. X.400でコード化されたRFC822
The previous section showed a mapping from X.400 to RFC 822. In the case where the mapping was symmetrical and based on the equivalence mapping, this has also shown how RFC 822 is encoded in the X.400. This equivalence cannot be used for all RFC 822 addresses.
前項はX.400からRFC822までマッピングを示しました。 また、ケースの中とマッピングが対称であった等価性マッピングに基づいて、これはRFC822がX.400でどうコード化されるかを示しました。 すべてのRFC822アドレスにこの等価性を使用できません。
The general case is mapped by use of domain defined attributes. A (Printable String) 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 follows RFC 822, and RFC 1123 [10,16]. Domains shall always be fully qualified.
一般的なケースはドメインの定義された属性の使用で写像されます。 (印刷可能なString)ドメインの定義されたタイプ"RFC-822"は定義されます。 関連属性値はこの.3のセクション3.3仕様通りにコード化されたASCIIストリングです。 ASCIIストリングの解釈はRFC822、およびRFC1123[10、16]に続きます。 ドメインは完全にいつも資格があるものとします。
Kille Standards Track [Page 48] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[48ページ]。
Other OR Address attributes will be used to identify a context in which the OR Address will be interpreted. This might be a Management Domain, or some part of a Management Domain which identifies a gateway MTA. For example:
他のOR Address属性は、OR Addressが解釈される文脈を特定するのに使用されるでしょう。 これは、Management Domain、またはゲートウェイMTAを特定するManagement Domainの何らかの部分であるかもしれません。 例えば:
C = "GB"
ADMD = "GOLD 400"
PRMD = "UK.AC"
O = "UCL"
OU = "CS"
"RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK"
「Cs」"UCL"「金400」「GB」C=ADMD=PRMD="UK.AC"O=OU="RFC-822"は"Jimmy(a)WIDGET-LABS.CO.UK"と等しいです。
OR
OR
C = "TC"
ADMD = "Wizz.mail"
PRMD = "42"
"rfc-822" = "postel(a)venera.isi.edu"
"Wizz.mail"「Tc」C=ADMD=PRMDは「42インチ"rfc-822"は"postel(a)venera.isi.edu"と等しいこと」と等しいです。
Note in each case the PrintableString encoding of "@" as "(a)". In the second example, the "RFC-822" domain defined attribute is interpreted everywhere within the (Private) Management Domain. In the first example, further attributes are needed within the Management Domain to identify a gateway. Thus, this scheme can be used with varying levels of Management Domain co-operation.
「(a)」としてその都度"@"のPrintableStringコード化に注意してください。 2番目の例では、"RFC-822"ドメインの定義された属性は(個人的)の管理ドメインの中のいたる所で解釈されます。 最初の例では、さらなる属性が、ゲートウェイを特定するのにManagement Domainの中で必要です。 したがって、異なったレベルのManagement Domain協力と共にこの体系を使用できます。
There is a limit of 128 characters in the length of value of a domain defined attribute, and an OR Address can have a maxmimum of four domain defined attributes. Where the printable string generated from the RFC 822 address exceeds 128 characters, 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 (Printable String) DDA keywords are: RFC822C1; RFC822C2; RFC822C3. Longer addresses cannot be encoded.
ドメインの定義された属性の価値の長さにおける、128のキャラクタの限界があります、そして、OR Addressは4つのドメインの定義された属性のmaxmimumを持つことができます。 RFC822アドレスから生成された印刷可能なストリングが128のキャラクタを超えているところでは、追加ドメイン定義された属性は、最大512のキャラクタがコード化されるのを可能にするのに使用されます。 次のものが始められる完全に前にこれらの属性はいっぱいにされるものとします。 (印刷可能なString)DDAキーワードは以下の通りです。 RFC822C1。 RFC822C2。 RFC822C3。 より長いアドレスをコード化できません。
MIXER defines a representation of RFC 822 addresses in printable string domain defined attributes. Teletex domain defined attributes with a key of RFC-822, RFC822C1; RFC822C2; RFC822C3 shall not be generated. This is for backwards compatibility reasons.
MIXERは印刷可能なストリングドメイン定義された属性における、RFC822アドレスの表現を定義します。 テレテックスドメインはRFC-822、RFC822C1のキーで属性を定義しました。 RFC822C2。 RFC822C3を生成しないものとします。 これは遅れている互換性理由であります。
Kille Standards Track [Page 49] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[49ページ]。
Reception of these attributes in the manner defined below is mandatory. This is to allow the possibility for future versions of MIXER to allow generation of teletex domain defined attributes. Where the values of all of these teletex domain defined attributes are printable string characters, they shall be interpreted in the same way as the printable string domain defined attributes. If this is not the case, the printable string encoding translation shall be omitted. If both teletex and printable string attributes are present, this is valid if and only if they represent exactly the same RFC 822 address.
以下で定義された方法における、これらの属性のレセプションは義務的です。 これは、MIXERの将来のバージョンがテレテックスのドメインの定義された属性の世代を許容する可能性を許容するためのものです。 これらのテレテックスのドメインの定義された属性のすべての値が印刷可能なストリングキャラクタであるところでは、印刷可能なストリングドメインが属性を定義したので、同様に、彼らは解釈されるものとします。 これがそうでないなら、翻訳をコード化する印刷可能なストリングは省略されるものとします。 そして、テレテックスと印刷可能なストリング属性の両方が存在しているなら、これが有効である、彼らがまさに同じRFC822アドレスを表す場合にだけ。
4.3.3. Component Ordering
4.3.3. コンポーネント注文
In most cases, ordering of OR Address components is not significant for the mappings specified. However, Organizational 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:
多くの場合、指定されたマッピングには、OR Addressの部品の注文は重要ではありません。 しかしながら、Organizational 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
(Organizational 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 (right hand side or domain part). If
there is an Organization Attribute, it shall be to the right
of any Organizational Unit attributes. These requirements
are for the following reasons:
1. RFC822アドレスの地方の部分で使用されるようにMTS.ORAddressの(stdかアドレス)をコード化するテキスト。 オーダーが複数の値(組織的なUnit、およびDomain Defined Attributes)を持っているかもしれないそれらのコンポーネントに必要です。 822.stdかアドレスを作るとき、与えられたタイプの成分がRHS(正しい手の側かドメイン部分)で最も重要なコンポーネントと共に階層的順序にあるものとします。 Organization Attributeがあれば、どんなOrganizational Unit属性の右にはもそれがあるものとします。 これらの要件が以下の理由であります:
- Alignment to the hierarchy of other components in RFC
822 addresses (thus, Organizational Units will appear
in the same order, whether encoded on the RHS or LHS).
- RFC822アドレス(その結果、Organizational Unitsは同次に現れるでしょう、RHSかLHSでコード化されるか否かに関係なく)の他のコンポーネントの階層構造への整列。
- 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.
- それを確実にするために、ゲートウェイは一貫したアドレスを作ります。 これは、ともにエンドユーザを助けて、同じメッセージイドを生成するためのものです。
Kille Standards Track [Page 50] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[50ページ]。
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 Organizational Units (OU) in MTS.ORAddress, the
first OU in the SEQUENCE is the most significant, as specified
in X.400.
2. MTS.ORAddressのOrganizational 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, MIXER does not give additional implications on the ordering significance within X.400.
この注文がこのマッピングに義務的ですが、MIXERがX.400の中の注文意味で追加含意を与えないことに注意してください。
4.3.4. RFC 822 -> X.400 Basic Address Mapping
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 go to stage
II.
ステップ2を意志に発送されて、適用するドメインは引き出す1を上演します。撮影、(ことによるとヌル) セットの属性。 そして、ステージIIまで行ってください。
The gateway may reduce a source route address to this form by
removal of all but the last domain. In terms of the design
intentions of RFC 822, this would be an incorrect action. (Note
that an address of the form local%part@domain is not a source
route). However, in most cases, it will provide a better service
ゲートウェイはソースルート・アドレスをこのフォームに最後のドメイン以外のすべての取り外しで減少させるかもしれません。 RFC822の設計目標で、これは不正確な動作でしょう。 (フォーム local%part@domain のアドレスが送信元経路でないことに注意します。) しかしながら、多くの場合、それは、より良いサービスを提供するでしょう。
Kille Standards Track [Page 51] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[51ページ]。
to the end user, and is in line with the Internet Host
Requirements. This is a reflection on the common inappropriate
use of source routing in RFC 822 based systems, despite the
discussion in the Host Requirements [10]. Either approach, or
the intermediate approach of stripping only domain references
which reference the local gateway are conformant to this
specification.
エンドユーザ、インターネットHost Requirementsに沿って、あります。 これはRFC822のベースのシステムにおけるソースルーティングの一般的な誤用に関する反省です、Host Requirements[10]での議論にもかかわらず。 地方のゲートウェイに参照をつけるドメイン参照だけを剥取るアプローチか中間的アプローチのどちらかがこの仕様へのconformantです。
2. If the 822.local-part uses the 822.quoted-string encoding,
remove this quoting. If the resulting unquoted
822.local-part has leading space, trailing space, or two
adjacent spaces go to stage II.
2. 822.local-部分が822.quoted-stringコード化を使用するなら、この引用を取り除いてください。 結果になることが引用を終わったなら、822.local-部分には、スペースを引きずって、主なスペースがあるか、または2つの隣接している空間がステージIIまで行きます。
3. If the unquoted 822.local-part contains any characters not
in PrintableString, "{", "}", "*", and "$", go to stage II.
3. 引用を終わっている822.local-部分がどんなPrintableStringにも何かキャラクタを含んでいないなら「「」、」、「*」、および「$」はステージIIまで行きます。
4. Parse the (unquoted) 822.local-part according to the EBNF
EBNF.std-or-address-input. Checking of upper bounds shall
not be 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.
4. EBNF EBNF.stdかアドレス入力に従って、(引用を終わられます)822.local-部分を分析してください。 ここに上限の照合をしないものとします。 これであるなら、やり損ないを分析してください、そして、EBNF EBNF.encoded-pnに従って、地方の部分を分析してください。 これであるなら、やり損ないを分析してください、そして、ステージIIまで行ってください。 結果は1セットのタイプ/値の組です。
5. Associate the EBNF.attribute-value syntax (determined from
the identified type) with each value, and check that it
conforms. If not, go to stage II.
5. EBNF.attribute-value構文(特定されたタイプから断固とした)を各値に関連づけてください、そして、それが従うのをチェックしてください。そうでなければ、ステージIIまで行ってください。
6. If the set of attributes forms a valid X.400 address,
according to X.402, then go to step 9. All forms of X.400
address are allowed at this stage. Steps 7-8 default
attributes for certain types of OR Address.
6. X.402によると、属性のセットが有効なX.400アドレスを形成するなら、ステップ9に行ってください。 X.400アドレスのすべてのフォームが現在のところ、許容されています。 ステップ7-8 OR Addressのあるタイプのための省略時の属性。
7. If the set of attributes cannot form a mnemonic form of
X.400 address after addition of attributes which may be
derived from the EBNF.domain (C, ADMD, PRMD, O, OU), go to
stage II.
7. 属性のセットがEBNF.domain(C、ADMD、PRMD、O、OU)から得られるかもしれない属性の追加の後に簡略記憶フォームのX.400アドレスを形成できないなら、ステージIIまで行ってください。
8. Attempt to parse EBNF.domain as:
8. 以下としてEBNF.domainを分析するのを試みてください。
*( domain-syntax "." ) known-domain
*「(ドメイン構文、」、」、) 知られているドメイン
Where EBNF.known-domain is the longest possible match in the set
of MCGAMs being used by the gateway (described in Section 4.2).
EBNF.domain-syntax is the restricted domain syntax defined in
Section 4.2, to which all of the domain components shall conform
for the parse to be successful. If this fails, go to stage II.
EBNF.known-ドメインがゲートウェイ(セクション4.2では、説明される)によって使用されるMCGAMsのセットで可能な限り長いマッチであるところ。 EBNF.domain-構文はセクション4.2で定義された、制限されたドメイン構文です、ドメインコンポーネントのすべてがどれのために従うものとするかにうまくいくには、分析してください。 これが失敗するなら、ステージIIまで行ってください。
Kille Standards Track [Page 52] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[52ページ]。
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 MCGAM used identifies an
"omitted attribute", then this attribute shall 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.domain-構文コンポーネントによって含意された属性を割り当ててください: C、ADMD、PRMD、O、OU。 使用されるMCGAMが「省略された属性」を特定するとこの属性が系統的な配分で省略されることに注意してください。 この新しいコンポーネントであるなら上限(ADMD: 16; PRMD: 16; O: 64; OU: 32)を超えてくださいか、それは、4OUsに通じて、次に、属性が引き出されている状態で、ステージIIまで行くでしょう。
The attributes derived in this step (referred to as RHS
attributes) are merged with the ones derived from the LHS (step
6). In some cases, not all of the RHF attributes are used. LHS
attributes are all used. C will not be in the LHS attributes.
If ADMD is in the LHS attributes, only C is taken from the RHS
attributes. If PRMD is in the LHS attributes, C and ADMD are
taken from the RHS attributes. If O is on the LHS, C, ADMD and
PRMD (if present) are taken from the RHS attributes. In other
cases all RHS attributes are taken.
このステップ(RHS属性と呼ばれる)で引き出された属性はLHS(ステップ6)から得られたものに合併されています。 いくつかの場合、RHF属性のすべてが使用されているというわけではありません。 LHS属性はすべて使用されます。 CがLHS属性にないでしょう。 ADMDがLHS属性にあるなら、RHS属性からCだけを取ります。 PRMDがLHS属性にあるなら、RHS属性からCとADMDを取ります。 OがLHSにあるなら、RHS属性からC、ADMD、およびPRMD(存在しているなら)を取ります。 他の場合では、すべてのRHS属性を取ります。
9. 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.
9. 属性のセットがX.400で与えられているこのセットでMTS.ORAddress仕様と、そして、制限に一致していて、上限が全くどんな属性のためにも超えられていないのを確実にしてください。 そうでなければ、ステージIIまで行ってください。
10. Build the OR Address from this information.
10. この情報からOR 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 refers to a recipient on an RFC 822 system or that the encoding of the address is invalid. Such addresses shall be encoded in an X.400 OR Address using a domain defined attribute.
これにRFC822EBNF.822-アドレスが有効なX.400コード化でない場合にだけ達するでしょう。 これは、アドレスがRFC822システムの上の受取人について言及するか、またはアドレスのコード化が無効であることを含意します。 そのようなアドレスは、X.400 OR 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 OR Address in the manner described
below.
3. 以下で説明された方法における、OR Addressの残りを築き上げてください。
Kille Standards Track [Page 53] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[53ページ]。
It is not always 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 5.1.3.
長さの制限のためドメインの定義された属性をコード化するのはいつも可能であるというわけではありません。 限界がMTSレベルにおけるマッピングによって超えられているなら、ゲートウェイは問題のメッセージを拒絶するものとします。 これがIPMSレベルで起こると、動作はセクション5.1.3で議論するIPMSコード化に取られた方針存在によるでしょう。
Use Stage I, step 8, to generate a set of attributes to build the remainder of the address. The administrative equivalence of the mappings will ensure correct routing through X.400 to a gateway back to RFC 822.
Stage I、ステップ8を使用して、1セットの属性を生成して、アドレスの残りを築き上げてください。 マッピングの管理等価性はX.400を通してRFC822へのゲートウェイに正しいルーティングを確実にするでしょう。
If Stage I, step 8 does not generate a set of attributes or the address generated is unroutable, the remained of the OR address is generated as follows. The remainder of the OR address effectively identifies a source route to a gateway from the X.400 side. There are three cases, which are handled differently:
Stage I、ステップ8が1セットの属性を生成しないか、または作られたアドレスが非発送可能であるなら作る、残されて、ORアドレスは以下の通り作られます。 事実上、ORアドレスの残りはX.400側からゲートウェイに送信元経路を特定します。 3つのケースがあります:(ケースは異なって扱われます)。
SMTP Return Address
This shall be set up so that errors are returned through the
same gateway. Therefore, the OR Address of the local
gateway shall be used.
SMTP Return Address Thisがセットアップされるものとするので、誤りは同じゲートウェイを通して返されます。 したがって、地方のゲートウェイのOR 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.
IPMS Addresses Theseは、返答するために最適化されます。 一般に、メッセージがX.400世界の中でどこでも終わるかもしれないので、この最適化は変換されるRFC822アドレスに、適切なゲートウェイを特定します。 アドレスが発送される822.domainは、適切なゲートウェイを選択するのに使用されます。
In this case, it may be useful to use a non-local gateway,
which will optimise the reply address. This information
may be looked up in gateway tables in a manner equivalent to
the MCGAM lookup. Because of the similarity of lookup, the
three MCGAM lookup mechanisms (table, X.500, DNS) are also
available to look up this information. This information is
local, and a gateway may insert any appropriate (gateway)
OR Address. The longest possible match on the 822.domain
defines which gateway to use. This mechanism is used for
any part of the X.400 namespace for which it is desirable to
identify a preferred X.400 gateway in order to optimise
routing.
この場合、非地方のゲートウェイを使用するのは役に立つかもしれません。(ゲートウェイは回答アドレスを最適化するでしょう)。 この情報はMCGAMルックアップに同等な方法によるゲートウェイテーブルで調べられるかもしれません。 ルックアップの類似性のために、また、3つのMCGAMルックアップメカニズム(テーブル、X.500、DNS)も、この情報を調べるために利用可能です。 この情報はローカルです、そして、ゲートウェイはどんな適切な(ゲートウェイ)OR Addressも挿入するかもしれません。 822.domainにおける可能な限り長いマッチは、どのゲートウェイを使用したらよいかを定義します。 ルーティングを最適化して、このメカニズムは都合のよいX.400ゲートウェイを特定するのが望ましいX.400名前空間のどんな部分にも使用されます。
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 locally used MCGAMs.
写像でないのが822.domainに関して見つけられるなら、デフォルト値(通常地方のゲートウェイのもの)は使用されています。 局所的に使用されたMCGAMsを無視するのは決して適切ではありません。
Kille Standards Track [Page 54] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[54ページ]。
SMTP Recipient
As the RFC 822 and X.400 worlds are in principle fully
connected, there is no technical reason for this situation
to occur. In practice, this is not the case. In some cases,
routing may be configured to use X.400 to connect an RFC 822
island to the Internet. The information that this part of
the domain space is to be routed by X.400 rather than
remaining within the RFC 822 world shall be configured
privately into the gateway in question. X.400 routing shall
not make use of the presence of the RFC-822 DDA to perform
X.400 routing. The OR address shall then be generated in
the same manner as for an IPMS address, using the locally
available MCGAMs. 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.
SMTP Recipient As RFC822とX.400世界は原則として完全につなげられて、この状況が起こるどんな技術的な理由もありません。 実際には、これはそうではありません。 いくつかの場合、ルーティングは、RFC822島をインターネットにつなげるのにX.400を使用するために構成されるかもしれません。 ドメインスペースのこの部分がRFC822世界に残っているよりX.400によってむしろ発送されることであるという情報は問題のゲートウェイに個人的に構成されるものとします。 X.400ルーティングは、X.400ルーティングを実行するのにRFC-822 DDAの存在を利用しないものとします。 次に、ORアドレスはIPMSアドレスのように同じ方法で作られるものとします、局所的に利用可能なMCGAMsを使用して。ゲートウェイへのグローバルなドメインの定義が写像されて、重要な本件を支えることになっています、このマッピングの使用がリモートX.400アドレス(X.400ルーティング手順で発送できる)につながるとき。 RFC822からX.400までメッセージを変換すると決める基礎としてこのマッピングの情報を使用しないものとします。
Three examples are given, neither of which has applicable MCGAMs.
3つの例はどれに適切なMCGAMsがあるかがどちらも出されません。
Example 1: (Address not in "localpart" "@" "domainpart")
例1: (どんな"localpart""@""domainpart"のアドレスでないも)
@relay.co.uk:userb@host2
@relay.co.uk: userb@host2
maps to
地図
c=gb; a= ; p=uk.ac; o=mr; dd.rfc-822=(a)relay.co.uk:userb(a)host2;
c=gb。 =。 p=uk.ac。 o=mr。 dd.rfc-822=(a)relay.co.uk: userb(a)host2。
Example 2: (Address with non printablestring characters)
例2: (非printablestringしているキャラクタとのアドレス)
Tom_Harris@cs.widget.com
Tom_Harris@cs.widget.com
maps to
地図
c=us; a=MCI; P=relay; dd.rfc-822=Tom(u)Harris(a)cs.widget.com;
cは私たちと等しいです。 =MCI。 Pはリレーと等しいです。 dd.rfc-822はトム(u)Harris(a)cs.widget.comと等しいです。
Example 3: (Address with an entry for alter.net into the OR Address of Preferred Gateway table, pointing to c=gb; A=BTglobal; P=relay)
例3: (PreferredゲートウェイのAddressがテーブルの上に置くORへのalter.netのためのエントリーがあるc=gb; A=BTglobal; P=リレーを示すアドレス
postmaster@UK.alter.net
postmaster@UK.alter.net
maps to
地図
c=gb; a=BTglobal; P=relay; dd.rfc-822=postmaster(a)UK.alter.net;
c=gb。 a=BTglobal。 Pはリレーと等しいです。 dd.rfc-822=postmaster(a)UK.alter.net。
Kille Standards Track [Page 55] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[55ページ]。
4.3.4.1. Heuristic for mapping RFC 822 to X.400
4.3.4.1. RFC822をX.400に写像するためのヒューリスティック
The following heuristic, which relates to ordering of address components, may be used when mapping from RFC 822 to X.400. The ordering of attributes may be inverted or mixed, and so the following heuristics may be applied:
RFC822からX.400まで写像するとき、以下のヒューリスティック(アドレス構成要素の注文に関連する)は使用されるかもしれません。 属性の注文を逆にするか、または混ぜるかもしれないので、以下の発見的教授法は適用されるかもしれません:
If there is an Organization attribute to the left of any Org Unit
attribute, assume that the hierarchy is inverted. This is to
facilitate the situation where a user has input the attributes in
reverse hierarchical order. To do this the gateway shall first
map according to the order defined in 4.3.3. If this mapping
generates an address which X.400 address verification shows to be
invalid, this heuristic may be applied as an alternative to
immediate rejection of the address.
どんなOrg Unit属性の左へのOrganization属性もあれば、階層構造が逆さであると仮定してください。 これは、ユーザが逆の階層的順序における属性を入力した状況を容易にするためのものです。 これをするために、注文定義されたコネ4.3に従って、ゲートウェイは最初に、.3を写像するものとします。 このマッピングが、X.400アドレス検査が示しているアドレスが無効であると生成するなら、このヒューリスティックはアドレスの即座の拒絶に代わる手段として適用されるかもしれません。
4.3.5. X.400 -> RFC 822 Basic Address Mapping
4.3.5. X.400->RFC822の基本のアドレス・マッピング
There are two basic cases:
2つの基本的なケースがあります:
1. RFC 822 addresses encoded in X.400.
1. X.400でコード化されたRFC822アドレス。
2. "Genuine" X.400 addresses. This may include symmetrically
encoded RFC 822 addresses.
2. 「本物」のX.400アドレス。 これは対称的にコード化されたRFC822アドレスを含むかもしれません。
When an MTS Recipient OR Address is interpreted, gatewaying will be selected if there is a single "RFC-822" domain defined attribute present. In this case, use mapping A and in other cases, use mapping B.
MTS Recipient OR Addressが解釈されるとき、存在しているただ一つの"RFC-822"ドメイン定義された属性があると、gatewayingは選択されるでしょう。 この場合、マッピングA、および他の場合におけるBを写像する使用を使用してください。
RFC 1327 specified that this shall only be done when the gateway identfied is local or otherwise known, and identified the approach specified here as a pragmatic option. Experience has shown that this is effective in practice, despite theoretical problems.
RFC1327は、これをidentfiedされたゲートウェイが地方であるときに、するか、または別の方法で知っているだけであると指定して、ここで指定されたアプローチが実践的なオプションであると認識しました。 経験は、理論上の問題にもかかわらず、これが実際には有効であることを示しました。
If a gateway wishes to make a mapping in a manner similar to RFC 1327, but does not wish for this global interpretation (e.g., to support an RFC 822 local system, which does not use global addressing), then it may choose a private domain defined attribute, different to "RFC-822". An RFC 1327 gateway might be configurable to operate in this manner.
ゲートウェイが方法によるマッピングをRFC1327と同様にすることを願っていますが、このグローバルな解釈(例えばRFCがグローバルなアドレシングを使用しない822ローカルシステムであるとサポートする)を望んでいないなら、個人的なドメイン定義された属性を選ぶかもしれません、"RFC-822"に、異なります。 RFC1327ゲートウェイはこの様に作動するのにおいて構成可能であるかもしれません。
Mapping A
Aを写像します。
1. Map the domain defined attribute value to ASCII, as defined
in Chapter 3, and drop all other attributes.
1. 第3章で定義されるようにドメインの定義された属性値をASCIIに写像してください、そして、他のすべての属性を下げてください。
Kille Standards Track [Page 56] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[56ページ]。
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 shall 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
original values shall be used.
これらの変換はルックアップだけのためのものです。 EBNF.stdかアドレス・マッピングが4のように)使用されているなら、元の値は使用されるものとします。
2. The numeric country codes may be mapped to the two letter
values (as defined in ISO 3166). Global mappings are
usually only defined in terms of the ISO 3166 codes.
2. 数値国名略号は2つの手紙値に写像されるかもしれません(ISO3166で定義されるように)。 通常、グローバルなマッピングはISO3166コードで定義されるだけです。
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 local
set of MCGAMs. If no match is found, allocate the domain as
described below, and go to step 5. The default domain to be
used is the specification of the local gateway. A gateway
may use other domains according to private mapping tables or
heuristics. For example, it may choose a domain which it
knows to provide a free gateway service to the mapped
address.
3. 階層構造が4.3の.1と包含の省略された属性で指定したことに注意して、MCGAMsの地方のセットで関連ドメイン仕様を持っている最大のセットの属性を決定してください。マッチが全く見つけられないなら、以下で説明されるようにドメインを割り当ててください、そして、ステップ5に進んでください。 使用されるべきデフォルトドメインは地方のゲートウェイの仕様です。 個人的なマッピングテーブルか発見的教授法によると、ゲートウェイは他のドメインを使用するかもしれません。 例えば、それは自由なゲートウェイサービスを写像しているアドレスに提供するのを知っているドメインを選ぶかもしれません。
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
MCGAMs, 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について言及する場合では、発生しているドメインが正しくゲートウェイにルートを望んでいるのは、重要です。 一般に、これは慎重に達成されます。ゲートウェイがこのチェックをするどんな簡単な方法もMCGAMsないので定義で掘られるordinating RFCの共同822。 ゲートウェイへのルートではなく、使用されているのが、1つのコンポーネントだけがあるドメインがそうするということであるということである1つの規則。 発生しているドメインが正しくどんなルートもしないなら、まるでマッチが全く見つけられないかのようにアドレスは扱われます。
The gateway may also make use of a mapping equivalent to the
MCGAM mapping to determine the domain to use. This mapping
is done from the OR Address hierarchy. This is not a
global mapping, but is a routing style mapping from the OR
Address space, to enable a best choice domain to be
inserted. This mapping is supported by the three MCGAM
lookup mechanisms.
また、ゲートウェイはドメインが使用することを決定するMCGAMマッピングに同等なマッピングを利用するかもしれません。 OR Address階層構造からこのマッピングをします。 これは、最も良い特選しているドメインが挿入されるのを可能にするためにはグローバルなマッピングではありませんが、ORからAddressスペースを写像するルーティングスタイルです。 このマッピングは3つのMCGAMルックアップメカニズムによってサポートされます。
Kille Standards Track [Page 57] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[57ページ]。
4. The mapping identified in 3) gives a domain, and an OR
address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU.
For each successive component below the OR 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 OR
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 OR address shall be
encoded on the LHS. This is to ensure a reversible mapping. For
example, if there is an address /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で)特定されたマッピングはドメイン、およびORアドレス接頭語を与えます。 階層構造に従ってください: C、ADMD、PRMD、O、OU。 ORアドレス接頭語の下におけるそれぞれの連続したコンポーネントのために、どれが構文EBNF.domain-構文に従うか、(中で定義される、4.3、.1、)、次のサブドメインを割り当ててください。 822.local部分がヌルであるはずがないので、X.400アドレスの少なくとも1つの属性をサブドメインに写像しないものとします。 ORアドレス接頭語の属性が省略されると、ドメインコンポーネントに写像されて、これらは正しく唯一持つでしょう。 接頭語の下で省略された属性があるところでは、ORアドレスに残っているすべての属性がLHSでコード化されるものとします。 これは、リバーシブルのマッピングを確実にするためのものです。 例えば、アドレス/S=XX/O=YY/ADMD=A/C=NN/があって、/ADMD=A/Cであることのマッピング=NN/が使用されているなら、/S=XX/O=YY/はLHSでコード化されます。
5. If the address contains any attribute not used in mnemonic
form, then all of the attributes in the address shall be encoded
on the LHS in EBNF.std-or-address syntax, as described below.
5. アドレスが何か簡略記憶フォームで使用されない属性を含んでいるなら、アドレスの属性のすべてが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 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. Generation of the latter style is
strongly recommended.
簡略記憶フォームのアドレスにおいて、残っているコンポーネントが個人名コンポーネントであるなら.1、当時のEBNF.encoded-pnを4.2の制限に従わせるのは、822.local-部分を形成するために引き出されます。 他の場合では、残っているコンポーネントは、822.local-部分として単にEBNF.stdかアドレス構文を使用することでコード化されます。 必要なら、822.quoted-stringコード化は使用されています。 ↓これは法的な引用に関する例です: "a b" .c@x; 「b.c」@x。 どちらのフォームも作られるかもしれません。 後者のスタイルの世代は強く推薦されます。
Four examples are given.
4つの例が出されます。
Example 1: (Address with missing X.400 elements and no specific mapping rule for "o=sales; a=Master400; C=it", where a mapping exists for a=master400; C=it;)
例1: (要素を記述しますが、「o=販売; a=Master400; Cはそれと等しい」ようにマッピングがa=master400であるときに存在するなくなったX.400と共にどんな特定の配置規則も記述しないでください; Cはそれと等しいです;)
S=Support; O=sales; A=Master400; C=it;
Sはサポートと等しいです。 Oは販売と等しいです。 A=Master400。 Cはそれと等しいです。
maps to
地図
/S=Support/o=sales/@Master400.it
/Sはサポート/o= sales/@Master400.it と等しいです。
Kille Standards Track [Page 58] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[58ページ]。
Example 2: (Address with illegal characters in RFC822 generated domain if default hierarchical translation (specific mapping rule is existing for c=fr; a=atlas; p=autoroutes) is used)
例2: (デフォルトの階層的な翻訳(特定の配置規則はc=fr; =地図帳; p=オートルートに存在している)が使用されているなら、違法キャラクタがRFC822にあるアドレスはドメインを発生させました)
S=renseignements; O=Region Parisienne; P=autoroutes; A=atlas; C=fr;
S=renseignements。 Oは領域Parisienneと等しいです。 Pはオートルートと等しいです。 =地図帳。 Cはfrと等しいです。
maps to
地図
"/S=renseignements/o=Region Parisienne/"@autoroutes.fr
@autoroutes「/S=renseignements/oは領域Parisienne/と等しく」.fr
Example 3: (Address containing elements not mappable into RFC822 local part)
例3: (RFC822の地方の部分にmappableでない要素を含むアドレス)
S=Rossi; DD.cap=20100; DD.ph1=Via Larga 11; DDA.city=Milano; A=PtPostel; C=it;
Sはロッシィと等しいです。 DD.cap=20100。 Larga11を通したDD.ph1=。 DDA.cityはミラノと等しいです。 A=PtPostel。 Cはそれと等しいです。
maps to
地図
"/DD.cap=20100/DD.ph1=Via Larga 11/DD.city=Milano/S=Rossi/"@ptpostel.it
@ptpostel「Larga11/DD.cityを通した/DD.cap=20100/DD.ph1=はミラノ/S=ロッシィ/と等しく」.it
Example 4: (Address with an entry for A=ATT; C=us; into the domain of Preferred Gateway table, pointing to attmail.com)
例4: (A=ATT; C=私たちのためのPreferredゲートウェイテーブルのドメインへのエントリーがあるattmail.comを示すアドレス
G=Andy; S=Wharol; O=MMNY; A=ATT; C=us;
Gはアンディと等しいです。 S=Wharol。 O=MMNY。 =ATT。 Cは私たちと等しいです。
maps to
地図
/G=Andy/S=Wharol/O=MMNY@attmail.com
/Gはアンディ/S=Wharol/O= MMNY@attmail.com と等しいです。
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 送信元経路。(そこでは、反復が複数のゲートウェイの向こう側に起こります)。
Kille Standards Track [Page 59] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[59ページ]。
4.4.1. Recursive Mappings
4.4.1. 再帰的なマッピング
It is possible to supply an address which is recursive at a single gateway. For example:
1門で再帰的なアドレスを供給するのは可能です。 例えば:
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 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 received message will have the originator and any 3rd party X.400 OR Addresses in correct format (rather than doubly encoded). In cases (X.400 or RFC 822) where there is common agreement on gateway identification, then this will apply to multiple gateways.
定義されたマッピングは、1門の向こう側に対称であってリバーシブルです。 対称は(メール発破器タイプ)発送先リスト拡大の場合で特に役に立ちます。 例えば、X.400ユーザは彼が属すRFC822システムの上のリストに発信します。 受信されたメッセージは正しい形式(二倍コード化されているよりむしろ)で創始者とどんな第3パーティーX.400 OR Addressesも持つでしょう。 そして、ゲートウェイ識別の一般的な協定がある場合(X.400かRFC822)では、これは複数のゲートウェイに適用されるでしょう。
When a message traverses multiple gateways, the mapping will always be reversible, in that a reply can be generated which will correctly reverse the path. In many cases, the mapping will also be symmetrical, which will appear clean to the end user. For example, if countries "AB" and "XY" have RFC 822 networks, but are interconnected by X.400, the following may happen: The originator specifies:
メッセージが複数のゲートウェイを横断するとき、マッピングはいつもリバーシブルになるでしょう、正しく経路を逆にする回答が発生できるので。 多くの場合、また、マッピングは対称になるでしょう(エンドユーザにとってきれいに見えるでしょう)。 例えば、RFCには822のネットワークがありますが、国の「AB」と"XY"がX.400によってインタコネクトされるなら、以下は起こるかもしれません: 創始者は指定します:
Joe.Soap@Widget.PTT.XY
Joe.Soap@Widget.PTT.XY
Kille Standards Track [Page 60] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[60ページ]。
This is routed to a gateway, which generates:
これはゲートウェイに発送されます。(それは、以下を発生させます)。
C = "XY"
ADMD = "PTT"
PRMD = "Griddle MHS Providers"
Organization = "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 equivalences are defined. In other cases, the reversibility is more important, due to the (far too frequent) cases where RFC 822 and X.400 services are partitioned.
マッピングはマッピングの等価性が定義されるところで対称になるだけでしょう。 他の場合では、リバーシブルは、より重要です、RFC822とX.400サービスが仕切られる(はるかに頻繁過ぎる)のケースのため。
The syntax may be used to source route. THIS IS STRONGLY DISCOURAGED. For example:
構文は送信元経路に使用されるかもしれません。 これは強くがっかりしています。 例えば:
X.400 -> RFC 822 -> X.400
X.400->RFC822->X.400
C = "UK"
ADMD = "Gold 400"
PRMD = "UK.AC"
"RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR"
「C=「イギリス」ADMD=「金400インチのPRMD="UK.AC""RFC-822"=」/PN=デュバル/DD.Titleはマネージャ/(a)Inria.ATLAS.FRと等しいです」
This will be sent to an arbitrary UK Academic Community gateway by X.400. Then it will be sent by JNT Mail to another gateway determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This will then derive the X.400 OR Address:
これはX.400によって任意のイギリスのAcademic Communityゲートウェイに送られるでしょう。 そして、JNTメールはドメインInria.ATLAS.FR(FR.ATLAS.Inria)のそばで断固としたもう1つの門にそれを送るでしょう。 次に、これはX.400 OR Addressを引き出すでしょう:
C = "FR"
ADMD = "ATLAS"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
「デュバル」という"Inria"「ATLAS」「フラン」C=ADMD=PRMD=PN.S=「タイトル」は「マネージャ」と等しいです。
Kille Standards Track [Page 61] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[61ページ]。
Similarly:
同様に:
RFC 822 -> X.400 -> RFC 822
RFC822->X.400->RFC822
"/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu
@monet「西暦/ADMD/RFC-822=jj(a)seismo.css.gov/PRMD==BT/CはGB/と等しく」.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 OR Name, along with OR Address. The RFC 822 addresses are mapped onto the OR 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はOR Addressに伴うOR Nameの任意の部分です。 RFC822アドレスはOR Addressの部品に写像されます。 ディレクトリNameのための機能的マッピングが全くRFC822側にないとき、原文のマッピングは使用されています。 この仕様の目標に関してリバーシブルのための要件が全くありません。 第三者受取人に関して機能性のいくらかの損失がディレクトリ名だけを与えますが、これがディレクトリNamesに、完全なマッピングを加える重要な余分な複雑さより望ましく見えるところにあるかもしれません。
The Directory Name shall be represented within an RFC 822 comment using the comaptible formats of RFC 1484 or RFC 1485. It is recommended that the directory string format of RFC 1485 is used [24]. The User Friendly Name form of RFC 1484 may be used [25].
ディレクトリNameは、RFC822コメントの中にRFC1484かRFC1485のcomaptible形式を使用することで表されるものとします。 RFC1485のディレクトリ記号列の書式が中古の[24]であることはお勧めです。 RFC1484のUser Friendly Nameフォームは中古の[25]であるかもしれません。
4.6. MTS Mappings
4.6. MTSマッピング
The basic mappings at the MTS level are:
MTSレベルにおける基本のマッピングは以下の通りです。
1) SMTP originator ->
MTS.PerMessageSubmissionFields.originator-name
MTS.OtherMessageDeliveryFields.originator-name ->
SMTP originator
1) SMTP創始者->MTS.PerMessageSubmissionFields.originator-名前MTS.OtherMessageDeliveryFields.originator-名前->SMTP創始者
2) SMTP recipient ->
MTS.PerRecipientMessageSubmissionFields
MTS.OtherMessageDeliveryFields.this-recipient-name ->
SMTP recipient
2) SMTP受取人->MTS.PerRecipientMessageSubmissionFields MTS.OtherMessageDeliveryFields.this-受取人名義の->SMTP受取人
SMTP recipients and return addresses are encoded as EBNF.822-address.
SMTP受取人と返送先はEBNF.822-アドレスとしてコード化されます。
The MTS Originator is always encoded as MTS.OriginatorName, which maps onto MTS.ORAddressAndOptionalDirectoryName, which in turn maps onto MTS.ORName.
MTS OriginatorがMTS.OriginatorName、MTS.ORAddressAndOptionalDirectoryNameへのどの地図としていつもコード化されるか、どれ、順番に、MTS.ORNameに写像するか。
Kille Standards Track [Page 62] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[62ページ]。
4.6.1. RFC 822 -> X.400 MTS Mappings
4.6.1. RFC822->X.400 MTSマッピング
From the SMTP Originator, use the basic ORAddress mapping, to generate MTS.PerMessageSubmissionFields.originator-name (MTS.ORName), without a DirectoryName.
SMTP 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 SMTP recipient by the basic ORAddress
mapping.
基本のORAddressマッピングはSMTP受取人から受取人名のThisを得ます。
originator-report-request
This may either be set to "delivery-report", or set according to
SMTP extensions as set out in Appendix A.
創始者レポート要求ThisはAppendix Aを始められるように「配送レポート」に用意ができているか、またはSMTP拡張子に従って、用意ができるかもしれません。
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 MTS Mappings
4.6.2. X.400->RFC822MTSマッピング
The basic functionality is to generate the SMTP originator and recipients. There is information present on the X.400 side, which cannot be mapped into analogous SMTP services. For this reason, new RFC 822 fields are added for the MTS Originator and Recipients. The information discarded at the SMTP level will be present in these fields. In some cases a (positive) delivery report will be generated.
基本機能はSMTP創始者と受取人を発生させることです。 類似のSMTPサービスに写像できないX.400側の現在の情報があります。 この理由で、新しいRFC822分野はMTS OriginatorとRecipientsのために加えられます。 SMTPレベルで捨てられた情報はこれらの分野に存在するでしょう。 いくつかの場合、(積極的)の配送レポートは作られるでしょう。
4.6.2.1. SMTP Mappings
4.6.2.1. SMTPマッピング
Use the basic ORAddress mapping, to generate the SMTP 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)からSMTP創始者(返送先)を発生させてください。 MTS.ORName.directory-nameが存在しているなら、捨てられます。 それがユーザ4.6で説明されるように提示されることに注意してください。(.2 .2)。
The mapping uses the MTA level information, and maps each value of MTA.PerRecipientMessageTransferFields.recipient-name, where the responsibility bit is set, onto an SMTP recipient.
マッピングは、MTAの平らな情報を使用して、責任ビットが設定されるMTA.PerRecipientMessageTransferFields.recipient-名前の各値を写像します、SMTP受取人に。
Note:The SMTP recipient is conceptually generated from
MTS.OtherMessageDeliveryFields.this-recipient-name. This is done
by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and
generating an SMTP recipient according to the basic ORAddress
注意: SMTP受取人はMTS.OtherMessageDeliveryFields.this受取人名から概念的に発生します。 MTS.OtherMessageDeliveryFields.this受取人名を取って、基本的なORAddressに応じてSMTP受取人を発生させることによって、これをします。
Kille Standards Track [Page 63] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[63ページ]。
mapping, discarding MTS.ORName.directory-name if present.
However, if this model was followed exactly, there would be no
possibility to have multiple SMTP recipients on a single message.
This is unacceptable, and so layering is violated.
存在しているならMTS.ORName.directory-nameを捨てて、写像します。 しかしながら、このモデルがまさに従われているなら、複数のSMTP受取人がただ一つのメッセージにいる可能性が全くないでしょうに。 これが容認できないので、レイヤリングは違反されます。
4.6.2.2. Generation of RFC 822 Headers
4.6.2.2. RFC822ヘッダーの世代
Not all per-recipient information can be passed at the SMTP 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:".
SMTPレベルですべての1受取人あたりの情報を通過できるというわけではありません。 これは推論します、2の新しいRFC。822個のヘッダーが創造されます、RFC822受取人までこの情報を運ぶために。 これらの分野がそうである、「X400-創始者:」 そして、「X400-受取人:」
The "X400-Originator:" field is set to the same value as the SMTP 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-創始者:」 分野はSMTP創始者と同じ値に設定されます。 さらに、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. In this case, discard the per-recipient information.
複数のRFC822受取人がいれば、問題があります、そして、受取人の公開は禁止されています。 この場合、1受取人あたりの情報を捨ててください。
If any MTS.ORName.directory-name is present, it shall be represented in an 822.comment.
どれか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 described in Section 5.3.6. Other information is represented in an 822.comment 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 defined by redirect-comment.
MTS.OtherMessageDeliveryFields.orignallyが受取人名を意図したなら、リダイレクションが、存在していて、あったか、または発送先リスト拡大がありました。 発送先リスト拡大がaである、-、オプション、およびこれが交際する状態で表されるという情報を通信させてください、「dl拡大歴史:」 セクション5.3.6で説明された分野。 中、MTS.OtherMessageDeliveryFields.this受取人名に関連している822.commentに他の情報を表して、異なったRFCにメッセージを渡すかもしれない、数個が演説する822人の受取人、およびそう、「X400-受取人:」 分野には、そのようなコメントがあるかもしれません。 非論評された受取人はRFC822受取人です。 コメントのEBNFは再直接のコメントで定義されます。
Kille Standards Track [Page 64] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[64ページ]。
redirect-comment = redirect-first *( redirect-subsequent )
再直接のコメントは再直接の最初の*と等しいです。(再直接にその後)です。
redirect-first = "Originally To:" mailbox "Redirected on"
date-time "To:" redirection-reason
再直接の1番目は「元々のTo:」と等しいです。 メールボックス、「」 日付-時間「To:」では、向け直されます。 リダイレクション理由
redirect-subsequent = mailbox "Redirected Again on"
date-time "To:" redirection-reason
メールボックスが「Againを向け直した」再直接にその後の=は「To:」を日付で調節します。 リダイレクション理由
redirection-history-item = "intended recipient" mailbox
"redirected to" redirection-reason
"on" date-time
リダイレクション歴史項目=「意図している受取人」メールボックス、「」リダイレクション理由“on"日付-時間まで向け直されます。
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
/ "Directory Look Up"
/ "Alias"
リダイレクション理由は「ディレクトリは調べる」という/「受取人の割り当てられた交互の受取人」/「創始者の要求された交互の受取人」/「受取人のMdの割り当てられた交互の受取人」/「別名」と等しいです。
It is derived from MTA.PerRecipientMessageTransferFields.extension.redirection-history. The values are taken from the X.400(92) Implementor's guide (Version 13, July 1995). The first three values are in X.400(88). The fourth value is in X.400(92), but has the name "recipient-directory- substitution-alternate-recipient". An example of this with two redirects is:
MTA.PerRecipientMessageTransferFields.extension.redirection-歴史からそれを得ます。 値はX.400(92)作成者のガイド(1995年7月のバージョン13)から抜粋されます。 最初の3つの値がX.400(88)にあります。 4番目の値には、X.400(92)にありますが、名前「受取人ディレクトリ代替交互の受取人」があります。 2があるこの例が向け直す、あります:
X400-Recipients: postmaster@widget.com (Originally To:
sales-manager@sales.widget.com
Redirected on Thu, 30 May 91 14:39:40 +0100
To: Originator Requested 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受取人に関連している有益なストリングになるでしょう。 いくつかの場合、ストリング値は定義されます。 残りにおいて、ストリング値は作成者によって選ばれるものとします。 パラメタにデフォルト値があるなら、パラメタにそのデフォルト値があると、ノーコメントは挿入されるものとします。
requested-delivery-method
要求された発送方法
physical-forwarding-prohibited
"(Physical Forwarding Prohibited)".
「(禁止された物理的な推進)」という禁止された物理的な推進。
Kille Standards Track [Page 65] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[65ページ]。
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 SMTP is used, the behaviour is specified in Appendix A. In other cases, 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.
SMTPが使用されているなら、ふるまいはAppendix A.In他の場合で指定されます、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を特定します。
Kille Standards Track [Page 66] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[66ページ]。
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 OR 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 ORでは、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. Any
source routing shall be removed. 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 using a human oriented
mapping (as described in Section 3.5). If the string is not
null, it is assigned to IPMS.ORDescriptor.free-form-name.
そして、人間の指向のマッピングを使用することで(セクション3.5で説明されるように)このストリングは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 (false and none).
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 (as described in Section 3.5), and a IPMS.ORDescriptor with only an free-form-name component built from it.
822.group構造物が存在しているなら、どんな含まれている822.mailboxも、別々のIPMS.ORDescriptorを発生させるように同じくらい上でコード化されます。 無料のフォーム名のコンポーネントだけがそれから造られている状態で、822.groupはT.61(セクション3.5で説明されるように)、および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が出席しています。
Kille Standards Track [Page 67] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[67ページ]。
1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as
EBNF.822-address.
1. EBNF.822-アドレスとしてIPMS.ORDescriptor.formal-name(MTS.ORName)をコード化してください。
2a. If IPMS.ORDescriptor.free-form-name is present, convert it
to ASCII or T.61 (Section 3.5), and use this as the 822.phrase
component of 822.mailbox using the 822.phrase 822.route-addr
construct.
2a。 IPMS.ORDescriptor.freeフォーム名が存在しているなら、ASCIIかT.61(セクション3.5)にそれを変換してください、そして、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 an 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-181-333-7777)
(Tel+44-181-333-7777)
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)" may be appended to the address.
"(Receipt Notification Requested)" may be used to infer "(Non
Receipt Notification Requested)". 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リターン)」をアドレスに追加するかもしれません。 「(領収書Notification Requested)」は、「(通知が要求した非領収書)」を推論するのに使用されるかもしれません。 P1とP2情報を関連させる努力はゲートウェイがReceipt Notificationsを送るのを正当化できないくらい大きいです。
In RFC 1327, inclusion of these comments was mandatory.
Experience has shown that the clutter and confusion caused to
RFC 822 users does not justify the information conveyed.
Implementors are recommended to not include these comments.
Unless an application is found where retention of these comments
is desirable, they will be dropped from the next version.
RFC1327では、これらのコメントの包含は義務的でした。 経験は、RFC822ユーザに引き起こされた散乱と混乱が伝えられた情報を正当化しないのを示しました。 作成者はこれらのコメントを含まないためにお勧めです。 これらのコメントの保有が望ましいところで法則が見つけられないと、それらは次のバージョンから落とされるでしょう。
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 (see section 3.5), and used as 822.phrase within the RFC 822 822.group syntax. For example:
IPMS.ORDescriptor.formal-nameが欠けるなら、IPMS.ORDescriptor.freeフォーム名は、ASCII(セクション3.5を見る)に変換されて、822.phraseとしてRFC 822 822.group構文の中で使用されます。 例えば:
Free Form Name ":" ";"
「フォーム名を解放してください」:、」 ";"
Kille Standards Track [Page 68] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[68ページ]。
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, 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 provides fully reversible mappings when messages pass multiple times across the X.400/RFC 822 boundary.
822.msg-イドとIPMS.IPMIdentifierの間には、両方の道を写像する必要があります。 これは参照RFC822Message IDへのX.400 Receipt Notifications、Replies、およびCross Referencesを考慮します。(IDはゲートウェイ発生しているIDより望ましいです)。 リバーシブルの、そして、対称のマッピングは定義されます。 メッセージがX.400/RFC822境界の向こう側に複数の回を通過するとき、これは完全にリバーシブルのマッピングを提供します。
An important issue with messages identifiers is mapping to the exact form, as many systems use these ids as uninterpreted keys. The use of table driven mappings is not always symmetrical, particularly in the light of alternative domain names, and alternative management domains. For this reason, a purely algorithmic mapping is used. A mapping which is simpler than that for addresses can be used for two reasons:
メッセージ識別子の切迫した課題は正確なフォームへのマッピングです、多くのシステムが非解釈されたキーとしてこれらのイドを使用するとき。 テーブルの駆動マッピングの使用はいつも対称であるというわけではありません、特に代替のドメイン名、および代替の管理ドメインの見地から。 この理由で、純粋にアルゴリズムのマッピングは使用されています。 2つの理由にアドレスのためのそれを使用できるより簡単なマッピング:
- There is no major requirement to make message IDs "natural"
- メッセージIDを「自然に」するというどんな主要な要件もありません。
- There is no issue about being able to reply to message IDs.
(For addresses, creating a return path which works is more
important than being symmetrical).
- メッセージIDに答えることができることに関する問題が全くありません。 (アドレスにおいて、働いているリターンパスを作成するのは対称であるより重要です。)
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 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 constructed by building a string of syntax EBNF.id-loc from IPMS.IPMIdentifier.
822.msg-イドの822.domainは値の「MHS」に用意ができています。 822.msg-イドの822.local-部分は、IPMS.IPMIdentifierから構文EBNF.id-locのストリングを造ることによって、構成されます。
id-loc ::= [ printablestring ] "*" [ std-or-address ]
イド-loc:、:= [printablestringします] 「*」[stdかアドレス]
Kille Standards Track [Page 69] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[69ページ]。
EBNF.printablestring is the IPMS.IPMIdentifier.user-relative- identifier, and EBNF.std-or-address being an encoding of the IPMS.IPMIdentifier.user derived according to this specification. 822.local-part is derived from EBNF.id-loc, if necessary using the 822.quoted-string encoding. For example:
EBNF.printablestringによるこの仕様通りに引き出されたIPMS.IPMIdentifier.userのコード化であるIPMS.IPMIdentifier.user相対的な識別子と、EBNF.stdかアドレスです。 必要なら、822.quoted-stringコード化を使用して、EBNF.id-locから822.の地方の部分を得ます。 例えば:
<"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS>
「147 */Sはディートリッヒ/O=シーメンス/ADMD=DBP/C=DE/と等しい」という<@MHS>。
4.7.3.3. 822.msg-id -> IPMS.IPMIdentifier
4.7.3.3. 822. msg-イド->IPMS.IPMIdentifier
If the 822.local-part can be parsed as:
822.local-部分がそうすることができるなら、以下として分析されてください。
[ printablestring ] "*" [ std-or-address ]
[printablestringします] 「*」[stdかアドレス]
and the 822.domain is "MHS", then this ID was X.400 generated. If EBNF.printablestring is present, the value is assigned to IPMS.IPMIdentifier.user-relative-identifier. If EBNF.std-or-address is present, the OR 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かアドレスが存在しているなら、それから得られたOR 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 and omit IPMS.IPMID.user.
さもなければ、これはRFC822発生しているIDです。 この場合、角度支柱なしで822.msg-イドをコード化する印刷可能なストリングにIPMS.IPMIdentifier.userの相対的な識別子を設定してください、そして、IPMS.IPMID.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 "In-Reply-To:" and "References:", the encoding 822.phrase may be used as an alternative to 822.msg-id. To map from 822.phrase to IPMS.IPMIdentifier, assign IPMS.IPMIdentifier.user-relative- identifier to the phrase. When mapping from IPMS.IPMIdentifier for "In-Reply-To:" and "References:", if IPMS.IPMIdentifier.user is
「以下に対して」 そして、「以下に参照をつける」、コード化している822.phraseは822.msg-イドに代わる手段として使用されるかもしれません。 822.phraseから句へのIPMS.IPMIdentifier.user相対的な識別子のIPMS.IPMIdentifier、案配まで写像するために。 IPMS.IPMIdentifierから、「以下に対して」のために写像します。 IPMS.IPMIdentifier.userが参照箇所であるなら「以下に参照をつけます」。
Kille Standards Track [Page 70] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[70ページ]。
absent and IPMS.IPMIdentifier.user-relative-identifier does not parse as 822.msg-id, generate an 822.phrase rather than adding the domain MHS.
そして、休み、822.msg-イドとしてIPMS.IPMIdentifier.userの相対的な識別子を分析しないで、ドメイン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 implementation of this standard may recognise message IDs generated by RFC 987. This is not recommended.
ここで定義されたマッピングはRFC987で使用されるそれに異なっています、多くの場合における変えられたメッセージIDへのRFC987マッピングリードとして。 問題を修正するのは後方に互換性を保有するより望ましいです。 この規格の実現は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: Detailed Mappings
5.1. RFC822->X.400: 詳細なマッピング
The mapping of RFC 822/MIME messages to X.400 InterPersonal Messages is described in Sections 5.1.1 to 5.1.7. Mapping of NOTARY format delivery status notifications, which are all messages of type multipart/report and subtype delivery-status-notifications to X.400 delivery reports is covered in Section 5.1.8.
X.400 InterPersonal MessagesへのRFC822/MIMEメッセージに関するマッピングはセクション5.1で.1〜5.1に.7に説明されます。 NOTARY形式配送状態通知に関するマッピング。(通知はタイプに関するすべてのメッセージがセクション5.1.8でカバーされているという複合/レポートと「副-タイプ」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.
独身のIP MessageはRFC822メッセージから発生します。 RFC822ヘッダーは、IPMS.Headingを発生させるのに使用されます。
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で定義されます。 そして、これは既存のサービスに写像できない分野に使用されます。
Kille Standards Track [Page 71] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[71ページ]。
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分野リスト
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"). All 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 is generated from the RFC 822 message body in the manner described in Section 5.1.5.
このセクションの規則に従って、IPM(IPMS Service Request)は発生します。 IPMS.IPM.bodyはRFC822メッセージボディーからセクション5.1.5で説明された方法で発生します。
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としてコード化されます。 拡大見出し分野が発生するなら、後者はいつもケースになるでしょう。
Kille Standards Track [Page 72] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[72ページ]。
When generating the IPM, the issue of upper bounds are handled as follows. Truncate fields to the upper bounds specified in X.400. This will prevent problems with UAs which enforce upper bounds, but will sometimes discard useful information. This approach will cause more problems for some fields than others (e.g., truncating an OR Address component that would be used to route a reply would be a more severe problem than truncating a Free Form Name). If the Free Form name is truncated, it shall be done so that it does not break RFC 822 comments and RFC 1522 encoding.
IPMを発生させる上限の問題が以下の通り扱われるとき。 X.400で指定された上限に分野に先端を切らせてください。 これは、上限を実施するUAsに関する問題を防ぎますが、時々役に立つ情報を捨てるでしょう。 このアプローチは他のものよりいくつかの分野への問題を引き起こすでしょう(例えば、回答を発送するのに使用されるOR Addressの部品に先端を切らせるのは、Free Form Nameに先端を切らせるより厳しい問題でしょう)。 Free Form名が端が欠けているなら、RFC822コメントと1522年のRFCコード化を壊さないように、それをするものとします。
Note:This approach removes a choice of options given in RFC 1327,
based on operational experience.
注意: このアプローチは運用経験に基づいてRFC1327で与えられたオプションの選択を取り除きます。
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. Because X.400 does not have
the same From/Sender distinction as RFC 822, this mapping is not
always natural and may lead to unexpected results in some cases.
送付者: IPMS.Heading.originatorに写像されます。 X.400にはRFC822として同じFrom/送付者区別がないので、このマッピングは、いつも自然であるというわけではなく、いくつかの場合、予期しなかった結果につながるかもしれません。
Reply-To:
Mapped to IPMS.Heading.reply-recipients.
Reply-To IPMS.Heading.reply-受取人に写像されます。
Kille Standards Track [Page 73] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[73ページ]。
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 shall either be mapped to a zero length sequence or
mapped to a single recipient that has a free from name "BCC" and
no other addressing information. This alternate treatment is
allowed because some X.400 systems cannot handle a zero lenght
sequence of addresses.
Bcc: 少なくとも1つBCC:があれば、IPMS.Heading.blind-写し受信者に写像されます。 受取人。 受取人が全くこの分野になければ、それは、ゼロ・レングス系列に写像されるものとするか、または名前「BCC」にもかかわらず、他のアドレス指定情報がないのから自由行動ができる独身の受取人に写像されるものとします。 いくつかのX.400システムがアドレスのaゼロlenght系列を扱うことができないので、この代替治療は許容されています。
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 multiple values, this cannot be done as the X.400
heading is single valued. In this case no IPMS.Heading.replied-
to-IPM is generated and the values are mapped to
IPMS.Heading.related-IPMs, along with any values from a
"References:" field.
以下に対して 1つの値があれば、それは適宜IPMS.Heading.repliedからIPM、822.phraseを使用するか、または822.msg-イドマッピングに写像されます。 複数の値があれば、X.400見出しが評価されていた状態でただ一つであるので、これができません。 この場合、IPMS.Heading.repliedが全くIPMに発生しないで、値は、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 Section 3.3.4.
Subject: IPMS.Heading.subjectに写像されます。 分野本体はセクション3.3.4で参照をつけられる人間の指向のマッピングを使用します。
Comments:
Mapped onto a heading extension.
コメント: 見出し拡張子に写像されます。
This is a change from 1327, which specified to 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: " and that this body part shall precede the
other one. Experience has shown that this complexity is not
justified. This text is retained to facilitate backwards
compatibility.
これは1327年からの変化です。(ストリングが先行した分野の値を含んで、デフォルト(ia5)に用意ができているIPMS.IA5TextBodyPart.parameters.repertoireと共にタイプIPMS.IA5TextBodyPartのIPMS.BodyPartを発生させるように指定されて、その変化は「以下について論評します」)。 「そして、このボディーが離れているのがもう片方に先行するものとします。」 経験は、この複雑さが正当でないことを示しました。 本稿は、後方に互換性を容易にするために保有されます。
Encrypted:
Mapped onto a heading extension.
コード化される: 見出し拡張子に写像されます。
Resent-*
Mapped onto a heading extension.
*に憤慨する、見出し拡張子に写像されます。
Kille Standards Track [Page 74] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[74ページ]。
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、意味論が(論証上)わずかに異なっていて、それはたぶん努力の少しも価値があるのが、使用に可能でないことに注意してください。
Content-Language:
This field is defined in RFC 1766 [7]. Map the first two
characters of each value given onto the IPM Languages extension.
If any comments or values longer than two characters occur, a
header extension shall also be generated.
満足している言語: この分野はRFC1766[7]で定義されます。 IPM Languages拡張子に与えられたそれぞれの値の最初の2つのキャラクタを写像してください。 また、何か2つのキャラクタより長いコメントや値が起こるなら、ヘッダー拡大は発生するものとします。
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).
フィールズIn特定のX-*がさばいて、「不法入国者」が一般的な用法でさばく(例えば、「1日に実を結ばせてください」)もう一方は見出し拡張子に写像されます、この仕様の別のセクションか付録で覆われない場合。 同じ処理は分野の内容がRFC822(例えば、非分析可能構文がある日付:分野)に従わないRFC822分野に適用されます。
The mapping of the following headings is defined in RFC 2157.
以下の見出しに関するマッピングはRFC2157で定義されます。
MIME-Version: 5 Content-Transfer-Encoding: Content-Type Content-ID Content-Description
MIMEバージョン: 5 満足している転送コード化: コンテントタイプのコンテントIDの満足している記述
5.1.4. Generating the IPM Body
5.1.4. IPMボディーを発生させます。
Generation of the IPM Body is defined in RFC 2157.
IPM Bodyの世代はRFC2157で定義されます。
5.1.5. Mappings to the MTS Abstract Service
5.1.5. MTSの抽象的なサービスへのマッピング
The MTS.MessageSubmissionEnvelope comprises MTS.PerMessageSubmissionFields, and MTS.PerRecipientMessageSubmissionFields. The mandatory parameters are defaulted as follows.
MTS.MessageSubmissionEnvelopeはMTS.PerMessageSubmissionFields、およびMTS.PerRecipientMessageSubmissionFieldsを包括します。 義務的なパラメタはそうです。以下の通り、デフォルトとしました。
MTS.PerMessageSubmissionFields.originator-name
This is always generated from SMTP, as defined in Chapter 4.
MTS.PerMessageSubmissionFields.originator-名前Thisは第4章で定義されるようにSMTPからいつも発生します。
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 SMTP, as defined in Chapter 4.
第4章で定義されるようにSMTPからMTS.PerRecipientMessageSubmissionFields.recipient-名前Theseをいつも供給するでしょう。
Kille Standards Track [Page 75] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[75ページ]。
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.
- (信頼できる)の配送の機会を最大にするのが望ましく思えるように交互の受取人は許容されています。
If SMTP is used, Appendix A shall be followed in setting these parameters.
SMTPが使用されているなら、これらのパラメタを設定する際にAppendix Aに続くものとします。
The trace is set to indicate conversion (described below) and the encoded information types in the trace is derived from the message generated by the gateway, and shall reflect all body parts (including those in enclosed messages). In addition it shall include the Encoded Information Type "eit-mixer", which is defined in Appendix D. The presence of the EIT will indicate to the X.400 recipient that a MIXER conversion has occurred. MTS.PerMessageSubmissionFields.original-encoded-information-types will include all of the values used in the trace, unless specified otherwise in RFC 2157.
跡が、変換(以下で、説明される)と跡のコード化された情報タイプがゲートウェイで発生するメッセージから得られて、すべての身体の部分を反映するだろうというのを(同封のメッセージにそれらを含んでいます)示すように設定されます。 さらに、Type「eit-ミキサー」というEncoded情報を含めるものとして、どれがEITの存在のAppendix D.で定義されるかがMIXER変換が起こったのをX.400受取人に示すでしょう。 コード化された情報がタイプするMTS.PerMessageSubmissionFields.originalは別の方法でRFC2157で指定されない場合跡で使用される値のすべてを含むでしょう。
This type of conversion will prevent the normal loop detection from working in certain circumstances, and introduces the possiblity of gateway loops. MIXER gateways shall therefore count the number of MIXER conversions made. If this count exceeds five in one direction, the message shall be treated as if a loop has been detected.
このタイプの変換は、通常の輪の検出がある特定の状況では働くのを防いで、ゲートウェイ輪のpossiblityを導入します。 したがって、MIXERゲートウェイは変換が作ったMIXERの数を数えるものとします。 このカウントが5を一方向に超えているなら、まるで輪が検出されたかのようにメッセージは扱われるものとします。
The MTS.PerMessageSubmissionFields.content-correlator is encoded as IA5String, and contains the Subject:, Message-ID:, Date:, and To: fields (if present) in this order. This includes the strings "Subject:", "Date:", "To:", "Message-ID:", and appropriate folding to make the field appear readable. 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 shall 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).
MTS.PerMessageSubmissionFields.content-相関器は、IA5Stringとしてコード化されて、Subject:、Message-IDを含んでいます:、日付:、およびTo: これの分野(存在しているなら)は注文されます。 これがストリング「Subject:」、「日付:」、「To:」を含んでいる、「Message ID: 」 野原を読み込み可能に見えさせるように折り重なりを当ててください。 これはMTS.ub満足している相関器の長さの(512)キャラクタに先端を切られるものとします。 添加、a「Subject:」があります。 分野(MTS.PerMessageSubmissionFields.content識別子)はそれのコンテンツの印刷可能なストリング表現に設定されます。 「このストリングの長さはMTS.ubの満足しているイドの長さの(16)よりすばらしいです、それが13のキャラクタに先端を切られるものとするということであるかどうか、そして、ストリング」… 」 追加しています。 両方が満足している相関器のはるかに大きい上限のため使用されます、そして、満足しているイドはX.400(1984)で利用可能です。
Kille Standards Track [Page 76] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[76ページ]。
5.1.6. Mappings to the MTA Abstract Service
5.1.6. MTAの抽象的なサービスへのマッピング
There is a need to map directly onto some aspects of the MTA Abstract service, for the following reasons:
直接いくつかの以下の理由のための抽象的にMTAサービスの局面に写像する必要があります:
- So 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 and no Resent: fields are present, the
MTA.PerMessageTransferFields.message-identifier may be generated
from it, using the mappings described in Chapter 4.
メッセージイド: これは存在しているかどうか、そして、Resentがありません: 分野が存在している、第4章で説明されたマッピングを使用して、MTA.PerMessageTransferFields.message-識別子はそれから発生するかもしれません。
This mapping arguably generates messages which do not conform to
US GOSIP (1984 version only), which states:
このマッピングは論証上US GOSIP(1984年のバージョン専用)に従わないメッセージを発生させます。US GOSIPは以下を述べます。
6.7.e MPDU Identifier Validation
6.7. e MPDU識別子合法化
(1) Validation of the GlobalDomainIdentifier component of the MPDU
Identifier is performed on reception of a message (i.e. the result
of a TRANSFER.Indication).
(1) MPDU IdentifierのGlobalDomainIdentifierの部品の合法化はメッセージ(すなわち、TRANSFER.Indicationの結果)のレセプションに実行されます。
(2) The country name should be known to the validating domain, and
depending on the country name, validation of the
(2) 国の名は有効にするドメイン、および国の名による合法化に知られているべきです。
ADMD name may also be possible.
また、ADMD名も可能であるかもしれません。
(3) Additional validation of the GlobalDomainIdentifier is
performed against the corresponding first entry in the
TraceInformation. If inconsistencies are found during the
comparison, a non-delivery notice with the above defined reason
and diagnostic code is generated.
(3) GlobalDomainIdentifierの追加合法化はTraceInformationで対応する初記入に対して実行されます。 矛盾が比較の間、見つけられるなら、上記の定義された理由による非引渡通告書の、そして、診断しているコードは発生します。
(4) A request will be generated to the CCITT for a more meaningful
diagnostic code (such as "InconsistentMPUTIdentifier").
(4) 要求は、より重要な診断コード("InconsistentMPUTIdentifier"などの)のためにCCITTに発生するでしょう。
Kille Standards Track [Page 77] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[77ページ]。
This applies to ADMDs only, and is specified in the 1984 version and not the 1988 version. Conformance depends on the interpretation of "inconsistency". The specification makes the most sensible choice, and so is not being changed in the update from RFC 1327.
これは、ADMDsだけに適用して、1988年のバージョンではなく、1984年のバージョンで指定されます。 順応は「矛盾」の解釈によります。 仕様は最も分別がある選択をします、そして、RFC1327からアップデートでまた変えられないのも、そうです。
Date: (and Resent-Date:)
If one or more Resent-Date: fields is present, the most recent
Resent-Date: field shall be used instead of the Date: field in the
following description.
日付: (日付:に憤慨します) 1か、より多くのResent-日付:です。 分野は現在の、そして、最新のResent-日付:です。 分野は日付:の代わりに使用されるものとします。 以下の記述では、さばきます。
The Date: field is used to set the first component of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement). The SMTP 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)の最初の部品を設定するのに使用されます。 SMTP創始者は、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.
Processing of Received: lines follows processing of Date:, and is
done from the bottom to the top of the RFC 822 header (i.e., in
chronological order). When other trace elements (in particular
X400-Received:) are processed the relative ordering (top to
bottom of the header) shall be retained correctly.
受け取られている: すべてのRFC822跡が、MTA.PerMessageTransferFields.trace-informationとMTA.PerMessageTransferFields.internal-トレース情報を引き出すのに使用されます。 受け取って、処理する、: 線に日付:の処理に続いて、下部からRFC822ヘッダー(すなわち、年代順に)の先端までします。 他の微量元素(特に、X400受信する:)が処理されるとき、相対的な注文(ヘッダーの下部に付ける)は正しく保有されるものとします。
The initial element of MTA.PerMessageTransferFields.trace-
information shall be generated from Date: as described above,
unless the message has previously been in X.400, when it will be
derived from the X.400 trace information.
MTA.PerMessageTransferFields.trace情報の初期の要素は日付:から発生するものとします。 上で説明されるように、以前に、メッセージがX.400になかった場合、X.400からそれを得るときには情報をたどってください。
Kille Standards Track [Page 78] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[78ページ]。
For each Received: field, the following processing shall be done.
If the "by" part of the received is present and there is an
available MCGAM which can map this domain, use it to derive an
MTS.GlobalDomainIdentifier. Otherwise MTS.GlobalDomainIdentifier
is set from local information. 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.
Requirements on trace stripping are discussed below.
各Receivedのために: 分野、以下の処理は完了しているものとします。 受け取られていることの“by"部分が存在していて、このドメインを写像できる利用可能なMCGAMがあれば、それを使用して、MTS.GlobalDomainIdentifierを引き出してください。 さもなければ、MTS.GlobalDomainIdentifierはローカルの情報から用意ができています。 これがMTA.PerMessageTransferFields.trace情報(MTA.TraceInformationElement.globalドメイン識別子)の最後の要素のものと異なるなら、新しいMTA.TraceInformationElementを作成してください、そして、任意にMTA.PerMessageTransferFields.internal-トレース情報を取り除いてください。 以下で跡のストリップに関する要件について議論します。
Then add a new element (MTA.InternalTraceInformationElement) to
MTA.PerMessageTransferFields.internal-trace-information, creating
this if needed. This shall be done, even if nter-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-トレース情報に加えます。 nter-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分
Generates the string
ストリングを発生させます。
vs6.Cs.Ucl.AC.UK
vs6.Cs.Ucl.AC.UK
The gateway shall add in a single element of trace information, reflecting the gateway's local information and the time of conversion. The MTA.InternalTraceInformationElement.mta-supplied- information (MTA.MTASuppliedInformation) is set as follows:
ゲートウェイはトレース情報のただ一つの要素を加えるものとします、ゲートウェイのローカルの情報と変換の時間を反映して。 MTA.InternalTraceInformationElement.mtaによって供給された情報(MTA.MTASuppliedInformation)は以下の通り設定されます:
MTA.DomainSuppliedInformation.arrival-time
Set to the time of conversion
変換の時間までのMTA.DomainSuppliedInformation.arrival-time Set
MTA.DomainSuppliedInformation.routing-action
Set to relayed
リレーされることへのMTA.DomainSuppliedInformation.routing-動作Set
Kille Standards Track [Page 79] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[79ページ]。
MTA.AdditionalAcctions.converted-encoded-information-types Set to correct set of EITs for the message that is generated by the gateway. This trace element will thus reflect gateway operation as a conversion.
ゲートウェイで発生するメッセージのためにEITsのセットを修正するMTA.AdditionalAcctions.convertedが情報タイプをコード化しているSet。 その結果、この微量元素は変換としてゲートウェイ操作を反映するでしょう。
This trace generation will often lead to generation of substantial amounts of trace information, which does not reflect X.400 transfers. Stripping of some of this trace may be necessary in some operational environments. This stripping shall be considered a function of the associated X.400 MTA, and not of the MIXER gateway.
この跡の世代はしばしばかなりの量のトレース情報の世代につながるでしょう。(トレース情報はX.400転送を反映しません)。 この跡のいくつかから奪い取るのがいくつかの運用環境で必要であるかもしれません。 このストリップはMIXERゲートウェイではなく、関連X.400 MTAの機能であると考えられるものとします。
5.1.7. Mapping New Fields
5.1.7. 新しい分野を写像します。
This specification defines a number of new fields for Reports, Notifications and IP Messages. A gateway conforming to this specification shall map all of these fields to X.400, except as defined below.
この仕様はReports、Notifications、およびIP Messagesのために多くの新しい分野を定義します。 以下で定義されるのを除いて、この仕様に一致しているゲートウェイはこれらの分野のすべてをX.400に写像するものとします。
The mapping of two extended fields is particularly important, in order to prevent looping. "DL-Expansion-History:" is mapped to MTA.PerMessageTransferFields.extensions.dl-expansion-history X400- Received: shall 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 shall 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:.
2つの拡張分野のマッピングは、輪にするのを防ぐために特に重要です。 「dl拡大歴史:」 X400が受け取ったMTA.PerMessageTransferFields.extensions.dl拡大歴史に写像されます: MTA.PerMessageTransferFields.trace情報とMTA.PerMessageTransferFields.internal-跡情報に写像されるでしょう。 場合では、どこがX400受信されたか: 日付:がプレゼント、普通のマッピングがありますか? 跡の最初の要素を発生させるのは完了していないものとします。 これがメッセージがX.400から来たからであるX400を受け取られていさせた状態で、1日から跡の最初の要素を取ることができます:
The following fields shall not be mapped, and shall be
以下の分野は、写像しないで、あるものとします。
- Discarded-X400-MTS-Extensions:
- 捨てられたX400-MTS拡張子:
- Message-Type:
- メッセージタイプ:
- Discarded-X400-IPMS-Extensions:
- 捨てられたX400-IPMS拡張子:
- X400-Content-Type:
- X400-コンテントタイプ:
- X400-Originator:
- X400-創始者:
- X400-Recipients:
- X400-受取人:
- X400-MTS-Identifier: Mapping this field would be useful in
some circumstances, but very dangerous in others (e.g.,
following an internet list expansion). Therefore it is not
mapped.
- X400-MTS-識別子: この分野を写像するのは、いくつかの事情で役に立ちますが、他のもので非常に危険でしょう(例えば、インターネットリスト拡大に続きます)。 したがって、それは写像されません。
Kille Standards Track [Page 80] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[80ページ]。
5.1.8. Mapping Delivery Status Notifications to X.400
5.1.8. 配送状態通知をX.400に写像します。
5.1.8.1. Basic Model
5.1.8.1. 基本型
Internet Mail delivery status notifications (DSN) are mapped to X.400 delivery reports. With message mapping, information without a mapping is carried by an IPM Extension. This cannot be done for delivery reports. Two mechanisms are used for information where there is not a direct mapping.
インターネットメール配送状態通知(DSN)はX.400配送レポートに写像されます。 メッセージマッピングで、マッピングのない情報はIPM Extensionによって運ばれます。 配送レポートのためにこれができません。 2つのメカニズムがダイレクトマッピングがどこにないかという情報に使用されます。
The first mechanism is to define extensions, which allow all of the DSN information to be carried in the delivery report. This is not completely satisfactory for two reasons:
最初のメカニズムは拡大を定義することです。(拡大は、DSN情報のすべてが配送レポートで運ばれるのを許容します)。 これは2つの理由で完全に満足できるというわけではありません:
1. User defined extensions are supported by the ISO version of
the standard, but not the CCITT one. Therefore,
implementation support for these extensions will not be
universal.
1. ユーザの定義された拡大はCCITT1ではなく、規格のISOバージョンで後押しされています。 したがって、これらの拡大の実現サポートは普遍的にならないでしょう。
2. X.400 User Agent implementations will not in general
recognise these extensions. Therefore, although the
information will be present, it will often not be available
to the user. This may be very problematic, as this
information may be critical to diagnosing the reason for a
failure.
2. 一般に、X.400ユーザエージェント実現はこれらの拡大を認識しないでしょう。 したがって、情報は存在するでしょうが、それはしばしばユーザにとって利用可能になるというわけではないでしょう。 この情報が失敗の理由を診断するのに重要であるかもしれないようにこれは非常に問題が多いかもしれません。
Therefore a second mechanism is defined. This shall always be used when the DSN contains non-delivery information, and may be used in other cases. This mechanism is to map the whole DSN (as if it were an ordinary multipart) into the return of content. This will make the DSN information available as a text body part in the outer message, with the real returned content as an enclosed message. This mechanism will ensure that information is not lost at the gateway.
したがって、2番目のメカニズムは定義されます。 これは、DSNが非配送情報を含むとき、いつも使用されて、他の場合に使用されるかもしれません。 このメカニズムが全体のDSNを写像することである、(それがある、普通である、複合、)、内容の復帰に。 これで、DSN情報は外側のメッセージでテキスト身体の部分として利用可能になるでしょう、同封のメッセージとしての全く返された内容で。 このメカニズムは、情報がゲートウェイで失われていないのを確実にするでしょう。
5.1.8.2. DSN Extensions
5.1.8.2. DSN拡張子
Two X.400 MTS extensions are defined as follows:
2つのX.400 MTS拡張子が以下の通り定義されます:
dsn-header-list EXTENSION
RFC822FieldList
::= id-dsn-header-list
dsnヘッダーリストEXTENSION RFC822FieldList:、:= イドdsnヘッダーリスト
dsn-field-list EXTENSION
RFC822FieldList
::= id-dsn-field-list
dsn分野リストEXTENSION RFC822FieldList:、:= イドdsn分野リスト
Kille Standards Track [Page 81] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[81ページ]。
The Object Identifiers id-dsn-header-list and id-dsn-field-list are defined in Appendix D. Theses extensions are used in the same way as the IPM extension rfc-822-field, described in Section 5.1.2. These extensions may only be used with ISO-10021, and not X.400 (which does not allow user extensions at the MTS level).
Object Identifiersイドdsnヘッダーリストとイドdsn分野リストはAppendix D.で定義されます。セクション5.1.2で説明されたIPM拡大rfc822分野と同様に、Theses拡張子は使用されます。 これらの拡張子はX.400ではなく、ISO-10021(MTSでのユーザ拡大にレベルを許容しない)と共に使用されるだけであるかもしれません。
5.1.8.3. DSN to Delivery Report Mapping
5.1.8.3. 配送へのDSNは、写像すると報告します。
Some DSNs are mapped to Delivery Reports and some to IPMs, according to the value of the action field. The mapping to an IPM is exactly as for a normal IPM mapping. The choice of IPM and Delivery report is made for each reported recipient. If this choice is different for different reported recipients both a Delivery Report and an IPM shall be generated.
動作分野の値に従って、いくつかのDSNsがIPMsへのDelivery Reportsといくつかに写像されます。 IPMへのマッピングはちょうど正常なIPMマッピングに似ています。 それぞれの報告された受取人のためにIPMとDeliveryレポートの選択をします。 異なった報告された受取人にとって、この選択が異なるなら、Delivery ReportとIPMの両方が発生するものとします。
Reports are not be submitted in the X.400 model, and so the report submission is considered in terms of the MTA Abstract Service. An MTA.Report is constructed. The MTA.ReportTransferEnvelope.report- identifier is generated from the Message-Id of the DSN (if present) and otherwise generated as the MTA would generate one for a submitted message.
提出されたコネがX.400モデルであったならレポートがそうでないので、レポート提案はMTAの抽象的なServiceに関して考えられます。 MTA.Reportは組み立てられます。 DSNのMessage-イドから、発生します(存在しているなら)。別の方法で、MTAが提出されたメッセージのための1つを発生させるだろうというのに応じて、MTA.ReportTransferEnvelope.report識別子は、発生します。
The DSN has an RFC 822 header. Trace is mapped in the same manner as for a message to MTA.ReportTransferEnvelope.trace-information. All other headers are used to create a dsn-header-list extension, which is added to MTA.PerReportTransferFields.extensions. The DSN will have a single SMTP recipient. This is mapped to the MTA.ReportTransferEnvelope.report-destination-name.
DSNには、RFC822ヘッダーがあります。 跡はメッセージのように同じ方法でMTA.ReportTransferEnvelope.trace-informationに写像されます。 他のすべてのヘッダーが、dsnヘッダーリスト拡張子を作成するのに使用されます。(拡張子はMTA.PerReportTransferFields.extensionsに加えられます)。 DSNには、独身のSMTP受取人がいるでしょう。 これはMTA.ReportTransferEnvelope.report目的地名に写像されます。
The DSN is then treated as a normal MIME message, and an X.400 IPM is generated. This IPM is used as MTA.PerReportTransferFields.returned-content, and its type is used to set MTA.PerReportTransferFields.content-type. The DSN body part is mapped as if it was IA5 text/plain.
次に、DSNは正常なMIMEメッセージとして扱われます、そして、X.400 IPMは発生します。 このIPMはMTA.PerReportTransferFields.returned-内容として使用されます、そして、タイプは、MTA.PerReportTransferFields.content-タイプを設定するのに使用されます。 まるでそれがIA5テキスト/明瞭であるかのようにDSN身体の部分は写像されます。
The mandatory MTA.PerReportTransferFields.subject-identifier shall be generated from the DSN.per-message-field original-envelope-id, if this starts with the string "X400-MTS-Identifier: ", and derived from the rest of the field, which is encoded as EBNF.mts-msg-id. In other cases, this field shall be generated by the MIXER Gateway.
これがストリングから始まるなら義務的なMTA.PerReportTransferFields.subject-識別子がDSN.perメッセージ分野のオリジナルの封筒イドから発生するものとする、「X400-MTS-識別子:」 「EBNF.mts-msg-イドとしてコード化される分野の残りから、派生しています」。 他の場合では、この分野はMIXERゲートウェイによって発生するものとします。
All other mappings are made from the DSN body part. A dsn-field-list extension is created and added to MTA.ReportTransferFields.extensions. This is referred to as the per report extension list. The DSN.per-message-fields are mapped as follows:
他のすべてのマッピングがDSN身体の部分から作られます。 dsn分野リスト拡張子は、MTA.ReportTransferFields.extensionsに作成されて、加えられます。 これが呼ばれる、レポート拡張子単位で記載してください。 DSN.perメッセージ分野は以下の通り写像されます:
Kille Standards Track [Page 82] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[82ページ]。
original-envelope-id-field reporting-mta-field dsn-gateway-field received-from-mta-field arrival-date-field extension-field other
元の封筒イド分野の報告しているmta分野のdsnゲートウェイ分野のmta分野から容認された到着年月日欄拡大分野他です。
All of these fields are added to the per report extension list.
Currently there are no other mappings defined.
これらの分野のすべてが加えられる、レポート拡張子単位で記載してください。 現在、マッピングが定義したどんな他のものもいません。
Each reported recipient is considered in turn, and a MTA.PerRecipientReportTransferFields created for each. The parameters of this are defaulted as follows:
それぞれが、受取人が順番に考えられて、MTA.PerRecipientReportTransferFieldsがそれぞれのために創造したと報告しました。 このパラメタがそうである、以下の通り、デフォルトとします:
originally-specified-recipient-number
In general, these are not available, and so are assigned
incrementally.
元々指定された受取人番号In一般、これらは、利用可能でないので、増加して割り当てられます。
last-trace-information
The arrival-time is generated from DSN.arrival-date if present,
and if not from the Date: of the DSN. This is a strucutred field,
and the Report element contains the key information on the
recipient. For a DeliveryReport, the type-ofMTS-user is defaulted
to public and the message-deliery-time is set to the same as the
arrival-time. For a NonDeliveryReport, the code mappings are
define in Section 5.1.8.4.
到着時間がDSN.arrival-日付からそうでなければ、存在していて、日付:から発生するという最後のトレース情報 DSNについて。 これはstrucutred分野です、そして、Report要素は受取人の主要な情報を含んでいます。 DeliveryReportに関しては、タイプofMTSユーザはデフォルトとして、公衆とメッセージdeliery時間が到着時間と同じくらいに用意ができているということです。 NonDeliveryReportに関して、コードマッピングはそうです。セクション5.1.8では、.4を定義してください。
A dsn-field-list extension is created and added to MTA.PerRecipientTransferFields.extensions. This is referred to as the per recipient extension list. The DSN.per-recipient-fields are mapped as follows
dsn分野リスト拡張子は、MTA.PerRecipientTransferFields.extensionsに作成されて、加えられます。 これが呼ばれる、受取人拡大単位で記載してください。 DSN.per受取人分野は以下の通り写像されます。
original-recipient-field
Mapped to MTA.PerRecipientReportTransferFields.originally-
intended-recipient-name.
MTA.PerRecipientReportTransferFields.originallyの意図している受取人名への元の受取人分野Mapped。
final-recipient-field
Mapped to MTA.PerRecipientReportTransferFields.actual-recipient-
name.
MTA.PerRecipientReportTransferFields.actual-受取人名への最終受理者分野Mapped。
action-field
If this is set to "failed", a non-delivery report is generated.
If this is set to "delivered" a delivery report is generated.
Bit one or two of MTA.PerRecipientTransferFields.per-recipient-
indicators is set accordingly. This also controls the encoding of
MTA.PerRecipientTransferFields.last-trace-information, and the
selection of the report type.
Ifを動作してさばいてください。これは「失敗されること」に設定されて、非配送レポートは作られます。 これが「渡されること」に設定されるなら、配送レポートは作られます。 MTA.PerRecipientTransferFields.per-受取人インディケータのビット1かtwoはそれに従って、設定されます。 また、これはMTA.PerRecipientTransferFields.last-トレース情報のコード化、およびレポートタイプの選択を制御します。
Kille Standards Track [Page 83] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[83ページ]。
For other values of the action-field ("delayed", "relayed",
"expanded"), an IPM is generated. This enables the status
information to be communicated to the X.400 user, without the
confusion of multiple delivery reports.
動作分野(「遅らせられ」て、「リレーされ」て、「広げられた」)の他の値において、IPMは発生します。 これは、状態情報が多重配信レポートの混乱なしでX.400ユーザに伝えられるのを可能にします。
status-field
This is added to the per report extension list. For non-delivery,
it is also used to generate the reason and diagnostic codes
contained within MTA.PerRecipientReportTransferFields.last-trace.
The mappings are defined below.
状態分野Thisが加えられる、レポート拡張子単位で記載してください。 また、非配送において、それは、MTA.PerRecipientReportTransferFields.last-跡の中に保管されていた理由と診断コードを発生させるのに使用されます。 マッピングは以下で定義されます。
remote-mta-field
遠く離れたmta分野
diagnostic-code-field
診断コード分野
last-attempt-date-field
最後に年月日欄を試みてください。
will-retry-until-field
分野まで再試行するでしょう。
extension-field
拡大分野
other
All of these fields are added to the per recipient extension list.
これらの分野の他のAllが加えられる、受取人拡大単位で記載してください。
5.1.8.4. Status Value Mappings
5.1.8.4. 状態値マッピング
Status values are mapped to X.400 reason and diagnostic codes as follows.
状態値はX.400理由と以下の診断コードに写像されます。
If a status value is found that is not in this table, the gateway may use the same mapping as for "X.n.0" (1/None or 0/None), or it may map to another, configurable code. Implementors are requested to forward new codes to the mixer list for inclusion in future versions of this standard. So for instance. "5.2.37", currently undefined, would map onto the same as "5.2.0", namely 1/None.
このテーブルにない状態値が見つけられるなら、ゲートウェイが同じマッピングを使用するかもしれない、「X.n.0"、(1/、なにもか0/、なにも)、別のものの、そして、構成可能なコードに写像するかもしれない、」 作成者がこの規格の将来のバージョンでの包含のためのミキサーリストに新法を送るよう要求されています。 あまりに例えば。 「現在未定義の0.37インチが同じくらいに写像する5.2、「5.2、すなわち、0インチ、1/、なにも、」
Kille Standards Track [Page 84] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[84ページ]。
DSN code Meaning X400 code Meaning
DSNコードMeaning X400コードMeaning
X.0.0 Other status 1/None
X.0.0他の状態1/、なし
X.1.0 Other Address Status 1/None X.1.1 Bad mailbox address 1/0 Unrecognized X.1.2 Bad system address 1/0 Unrecognized X.1.3 Bad mailbox address syntax 1/0 Unrecognized X.1.4 Mailbox address ambiguous 1/1 X.1.5 Only used for positive reports, not applicable X.1.6 Destination mailbox has moved 1/43 New addr unknown X.1.7 Bad sender's mailbox address syntax 1/11 Invalid arguments X.1.8 Bad sender's system address 1/11 Invalid arguments
X.1.0他のAddress Status1/、X.1.1 Badメールボックスアドレス1/0Unrecognized X.1.2 Badシステムアドレス1/0Unrecognized X.1.3 Badメールボックスアドレス構文1/0Unrecognized X.1.4 Mailboxアドレスあいまいな1/1X.1.5 Onlyが適切なX.1.6 Destinationメールボックスではなく、積極的なレポートに使用しなかったなにも未知のX.1.7 Bad送付者のメールボックスアドレス構文1/11Invalid議論X.1.8 Bad送付者のシステムアドレス1/11Invalid議論の1/43New addrを動かしました。
X.2.0 Other or undefined mailbox status 1/None X.2.1 Mailbox disabled, not accepting 1/4 Recipient unavail X.2.2 Mailbox full 1/4 X.2.3 Message length exceeds admin limit. 1/7 Content too long X.2.4 Mailing list expansion problem 1/30 DL expansion fail
X.2.0の他の、または、未定義のメールボックス状態、X.2.1 Mailboxのいずれも無能にしなかった1/、Recipient unavail X.2.2 Mailboxが洗い張りする1/4を受け入れないで、1/4X.2.3 Messageの長さはアドミン限界を超えています。 満足している1/7の長過ぎるX.2.4 Mailingリスト拡大問題1/30DL拡大は失敗します。
X.3.0 Other or undefined system status 0/None X.3.1 System full 1/2 MTS congestion X.3.2 System not accepting network messages 1/2 MTS congestion X.3.3 System not capable of selected feat 1/18 Unsupp crit func X.3.4 Message too big for system 1/7 X.3.5 System incorrectly configured 1/None
X.3.0の他の、または、未定義のシステム状態、X.3.1 Systemのいずれもできない1/2のMTSの混雑のX.3.2 Systemの受け入れていないネットワークメッセージ1/2MTS混雑X.3.3 Systemを洗い張りしない0/が功績を選択した、1/18Unsupp crit func X.3.4 Message、1/7X.3.5 Systemが不当に構成したシステムには、大き過ぎる1/、なし
X.4.0 Other or undefined network or routing 0/None X.4.1 No answer from host 0/None X.4.2 Bad connection 0/None X.4.3 Routing server failure 6/None Dir op unsucc. X.4.4. Unable to route 0/None X.4.5 Network congestion 1/2 MTS congest. X.4.6 Routing loop detected 1/3 X.4.7 Delivery time expired 1/5
X.4.0他か未定義である、0/をネットワークでつなぐか、または発送して、なにもに、X.4.1ノー、がホスト0/からX.4.2 Badのいずれにも答えない、接続、0/、なにも、X.4.3ルート設定サーバの故障、6/、ディルオプアートunsuccでないなにも。 X.4.4。 なにもに0/を発送するために、X.4.5 Network混雑1/2MTSは充血します。 X.4.6ルート設定輪は1/3X.4.7 Delivery時間満期の1/5を検出しました。
X.5.0 Other or undefined protocol status 1/None
X.5.0もう一方か未定義のプロトコル状態1/、なし
X.5.1 Invalid command 1/14 Protocol viol. X.5.2 Syntax error 1/14 X.5.3 Too many recipients 1/16 X.5.4 Invalid command arguments 1/14 X.5.5 Wrong protocol version 1/18 Unsupp.crit.func
X.5.1の無効のコマンド1/14プロトコルビオール。 X.5.2構文エラー1/14X.5.3 Too多くの受取人1/16X.5.4 Invalidコマンド議論1/14X.5.5 Wrongプロトコルバージョン1/18 Unsupp.crit.func
Kille Standards Track [Page 85] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[85ページ]。
X.6.0 Other or undefined media error 2/None Conv. not perf X.6.1 Media not supported 1/6 EIT unsupp. X.6.2 Conversion required and prohibited 1/9 X.6.3 Conversion required but not supported 2/8 X.6.4 Conversion with loss performed POSITIVE only X.6.5 Conversion failed 2/47 Unable to downgrade
X.6.0の他の、または、未定義のメディア誤り、2/、なにもに、Conv perf X.6.1メディアでないのは1/6EIT unsuppを支持しませんでした。 禁止された1/9X.6.3 ConversionがX.6.5 Conversionだけが失敗した損失の実行されたPOSITIVEと共に2/8X.6.4 ConversionをX.6.2変換が必要であり、必要でしたが、支持しなかった、ダウングレードへの2/47Unable
X.7.0 Other or undefined security status 1/46 X.7.1 Delivery not authorized, message ref 1/29 No DL submit perm X.7.2 Mailing list expansion prohibited 1/28 X.7.3 Security conversion req but not poss 1/46 Secure mess. error X.7.4 Security features not supported 1/46 X.7.5 Cryptographic failure 1/46 X.7.6 Cryptographic algorithm not supported 1/46 X.7.7 Message integrity failure 1/46
1/46X.7.1 Deliveryが認可しなかったX.7.0の他の、または、未定義のセキュリティ状態、審判1/29ノーDLがパーマX.7.2 Mailingリスト拡大を提出するというメッセージはposs1/46Secure混乱ではなく、1/28X.7.3 Security変換reqを禁止しました。誤りX.7.4 Security機能は支持された1/46X.7.7 Message保全故障1/46ではなく、1/46X.7.5 Cryptographic故障1/46X.7.6 Cryptographicアルゴリズムを支持しませんでした。
5.1.8.5. DSNs that originated in X.400
5.1.8.5. X.400で起こったDSNs
The mapping of X.400 delivery reports to DSNs will in general provide sufficient information to make a useful reverse mapping. Messages will often be mapped multiple times, commonly due to forwarding messages and to distribution lists. Multiple mappings for delivery reports will be a good deal less common. For this reason, the reverse mapping of the X.400 DSN extensions defined in MIXER is optional.
一般に、DSNsへのX.400配送レポートに関するマッピングは、役に立つ逆のマッピングを作るために十分な情報を提供するでしょう。 メッセージはしばしば複数の回一般的に推進メッセージと発送先リストに写像されるでしょう。 配送レポートのための複数のマッピングが非常に一般的でなくなるでしょう。 この理由で、MIXERで定義されたX.400 DSN拡張子の逆のマッピングは任意です。
5.2. Return of Contents
5.2. コンテンツの復帰
RFC 1327 offered two approaches for return of content, as this service is optional in X.400 and expected in RFC 822. MIXER simply requires that a gateway requests the return of content service from X.400.
RFC1327は内容の復帰のための2つのアプローチを提供しました、このサービスがX.400で任意でRFC822で予想されているように。 MIXERは、ゲートウェイがX.400からコンテンツサービスの復帰を要求するのを単に必要とします。
5.3. X.400 -> RFC 822: Detailed Mappings
5.3. X.400->RFC822: 詳細なマッピング
5.3.1. Basic Approach
5.3.1. 基本的なアプローチ
A single RFC 822 message is generated from the incoming IP Message, Report, or IP Notification. All IPMS.BodyParts are mapped onto a single RFC 822 body. Other services are mapped onto RFC 822 header fields. Where there is no appropriate existing field, new fields are defined for IPMS, MTS and MTA services.
独身のRFC822メッセージは入って来るIPのMessage、Report、またはIP Notificationから発生します。 すべてのIPMS.BodyPartsが独身のRFC822ボディーに写像されます。 他のサービスはRFC822ヘッダーフィールドに写像されます。 どんな適切な既存の分野もないところでは、新しい分野はIPMS、MTS、およびMTAサービスのために定義されます。
The gateway mechanisms will correspond to MTS Delivery. As with submission, there are aspects where the MTA (transfer) services are also used. In particular, there is an optimisation to allow for multiple SMTP recipients.
ゲートウェイメカニズムはMTS Deliveryに対応するでしょう。 服従のように、局面がまたMTA(転送)サービスが利用されるところにあります。 複数のSMTP受取人を考慮するために、特に、最適化があります。
Kille Standards Track [Page 86] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[86ページ]。
5.3.2. RFC 822 Settings
5.3.2. RFC822設定
An RFC 822 Message has a number of mandatory fields in the RFC 822 Header. Some SMTP services mandate specification of an SMTP 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:
RFC822MessageはRFC822Headerに多くの義務的な分野を持っています。 いくらかのSMTPがSMTP Originatorの命令仕様を修理します。 これが任意である場合ではさえ、通常、値を指定するのは望ましいです。 以下のデフォルト(指定されたマッピングが値を引き出さないなら、使用されるものとする)は定義されます:
SMTP 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.
SMTP 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 SMTP Originator. If this is gateway generated, an appropriate
822.phrase shall be added.
From: これはマッピングによって発生させられないなら、それがSMTP 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/識別子と等しいです。
Kille Standards Track [Page 87] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[87ページ]。
built-in-eit = "Undefined" ; undefined (0)
/ "Telex" ; tLX (1)
/ "IA5-Text" ; iA5Text (2)
/ "G3-Fax" ; g3Fax (3)
/ "TIF0" ; tIF0 (4)
/ "Teletex" ; tTX (5)
/ "Videotex" ; videotex (6)
/ "Voice" ; voice (7)
/ "SFD" ; sFD (8)
/ "TIF1" ; tIF1 (9)
内蔵のeit=「未定義」。 未定義の(0)/「テレックス」。 tLX(1)/「IA5テキスト」。 iA5Text(2)/「G3ファックス」。 g3Fax(3)/"TIF0""。 tIF0(4)/「テレテックス」。 tTX(5)/「ビデオテックス」。 ビデオテックス(6)/「声」。 声の(7)/"SFD"。 sFD(8)/"TIF1""。 tIF1(9)
MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info. MTS.EncodedInformationTypes.non-basic-parameters is ignored. Built in types are mapped onto fixed strings (compatible with X.400(1984) and RFC 987), and other types are mapped onto EBNF.object-identifier.
MTS.EncodedInformationTypesはEBNF.encoded-インフォメーションに写像されます。 MTS.EncodedInformationTypes.nonの基本のパラメタは無視されます。 内蔵型は固定ストリング(X.400(1984)とRFC987とのコンパチブル)に写像されます、そして、他のタイプはEBNF.object-識別子に写像されます。
5.3.3.2. Global Domain Identifier
5.3.3.2. グローバルなドメイン識別子
The following simple EBNF is used to represent MTS.GlobalDomainIdentifier:
以下の簡単なEBNFはMTS.GlobalDomainIdentifierを表すのに使用されます:
global-id = std-or-address
グローバルなイドはstdかアドレスと等しいです。
This is encoded using the std-or-address syntax, for the attributes within the Global Domain Identifier.
これは、属性にGlobal Domain Identifierの中でstdかアドレス構文を使用することでコード化されます。
5.3.4. Mappings from the IP Message
5.3.4. IPメッセージからのマッピング
Consider that an IPM has to be mapped to RFC 822. The IPMS.IPM comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is considered first. Some EBNF for new fields is defined:
IPMがRFC822に写像されなければならないと考えてください。 IPMS.IPMはIPMS.IPM.headingとIPMS.IPM.bodyを包括します。 見出しは最初に、考えられます。 新しい分野へのいくらかのEBNFが定義されます:
ipms-field = "Supersedes" ":" 1*msg-id
/ "Expires" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Content-Language" ":" 1#language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier
/ "Autosubmitted" ":" autosubmitted
「=が「取って代わる」ipms-分野」:、」 「1*msgイド/は「期限が切れ」」:、」 「日付-時間/「近く、返答」」:、」 「日付-時間/「重要性」」:、」 「重要性/「感度」」:、」 「感度/"Autoforwarded"」:、」 「論理演算子/「不完全なコピー」」:、」 「/「満足している言語」」:、」 「1#言語/「メッセージタイプ」」:、」 「メッセージタイプ/「捨てられたX400-IPMS拡張子」」:、」 「1#物識別子/"Autosubmitted"」:、」 autosubmittedしました。
importance = "low" / "normal" / "high"
重要性=「安値」/「標準」/「高値」
Kille Standards Track [Page 88] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[88ページ]。
sensitivity = "Personal" / "Private" /
"Company-Confidential"
「個人的である」か「個人的な」/感度=「社内秘密」
language = 2*ALPHA [ "(" language-description ")" ]
language-description = printable-string
言語が2*アルファーと等しい、[「(「言語記述」)」] 言語記述は印刷可能なストリングと等しいです。
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
メッセージタイプは「配送レポート」/「個人間の通知」/「複数の部分」と等しいです。
autosubmitted = "not-auto-submitted"
/ "auto-generated"
/ "auto-replied"
/ "auto-forwarded"
「自動提出されていなかった」状態で=をautosubmittedした、/、「自動発生している」/、「自動返答する」、/、「自動進められる」。
The mappings and actions for the IPMS.Heading are 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 shall be discarded, except for IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC: (the only RFC 822 field which allows zero recipients).
IPMS.Headingのためのマッピングと動作は現在、各要素に指定されます。 第4章に従って、アドレスとMessage Identifiersは写像されます。 他のマッピングは、説明されるか、または簡単です(アルゴリズムの)。 アドレスがある分野が零元を含んでいるなら、それは捨てられるものとします、IPMS.Heading.blind-写し受信者を除いて。(その写し受信者を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。
Kille Standards Track [Page 89] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[89ページ]。
IPMS.Heading.obsoleted-IPMs
Mapped to the extended RFC 822 field "Supersedes:". The replaces
the RFC 1327 field "Obsoletes:". Reverse mapping of the RFC 1327
field may be supported.
拡張RFC822へのIPMS.Heading.obsoleted-IPMs Mappedは「Supersedes:」をさばきます。 取り替え、RFC1327分野は「以下を時代遅れにします」。 RFC1327分野の逆のマッピングは支持されるかもしれません。
IPMS.Heading.related-IPMs
Mapped to "References:".
IPMS.Heading.related-IPMs、写像される、「以下に参照をつけます」。
IPMS.Heading.subject
Mapped to "Subject:". The contents are converted to ASCII or T.61
(as defined in Section 3.5). CRLF will not be present in a valid
X.400 field. Any CRLF present are not mapped, but are used as
points at which the subject field shall be folded, unless an RFC
1522 encoding is used.
「Subject:」に写像されたIPMS.Heading.subject。 内容はASCIIかT.61に変換されます(セクション3.5で定義されるように)。 CRLFは有効なX.400分野に存在しないでしょう。 現在のどんなCRLFも写像されませんが、対象の分野が折り重ねられるものとするポイントとして使用されます、1522年のRFCコード化が使用されていない場合。
IPMS.Heading.expiry-time
Mapped to the extended RFC 822 field "Expires:". The replaces the
RFC 1327 field "Expiry-Date:". Reverse mapping of the RFC 1327
field may be supported.
拡張RFC822分野へのIPMS.Heading.expiry-時間Mappedは「以下を吐き出します」。 取り替え、1327がさばくRFCは「以下と満期でデートします」。 RFC1327分野の逆のマッピングは支持されるかもしれません。
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 RFC 822 field "Content-Language:", defined in RFC
1766 [7]. This mapping may be made without loss of information.
RFC822分野への言語Mapped、「満足している言語:」 RFC1766[7]では、定義されています。 このマッピングは情報の損失なしで作られているかもしれません。
auto-submitted
Map to the extended RFC 822 field "Autosubmitted:".
拡張RFC822分野への自動提出されたMap、「Autosubmitted:」
Kille Standards Track [Page 90] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[90ページ]。
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-拡張子:」
5.3.4.1. Mapping the IPMS Body
5.3.4.1. IPMSボディーを写像します。
The mapping of the IPMS Body is defined in RFC 2157.
IPMS Bodyに関するマッピングはRFC2157で定義されます。
5.3.4.2. Example Message
5.3.4.2. 例のメッセージ
An example message, illustrating a number of aspects is given below.
例のメッセージであり、多くの局面を例証するのを以下に与えます。
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
X400-Content-Type: P2-1984 (2)
X400-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>,
Tony Bates <tony@ean-relay.ac.uk>,
Steve Kille <S.Kille@cs.ucl.ac.uk>
Subject: Email Problems
Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary-1
受け取られている: 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)のX400の満足している識別子: メール問題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 MIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界=境界-1
--boundary-1 Content-Type: text/plain; charset=US-ASCII
--境界-1コンテントタイプ: テキスト/平野。 charsetは米国-ASCIIと等しいです。
Hope you gentlemen.......
あなた方紳士は望んでいます…
Kille Standards Track [Page 91] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[91ページ]。
Regards,
敬具
Stephen Harrison UK GOSIP Project
スティーブンハリソンイギリスのGOSIPプロジェクト
--boundary-1 Content-Type: message/rfc822
--境界-1コンテントタイプ: メッセージ/rfc822
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 Content-Type: multipart/mixed; boundary=boundary-2
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: リンクコンテントタイプをメールする応答: 複合か混ぜられる。 境界=境界-2
--boundary-2
--境界-2
Dear Mr Harrison......
親愛なるハリソンさん…
--boundary-2--
--境界-2--
--boundary-1--
--境界-1--
5.3.5. Mappings from an IP Notification
5.3.5. IP通知からのマッピング
Because of the service setting, IP Notifications will not usually need to be mapped by a MIXER gateway. A message is generated, with the following fields:
サービス設定のために、通常、MIXERゲートウェイによってIP Notificationsによって写像される必要はないでしょう。 メッセージは以下の分野で発生します:
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 shall 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に、セットします。
Kille Standards Track [Page 92] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[92ページ]。
Discarded-X400-IPMS-Extensions:
Used for any discarded IPN extensions.
捨てられたX400-IPMS拡張子: どんな捨てられたIPN拡張子においても、使用されています。
The following EBNF is defined for the body of the Message. This format is defined to ensure that all information from an interpersonal notification is available to the end user in a uniform manner.
以下のEBNFはMessageのボディーのために定義されます。 この書式は、エンドユーザには、個人間の通知からのすべての情報が一定の方法で利用可能であることを保証するために定義されます。
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
[ ipn-content-return ]
ipnボディー形式は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:"
ipn満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
日付-時間自動都合のよい受取人=メールボックス領収書時間=コメント=printablestring ipn-supplはprintablestringと等しいです。
Kille Standards Track [Page 93] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[93ページ]。
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated" / "IPM Deleted"
破棄して推論している=が「ユーザ購読は終えた」/を「吐き出す」か、または「時代遅れにした」、「IPMは削除した」/
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 shall 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 the
message is included. In this case, the message is formatted as
multipart/mixed, and the returned message included as
message/rfc822 after the text body part. 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-時間
Kille Standards Track [Page 94] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[94ページ]。
acknowledgement-mode
Mapped to EBNF.acknowledgement-mode
EBNF.acknowledgement-モードへの承認モードMapped
suppl-receipt-info
Mapped to EBNF.ipn-suppl
EBNF.ipn-supplへのsuppl領収書インフォメーションMapped
An example notification is:
例の通知は以下の通りです。
From: Steve Kille <steve@cs.ucl.ac.uk>
To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
Subject: 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
/ "X400-Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time
";"
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( object-identifier / labelled-integer )
「mts-分野=「X400-MTS-識別子」」:、」 「mts-msg-イド/「X400創始者」」:、」 「メールボックス/「X400受取人」」:、」 「1#メールボックス/「元のコード化された情報タイプ」」:、」 「コード化されたインフォメーション/「X400コンテントタイプ」」:、」 「mtsの満足しているタイプ/「X400の満足している識別子」」:、」 「printablestring/「優先権」」:、」 「優先権/「創始者返送先」」:、」 「1#メールボックス/「dl拡大歴史」」:、」 「メールボックス」;、」 「日付-時間」;、」 「/「変換」」:、」 「禁止/「損失との変換」」:、」 「禁止/「納品日」」:、」 「日付-時間/「捨てられたX400-MTS拡張子」」:、」 1#(ラベルされた物識別子/整数)
prohibition = "Prohibited" / "Allowed"
=が「禁止する」か、または「許容した」禁止
Kille Standards Track [Page 95] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[95ページ]。
mts-msg-id = "[" global-id ";" *text "]"
「mts-msg-イド=、「[「グローバルなイド」;、」 *テキスト、」、]、」
mts-content-type = "P2" / labelled-integer
/ object-identifier
mtsの満足しているタイプは「物ラベルされたP2"/整数/識別子」と等しいです。
priority = "normal" / "non-urgent" / "urgent"
優先権は「正常である」か「不急」の/と「緊急」の状態で等しいです。
The mappings for each element of MTS.MessageDeliveryEnvelope can now be considered. Where the specified action does not result in an extended element being mapped, the criticality associated with this element shall be considered. If the element is marked as critical for transfer or for delivery, the message shall be non delivered by the gateway because a critical extension cannot be correctly handled.
現在、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 SMTP originator, and to the extended RFC 822 field
"X400-Originator:". This is described in Section 4.6.2.
SMTP創始者と、そして、拡張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
The handling of these elements is described in Section 4.6.2.
これらの要素の取り扱いが説明されるこの受取人名と他の受取人名のセクション4.6.2。
Kille Standards Track [Page 96] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[96ページ]。
originally-intended-recipient-name
The handling of this element is described in Section 4.6.2.
この要素の取り扱いが説明される元々意図した受取人名のセクション4.6.2。
converted-encoded-information-types
Discarded. This information will be mapped in the trace.
変換されたコード化された情報タイプDiscarded。 この情報は跡で写像されるでしょう。
message-submission-time
Mapped to Date:.
日付:へのメッセージ服従時間Mapped。
content-identifier
Mapped to the extended RFC 822 field "X400-Content-Identifier:".
In RFC 1327, this was "Content-Identifier:". This has been
changed to avoid confusion with MIME defined fields. Gateways
which reverse map, may support the old field.
拡張RFC822分野に、「X400は識別子を満足する」という満足している識別子Mapped。 これがRFC1327では、そうであった、「満足している識別子:」 MIMEの定義された分野への混乱を避けるためにこれを変えました。 地図を逆にして、古い分野を支持するかもしれないゲートウェイ。
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 a comment, as described in Section 4.6.2.2.
コメントへの要求された発送方法Mappedセクション4.6.2で.2に説明されて、
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
創始者証明書のメッセージ象徴の満足している秘密性アルゴリズム識別子
Kille Standards Track [Page 97] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[97ページ]。
content-integrity-check message-origin-authentication-check message-security-label proof-of-delivery-request
配送要求の満足している保全チェックメッセージ起源認証チェックメッセージ機密保護ラベル証拠
These elements imply use of security services not available in the
RFC 822 environment. If they are marked as critical for transfer
or delivery, then the message 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 an extended RFC 822 field "DL-
Expansion-History:". These fileds shall be ordered in the message
header, so that the most recent expansion comes first (same order
as trace).
dl拡大歴史Each要素が拡張RFC822分野に写像される、「dl拡大歴史:」 メッセージヘッダーでこれらのfiledsを注文するものとします、最新の拡大が一番になる(跡と同じオーダー)ように。
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 SMTP 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.
SMTP受取人はX.400受取人の完全リストから計算されます。 ゲートウェイ(責任ビットは設定される)を通り抜けながら、これはMTA.MessageTransferEnvelope.per受取人分野のメンバーのすべてです。 いくつかの場合、異なったRFC822メッセージは各受取人のために計算されるでしょう、各受取人への異なったサービスのリクエストのため。 中で議論する、4.6、.2、.2、この仕様は発生するか、または1受取人あたりの情報が捨てられる複数のメッセージを考慮します。
Kille Standards Track [Page 98] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[98ページ]。
The following EBNF is defined for extended RFC 822 headers:
以下のEBNFは拡張RFC822ヘッダーのために定義されます:
mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
/ "Latest-Delivery-Time" ":" date-time
「mta-分野=は「X400受信」だった」:、」 「x400-跡/「延期した納入」」:、」 「日付-時間/「最新の納期」」:、」 日付-時間
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-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 not 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. X.400 does not make this information available at the MTS level on delivery, because it requires that this service is provided by the first MTA. In the event that the first MTA does not provide this service, 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レベルで利用可能にしません、このサービスが最初のMTAによって提供されるのが必要であるので。 最初のMTAがこのサービスを提供しない場合、機能はゲートウェイによって任意に実行されるかもしれません: 時間がプロトコル要素で指定するまで、すなわち、ゲートウェイはメッセージを保持するかもしれません。 したがって、過去に、通常、この要素の価値があるでしょう。 この理由で、拡張RFC822分野は主として情報のためのものです。
If MTA.PerMessageTransferFields.extensions.dl-expansion-prohibited is present and set to dl-expansion-probited, the gateway may reject that message on the basis that it is unable to control distribution list expansion beyond the gateway. The service relating to this is described in Section 2.3.1.2. This approach was not specified in RFC 1327. If it is found to be useful, it may be made mandatory in future versions of MIXER.
禁止されたMTA.PerMessageTransferFields.extensions.dl拡大が存在していて、拡大がprobitedしたdlに設定されるなら、ゲートウェイはゲートウェイを超えて発送先リスト拡大を制御できないというベースに関するそのメッセージを拒絶するかもしれません。 これに関連するサービスはセクション2.3.1で.2に説明されます。 このアプローチはRFC1327で指定されませんでした。 役に立つのがわかっているなら、それをMIXERの将来のバージョンで義務的にするかもしれません。
Kille Standards Track [Page 99] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[99ページ]。
If MTA.PerMessageTransferFields.extensions.recipient-reassignment- prohibited is present and set to recipeint-reassignment-probited, the gateway may reject that message on the basis that it is unable to control distribution list expansion beyond the gateway. The service relating to this is described in Section 2.3.1.2. This approach was not specified in RFC 1327. If it is found to be useful, it may be made mandatory in future versions of MIXER.
MTA.PerMessageTransferFields.extensions.recipient-再割当てによって禁止されているなら、存在していて、probitedされたrecipeint再割当てに設定されて、ゲートウェイはゲートウェイを超えて発送先リスト拡大を制御できないというベースに関するそのメッセージを拒絶するかもしれません。 これに関連するサービスはセクション2.3.1で.2に説明されます。 このアプローチはRFC1327で指定されませんでした。 役に立つのがわかっているなら、それをMIXERの将来のバージョンで義務的にするかもしれません。
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情報になるでしょう。
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 MD /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)、。 試みられたMD/ADMD=Foo/CはGB/と等しいです。 リレーされて、広げられて、向け直される。 火曜日、1989年6月20日の19:25:11+0100
The gateway itself shall add a single line of trace information, indicating MIXER conversion by use of a comment. For example:
コメントの使用でMIXER変換を示して、ゲートウェイ自体はトレース情報の単線を加えるものとします。 例えば:
Received: from isode.com by isode.com
(MIXER Conversion following RFC 1327);
Thu, 2 Jan 1997 14:46:03 +0000
受け取られている: isode.comごとに。 木曜日、1997年1月2日の14:46:03+0000
If SMTP is being used, Appendix A shall also be followed, which includes optional mappings to extension parameters.
また、SMTPが使用されているなら、Appendix A(拡大パラメタに任意のマッピングを含んでいます)は続かれるものとします。
Kille Standards Track [Page 100] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[100ページ]。
5.3.8. Mappings from Report Delivery
5.3.8. レポート配送からのマッピング
that only reports destined for the MTS user will be mapped. Some additional services are also taken from the MTA service. X.400 Delivery Reports are Mapped onto Delivery Status Notifications, as defined by NOTARY [28].
レポートだけがMTSユーザのために運命づけられたのは写像されるでしょう。 また、MTAサービスからいくつかの追加サービスを取ります。 Delivery Status Notifications NOTARY[28]によって定義されるようにX.400配送ReportsはMappedです。
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)と受取人分野単位で。
The enclosing message is a MIME message of content type multipart/report, with report-type=delivery-status, which is generated with the following fields:
同封メッセージは複合の、または、レポートタイプ=配送で以下の分野で発生する状態を報告している満足しているタイプに関するMIMEメッセージです:
From:
An administrator at the gateway system.
From: ゲートウェイシステムの管理者。
To: A mapping of the
MTA.ReportTransferEnvelope.report-destination-name. This is
also the SMTP recipient.
To: MTA.ReportTransferEnvelope.report目的地名に関するマッピング。 また、これはSMTP受取人です。
Message-Type:
Set to "Delivery Report". This is strictly redundant, but
retained for backwards compatibility with RFC 1327.
メッセージタイプ: 「配送レポート」にセットしてください。 これは、厳密に余分ですが、後方にようにRFC1327との互換性を保有しました。
Subject:
The EBNF for the subject line is:
Subject: 件名のためのEBNFは以下の通りです。
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
「(「状態」)」という受けることがある線=「配送レポート」[“for"の目的地]
status = "success" / "failure" / "success and failures"
状態=「成功」/「失敗」/「成功と失敗」
destination = mailbox / "MTA" word
目的地=メールボックス/"MTA"単語
The subject is intended to give a clear indication as to the nature of the message, and summarise its contents. EBNF.status is set according to whether the recipients reported on are all successes, all failures, or a mixture. It is common for a report to reference a single recipient, in which case a subject line giving using all of the options of EBNF.status can be used. This gives useful information to the recipient. Where information varies between reported recpients, the options cannot be used. The EBNF.destination is used to indicate the addresses in the reports. If the report is for a single address, EBNF.mailbox is used to give the RFC 822
対象は、メッセージの本質に関して明確な指示を与えて、コンテンツについて略言することを意図します。 EBNF.statusはオンであると報告された受取人がすべて、そうかどうかに従って成功、すべての失敗、または混合物を設定することです。 それは、独身の受取人であって、どれが件名をケースに入れるかで与えている参照へのEBNF.statusのオプションのすべてを使用するレポートは使用できるので、一般的です。 これは役に立つ情報を受取人に与えます。 情報が報告されたrecpientsの間で異なるところでは、オプションを使用できません。 EBNF.destinationは、レポートのアドレスを示すのに使用されます。 レポートがただ一つのアドレスのためのものであるなら、EBNF.mailboxは、RFC822に与えるのに使用されます。
Kille Standards Track [Page 101] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[101ページ]。
representation of the address. If all of the reported recpients reference the same MTA this is included in EBNF.word. The MTA is determined from the delivery report's trace.
アドレスの表現。 同じ報告されたrecpients参照MTAのすべてなら、これはEBNF.wordに含まれています。 MTAは配送レポートの跡から断固としています。
The format of the body of the message follows the NOTARY delivery status notification format, and 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 the gateway, with three body parts. The first body part is ASCII text structured as follows:
メッセージ欄の書式は、NOTARY配送状態通知形式に続いて、すべての情報が一貫した方法でRFC822ユーザに伝えられるのを保証するために定義されます。 形式はまるでそれが3つの身体の部分があるゲートウェイから来るメッセージであるかのように構造化されます。 最初の身体の部分は以下の通り構造化されたASCIIテキストです:
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. オンであると報告されるそれぞれの受取人の状態の人間の概要。
The second (mandatory) body part is the NOTARY delivery status notification, which contains detailed information extracted from the report. This information may be critical to diagnosing an obscure problem.
2番目の(義務的)の身体の部分はNOTARY配送状態通知です。(その通知はレポートから抜粋された詳細な情報を含みます)。 この情報は不鮮明な問題を診断するのに重要であるかもしれません。
The third (optional) body part contains the returned message (return of content). This structure is useful to the RFC 822 recipient, as it enables the original message to be extracted. For negative reports it shall be included if the original message is available. For positive reports headers from the message shall be included if the original message is available.
3番目の(任意)の身体の部分は返されたメッセージ(内容の復帰)を含んでいます。 抽出されるべきオリジナルのメッセージを可能にするとき、この構造はRFC822受取人の役に立ちます。 否定的な報告に関しては、オリジナルのメッセージが利用可能であるなら、それは含まれているものとします。 積極的なレポートに関しては、オリジナルのメッセージが利用可能であるなら、メッセージからのヘッダーは含まれているものとします。
The first body part containing the user oriented description is of type text/plain. The format of this body part is defined below as EBNF.dr-user-info.
ユーザ指向の記述を含む最初の身体の部分はタイプテキスト/直さいです。 この身体の部分の書式は以下でEBNF.drユーザインフォメーションと定義されます。
dr-user-info = dr-summary <CRLF>
dr-recipients <CRLF>
dr-content-return
drユーザインフォメーションは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-成功/故障
Kille Standards Track [Page 102] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[102ページ]。
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 report-point
= [ "mta" mta-name "in" ] global-id content-correlator = *word
mta-name = word
dr-recip-失敗=「あなたのメッセージは以下のことのために送られませんでした」。 メールボックス<CRLF>、「以下に関して、推論してください」 *単語レポートポイント=["mta"mta-名前“in"]グローバルなイド満足している相関器=*単語mta-名前=単語
EBNF.dr-summary
The EBNF.content-correlator is taken from the content correlator
(or content identifier if there is no content correlator) and the
EBNF.date-time from the trace, as described in Section 5.3.8.3.
LWSP may be added to improve the layout of the body part.
EBNF.content-相関器が取られるEBNF.dr-概要満足している相関器(どんな満足している相関器もなければ、識別子を満足させる)と中で説明されるとしての跡からのEBNF.date-時間セクション5.3 .8 .3。 LWSPは、身体の部分のレイアウトを改良するために加えられるかもしれません。
EBNF.dr-recipients
There is an element for each recipient in the delivery report. In
each case, EBNF.mailbox is taken from the RFC 822 form of the
originally specified recipient, which is taken from the originally
specified recipient element if present or from the actual
recipient. When reporting success, the message delivery time is
used to derive EBNF.date-time. When reporting failure, the
information includes a human readable interpretation of the X.400
diagnostic and reason codes, and the supplementary information.
EBNF.dr-受取人Thereは配送レポートの各受取人のための要素です。 その都度、EBNF.mailboxは元々指定された受取人のRFC822フォームから抜粋されます。(その受取人は、元々指定された受取人要素から存在していること、または、実際の受取人から連れて行かれます)。 成功を報告するとき、メッセージ納期は、EBNF.date-時間を引き出すために費やされます。 失敗を報告するとき、情報はX.400病気の特徴と理由コードの人間の読み込み可能な解釈、および補助情報を含んでいます。
EBNF.dr-content-return
This is set according to whether or not the content is being
returned.
内容を返しているかどうかに従って、EBNF.drの満足しているリターンThisは用意ができています。
The EBNF of this body part is designed for english-speaking users. The language of the strings in the EBNF may be altered.
この身体の部分のEBNFはenglishを話すユーザのために設計されています。 EBNFのストリングの言語は変更されるかもしれません。
Kille Standards Track [Page 103] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[103ページ]。
The EBNF used in the delivery status notification is:
配送状態通知で使用されるEBNFは以下の通りです。
dr-per-message-fields =
/ "X400-Conversion-Date" ":" date-time
/ "X400-Subject-Submision-Identifier" ":"
mts-msg-id
/ "X400-Content-Identifier" ":" printablestring
/ "X400-Content-Type" ":" mts-content-type
/ "X400-Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Originator-and-DL-Expansion-History" ":"
mailbox ";" date-time ";"
/ "X400-Reporting-DL-Name" ":" mailbox
/ "X400-Content-Correlator" ":" content-correlator
/ "X400-Recipient-Info" ":" recipient-info
/ "X400-Subject-Intermediate-Trace-Information" ":"
x400-trace
/ dr-extensions
「メッセージ分野あたりのdr=/「X400変換日付」」:、」 「日付-時間/「X400の対象のSubmision識別子」」:、」 「mts-msg-イド/「X400の満足している識別子」」:、」 「printablestring/「X400コンテントタイプ」」:、」 「mtsの満足しているタイプ/「オリジナルのコード化された情報がタイプするX400」」:、」 「コード化されたインフォメーション/「X400創始者とdl拡大歴史」」、:、」 「メールボックス」;、」 「日付-時間」;、」 「/「X400の報告しているdl名」」:、」 「メールボックス/「X400の満足している相関器」」:、」 「満足している相関器/「X400受取人インフォメーション」」:、」 「受取人インフォメーション/「X400の対象の中間的トレース情報」」:、」 dr x400-跡/拡張子
dr-per-recipient-fields =
/ "X400-Redirect-Recipient" ":" "x400" ";" std-or
/ "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox
/ "X400-Converted-EITs" ":" encoded-info ";"
/ "X400-Delivery-Time" ":" date-time
/ "X400-Type-of-MTS-User" ":" labelled-integer
/ "X400-Last-Trace" ":" [ encoded-info ] date-time
/ "X400-Supplementary-Info" ":"
<"> printablestring <"> ";"
/ "X400-Redirection-History" ":" redirect-history-item
/ "X400-Physical-Forwarding-Address" ":" mailbox
/ "X400-Originally-Specified-Recipient-Number" ":"
integer
/ dr-extensions
「受取人分野あたりのdr=/「X400の再直接の受取人」」:、」 「"x400"」;、」 または、「std、-、/、「X400は再直接の受取人を写像した」、」、:、」 「"rfc822"」;、」 「メールボックス/「X400の転向しているEITs」」:、」 「コード化されたインフォメーション」;、」 「/「X400-納期」」:、」 「日付-時間/「MTSユーザのX400タイプ」」:、」 「ラベルされた整数/、「X400は跡を持続する」、」、:、」 「[コード化されたインフォメーション]の日付-時間/「X400の補っているインフォメーション」」:、」 <「>のprintablestring<">"」。 「/「X400リダイレクション歴史」」:、」 「再直接の歴史項目/「X400の物理的なフォーワーディング・アドレス」」:、」 「メールボックス/「X400は元々、受取人番号を指定」であっていた」:、」 dr整数/拡張子
dr-extensions = "X400-Discarded-DR-Extensions" ":"
1# (object-identifier / labelled-integer)
「dr-拡大は「X400はDR拡張子を捨てたこと」と等しい」:、」 1# (ラベルされた物識別子/整数)
dr-diagnostic = "Reason" labelled-integer-2
[ ";" "Diagnostic" labelled-integer-2 ]
= 「推論してください」というdr-病気の特徴のラベルされた整数2[「」、;、ラベルされた「診断している」整数2]
A body part of type delivery status, as defined by NOTARY, is generated. MIXER extends this delivery status notification (DSN) specification, by defining additional per message fields in EBNF.dr- per-message-fields and additional per recipient fields in EBNF.dr- per-recipient-fields. These are used as extensions to DSN.per- message-fields and DSN.per-recipient-fields. MIXER also defines a new NOTARY address type "x400", with encoding of EBNF.std-or. A directory name may be inluded as an RFC 822 comment.
NOTARYによって定義されるタイプ配送状態の身体の部分は発生します。 そして、MIXERがメッセージ分野単位でEBNF.drでメッセージ分野あたり追加している定義でこの配送状態通知(DSN)仕様を広げている、EBNF.drで追加受取人分野あたり受取人分野あたり これらは拡大としてDSN.perメッセージ分野とDSN.per受取人分野に使用されます。 またはまた、MIXERがコード化がある新しいNOTARYアドレスタイプ"x400"を定義する、EBNF.std、-。 RFC822が論評するようにディレクトリ名はinludedされるかもしれません。
Kille Standards Track [Page 104] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[104ページ]。
The following DSN.per-message-fields are always generated:
以下のDSN.perメッセージ分野はいつも発生します:
DSN.reporting-mta-field
The DSN.mta-name-type is set to "x400", and this string is
reserved by MIXER. The DSN.mta-name has its syntax specified by
EBNF.report-point, with the information derived from the first
element of the DR's trace.
DSN.mta名前タイプが用意ができているDSN.reporting-mta-分野"x400"、およびこのストリングはそうです。MIXERによって予約されます。 DSN.mta-名前で、DRの跡の最初の要素から得られた情報で構文をEBNF.report-ポイント指定します。
DSN.arrival-date-field
This is derived from the date of the
MTA.PerRecipientReportTransferFields.last-trace-info.arrival-time
of the first recipient in the report.
レポートのMTA.PerRecipientReportTransferFields.lastが最初の受取人についてinfo.arrival-timeをたどることの日付からDSN.arrival-年月日欄Thisを得ます。
The following two EBNF.per-message-fields are generated by the MIXER gateway:
以下の2つのEBNF.perメッセージ分野がMIXERゲートウェイで発生します:
DSN.dsn-gateway-field
The type is set to "dns" and the domain set to the local domain
of the gateway.
タイプが用意ができているDSN.dsnゲートウェイ分野"dns"とドメインはゲートウェイの局所領域にセットしました。
X400-Conversion-Date:
The EBNF.date-time is set to the time of the MIXER conversion.
X400変換日付: EBNF.date-時間はMIXER変換の時間に決められます。
The elements of MTS.ReportDeliveryEnvelope.per-report-fields are mapped as follows onto the DSN per message fields as follows:
MTS.ReportDeliveryEnvelope.perレポート分野の要素は以下の通り以下のメッセージ分野あたりのDSNに写像されます:
subject-submission-identifier
Mapped to DSN.original-envelope-id-field. The encoding of this
MTS Identifier follows the format EBNF.mts-msg-id.
DSN.original封筒イド分野への対象の服従識別子Mapped。 このMTS Identifierのコード化は形式EBNF.mts-msg-イドに従います。
content-identifier
Mapped to X400-Content-Identifier:
X400の満足している識別子への満足している識別子Mapped:
content-type
Mapped to X400-Content-Type:
X400-コンテントタイプへの満足しているタイプMapped:
original-encoded-information-types
Mapped to X400-Encoded-Info:
X400がインフォメーションをコード化していたことへの元のコード化された情報タイプMapped:
The extensions from MTS.ReportDeliveryEnvelope.per-report- fields.extensions are mapped as follows:
MTS.ReportDeliveryEnvelope.per-レポートfields.extensionsからの拡大は以下の通り写像されます:
originator-and-DL-expansion-history
Each element is mapped to an "X400-Originator-and-DL-Expansion-
History:" They shall be ordered so that the most recent expansion
comes first in the header (same order as trace).
そして、創始者とDL拡大歴史Each要素が写像される、「X400-創始者、-、-、dl拡大歴史:、」 それらが注文されるものとするので、最新の拡大はヘッダー(跡と同じオーダー)で一番になります。
Kille Standards Track [Page 105] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[105ページ]。
reporting-DL-name
Mapped to X400-Reporting-DL-Name:
dl名を報告するX400に写像された報告しているdl名:
content-correlator
If the content correlator starts with the string "SMTP/NOTARY
ENVID: ", then the remainder of the content correlator is mapped
to the DSN original-envelope-id field. If this is not the case,
the content correlator is mapped to X400-Content-Correlator:,
provided that the encoding is IA5String (this will always be the
case).
満足している相関器がストリングから始動する満足している相関器If、「SMTP/公証人ENVID:」 「そして、満足している相関器の残りはDSNオリジナルの封筒イド分野に写像されます」 これがそうでないなら、満足している相関器はX400の満足している相関器に写像されます:、コード化がIA5String(これはいつもそうになる)であれば。
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. They
shall be listed in the X400-Discarded-DR-Extensions: field.
誤りがリモートMTAにないと、これらのセキュリティパラメタは存在しないでしょう。 存在しているなら、全体のレポートを捨てることに優先してそれらは捨てられるものとします。 X400がDR拡張子を捨てたところにそれらは記載されているものとします: さばきます。
If there are any other DR extensions, they shall also be discarded and listed in the X400-Discarded-DR-Extensions: field.
他のDR拡張子があれば、また、X400がDR拡張子を捨てたところに、それらは、捨てられて、記載されるものとします: さばきます。
For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields, a set of DSN.per-recipient-fields is generated. The fields are filled in as follows:
MTS.ReportDeliveryEnvelope.per受取人分野の各要素において、1セットのDSN.per受取人分野は発生します。 分野は以下の通り記入されます:
actual-recipient-name
If originally-intended-recipient-name is not present, generate a
DSN.original-recipient-field fields, with DSN.address-type of
"rfc822", and with an RFC 822 mailbox generated from the address
encoded as specified by NOTARY. Also generate a DSN.final-
recipient-field field, which holds the X.400 representation of the
same address. If the directory name is present, it shall be added
as a trailing comment in the X.400 form.
実際の受取人名のIf、元々意図した受取人名は存在していなくて、a DSN.original受取人分野分野を発生させてください、"rfc822"、およびRFC822メールボックスがNOTARYによって指定されるようにコード化されたアドレスから発生しているDSN.address-タイプで。 また、DSN.final受取人分野分野を発生させてください。(それは、同じアドレスのX.400表現を保持します)。 ディレクトリ名が存在しているなら、それは引きずっているコメントとしてX.400フォームで加えられるものとします。
If originally-intended-recipient-name is present, generate an
"X400-Mapped-Redirect-Recipient:" field, with DSN.address-type of
"rfc822", and with an RFC 822 mailbox generated from the address
encoded as specified by NOTARY. Also generate an "X400-Redirect-
Recipient:" field, which holds the X.400 representation of the
same address. If the directory name is present, it shall be added
as a trailing comment in the X.400 form.
元々意図した受取人名が存在しているなら発生、「X400は再直接の受取人を写像しました」。 "rfc822"のDSN.address-タイプ、およびRFCと共にNOTARYによって指定されるようにコード化されたアドレスから発生する822メールボックスをさばいてください。 また、発生する、「X400再直接の受取人:」 分野。(その分野は同じアドレスのX.400表現を保持します)。 ディレクトリ名が存在しているなら、それは引きずっているコメントとしてX.400フォームで加えられるものとします。
Kille Standards Track [Page 106] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[106ページ]。
report
If it is MTS.Report.delivery, then set DSN.action-field to
"delivered", and set "X400-Delivery-Time:" and "X400-Type-of-MTS-
User:" from the information in the report. DSN.status field is
set to "2.0.0".
それがMTS.Report.deliveryであるというレポートIf、次に、「渡されること」へのセットDSN.action-分野、およびセット、「X400-納期:」 そして、「X400-タイプ、-、MTS-ユーザについて:、」 レポートの情報から。 DSN.status分野が設定される、「2.0 0インチ」
If it is MTS.Report.non-delivery, then set DSN.action-field to
"failed". DSN.diagnostic-code-field is encoded according to the
syntax EBNF.dr-diagnostic, with the labelled integers set from the
reason and diagnostic codes. DSN.status-field is derived from the
reason and diagnostic codes, as described below.
それがMTS.Report.non-配送であるなら、「失敗されること」にDSN.action-分野を設定してください。 構文EBNF.dr-病気の特徴によると、DSN.diagnosticコード分野はラベルされた整数セットで理由と診断コードからコード化されます。 以下で説明されるように理由と診断コードからDSN.status-野原を得ます。
converted-encoded-information-types
Set X400-Converted-EITs:
改心したコード化された情報タイプのSet X400の転向しているEITs:
originally-intended-recipient
Generate a DSN.final-recipient-field field, with DSN.address-type
of "rfc822", and with an RFC 822 mailbox generated from the
address encoded as specified by NOTARY. Also generate a
DSN.original-recipient-field field, which holds the X.400
representation of the same address. If the directory name is
present, it shall be added as a trailing comment in the X.400
form.
"rfc822"のDSN.address-タイプ、およびRFC822メールボックスがNOTARYによって指定されるようにコード化されたアドレスから発生している元々意図した受取人Generate a DSN.final-recipient-分野分野。 また、DSN.original受取人分野分野を発生させてください。(それは、同じアドレスのX.400表現を保持します)。 ディレクトリ名が存在しているなら、それは引きずっているコメントとしてX.400フォームで加えられるものとします。
supplementary-info
Set X400-Supplementary-Info:
補っているインフォメーションのSet X400の補っているインフォメーション:
redirection-history
Generate an "X400-Redirection-History:" field for each redirect
history element. The fields are ordered with the earliest
redirect first.
リダイレクション歴史Generate、「X400リダイレクション歴史:」 それぞれの再直接の歴史要素のために、さばきます。 最も早いのが再直接で分野は最初に、命令されます。
physical-forwarding-address
Set X400-Physical-Forwarding-Address as a mailbox, with directory
name in comment if present.
存在しているならコネが論評するディレクトリ名があるメールボックスとしての物理的なフォーワーディング・アドレスのSet X400の物理的な推進アドレス。
recipient-certificate
Discard
受取人証明書Discard
proof-of-delivery
Discard
配達証明Discard
Any unknown extensions shall be discarded, irrespective of criticality. All discarded extensions shall be included in a "X400- Discarded-DR-Extensions:" field.
どんな未知の拡大も臨界の如何にかかわらず捨てられるものとします。 すべての捨てられた拡大がaに含まれているものとする、「X400の捨てられたDR拡張子:」 さばきます。
Kille Standards Track [Page 107] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[107ページ]。
The number from the MTA.PerRecipientReportTransferFields.originally- specified-recipient-number shall be mapped to "X400-Originally- Specified-Recipient-Number:", in order to facilitate reverse mapping of delivery reports.
MTA.PerRecipientReportTransferFields.originallyの指定された受取人番号からの数が写像されるものとする、「X400、-、元々の指定された受取人番号:、」、逆を容易にするために、配送に関するマッピングは報告します。
The original message shall be included in the delivery status notification 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 is not a legal message format, a dump of the ASN.1 may be included, encoded as application/octet- string. This is recommended, but not required.
それが利用可能であるなら、オリジナルのメッセージは配送状態通知に含まれているものとします。 通常、オリジナルのメッセージはセクション5.2で議論するようにゲートウェイで利用可能になるでしょう。 オリジナルのメッセージが利用可能ですが、法的なメッセージ・フォーマットでないなら、ASN.1のダンプは、アプリケーション/八重奏ストリングとして含まれていて、コード化されているかもしれません。 これは、推薦されますが、必要ではありません。
Where the original message is included, it shall be encoded according to the MIME specifications as content type message/rfc822.
オリジナルのメッセージが含まれているところでは、それはMIME仕様通りに内容タイプメッセージ/rfc822としてコード化されるものとします。
5.3.8.2. Status Code Mappings
5.3.8.2. ステータスコードマッピング
This section defines the mappings from X.400 diagnostic and status codes to the NOTARY Status field.
このセクションはX.400病気の特徴とステータスコードからNOTARY Status分野までマッピングを定義します。
C/D X400 meaning DSN code Means
C/D X400意味DSNコードMeans
0/Any Transfer failure (may be temporary) 4.4.0 Other net/route
1/Any Unable to transfer 5.0.0 Other, unknown
2/Any Conversion not performed 5.6.3 Conv not supported
3/Any Physical rendition not performed 5.6.0 Other media error
4/Any Physical delivery not performed 5.1.0 Other address
status
5/Any Restricted delivery 5.7.1
6/Any Directory operation unsuccessful 5.4.3 Routing server
failure
7/Any Deferred delivery not performed 5.3.3 Not capable
失敗..一時的..ネット..発送..移す..未知..実行..支持..表現..実行..メディア..誤り..配送..実行..アドレス..状態..配送..ディレクトリ..操作..失敗..ルート設定..サーバ..失敗..配送..実行..できる
1/0 Unrecognized OR name 5.1.1 1/1 Ambiguous OR name 5.1.4 1/2 MTS congestion 4.3.1 1/3 Loop detected 5.4.6 1/4 Recipient unavailable 4.2.1 1/5 Delivery time expired 4.4.7 1/6 Encoded information types unsupported 5.6.1 Media unsupp. 1/7 Content too long 5.2.3 2/8 Conversion impractical 5.6.3 2/9 Conversion prohibited 5.6.3 1/10 Implicit conversion not subscribed 5.6.3 1/11 Invalid arguments 5.5.2 1/12 Content syntax error 5.5.2 1/13 Size constraint violation 5.5.2 1/14 Protocol violation 5.5.0
1/0の認識されていないOR名前5.1.1 1/1Ambiguous OR名前5.1.4 1/2MTS混雑4.3.1 1/3Loopは5.4.6 1/4満期の4.4.7 1/6Encoded情報がサポートされない5.6に.1メディアunsuppをタイプするRecipientの入手できない4.2.1 1/5Delivery時間を検出しました。 1/7内容長過ぎる5.2.3 2/8Conversion非実用的な5.6.3 2/9Conversionは5.6.3 1/10 Implicit申し込まれなかった変換の議論5.5.2 1/12Content構文エラー5.5.2 1/13Size規制違反5.5.2 1/14プロトコル5.6.3 1/11Invalid違反5.5.0を禁止しました。
Kille Standards Track [Page 108] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[108ページ]。
1/15 Content type not supported 5.6.1 Media unsupp.
1/16 Too many recipients 5.5.3
1/17 No bilateral agreement 5.4.4
1/18 Unsupported critical function 5.3.3 System not capable
2/19 Conversion with loss prohibited 5.6.2
2/20 Line too long 5.6.0
2/21 Page split 5.6.0
2/22 Pictorial symbol loss 5.6.2
2/23 Punctuation symbol loss 5.6.2
2/24 Alphabetic character loss 5.6.2
2/25 Multiple information loss 5.6.2
1/26 Recipient reassignment prohibited 5.4.0 Undefined net/route
1/27 Redirection loop detected 5.4.6
1/28 DL expansion prohibited 5.7.2
1/29 No DL submit permission 5.7.1 Delivery not
authorized
1/30 DL expansion failure 4.2.4
4/31 Physical rendition attrs not supported 5.6.0 Undefined media
error
4/32-45 Various physical mail stuff 5.1.0 Other address
status
1/43 New address unknown 5.1.6 Destination mbox
moved
1/46 Secure messaging error 5.7.0 Other security
status
2/47 Unable to downgrade 5.3.3 System not capable
0/48 Unable to complete transfer 5.3.4 Message too big
0/49 Transfer attempts limit reached 4.4.7 Delivery time
expired
5.6の支持された.1メディアではなく、1/15の満足しているタイプunsupp。 できる2/19Conversionではなく、再割当てが5.4に、ネット/ルート1/27Redirectionが輪にする.0Undefinedを禁止したという損失の禁止された5.6.2 2/20線長過ぎる5.6.0 2/21の損失5.6.2 2/23Punctuationシンボル損失5.6.2 2/24Alphabeticキャラクタ損失5.6.2 2/25Multipleページ分裂5.6.0 2/22Pictorialシンボル情報損失5.6.2 1/26Recipientと機能5.3.3Systemが5.4.6 1/28 DL拡大を検出したのが重要な多く過ぎる受取人5.5.3 1/17いいえ、二国間条約5.4.4 1/18Unsupportedが5.7に禁止した1/16; 2 1/29ノーDLが支持された5.6.0Undefinedメディア誤り4/32-45Variousではなく、身体検査が完全な状態で5.3.3Systemできない0/48Unableを格下げするためにものの5.1.0Otherアドレス状態1/43New住所不明5.1.6Destination mbox動く1/46Secureメッセージング誤り5.7.0Otherセキュリティ状態に2/47Unableを郵送する許可のDeliveryの認可されなかった1/30DL拡大の5.7.1故障4.2.4 4/31Physical表現attrsを提出する、転送、5.3、.4Message、大き過ぎる0/49Transferは達している4.4.7Delivery時間が吐き出した限界を試みます。
5.3.8.3. MTA Mappings
5.3.8.3. MTAマッピング
The single SMTP 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章のマッピングを使用して、独身のSMTP受取人はMTA.ReportTransferEnvelope.report目的地名から組み立てられます。 ユーザメッセージなどと異なって、この情報はMTSレベルで利用可能ではありません。
The following additional mappings are made, which results in fields in the outer header of the DSN.
以下の追加マッピングは作られています(DSNの外側のヘッダーの分野をもたらします)。
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を引き出すのに使用されるかもしれない、「メッセージイド:」 さばきます。
Kille Standards Track [Page 109] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[109ページ]。
MTA.ReportTransferEnvelope.trace-information
and
MTA.ReportTransferEnvelope.internal-trace-information
MTA.ReportTransferEnvelope.trace-informationとMTA.ReportTransferEnvelope.internal-トレース情報
Mapped onto the extended RFC 822 field "X400-Received:", as
described in Section 5.3.7. Date: is generated from the first
element of trace.
拡張RFC822フィールドに写像される、「X400が受け取られている:、」、セクション5.3では、.7に説明されます。 日付: 跡の最初の要素から、発生します。
The following additional mappings are made, which result in per message fields in the DSN body part:
以下の追加マッピング(メッセージ単位でDSN身体の部分の分野をもたらす)は作られています:
MTA.PerRecipientReportTransferFields.last-trace-information
Mapped to X400-Last-Trace:".
「MTA.PerRecipientReportTransferFields.last-トレース情報が写像した、X400は跡を持続します:、」
MTA.PerReportTransferFields.subject-intermediate-trace-
information Mapped to "X400-Subject-Intermediate-Trace-
Information:". These fields are ordered so that the most recent
trace element comes first.
MTA.PerReportTransferFields.subject中間的な跡情報Mapped、「X400-対象中間的な跡情報:」 これらの分野が命令されるので、最新の微量元素は一番になります。
5.3.8.4. Example Delivery Reports
5.3.8.4. 例の配送レポート
This section contains sample delivery reports. These are the same examples used in RFC 1327, and so they also illustrate the changes between RFC 1327 and this document. Example Delivery Report 1:
このセクションはサンプル配送レポートを含みます。 これらがRFC1327で使用される同じ例であるので、また、それらはRFC1327とこのドキュメントの間の変化を例証します。 例の配送レポート1:
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> X400-Content-
Identifier: Greetings. MIME-Version: 1.0 Content-Type:
multipart/report; report-type=delivery-status;
boundary=boundary-1
受け取られている: 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 .480.34インチ@cs.ucl.ac.uk>X400-内容識別子:、」 こんにちは。 MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界=境界-1
--boundary-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 に渡されませんでした: 悪いAddress MTA'bbn.com'はエラーメッセージ(USER)の未知のユーザ名を中に与えます。
Kille Standards Track [Page 110] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[110ページ]。
"H.Hildegard@bbn.com"
" H.Hildegard@bbn.com "
The Original Message follows:
Original Messageは続きます:
--boundary-1 content-type: message/delivery-status
--境界-1の満足しているタイプ: 配送メッセージ/状態
Reporting-MTA: x400; bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold
400/C=gb/ Arrival-Date: Thu, 7 Feb 1991 15:48:34 +0000 DSN-Gateway:
dns; bells.cs.ucl.ac.uk X400-Conversion-Date: Thu, 7 Feb 1991
15:48:40 +0000 Original-Envelope-Id:
[/PRMD=uk.ac/ADMD=gold
400/C=gb/;<1803.665941698@UK.AC.UCL.CS>] X400-Content-Identifier:
Greetings. X400-Subject-Intermediate-Trace-Information:
/PRMD=uk.ac/ADMD=gold 400/C=gb/;
arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed X400-
Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold
400/C=gb/;
arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed
報告しているMTA: x400。 /PRMD=uk.ac/ADMDのbells.cs.ucl.ac.uk=金400/Cは到着gb/日付:と等しいです。 木曜日、1991年2月7日の15:48:34+0000DSN-ゲートウェイ: dns。 bells.cs.ucl.ac.uk X400変換日付: 木曜日、1991年2月7日の15:48:40+0000のオリジナルの封筒イド: [/PRMD=uk.ac/ADMD=金400/Cが gb/;<1803.665941698@UK.AC.UCL.CS と等しい、gt;、]、X400の満足している識別子: こんにちは。 X400の対象の中間的トレース情報: /PRMD=uk.ac/ADMD=金400/Cはgb/と等しいです。 到着、木曜日、1991年2月7日の15:48:20+0000動作Relayed X400の対象の中間的跡の情報: /PRMD=uk.ac/ADMD=金400/Cはgb/と等しいです。 到着、木曜日、1991年2月7日15:48:18+0000動作Relayed
Original-Recipient: rfc822; H.Hildegard@bbn.com Final-Recipient:
x400;
/RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold
400/C=gb/; Action: failure Status: 5.1.1 Diagnostic-Code: x400;
Reason 1 (Unable-To-Transfer);
Diagnostic 0 (Unrecognised-ORName) X400-Last-Trace: (ia5) Thu, 7
Feb 1991 15:48:18 +0000; X400-Originally-Specified-Recipient-Number:
1 X400-Supplementary-Info: "MTA 'bbn.com' gives error message (USER)
Unknown user name in "H.Hildegard@bbn.com"";
オリジナルの受取人: rfc822。 H.Hildegard@bbn.com 最終受理者: x400。 /RFC-822=H.Hildegard(a)bbn.com/OU=Cs/O=ucl/PRMD=uk.ac/ADMD=金400/Cはgb/と等しいです。 動作: 失敗Status: 5.1.1 診断コード: x400。 理由1(移すことができない)。 診断、0 (認識されていないORName) X400は跡を持続します: (ia5) 木曜日、1991年2月7日の15:48:18+0000。 X400は元々、受取人番号を指定しました: 1 X400の補っているインフォメーション: 「MTA'bbn.com'は" H.Hildegard@bbn.com "のエラーメッセージ(USER)の未知のユーザ名を与えます」。
--boundary-1 Content-Type: message/rfc822
--境界-1コンテントタイプ: メッセージ/rfc822
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
スティーブ
--boundary-1--
--境界-1--
Kille Standards Track [Page 111] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[111ページ]。
Example Delivery Report 2:
例の配送レポート2:
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:46:11 +0000
Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk>
X400-Content-Identifier: A useful mess...
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=boundary-1
受け取られている: 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:46:11+0000Message ID: <、「0インチ@cs.ucl.ac.ukの>のX400の満足しているDLE/910207154840Z/識別子:」 役に立つ混乱… MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界=境界-1
--boundary-1
--境界-1
This report relates to your message:
A useful mess...
このレポートはあなたのメッセージに関連します: 役に立つ混乱…
of Thu, 7 Feb 1991 15:43:20 +0000
木曜日、1991年2月7日の15:43:20+0000について
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 Original Message is not available
Original Messageは利用可能ではありません。
--boundary-1 content-type: message/delivery-status
--境界-1の満足しているタイプ: 配送メッセージ/状態
Reporting-MTA: x400; /PRMD=DGC/ADMD=GOLD 400/C=GB/ Arrival-Date: Thu, 7 Feb 1991 15:48:40 +0000 DSN-Gateway: dns; bells.cs.ucl.ac.uk X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000 Original-Envelope-Id:
報告しているMTA: x400。 /PRMD=DGC/ADMDは400/C金=GB/到着日付:と等しいです。 木曜日、1991年2月7日の15:48:40+0000DSN-ゲートウェイ: dns。 bells.cs.ucl.ac.uk X400変換日付: 木曜日、1991年2月7日の15:49:12+0000のオリジナルの封筒イド:
Kille Standards Track [Page 112] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[112ページ]。
[/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>]
X400-Content-Identifier: A useful mess...
[/PRMD=uk.ac/ADMD=金400/Cが gb/;<1796.665941626@UK.AC.UCL.CS と等しい、gt;、]、X400の満足している識別子: 役に立つ混乱…
Original-Recipient: rfc822; j.nosuchuser@dle.cambridge.DGC.gold-400.gb
Final-Recipient: x400;
/I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/
Action: failure
Status: 5.1.1
Diagnostic-Code: x400; Reason 1 (Unable-To-Transfer);
Diagnostic 0 (Unrecognised-ORName)
X400-Supplementary-Info: "DG 21187: (CEO POA) Unknown addressee."
X400-Originally-Specified-Recipient-Number: 1
オリジナルの受取人: rfc822。 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 最終受理者: x400。 /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=金400/CはGB/動作と等しいです: 失敗Status: 5.1.1 診断コード: x400。 理由1(移すことができない)。 診断0(認識されていないORName)のX400の補っているインフォメーション: 「DG21187:」 (最高経営責任者POA) 「未知の受け取り人。」 X400は元々、受取人番号を指定しました: 1
--boundary-1--
--境界-1--
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を利用するものとします。
Kille Standards Track [Page 113] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[113ページ]。
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 MIXER is used with SMTP, conformance to this appendix is mandatory.
このAppendixはシンプルメールトランスファプロトコル(RFC821)に特定です。 それはこのプロトコルの文脈における特定の変化について説明します。 MIXERがSMTPと共に使用されるとき、この付録への順応は義務的です。
1. Probes
1. 徹底的調査
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.
セクション5.3.9で説明されるように徹底的調査を修理するとき、配送レポートに含まれた情報の精度を増加させるSMTP VRFYコマンドで使用をするかもしれません。
2. Long Lines
2. 長い線
SMTP is a text oriented protocol, and is required to support a line length of at least 1000 characters. Some implementations do not support line lengths greater than 1000 characters. This can cause problems. Where body parts have long lines, it is recommended to use a MIME encoding that folds lines (quoted printable).
SMTPはテキスト指向のプロトコルであり、少なくとも1000のキャラクタの行長を支持しなければなりません。 いくつかの実現は1000のキャラクタより大きい行長を支持しません。 これは問題を起こすことができます。身体の部分には長い線があるところでそれをコード化するMIMEを使用するのが線を折り重ねることが勧められる、(引用、印刷可能である、)
3. SMTP Extensions
3. SMTP拡張子
There are several RFCs that specify extensions to SMTP. Most of these are not relevant to MIXER. The NOTARY work to support delivery report defines extensions which are relevant [29]. Use of these extensions by a MIXER gateway is optional. If these extensions are used, they shall be used in the manner described below.
SMTPに拡大を指定する数個のRFCsがあります。 これらの大部分はMIXERに関連していません。 配送レポートを支持するNOTARY仕事は関連[29]である拡大を定義します。 MIXERゲートウェイのそばのこれらの拡張子の使用は任意です。 これらの拡大が使用されているなら、それらは以下で説明された方法で使用されるものとします。
3.1. SMTP Extension mapping to X.400
3.1. X.400へのSMTP Extensionマッピング
Mappings are defined for the following extensions:
マッピングは以下の拡大のために定義されます:
NOTIFY
This is used to set the report and non-delivery bits of
MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
If the value is NEVER, both bits are zero. If SUCCESS is present,
the report bit is set. Otherwise, the non-delivery-report bit is
set. If the gateway uses the NOTIFY command, it shall perform
this mapping in all cases.
NOTIFY Thisは、MTA.PerRecipientMessageTransferFields.per受取人インディケータのレポートと非配送ビットを設定するのに使用されます。 値が決してそうでないなら、両方のビットはゼロです。 SUCCESSが存在しているなら、レポートビットは設定されます。 さもなければ、非配送しているレポートビットは設定されます。 ゲートウェイがNOTIFYコマンドを使用するなら、それはすべてのケースの中のこのマッピングを実行するものとします。
ORCPT
If the address type of the original recipient is "x400" or
"rfc822", this may be used at the MTS level, to generate an
element of redirection history, with the redirection date being
the date of conversion and the reason set to "alias".
"rfc822"、オリジナルの受取人のアドレスタイプのORCPT Ifは"x400"であるかこれはリダイレクション歴史の原理を発生させるのにMTSレベルに使用されるかもしれません、変換の日付であるリダイレクション日付と理由が「別名」に決められている状態で。
Kille Standards Track [Page 114] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[114ページ]。
ENVID
If present, this may be used to generate a content correlator.
This is used rather than the MTS Identifier, as the ENVID is
unique for the UA only and is likely to be too large to map to an
MTS identifier. The content correlator is encoded as an IA5 String
containing the ENVID and prefixed by the string:
現在のENVID If、これは、満足している相関器を発生させるのに使用されるかもしれません。 これはMTS Identifierよりむしろ使用されます、ENVIDがUAだけにユニークであり、MTS識別子に写像できないくらい大きい傾向があるときに。 満足している相関器は、ENVIDを含むIA5 Stringとしてコード化されて、ストリングによって前に置かれています:
"SMTP/NOTARY ENVID: "
「SMTP/公証人ENVID:」 "
If the ENVID starts with the string "X400-MTS-Identifier: ", then
this ENVID was generated from an X.400 MTS Identifier. The
reverse mapping defined in Section 3.2 of Appendix A shall not be
used, as this may cause problems in certain situations (e.g.,
where the message was expanded by an Internet mailing list).
ENVIDがストリングから始まる、「X400-MTS-識別子:」 「そして、このENVIDはX.400 MTS Identifierから発生しました」 Appendix Aのセクション3.2で定義された逆のマッピングを使用しないものとします、これが、ある状況で問題を起こすとき(例えば、メッセージはインターネットメーリングリストによってどこに広げられましたか)。
3.2. X.400 Mapping to SMTP Extensions
3.2. 拡大をSMTPに写像するX.400
The following extensions may be used as a part of the MIXER mapping:
以下の拡張子はMIXERマッピングの一部として使用されるかもしれません:
NOTIFY
The originator-report and originator-non-delivery-report bits of
MTA.PerRecipientMessageTransferFields.per-recipient-indicators
determine how this is used. If both bits are zero, the parameter
is NEVER. If the report bit is set, SUCCESS is used. Otherwise,
FAILURE is used. If this is done, the gateway shall not generate
a delivery report for this recipient, unless this is needed in the
case where the originating MTA service report requirements differ
from the user requirements. Additional originating MTA
requrirements are satisfied by the gateway.
MTA.PerRecipientMessageTransferFields.per受取人インディケータのNOTIFY創始者レポートと非配送が報告する創始者ビットは、これがどのように使用されているかを決定します。 両方のビットがゼロであるなら、パラメタは決してゼロではありません。レポートビットが設定されるなら、SUCCESSは使用されています。 さもなければ、FAILUREは使用されています。 これが完了しているなら、ゲートウェイはこの受取人のために配送レポートを作らないものとします、これが由来しているMTAサービスレポート要件がユーザ要件と異なっている場合で必要でない場合。 追加由来しているMTA requrirementsはゲートウェイで満足しています。
ORCPT
If the MTS.perRecipientDeliveryFields.originally-intended-
recipient-name is present, the ORCPT command may be used to carry
this value, using the "x400" syntax.
MTS.perRecipientDeliveryFields.originallyによって意図されて受取人名義のORCPT Ifが存在している、ORCPTコマンドはこの値を運ぶのに使用されるかもしれません、"x400"構文を使用して。
ENVID
This may be generated, with the value taken from the
MTS.MessageDeliveryEnvelope.message-delivery-identifer. If this
is done, it shall be encoded as EBNF.mts-msg-id, preceded by the
string "X400-MTS-Identifier: ".
ENVID ThisはMTS.MessageDeliveryEnvelope.message配送identiferから値を取っていて発生するかもしれません。 これが完了しているなら、それがストリングが先行したEBNF.mts-msg-イドとしてコード化されるものとする、「X400-MTS-識別子:」 ".
RET
If MTA.PerMessageTransferFields.per-message-indicators.content-
return-request is set to FALSE, the parameter RET may be set to
HDRS, to specify return of headers only.
RET If MTA.PerMessageTransferFields.per-メッセージindicators.content-返送依頼はFALSEに設定されて、パラメタRETはヘッダーだけの帰りを指定するのをHDRSに用意ができるかもしれません。
Kille Standards Track [Page 115] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[115ページ]。
Appendix B - Mapping with X.400(1984)
付録B--X.400があるマッピング(1984)
This appendix defines modifications 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. The heading extension feature is used at the IPMS level, and this shall be replaced by the RFC 987 approach. All header information which would usually be mapped into the rfc-822-heading- list extension 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. RFC 822 extended headers which could be mapped into X.400(1988) elements, are also mapped to the body part.
RFC822からX.400(1984)まで写像するとき、1988の特定の特徴で無駄をすることができます。 MTSレベルでそのような特徴の無駄をします。 IPMSレベルに見出し拡大機能を使用します、そして、これをRFC987アプローチに取り替えるものとします。 通常、rfc-822の向かっているリストの拡大に写像されるすべてのヘッダー情報がただ一つのIA5身体の部分に写像されます。(それは、メッセージで最初の身体の部分です)。 この身体の部分がストリングから始まる、「RFC822ヘッダー:」 1番目として、立ち並んでください。 そして、ヘッダーはこの線に従います。 この仕様は1988か1984年からこの形式の正しい逆のマッピングを必要とします。 RFC822はX.400(1988)要素に写像できて、また身体の部分に写像されるヘッダーを広げました。
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 shall 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 shall 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 attributes of zero length may be present in an OR Address. This is not legal in 1988, except for ADMD where the case is explicitly described in Section 4.3.5. Attributes of zero length are deprecated (the attribute shall be omitted), and will 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=/).
ゼロ・レングスの属性がOR Addressに存在しているのは、可能です。 これはケースがセクション4.3.5で明らかに説明されるADMD以外の1988年に法的ではありません。 ゼロ・レングスの属性は、推奨しなく(属性は省略されるものとします)、したがって、珍しくなるでしょう。 しかしながら、いくつかのシステムが、それらを発生させて、それらを当てにします。 または、したがって、どんなヌル属性もenoded使用になる、std、-、(例えば、/o=/)をコード化します。
Kille Standards Track [Page 116] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[116ページ]。
If a non-Teletex Common Name (CN) is present, it shall be mapped onto a Domain Defined Attribute "Common". This is in line with RFC 1328 on X.400 1988 to 1984 downgrading [22].
非テレテックス俗称(CN)が存在しているなら、それはDomain Defined Attributeに「一般的に」写像されるものとします。 これは、[22]を格下げしながら、X.400 1988年から1984の上のRFC1328に沿ってあります。
This specification defines a mapping of the Internet message framework to X.400. Body part mappings are defined in RFC 2157 [6], which relies on X.400(88) features. Downgrading to X.400(84) for body parts is defined in RFC 1496 (HARPOON), which shall be followed in the context of this appendix [5].
この仕様はインターネットメッセージ枠組みに関するマッピングをX.400と定義します。 ボディー部分マッピングはRFC2157[6]で定義されます。([6]はX.400(88)の特徴を当てにします)。 身体の部分へのX.400(84)への格下げはRFC1496(HARPOON)で定義されます。(RFCはこの付録[5]の文脈で続かれるものとします)。
Kille Standards Track [Page 117] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[117ページ]。
Appendix C - RFC 822 Extensions for X.400 access
付録C--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 access 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サービスまでのアクセスを与えるために提供されるかもしれない多くの任意のマッピングを定義します。 これらのマッピングはこの仕様の基本的な範囲を超えています。 X.400にアクセスするのにメカニズムとして拡張RFC822を使用するという明確な要求がありました、そして、これらの拡大はある特徴へのアクセスを提供します。 この機能性を提供するなら、この付録に従うものとします。 以下の見出しは定義されます:
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "X400-Content-Return" ":" prohibition
「敷衍された見出しは「不着損害レポートを防いでください」と等しい」:、」 「/、「配送レポートを作ってください」、」、:、」 「/「交互の受取人」」:、」 「禁止/、「受取人を明らかにする、」、」、:、」 「禁止/「X400の満足しているリターン」」:、」 禁止
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 X400-Content-Return allow for override of the default settings for MTS.PerMessageIndicators.
交互の受取人、Disclose-受取人、およびX400の満足しているリターンはMTS.PerMessageIndicatorsに関して既定の設定のオーバーライドを考慮します。
Use of NOTARY mechanisms is a preferred meachanism for controlling these parameters.
NOTARYメカニズムの使用は、これらのパラメタを制御するための都合のよいmeachanismです。
Kille Standards Track [Page 118] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[118ページ]。
Appendix D - Object Identifier Assignment
付録D--物の識別子課題
The following Object Identifiers shall be used.
以下のObject Identifiersは使用されるものとします。
internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC
1155
インターネット:、:= RFC1155からのOBJECT IDENTIFIER iso org(3) dod(6)1
mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned
OBJECT IDENTIFIERに郵送してください:、:= インターネット7--割り当てられたIANA
mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
1495
mixer-core OBJECT IDENTIFIER ::= { mixer core(3) }
ミキサーOBJECT IDENTIFIER:、:= メールミキサー(1)--RFC1495ミキサーコアOBJECT IDENTIFIERから引き継ぐ:、:= ミキサーコア(3)
id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4}
イドrfc822分野リストOBJECT IDENTIFIER:、:= ミキサーコア2イドdsnヘッダーリストOBJECT IDENTIFIER:、:= ミキサーコア3イドdsn分野リストOBJECT IDENTIFIER:、:= ミキサーコア4
eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5}
-- the MIXER pseudo-EIT
eit-ミキサーOBJECT IDENTIFIER:、:= ミキサーコア5--ミキサー疑似EIT
This object identifier for id-rfc-822-field-list is different to the one assigned in RFC 1327, which was erroneous.
イドrfc822分野リストのためのこの物の識別子は誤ったRFC1327で割り当てられたものに異なっています。
Kille Standards Track [Page 119] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[119ページ]。
Appendix E - BNF Summary
付録E--BNF概要
boolean = "TRUE" / "FALSE"
論理演算子=「本当」/「誤っています」。
numericstring = *(DIGIT / " ")
numericstringは*と等しいです。(ケタ/、「「)」
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")」
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」)」
labelled-integer-2 ::= [ numericstring ] "(" key-string ")"
ラベルされた整数2:、:= 「(「主要なストリング」の)」という[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つの#コード化されたタイプと等しいです。
Kille Standards Track [Page 120] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[120ページ]。
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"
/ dd-key "." std-printablestring
」 . 」 「stdかアドレス=1*(「/」属性「=」価値)」/」 dd属性=標準体型/"RFC-822"/キーstd-printablestring
std-or-address-input = [ sep pair ] sep pair *( sep pair )
sep [ pair sep ]
stdかアドレス入力=[sep組]sep組*(sep組)sep[組sep]
sep = "/" / ";"
pair = input-attribute "=" value
input-attribute = attribute
/ dd-key ":" std-printablestring
「sepは」 /と等しい」という/、」、;、」 「組=入力属性は「」 値入力属性=dd属性/キーと等しいです」」 std-printablestring
standard-type = key-string
標準体型=の主要なストリング
dd-key = key-string
dd主要な=キーストリング
value = std-printablestring
値はstd-printablestringと等しいです。
std-printablestring
= *( std-char / std-pair )
std-printablestringは*と等しいです。(std std-炭/対にします)です。
std-char = <"{", "}", "*", and any ps-char
「std-炭は<と等しい」、「」、」、「*」、およびどんなps-炭
Kille Standards Track [Page 121] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[121ページ]。
except "/" and "=" >
std-pair = "$" ps-char
「」 /」と「=」>std-組=「$」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=単語到着時間=日付-時間
md-or-mta = "MD" global-id
/ "MTA" mta
「MD」グローバルなイド/"MTA"Mdかmta=mta
Action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
「向け直される」か、「広げられる」、「リレーされる」、または「別ルートで送られた」動作リスト=1#動作動作=
dr-user-info = dr-summary <CRLF>
dr-recipients <CRLF>
dr-content-return
drユーザインフォメーションは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>)
Kille Standards Track [Page 122] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[122ページ]。
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>、「以下に関して、推論してください」 *単語
report-point = [ "mta" mta-name "in" ] global-id content-correlator = *word mta-name = word
レポートポイント=["mta"mta-名前“in"]グローバルなイド満足している相関器=*単語mta-名前=単語
dr-per-message-fields =
/ "X400-Conversion-Date" ":" date-time
/ "X400-Subject-Submision-Identifier" ":"
mts-msg-id
/ "X400-Content-Identifier" ":" printablestring
/ "X400-Content-Type" ":" mts-content-type
/ "X400-Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Originator-and-DL-Expansion-History" ":"
mailbox ";" date-time ";"
/ "X400-Reporting-DL-Name" ":" mailbox
/ "X400-Content-Correlator" ":" content-correlator
/ "X400-Recipient-Info" ":" recipient-info
/ "X400-Subject-Intermediate-Trace-Information" ":"
x400-trace
/ dr-extensions
「メッセージ分野あたりのdr=/「X400変換日付」」:、」 「日付-時間/「X400の対象のSubmision識別子」」:、」 「mts-msg-イド/「X400の満足している識別子」」:、」 「printablestring/「X400コンテントタイプ」」:、」 「mtsの満足しているタイプ/「オリジナルのコード化された情報がタイプするX400」」:、」 「コード化されたインフォメーション/「X400創始者とdl拡大歴史」」、:、」 「メールボックス」;、」 「日付-時間」;、」 「/「X400の報告しているdl名」」:、」 「メールボックス/「X400の満足している相関器」」:、」 「満足している相関器/「X400受取人インフォメーション」」:、」 「受取人インフォメーション/「X400の対象の中間的トレース情報」」:、」 dr x400-跡/拡張子
dr-per-recipient-fields =
/ "X400-Redirect-Recipient" ":" "x400" ";" std-or
/ "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";"
mailbox
/ "X400-Converted-EITs" ":" encoded-info ";"
/ "X400-Delivery-Time" ":" date-time
/ "X400-Type-of-MTS-User" ":" labelled-integer
/ "X400-Last-Trace" ":" [ encoded-info ] date-time
/ "X400-Supplementary-Info" ":"
<"> printablestring <"> ";"
/ "X400-Redirection-History" ":" redirect-history-item
/ "X400-Physical-Forwarding-Address" ":" mailbox
/ "X400-Originally-Specified-Recipient-Number" ":"
integer
/ dr-extensions
「受取人分野あたりのdr=/「X400の再直接の受取人」」:、」 「"x400"」;、」 または、「std、-、/、「X400は再直接の受取人を写像した」、」、:、」 「"rfc822"」;、」 「メールボックス/「X400の転向しているEITs」」:、」 「コード化されたインフォメーション」;、」 「/「X400-納期」」:、」 「日付-時間/「MTSユーザのX400タイプ」」:、」 「ラベルされた整数/、「X400は跡を持続する」、」、:、」 「[コード化されたインフォメーション]の日付-時間/「X400の補っているインフォメーション」」:、」 <「>のprintablestring<">"」。 「/「X400リダイレクション歴史」」:、」 「再直接の歴史項目/「X400の物理的なフォーワーディング・アドレス」」:、」 「メールボックス/「X400は元々、受取人番号を指定」であっていた」:、」 dr整数/拡張子
Kille Standards Track [Page 123] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[123ページ]。
dr-extensions = "X400-Discarded-DR-Extensions" ":"
1# (object-identifier / labelled-integer)
「dr-拡大は「X400はDR拡張子を捨てたこと」と等しい」:、」 1# (ラベルされた物識別子/整数)
dr-diagnostic = "Reason" labelled-integer-2
[ ";" "Diagnostic" labelled-integer-2 ]
= 「推論してください」というdr-病気の特徴のラベルされた整数2[「」、;、ラベルされた「診断している」整数2]
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
/ "X400-Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( object-identifier / labelled-integer )
「mts-分野=「X400-MTS-識別子」」:、」 「mts-msg-イド/「X400創始者」」:、」 「メールボックス/「X400受取人」」:、」 「1#メールボックス/「元のコード化された情報タイプ」」:、」 「コード化されたインフォメーション/「X400コンテントタイプ」」:、」 「mtsの満足しているタイプ/「X400の満足している識別子」」:、」 「printablestring/「優先権」」:、」 「優先権/「創始者返送先」」:、」 「1#メールボックス/「dl拡大歴史」」:、」 「メールボックス」;、」 「日付-時間」;、」 「/「変換」」:、」 「禁止/「損失との変換」」:、」 「禁止/「納品日」」:、」 「日付-時間/「捨てられたX400-MTS拡張子」」:、」 1#(ラベルされた物識別子/整数)
prohibition = "Prohibited" / "Allowed"
=が「禁止する」か、または「許容した」禁止
mts-msg-id = "[" global-id ";" *text "]"
「mts-msg-イド=、「[「グローバルなイド」;、」 *テキスト、」、]、」
mts-content-type = "P2" / labelled-integer
/ object-identifier
mtsの満足しているタイプは「物ラベルされたP2"/整数/識別子」と等しいです。
priority = "normal" / "non-urgent" / "urgent"
優先権は「正常である」か「不急」の/と「緊急」の状態で等しいです。
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-理由
Kille Standards Track [Page 124] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[124ページ]。
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:"
ipn満足しているリターンは「Original Messageは利用可能でない」という/と等しいです。「Original Messageは以下に続きます」。
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
日付-時間自動都合のよい受取人=メールボックス領収書時間=コメント=printablestring ipn-supplはprintablestringと等しいです。
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated" / "IPM Deleted"
破棄して推論している=が「ユーザ購読は終えた」/を「吐き出す」か、または「時代遅れにした」、「IPMは削除した」/
acknowledgement-mode = "Manually" / "Automatically"
承認モードは「自動的に」「手動」という/と等しいです。
ipms-field = "Supersedes" ":" 1*msg-id
/ "Expires" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Content-Language" ":" 1#language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":"
1#object-identifier
/ "Autosubmitted" ":" autosubmitted
「=が「取って代わる」ipms-分野」:、」 「1*msgイド/は「期限が切れ」」:、」 「日付-時間/「近く、返答」」:、」 「日付-時間/「重要性」」:、」 「重要性/「感度」」:、」 「感度/"Autoforwarded"」:、」 「論理演算子/「不完全なコピー」」:、」 「/「満足している言語」」:、」 「1#言語/「メッセージタイプ」」:、」 「メッセージタイプ/「捨てられたX400-IPMS拡張子」」:、」 「1#物識別子/"Autosubmitted"」:、」 autosubmittedしました。
importance = "low" / "normal" / "high"
重要性=「安値」/「標準」/「高値」
sensitivity = "Personal" / "Private" /
"Company-Confidential"
「個人的である」か「個人的な」/感度=「社内秘密」
language = 2*ALPHA [ "(" language-description ")" ]
言語は2*アルファーと等しいです。[「(「言語記述」)」]
Kille Standards Track [Page 125] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[125ページ]。
language-description = printable-string
言語記述は印刷可能なストリングと等しいです。
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
メッセージタイプは「配送レポート」/「個人間の通知」/「複数の部分」と等しいです。
autosubmitted = "not-auto-submitted"
/ "auto-generated"
/ "auto-replied"
/ "auto-forwarded"
「自動提出されていなかった」状態で=をautosubmittedした、/、「自動発生している」/、「自動返答する」、/、「自動進められる」。
redirect-comment = redirect-first *( redirect-subsequent )
再直接のコメントは再直接の最初の*と等しいです。(再直接にその後)です。
redirect-first = "Originally To:" mailbox "Redirected on"
date-time "To:" redirection-reason
再直接の1番目は「元々のTo:」と等しいです。 メールボックス、「」 日付-時間「To:」では、向け直されます。 リダイレクション理由
redirect-subsequent = mailbox "Redirected Again on"
date-time "To:" redirection-reason
メールボックスが「Againを向け直した」再直接にその後の=は「To:」を日付で調節します。 リダイレクション理由
redirection-history-item = "intended recipient" mailbox
"redirected to" redirection-reason
"on" date-time
リダイレクション歴史項目=「意図している受取人」メールボックス、「」リダイレクション理由“on"日付-時間まで向け直されます。
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
/ "Directory Look Up"
/ "Alias"
リダイレクション理由は「ディレクトリは調べる」という/「受取人の割り当てられた交互の受取人」/「創始者の要求された交互の受取人」/「受取人のMdの割り当てられた交互の受取人」/「別名」と等しいです。
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
「(「状態」)」という受けることがある線=「配送レポート」[“for"の目的地]
status = "success" / "failure" / "success and failures"
状態=「成功」/「失敗」/「成功と失敗」
destination = mailbox / "MTA" word
目的地=メールボックス/"MTA"単語
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "X400-Content-Return" ":" prohibition
「敷衍された見出しは「不着損害レポートを防いでください」と等しい」:、」 「/、「配送レポートを作ってください」、」、:、」 「/「交互の受取人」」:、」 「禁止/、「受取人を明らかにする、」、」、:、」 「禁止/「X400の満足しているリターン」」:、」 禁止
Kille Standards Track [Page 126] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[126ページ]。
Appendix F - Text format for MCGAM distribution
付録F--MCGAM分配のためのテキスト形式
1. Text Formats
1. テキスト形式
This appendix defines text formats for exchange of four types of mapping.
この付録は4つのタイプに関するマッピングの交換のためにテキスト書式を定義します。
1. Domain Name Space -> OR Address Space MCGAM
1. ドメイン名スペース->かアドレス空間MCGAM
2. OR Address Space -> Domain Name Space MCGAM
2. または、アドレス空間->ドメイン名スペースMCGAM
3. Domain Name Space -> OR Address of preferred gateway
3. 都合のよいゲートウェイのドメインName Space->OR Address
4. OR Address Space -> Domain Name of preferred gateway
4. 都合のよいゲートウェイのOR Address Space->Domain Name
2. Mechanisms to register and to distribute MCGAMs
2. 登録して、MCGAMsを分配するメカニズム
There is a well known set of MCGAM tables.
よく知られているセットのMCGAMテーブルがあります。
The global coordination of the mapping rules is a part of the DANTE MailFLOW Project. New mapping rules may be defined by the authority responsible for the relevant name space. The rules need to be registered with a national mapping registration authority, which in turn passes them on to the central mapping registration authority. All the collected mapping rules are merged together into the globally coordinated mapping tables by the MailFLOW Project Team. The tables are available from the national mapping registration authorities.
配置規則のグローバルなコーディネートはダンテMailFLOW Projectの一部です。 新しい配置規則はスペースという関連名前に原因となる権威によって定義されるかもしれません。 規則は、国家のマッピング登録局に登録される必要があります。(順番に、登録局は中央のマッピング登録局にそれらを通過します)。 MailFLOW Project Teamはグローバルに連携しているマッピングテーブルとすべての集まっている配置規則を結合させます。 テーブルは国家のマッピング登録局から利用可能です。
To get a contact address of the mapping registration authority for the respective country or more information about the MailFLOW Project contact:
MailFLOW Projectに関するそれぞれの国か詳しい情報のためにマッピング登録局の連絡先を得るために、以下に連絡してください。
SWITCH
MailFLOW Project Team
Limmatquai 138
8001 Zuerich
Switzerland
スイッチMailFLOWプロジェクト・チームLimmatquai138 8001Zuerichスイス
email: mailflow@mailflow.dante.net
S=MailFLOW;O=MailFLOW;P=DANTE;A=mailnet;C=fi;
メール: mailflow@mailflow.dante.net S=MailFLOW; O=MailFLOW; P=ダンテ; A=mailnet; Cはfiと等しいです。
fax: +41 1 268 15 68
tel: +41 1 268 15 20
fax: +41 1 268、15 68、tel: +41 1 268 15 20
Kille Standards Track [Page 127] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[127ページ]。
3. Syntax Definitions
3. 構文定義
An address syntax is defined, which is compatible with the syntax used for 822.domains. By representing the OR 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 OR addresses, so that it can be used in other applications. Not all attributes are used in the table formats defined.
アドレス構文(822.domainsに使用される構文と互換性がある)は定義されます。 ドメインとしてORアドレスを表すことによって、ドメイン->ドメインマッピングとして機械的にすべてのルックアップを実行できます。 初めは、定義されたこの構文はテーブル形式における使用のためのものですが、構文はDomain Name Serviceとの使用のために適合させられるのを適当にする方法で定義されます。 この構文は、他のアプリケーションでそれを使用できるようにORアドレスの一般的な表現を考慮します。 すべての属性が形式が定義したテーブルで使用されるというわけではありません。
To allow the mapping where a level of the hierarchy is omitted, the pseudo-value "@" (not a printable string character) is used to indicate omission of a level in the hierarchy. This is distinct from the form including the element with no value, although a correct X.400 implementation will interpret both in the same manner.
階層構造のレベルが省略されるマッピングを許容するなら、疑似価値の"@"(印刷可能なストリングキャラクタでない)は、階層構造における、レベルの省略を示すのに使用されます。 これは値なしで要素を含むフォームと異なっています、正しいX.400実現が同じ方法で両方を解釈するでしょうが。
This syntax is not intended to be handled by users.
この構文はユーザによって扱われることを意図しません。
dmn-or-address = dmn-part *( "." dmn-part )
mn-part = dmn-attribute "$" value
dmn-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-属性「$」値dmn-属性=標準体型/「~」dmn-printablestring dmnかアドレス=dmn-部分*(「.」 dmn-部分)Mn部分=価値=dmn-printablestring=は*(dmn dmn-炭/対にしている)dmn-炭=<と等しい」、「」、」、「*」、および」 . 「>dmn-組は」 \と等しいこと」を除いたどんなps-炭
An example usage:
例の用法:
~ROLE$Big\.Chief.ADMD$ATT.C$US
PRMD$DEC.ADMD$@.C$US
~役割の$大きい\.Chief.ADMD$ATT.C$米国 PRMD$DEC.ADMD$@.C$US
The first example illustrates quoting of a "." and a domain define attribute (ROLE). The second example illustrates omission of the ADMD level. There shall 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.
「最初の例はa」の引用を例証し」てドメインは属性(役割)を定義します。 2番目の例はADMDレベルの省略を例証します。 すべてのコンポーネントの厳しい注文がRHSで最も重要なコンポーネントがあるこのテーブルにあるでしょう。 これは、コード化がドメインとして扱われるのを許容します。
Various further restrictions are placed on the usage of dmn-or- address in the address space mapping tables.
または、さらなる様々な制限がdmnの使用法に関して課される、-、-アドレス空間マッピングにテーブルを記述してください。
a. Only C, ADMD, PRMD, O, and up to four OUs may be used.
a。 C、ADMD、PRMD、O、および最大4OUsだけを使用してもよいです。
Kille Standards Track [Page 128] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[128ページ]。
b. 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.
b。 階層構造はどんなレベルでも終わるかもしれませんが、この階層構造からコンポーネントを全く省略しないものとします。 省略されたコンポーネントにマッピングがあるなら、"@"構文は使用されています。
4. Table Lookups
4. 索表
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:
マッチを決定するとき、すべてのルックアップに適用される局面があります。 いつもマッチはケース独立者です。 すべての3個のテーブルのためのキーはドメインです。 可能な限り長いマッチを入手するものとします。 テーブルには以下のキーによる2つのエントリーがあると仮定してください:
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:.
ドメイン「A.B.C」はどんなマッチも返さないでしょう。 ドメイン「I.J.K.L」がエントリーに合う、「J.K.L:」
5. Domain -> OR Address MCGAM format
5. ドメイン->OR Address MCGAM形式
The BNF is:
BNFは以下の通りです。
domain-syntax "#" dmn-or-address "#"
ドメイン構文「#」dmnかアドレス「#」
EBNF.domain-syntax is defined in Section 4.2. Note that the trailing "#" is used for clarity, as the dmn-or-address syntax might lead to values with trailing blanks. Lines starting with "#" are comments.
EBNF.domain-構文はセクション4.2で定義されます。 dmnかアドレス構文が引きずっている空白がある値につながるかもしれなくて、引きずっている「#」が明快に使用されることに注意してください。 「#」から始まる線はコメントです。
For example:
AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE#
例えば: AC.UK#PRMD$イギリスの\.AC.ADMD$金の400.C$GB#XEROX.COM#O$Xerox.ADMD$ATT.C$U.S.#GMD.DE# O$@.PRMD$GMD.ADMD$DBP.C$DE #
A domain is looked up to determine the top levels of an OR Address. Components of the domain which are not matched are used to build the remainder of the OR address, as described in Section 4.3.4.
ドメインは、OR Addressのトップレベルを決定するために見上げられます。 ドメインの取り組んでいないコンポーネントはORアドレスの残りを築き上げるのに使用されます、セクション4.3.4で説明されるように。
6. OR Address -> Domain MCGAM format
6. OR Address->Domain MCGAM形式
The syntax of this table is:
このテーブルの構文は以下の通りです。
dmn-or-address "#" domain-syntax "#"
dmnかアドレス「#」ドメイン構文「#」
For example:
例えば:
#
# Mapping table
#
PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
# # テーブル#PRMD$イギリスの\.AC.ADMD$GOLD 400.C$GB#AC.UK#を写像します。
Kille Standards Track [Page 129] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[129ページ]。
The OR 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.
OR Addressは、ドメインキーを発生させるのに使用されます。 正しくコンポーネントを注文して、階層構造でなくなったコンポーネントに記入するのは重要です。 このマッピングの使用はセクション4.3.2で説明されます。
7. Domain -> OR Address of Preferred Gateway table
7. Preferredゲートウェイの->OR Addressが見送るドメイン
This uses the same format as the domain -> OR address MCGAM table. In this case, the restriction to only use C/ADMD/PRMD/O/OU does not apply. Use of this mapping is described in Section 4.3.4. A domain cannot appear in this table and in the domain to OR Address table.
これはドメイン->ORアドレスMCGAMテーブルと同じ形式を使用します。 この場合、使用C/ADMD/PRMD/O/OUだけへの制限は適用されません。 このマッピングの使用はセクション4.3.4で説明されます。 ドメインはこのテーブルとドメインにOR Addressテーブルに現れることができません。
8. OR Addresss -> domain of Preferred Gateway table
8. PreferredゲートウェイテーブルのOR Addresss->ドメイン
This uses the same format as the OR Address -> domain MCGAM table. Use of this mapping is described in Section 4.3.5. An OR Address cannot appear in this table and in the OR Address to domain table.
これはOR Address->ドメインMCGAMテーブルと同じ形式を使用します。 このマッピングの使用はセクション4.3.5で説明されます。 OR AddressはこのテーブルとOR Addressでドメインテーブルに見えることができません。
Kille Standards Track [Page 130] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[130ページ]。
Appendix G - Conformance
付録G--順応
This appendix defines a number of options, which a conforming gateway shall specify. Conformance to this specification shall not be claimed if any of the mandatory features are not implemented. A specification of conformance may list the service elements of Chapter 2, in order to be clear that full conformance is provied. In particular:
この付録は多くのオプションを定義します。(従うゲートウェイはオプションを指定するものとします)。 義務的な特徴のいずれも実行されないなら、この仕様への順応を要求しないものとします。 順応の仕様は第2章のサービス要素を記載するかもしれません、完全な順応がproviedされるのが明確になるように。 特に:
- Formats for all fields shall be followed.
- すべての分野への形式は続かれるものとします。
- The gateway shall enable MCGAMs to be used.
- ゲートウェイは、MCGAMsが使用されるのを可能にするものとします。
- 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.
- SMTPに写像するとき、RFC1137に続かないものとします。
- All mappings of trace shall be implemented.
- 跡に関するすべてのマッピングが実行されるものとします。
- There shall be a mechanism to access all three global
mappings.
- すべての3つのグローバルなマッピングにアクセスするメカニズムがあるでしょう。
- RFC 2157 shall be followed for mapping body parts.
- RFC2157は、身体の部分を写像するために続かれるものとします。
- When it is specified that a MIME format message is
generated, RFC 2045 shall be followed.
- MIME形式メッセージが発生すると指定されるとき、RFC2045は続かれるものとします。
A gateway shall specify:
ゲートウェイは指定するものとします:
- Which Interent Message Transport (822-MTS) protocols are
supported. If SMTP is supported, Appendex A of MIXER shall
be used.
- どのInterent Message Transport(822-MTS)プロトコルがサポートされますか? SMTPが支持されるなら、MIXERのAppendex Aは使用されるものとします。
- Which X.400 versions are supported (84, 88, 92).
- どのX.400バージョンが支持されますか?(84、88、92)
- Which mechanisms (table, X.500, DNS) are supported to access
MCGAMs.
- どのメカニズム(テーブル、X.500、DNS)が、MCGAMsにアクセスするためにサポートされますか?
- The mechanism or mechanisms by which the global mapping
information is accessed.
- グローバルなマッピング情報がアクセスされているメカニズムかメカニズム。
The following are optional parts of this specification. A conforming implementation shall specify which of these it supports.
↓これはこの仕様のオプショナル・パーツです。 従う実現は、それがこれらのどれを支持するかを指定するものとします。
- Support for the extension mappings of Appendix C.
- 拡大には、Appendix Cに関するマッピングを支持してください。
Kille Standards Track [Page 131] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[131ページ]。
- 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)
Kille Standards Track [Page 132] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[132ページ]。
Appendix H - Change History: RFC 987, 1026, 1138, 1148
付録H--歴史を変えてください: 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 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.
RFC1138はRFC987仕事に基づきました。 それは、編集の誤りを含んで、数カ月後にRFC1148として再発行されました。 RFC1148は、それが広くほかの場所と呼ばれるドキュメントであるので、ここと呼ばれるでしょう。 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マッピングをリバーシブルにしてください。
Kille Standards Track [Page 133] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[133ページ]。
- 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マッピングを変えます。
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 OR Address
syntax
- OR 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付属物を削除してください。
Kille Standards Track [Page 134] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[134ページ]。
Appendix I - Change History: RFC 1148 to RFC 1327
付録I--歴史を変えてください: RFC1148からRFC1327
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上限は正しく扱われます。
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 compatibility with the PDAM on
writing OR Addresses.
- 変更がOR Addressesに書きながらPDAMとの互換性を改良すると行われました。
+ 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:の形式 線は定義されます。
Kille Standards Track [Page 135] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[135ページ]。
- 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番目のテーブル定義は加えました。
- 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.
- 順応での付録は加えられます。
Kille Standards Track [Page 136] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[136ページ]。
Appendix J - Change History: RFC 1327 to this Document
付録J--歴史を変えてください: このDocumentへのRFC1327
1. General
1. 一般
This update is primarily for stability, and to fold in compatibility for MIME and to add support for the new NOTARY delivery status notifications. Other general changes:
このアップデートは、主として安定性、MIMEのために互換性で折り重なって、新しいNOTARY配送状態通知のサポートを加えることです。 他の一般は変化します:
- Various editorial updates
- 様々な編集のアップデート
- Minor EBNF errors
- 小さい方のEBNF誤り
- Reference to mapping table support by DNS and X.500.
- DNSとX.500によるテーブルサポートを写像することの参照。
- Alignment to X.400(92)
- X.400への整列(92)
- Assignment of a new object identifier
- 新しい物の識別子の課題
- Removal of specification relating to body mapping, which is
now defined in RFC 2157.
- 現在RFC2157で定義されるボディーマッピングに関連する仕様の取り外し。
2. Service Elements
2. サービス要素
- Support of Auto-Submitted service
- Autoによって提出されたサービスのサポート
3. Basic Mappings
3. 基本のマッピング
- Comments shall not be used in new headers, to remove parsing
ambiguity
- あいまいさを分析しながら取り外すのに新しいヘッダーでコメントを使用しないものとします。
- RFC 1522 encoding may be used as an alternative to X.408
downgrade, where appropriate.
- RFC1522コード化は適切であるところでX.408ダウングレードに代わる手段として使用されるかもしれません。
- Correct handling of RFC 822 four year dates.
- RFC822 4年間の日付の取り扱いを修正してください。
4. Addressing
4. アドレシング
- Replaced the mandatory global address mapping with MCGAMs.
- 義務的なグローバルアドレスマッピングをMCGAMsに取り替えました。
- Add codes and add a heuristic to align to the standard X.400
form of writing OR Addresses.
- コードを加えてください、そして、ヒューリスティックを加えて、ORに書く標準のX.400フォームにAddressesを並べてください。
- Improved text on ordering heuristic
- ヒューリスティックを注文することに関する改良されたテキスト
- Leading "/" interpretation added
- 」 解釈が加えた「主な」/
Kille Standards Track [Page 137] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[137ページ]。
- All bar one of the address mapping heuristics made
mandatory.
- すべてが義務的にされたアドレス・マッピング発見的教授法の1つを禁じます。
- Interpretation of domain defined attribute "RFC-822" made
mandatory in all cases
- ドメインの解釈はすべての場合で義務的にされた属性"RFC-822"を定義しました。
- Make report request comments optional
- レポート要求コメントを任意にしてください。
5. Detailed Mappings
5. 詳細なマッピング
- Comments no longer maps to separate body part
- もう、身体の部分を切り離すために地図について論評しません。
- Allow Languages to be multi-valued
- Languagesがマルチ評価されているのを許容してください。
- Change Content-Identifier to X400-Content-Identifier, in
order to avoid confusion with MIME.
- MIMEへの混乱を避けるためにContent-識別子をX400の満足している識別子に変えてください。
- Reverse mapping of MIXER defined fields made mandatory
- MIXERの逆のマッピングは義務的にされた分野を定義しました。
- "Expiry-Date:" changed to "Expires:".
- 「以下と満期でデートしてください」 変化する、「以下を吐き出します」。
- "Obsoletes:" changed to "Supersedes:".
- 「以下を時代遅れにします」 「Supersedes:」に変えます。
- Define correct handling when "Resent-Date:" is present.
- 定義、いつを扱うかながら修正する、「日付:に憤慨する、」 プレゼント。
6. Appendices
6. 付録
- Change "Content-Return" to "X400-Content-Return" in Appendix
C.
- 付録Cにおける「X400の満足しているリターン」への「満足しているリターン」を変えてください。
- Relaxation of restrictions on mapping 3 in Appendix F.
- Appendix Fで3を写像するときの制限の緩和。
- Add linkage to HARPOON in Appendix B.
- Appendix BでHARPOONにリンケージを加えてください。
- RFC 2157 added to the conformance statement of Appendix
G.
- RFC2157はAppendix Gの順応声明に加えました。
- Added Appendix L, with ASN. Summary.
- ASNと共に付録Lを加えました。 概要。
Kille Standards Track [Page 138] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[138ページ]。
Appendix L - ASN.1 Summary
付録L--ASN.1概要
MIXER Definitions { iso org(3) dod(6) internet(1) mail(7)
mixer(1) mixer-core(3) definitions(1) }
ミキサー定義iso org(3) dod(6)インターネット(1)メール(7)ミキサー(1)ミキサーコア(3)定義(1)
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
-- exports everything
-- すべてを輸出します。
IMPORTS
輸入
EXTENSION FROM
MTSAbstractService {join-iso-ccit mhs-motis(6) mts(3)
modules(0) mts-abstract-service(1) }
MTSAbstractServiceからの拡大iso-ccit mhs-motis(6) mts(3)を接合しているモジュール(0)mts抽象的なサービス(1)
HEADING-EXTENSION FROM
IPMSAbstractService {join-iso-ccit mhs-motis(6) ipms(1)
modules(0) abstract-service(3) }
IPMSAbstractServiceからの見出し拡張子iso-ccit mhs-motis(6) ipms(1)を接合しているモジュール(0)要約サービス(3)
rfc-822-field HEADING-EXTENSION
VALUE RFC822FieldList
::= id-rfc-822-field-list
rfc822分野HEADING-EXTENSION VALUE RFC822FieldList:、:= イドrfc822分野リスト
RFC822FieldList ::= SEQUENCE OF RFC822Field
RFC822FieldList:、:= RFC822Fieldの系列
RFC822Field ::= IA5String
RFC822Field:、:= IA5String
dsn-header-list EXTENSION
RFC822FieldList
::= id-dsn-header-list
dsnヘッダーリストEXTENSION RFC822FieldList:、:= イドdsnヘッダーリスト
dsn-field-list EXTENSION
RFC822FieldList
::= id-dsn-field-list
dsn分野リストEXTENSION RFC822FieldList:、:= イドdsn分野リスト
internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC
1155
インターネット:、:= RFC1155からのOBJECT IDENTIFIER iso org(3) dod(6)1
mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned
OBJECT IDENTIFIERに郵送してください:、:= インターネット7--割り当てられたIANA
Kille Standards Track [Page 139] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[139ページ]。
mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
1495
mixer-core OBJECT IDENTIFIER ::= { mixer core(3) }
ミキサーOBJECT IDENTIFIER:、:= メールミキサー(1)--RFC1495ミキサーコアOBJECT IDENTIFIERから引き継ぐ:、:= ミキサーコア(3)
id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4}
イドrfc822分野リストOBJECT IDENTIFIER:、:= ミキサーコア2イドdsnヘッダーリストOBJECT IDENTIFIER:、:= ミキサーコア3イドdsn分野リストOBJECT IDENTIFIER:、:= ミキサーコア4
eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5}
-- the MIXER pseudo-EIT
eit-ミキサーOBJECT IDENTIFIER:、:= ミキサーコア5--ミキサー疑似EIT
END -- MIXER ASN.1
終わり--ミキサーASN.1
Kille Standards Track [Page 140] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[140ページ]。
SECURITY CONSIDERATIONS
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
AUTHOR'S ADDRESS
作者のアドレス
Steve Kille Isode Ltd The Dome The Square Richmond TW9 1DT England
スティーブKille Isode Ltdドームの正方形のリッチモンドTW9 1DTイギリス
Phone: +44-181-332-9091 Internet EMail: S.Kille@ISODE.COM
以下に電話をしてください。 +44-181-332-9091 インターネットメール: S.Kille@ISODE.COM
X.400 Email: I=S; S=Kille; P=Isode; A=Mailnet; C=FI;
X.400はメールします: I=S。 S=Kille。 P=Isode。 A=Mailnet。 CはFIと等しいです。
UFN: S.Kille, Isode, GB
UFN: S.Kille、Isode、GB
References
参照
1. CCITT , "Recommendations X.400", Message Handling Systems:
System Model - Service Elements, October 1984.
1. CCITT、「推薦X.400」メッセージハンドリングシステム: システムモデル--Elements、1984年10月を修理してください。
2. Allocchio, C., "MaXIM11 - Mapping between X.400 / Internet
Mail and Mail-11 mail", RFC 2162, January 1998.
2. Allocchio、C.、「MaXIM11、X.400/インターネットメールとメール-11メールの間で写像する、」、RFC2162、1月1998日
3. Allocchio, C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998.
3. Allocchio、C.、「(MCGAM)を写像するミキサーConformantグローバルアドレスを分配するのにインターネットDNSを使用します」、RFC2163、1998年1月。
4. Alvestrand, H., Kille, S., Miles, R., Rose, M., and S.
Thompson, "Mapping between X.400 and RFC-822 Message
Bodies", RFC 1495, August 1993.
4. Alvestrand、H.、Kille、S.、マイル、R.、ローズ、M.、およびS.トンプソン、「X.400とRFC-822メッセージボディーの間のマッピング」、RFC1495(1993年8月)。
5. Alvestrand, H., Romaguera, J., and K. Jordan, "Rules for
Downgrading Messages for X.400(88) to X.400(84) When MIME
Content-Types are Present in the Messages (Harpoon)", RFC
1496, August 1993.
5. Alvestrand(H.、Romaguera、J.、およびK.ジョーダン)は「MIMEコンテントタイプがMessages(もり)のPresentであるときに、X.400(88)のためのDowngrading MessagesのためにX.400(84)に統治します」、RFC1496、1993年8月。
6. Alvestrand, H., and S. Thompson, "Equivalences between X.400
and RFC-822 Message Bodies", RFC 1494, August 1993.
6. Alvestrand、H.、およびS.トンプソン、「X.400とRFC-822メッセージボディーの間の等価性」、RFC1494、1993年8月。
7. Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
7. Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、1995年3月。
Kille Standards Track [Page 141] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[141ページ]。
8. Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
Message Bodies", RFC 2157, January 1998.
8. H. Alvestrand、1998年1月、「X.400とRFC-822/MIMEメッセージの間でボディーを写像すること」でのRFC2157。
9. Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
9. N.、およびN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
10. Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, October 1989.
10. ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
11. CCITT/ISO, "CCITT Recommendations X.420/ ISO/IEC 10021-7,"
Message Handling Systems: Interpersonal Messaging System,
Dec 1988.
11. CCITT/ISO、「CCITT推薦X.420/ISO/IEC10021-7」、メッセージハンドリングシステム: 1988年12月の個人間のメッセージシステム。
12. CCITT/ISO, "CCITT Recommendations X.411/ ISO/IEC 10021-4,"
Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, Dec 1988.
12. CCITT/ISO、「CCITT推薦X.411/ISO/IEC10021-4」、メッセージハンドリングシステム: メッセージ転送システム: 抽象的なサービス定義と手順、1988年12月。
13. CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,"
Message Handling: System and Service Overview , Dec 1988.
13. CCITT/ISO、「CCITT推薦X.400/ISO/IEC10021-1」、メッセージハンドリング: システムとサービス概観、1988年12月。
14. CCITT/ISO, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO/IEC 8824, Dec
1988.
14. CCITT/ISO、「抽象構文記法1(ASN.1)の仕様」、CCITT推薦X.208/ISO/IEC8824、1988年12月。
15. CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,"
Message Handling: System and Service Overview , Dec 1992.
15. CCITT/ISO、「CCITT推薦X.400/ISO/IEC10021-1」、メッセージハンドリング: システムとサービス概観、1992年12月。
16. Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
16. クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
17. Kille, S., "Mapping Between X.400 and RFC 822", UK Academic
Community Report (MG.19) / RFC 987, June 1986.
17. Kille、S.、「X.400とRFC822の間のマッピング」、イギリス学界レポート(mg.19)/RFC987、1986年6月。
18. Kille, S., "Addendum to RFC 987", UK Academic Community
Report (MG.23) / RFC 1026, August 1987.
18. Kille、S.、「RFC987への付加物」、イギリス学界レポート(mg.23)/RFC1026、1987年8月。
19. Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC 1138, October 1989.
19. Kille、S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1138、10月1989日
20. Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC 1148, March 1990.
20. Kille、S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1148、3月1990日
21. Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC 1327, May 1992.
21. Kille、S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1327、5月1992日
22. Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328, May
1992.
22. Kille、S.、「X.400 1988年から1984格下げ」、RFC1328、1992年5月。
Kille Standards Track [Page 142] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[142ページ]。
23. Kille, S., "A String Encoding of Presentation Address", RFC
1278, November 1992.
23. Kille、S.、「プレゼンテーションアドレスをコード化するストリング」、RFC1278、1992年11月。
24. Kille, S., "A String Representation of Distinguished Name",
RFC 1485, January 1992.
24. Kille、S.、「分類名のストリング表現」、RFC1485、1992年1月。
25. Kille, S., "Using the OSI Directory to achieve User
Friendly Naming", RFC 1484, January 1992.
25. Kille、S.、「User Friendly Namingを達成するのにOSIディレクトリを使用します」、RFC1484、1992年1月。
26. Kille, S., "Use of an X.500/LDAP directory to support MIXER
address mapping", RFC 2164, January 1998.
26. Kille、S.、「MIXERアドレス・マッピングを支持するX.500/LDAPディレクトリの使用」、RFC2164、1998年1月。
27. Koorland, N., "Message Attachmment Work Group (MAWG): MAWG
Feasibility Project Guide," EMA Report, Version 1.5, Nov
1995.
27. Koorland、N.、「メッセージAttachmment仕事は以下を分類(MAWG)」。 「MAWG実行可能性プロジェクトガイド」、EMAレポート、バージョン1.5、1995年11月。
28. Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
28. ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。
29. Moore, K., "SMTP Service Extensions for Delivery Status
Notifications", RFC 1891, Januaty 1996.
29. ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、Januaty1996。
30. Postel, J., "SIMPLE MAIL TRANSFER PROTOCOL", STD 10, RFC 821,
August 1982.
30. ポステル、J.、「SMTP」、STD10、RFC821、1982年8月。
Kille Standards Track [Page 143] RFC 2156 MIXER January 1998
Kille規格はミキサー1998年1月にRFC2156を追跡します[143ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Kille Standards Track [Page 144]
Kille標準化過程[144ページ]
一覧
スポンサーリンク
