RFC1506 日本語訳
1506 A Tutorial on Gatewaying between X.400 and Internet Mail. J.Houttuin. August 1993. (Format: TXT=85550 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Houttuin Request for Comments: 1506 RARE Secretariat RARE Technical Report: 6 August 1993
Houttuinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1506年のまれな事務局まれな技術報告書: 1993年8月6日
A Tutorial on Gatewaying between X.400 and Internet Mail
X.400とインターネットメールの間のGatewayingの上のチュートリアル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Introduction
序論
There are many ways in which X.400 and Internet (STD 11, RFC 822) mail systems can be interconnected. Addresses and service elements can be mapped onto each other in different ways. From the early available gateway implementations, one was not necessarily better than another, but the sole fact that each handled the mappings in a different way led to major interworking problems, especially when a message (or address) crossed more than one gateway. The need for one global standard on how to implement X.400 - Internet mail gatewaying was satisfied by the Internet Request For Comments 1327, titled "Mapping between X.400(1988)/ISO 10021 and RFC 822."
X.400とインターネット(STD11、RFC822)メールシステムがインタコネクトされることができる多くの方法があります。 異なった方法でアドレスとサービス要素を互いに写像できます。 早めの利用可能なゲートウェイ実現によって、1つは必ず別のものより良かったというわけではありませんが、それぞれが異なった方法でマッピングを扱ったという唯一の事実は問題を織り込みながら専攻するのを導きました、特にメッセージ(または、アドレス)が1門以上を越えたとき。 どうX.400を実行するかの1つの国際基準の必要性--インターネット・メールgatewayingはインターネットRequest For Comments1327のそばで満足していて、題をつけられた「X.400(1988)/ISO10021とRFC822の間のマッピング」でした。
This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. The need for such a tutorial can be illustrated by quoting the following discouraging paragraph from RFC 1327, chapter 1: "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."
このチュートリアルは、新しいゲートウェイマネージャがRFC1327によると、gatewayingされるメールの複雑な対象に届くのを助けるために特に作成されました。 RFC1327、第1章から以下のがっかりしているパラグラフを引用することによって、そのようなチュートリアルの必要性を例証できます: 「警告:」 この仕様の残りは技術的に詳細です。 RFC822とX.400(1988)の文脈以外に、それは理解できないでしょう。 「これらの仕様になじみ深くない場合、このドキュメントを読むのを試みないでください。」
The introduction of this tutorial is general enough to be read not only by gateway managers, but also by e-mail managers who are new to gatewaying or to one of the two e-mail worlds in general. Parts of this introduction can be skipped as needed.
このチュートリアルの導入は十分一般的であるのが、ゲートウェイマネージャに読み込むだけではなく、gatewayingに新しいメールマネージャか2メールの1つにも一般に、世界を読み込むことであるということです。 必要に応じてこの序論の部分をスキップできます。
For novice end-users, even this tutorial will be difficult to read. They are encouraged to use the COSINE MHS pocket user guide [14] instead.
読むのはこのチュートリアルさえ初心者エンドユーザにとって、難しくなるでしょう。 彼らが[14] 代わりにCOSINE MHSポケットユーザガイドを使用するよう奨励されます。
To a certain extent, this document can also be used as a reference guide to X.400 <-> RFC 822 gatewaying. Wherever there is a lack of detail in the tutorial, it will at least point to the corresponding chapters in other documents. As such, it shields the RFC 1327 novice
また、ある程度、参照ガイドとしてX.400<->RFC822gatewayingにこのドキュメントを使用できます。 どこでも、詳細の不足があるところに、チュートリアルで、それは他のドキュメントに対応する章を少なくとも示すでしょう。 そういうものとして、それはRFC1327初心者を保護します。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 1] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[1ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
from too much detail.
あまりに多くの詳細から。
Acknowledgements
承認
This tutorial is heavily based on other documents, such as [2], [6], [7], [8], and [11], from which large parts of text were reproduced (slightly edited) by kind permission from the authors.
このチュートリアルはずっしりと他のドキュメントに基づいています、[2]や、[6]や、[7]や、[8]や、[11]などのように。(テキストのかなりの部分は親切な許可によって[11]から作者から再生させられました(わずかに編集されます))。
The author would like to thank the following persons for their thorough reviews: Peter Cowen (Nexor), Urs Eppenberger (SWITCH), Erik Huizer (SURFnet), Steve Kille (ISODE Consortium), Paul Klarenberg (NetConsult), Felix Kugler (SWITCH), Sabine Luethi.
作者は彼らの徹底的なレビューについて以下の人々に感謝したがっています: ピーター・カウエン(Nexor)、ウルスEppenberger(スイッチ)、エリックHuizer(SURFnet)、スティーブKille(ISODE共同体)、ポールKlarenberg(NetConsult)、フェリクス・クーグラー(スイッチ)(サビーヌLuethi)。
Disclaimer
注意書き
This document is not everywhere exact and/or complete in describing the involved standards. Irrelevant details are left out and some concepts are simplified for the ease of understanding. For reference purposes, always use the original documents.
このドキュメントはいたる所にありません。かかわった規格について説明するのにおいて正確である、そして/または、完全です。 無関係の詳細は省かれます、そして、いくつかの概念が理解の容易さのために簡素化されます。 参照目的には、いつも正本を使用してください。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 2] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[2ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
Table of Contents
目次
1. An overview of relevant standards ........................ 4
1.1. What is X.400 ? ...................................... 5
1.2. What is an RFC ? ..................................... 8
1.3. What is RFC 822 ? .................................... 9
1.4. What is RFC 1327 ? ................................... 11
2. Service Elements ......................................... 12
3. Address mapping .......................................... 14
3.1. X.400 addresses ...................................... 15
3.1.1. Standard Attributes .............................. 15
3.1.2. Domain Defined Attributes ........................ 17
3.1.3. X.400 address notation ........................... 17
3.2. RFC 822 addresses .................................... 19
3.3. RFC 1327 address mapping ............................. 20
3.3.1. Default mapping .................................. 20
3.3.1.1. X.400 -> RFC 822 ............................. 20
3.3.1.2. RFC 822 -> X.400 ............................. 22
3.3.2. Exception mapping ................................ 23
3.3.2.1. PersonalName and localpart mapping ........... 25
3.3.2.2. X.400 domain and domainpart mapping .......... 26
3.3.2.2.1. X.400 -> RFC 822 ......................... 27
3.3.2.2.2. RFC 822 -> X.400 ......................... 28
3.4. Table co-ordination .................................. 31
3.5. Local additions ...................................... 31
3.6. Product specific formats ............................. 32
3.7. Guidelines for mapping rule definition ............... 34
4. Conclusion ............................................... 35
Appendix A. References ...................................... 36
Appendix B. Index (Only available in the Postscript version) 37
Appendix C. Abbreviations ................................... 37
Appendix D. How to access the MHS Co-ordination Server ...... 38
Security Considerations ..................................... 39
Author's Address ............................................ 39
1. 関連規格の概観… 4 1.1. X.400は何ですか? 5 1.2. RFCは何ですか? ..................................... 8 1.3. RFC822は何ですか? 9 1.4. RFC1327は何ですか? 11 2. Elementsにサービスを提供してください… 12 3. マッピングを記述してください… 14 3.1. X.400アドレス… 15 3.1.1. 標準の属性… 15 3.1.2. ドメインは属性を定義しました… 17 3.1.3. X.400は記法を記述します… 17 3.2. RFC822アドレス… 19 3.3. RFC1327はマッピングを記述します… 20 3.3.1. デフォルトマッピング… 20 3.3.1.1. X.400->RFC822… 20 3.3.1.2. RFC822->X.400… 22 3.3.2. 例外マッピング… 23 3.3.2.1. PersonalNameとlocalpartマッピング… 25 3.3.2.2. X.400ドメインとdomainpartマッピング… 26 3.3.2.2.1. X.400->RFC822… 27 3.3.2.2.2. RFC822->X.400… 28 3.4. コーディネーションを見送ってください… 31 3.5. 地方の追加… 31 3.6. 製品の特定の形式… 32 3.7. 配置規則定義のためのガイドライン… 34 4. 結論… 35 付録A.参照… 36 37付録B.Index(補遣版だけで利用可能な)Appendix C.Abbreviations… 37 MHS Co-叙階式Serverにアクセスする付録D.How… 38 セキュリティ問題… 39作者のアドレス… 39
RARE Working Group on Mail and Messaging (WG-MSG) [Page 3] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[3ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
1. An overview of relevant standards
1. 関連規格の概観
This chapter describes the history, status, future, and contents of the involved standards.
本章はかかわった規格の歴史、状態、未来、およびコンテンツについて説明します。
There is a major difference between mail systems used in the USA and Europe. Mail systems originated mainly in the USA, where their explosive growth started as early as in the seventies. Different company-specific mail systems were developed simultaneously, which, of course, led to a high degree of incompatibility. The Advanced Research Projects Agency (ARPA), which had to use machines of many different manufacturers, triggered the development of the Internet and the TCP/IP protocol suite, which was later accepted as a standard by the US Department of Defense (DoD). The Internet mail format is defined in STD 11, RFC 822 and the protocol used for exchanging mail is known as the simple mail transfer protocol (SMTP) [1]. Together with UUCP and the BITNET protocol NJE, SMTP has become one of the main de facto mail standards in the US.
米国とヨーロッパで使用されるメールシステムの間には、主要な違いがあります。 主に米国で溯源されたシステムを郵送してください。そこでは、それらの爆発的成長が70年代と同じくらい早く始まりました。 異なった会社の特有のメールシステムは同時に、開発されました(もちろん高度の不一致に通じました)。 (Advanced Research Projects Agencyは多くの異なったメーカーのマシンを使用しなければなりませんでした)。Advanced Research Projects Agency(ARPA)はインターネットの発展とTCP/IPプロトコル群の引き金となりました。(それは、後で規格として米国国防総省(DoD)によって認められました)。 RFC822、インターネットメール書式はSTD11で定義されます、そして、メールを交換するのに使用されるプロトコルはSMTP(SMTP)[1]として知られています。 UUCPとBitnetプロトコルNJEと共に、SMTPは米国で主な事実上のメール規格の1つになりました。
Unfortunately, all these protocols were incompatible, which explains the need to come to an acceptable global mail standard. CCITT and ISO began working on a norm and their work converged in what is now known as the X.400 Series Recommendations. One of the objectives was to define a superset of the existing systems, allowing for easier integration later on. Some typical positive features of X.400 are the store-and-forward mechanism, the hierarchical address space and the possibility of combining different types of body parts into one message body.
残念ながら、これらのすべてのプロトコルが両立しなかったです(許容できるグローバルなメール規格に来る必要性がわかります)。 CCITTとISOは標準に働き始めました、そして、彼らの仕事は今X.400 Series Recommendationsとして知られていることで一点に集まりました。 目的の1つは後でより簡単な統合を考慮して、既存のシステムのスーパーセットを定義することでした。 X.400のいくつかの典型的な上向きの特徴が、店とフォワードメカニズムと、階層的なアドレス空間と異なったタイプの身体の部分を1つのメッセージ本体に結合する可能性です。
In Europe, the mail system boom came later. Since there was not much equipment in place yet, it made sense to use X.400 as much as possible right from the beginning. A strong X.400 lobby existed, especially in West-Germany (DFN). In the R&D world, mostly EAN was used because it was the only affordable X.400 product at that time (Source-code licenses were free for academic institutions).
ヨーロッパでは、メールシステムブームが後で来ました。 しかし、それほど多くない設備が適所にあったので、それで、X.400をできるだけ使用する意味は始めから右になりました。 強いX.400のロビーは特に西ドイツ(DFN)に存在しました。 研究開発世界では、その時それが唯一の手頃なX.400製品(アカデミックな団体において、ソースコードライセンスは無料であった)であったので、ほとんどEANが使用されました。
At the moment, the two worlds of X.400 and SMTP are moving closer together. For instance, the United States Department of Defense, one of the early forces behind the Internet, has decided that future DoD networking should be based on ISO standards, implying a migration from SMTP to X.400. As an important example of harmonisation in the other direction, X.400 users in Europe have a need to communicate with the Internet. Due to the large traffic volume between the two nets it is not enough interconnecting them with a single international gateway. The load on such a gateway would be too heavy. Direct access using local gateways is more feasible.
現在、X.400とSMTPの2つの世界が、より近くに一緒に動いています。 例えば、合衆国国防総省(インターネットの後ろの早めの力の1つ)は、将来のDoDネットワークがISO規格に基づくべきであると決めました、SMTPからX.400までの移動を含意して。 もう片方の方向への調和させることの重要な例として、ヨーロッパのX.400ユーザには、インターネットで交信する必要があります。 2つのネットの間の大きい交通量のために、国際的な1つの門でそれらとインタコネクトするのは十分ではありません。 そのようなゲートウェイの上の負荷は重過ぎるでしょう。 地方のゲートウェイを使用する直接アクセスは、より可能です。
Although the expected success of X.400 has been a bit disappointing
X.400の予想された成功は少し期待はずれですが
RARE Working Group on Mail and Messaging (WG-MSG) [Page 4] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[4ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
(mainly because no good products were available), many still see the future of e-mail systems in the context of this standard.
(主にどんな良い製品も利用可能でなかったので)、多くがこの規格の文脈でまだ電子メール・システムの未来に遭遇しています。
And regardless if in the long run X.400 will or will not take over the world of e-mail systems, SMTP cannot be neglected over the next ten years. Especially the simple installation procedures and the high degree of connectivity will contribute to a growing number of RFC 822 installations in Europe and world-wide in the near future.
そして、不注意に、X.400が結局電子メール・システムの世界を買収する場合、次の10年間SMTPを無視できません。 特に簡単な据え付け要領と高度の接続性は近い将来、ヨーロッパと世界中でRFCの増加している数に822のインストールを寄付するでしょう。
1.1. What is X.400 ?
1.1. X.400は何ですか?
In October 1984, the Plenary Assembly of the CCITT accepted a standard to facilitate international message exchange between subscribers to computer based store-and-forward message services. This standard is known as the CCITT X.400 series recommendations ([16], from now on called X.400(84)) and happens to be the first CCITT recommendation for a network application. It should be noted that X.400(84) is based on work done in the IFIP Working Group 6.5, and that ISO at the same time was proceeding towards a compatible document. However, the standardisation efforts of CCITT and ISO did not converge in time (not until the 1988 version), to allow the publication of a common text.
1984年10月に、CCITTのPlenary議会は、コンピュータに基づいている店とフォワードメッセージサービスに加入者の間の国際的な交換処理を容易にするために規格を受け入れました。 この規格は、CCITT X.400シリーズ推薦([16]として知られていて、これから先、X.400(84))と呼んで、たまたまネットワーク応用のための最初のCCITT推薦です。 X.400(84)がIFIP作業部会6.5で行われた仕事に基づいて、同時間のISOがコンパチブルドキュメントに向かって続いていたことに注意されるべきです。 しかしながら、CCITTとISOの規格化の努力は、時間内に(1988年のいずれのバージョンまでもそうしない)、一般的なテキストの公表を許すために一点に集まりませんでした。
X.400(84) triggered the development of software implementing (parts of) the standard in the laboratories of almost all major computer vendors and many software houses. Similarly, public carriers in many countries started to plan X.400(84) based message systems that would be offered to the users as value added services. Early implementations appeared shortly after first drafts of the standard were published and a considerable number of commercial systems are available nowadays.
X.400(84)がソフトウェア実行の開発の引き金となった、(離れている、)、ほとんどすべての一流のコンピュータ・ベンダーと多くのソフトウエア・ハウスの実験室の規格。 同様に、多くの国のパブリックキャリアは付加価値が付いたサービスとしてユーザに提供されるX.400(84)のベースのメッセージシステムを計画し始めました。 規格の最初の案文が発表されたすぐ後に早めの実現は現れました、そして、多数の商業の体系がこの頃は、利用可能です。
X.400(84) describes a functional model for a Message Handling System (MHS) and associates services and protocols. The model illustrated in Figure 1.1. defines the components of a distributed messaging system.
X.400(84)はMessage Handling System(MHS)のために機能論的モデルについて説明して、サービスとプロトコルを関連づけます。 図1.1で例証されたモデルは分配されたメッセージシステムの成分を定義します。
Users in the MHS environment are provided with the capability of sending and receiving messages. Users in the context of an MHS may be humans or application processes. The User Agent (UA) is a process that makes the services of the MTS available to the user. A UA may be implemented as a computer program that provides utilities to create, send, receive and perhaps archive messages. Each UA, and thus each user, is identified by a name (each user has its own UA).
MHS環境におけるユーザにメッセージの送受信の能力を提供します。 MHSの文脈のユーザは、人間かアプリケーション・プロセスであるかもしれません。 Userエージェント(UA)はMTSのサービスをユーザにとって利用可能にする過程です。 UAは作成するユーティリティを提供するコンピュータ・プログラムとして実行されて、発信して、受信して、恐らくメッセージを格納するかもしれません。 各UA、およびその結果各ユーザは名前によって特定されます(各ユーザはそれ自身のUAを持っています)。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 5] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[5ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
-----------------------------------------------------------------
| user user Message Handling Environment|
| | | |
| ----------------------------------------------------------|
| | | | Message Handling System ||
| | ---- ---- ||
| | |UA| |UA| ||
| | ---- ---- ||
| | | | ||
| | -------------------------------------------------||
| | | | | Message Transfer System |||
| | ---- | ----- ----- |||
|user-|-|UA|--|--|MTA| |MTA| |||
| | ---- | ----- ----- |||
| | | \ / |||
| | | \ / |||
| | | \ / |||
| | | \ / |||
| | | \ / |||
| | ---- | ----- |||
|user-|-|UA|--|---------|MTA| |||
| | ---- | ----- |||
| | -------------------------------------------------||
| ----------------------------------------------------------|
-----------------------------------------------------------------
Fig. 1.1. X.400 functional model
----------------------------------------------------------------- | ユーザユーザMessage Handling Environment| | | | | | ----------------------------------------------------------| | | | | メッセージハンドリングシステム|| | | ---- ---- || | | |Ua| |Ua| || | | ---- ---- || | | | | || | | -------------------------------------------------|| | | | | | メッセージ転送システム||| | | ---- | ----- ----- ||| |ユーザ|-|Ua|--|--|MTA| |MTA| ||| | | ---- | ----- ----- ||| | | | \ / ||| | | | \ / ||| | | | \ / ||| | | | \ / ||| | | | \ / ||| | | ---- | ----- ||| |ユーザ|-|Ua|--|---------|MTA| ||| | | ---- | ----- ||| | | -------------------------------------------------|| | ----------------------------------------------------------| ----------------------------------------------------------------- 図1.1。 X.400機能論的モデル
The Message Transfer system (MTS) transfers messages from an originating UA to a recipient UA. As implied by the Figure 1.1, data sent from UA to UA may be stored temporarily in several intermediate Message Transfer Agents (MTA), i.e., a store-and- forward mechanism is being used. An MTA forwards received messages to a next MTA or to the recipient UA.
Message Transferシステム(MTS)は由来しているUAから受取人UAまでメッセージを移します。 そして、UAからUAに送られたデータは図1.1によって含意されるように数人の中間的Message Transferエージェント(MTA)に一時格納されるかもしれません、すなわち、店、-、-前進のメカニズムが使用されています。 MTAは次のMTA、または、受取人UAに受信されたメッセージを転送します。
X.400(84) divides layer 7 of the OSI Reference Model into 2 sublayers, the User Agent Layer (UAL) and the Message Transfer Layer (MTL) as shown in the Figure 1.2.
X.400(84)は図1.2に示されるようにOSI Reference Modelの層7を2つの副層、UserエージェントLayer(UAL)、およびMessage Transfer Layer(MTL)に分割します。
The MTL is involved in the transport of messages from UA to UA, using one or several MTAs as intermediaries. By consequence, routing issues are entirely dealt with in the MTL. The MTL in fact corresponds to the postal service that forwards letters consisting of an envelope and a content. Two protocols, P1 and P3, are used between the MTL entities (MTA Entity (MTAE), and Submission and Delivery Entity (SDE)) to reliably transport messages. The UAL embodies peer UA Entities (UAE), which interpret the content of a message and offer specific services to the application process. Depending on the application to be supported on top of the MTL, one of several end-
仲介者として1か数個のMTAsを使用して、MTLはメッセージのUAからUAまでの輸送にかかわります。 結果で、ルーティング問題はMTLで完全に対処されています。 事実上、MTLは封筒と内容から成る手紙を転送する郵便業務に対応しています。 2つのプロトコル(P1とP3)が、メッセージを確かに輸送するのにMTL実体(MTA Entity(MTAE)、Submission、およびDelivery Entity(SDE))の間で使用されます。 UALは同輩UA Entities(UAE)を具体化します。(UA Entitiesはメッセージの内容を解釈して、アプリケーション・プロセスに対する特定のサービスを提供します)。 数個では、終わって、アプリケーションによって、MTL、1の上で支持されてください。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 6] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[6ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
to-end protocols (Pc) is used between UAEs. For electronic mail, X.400(84) defines the protocol P2 as part of the InterPersonal Messaging Service (IPMS). Conceivably other UAL protocols may be defined, e.g., a protocol to support the exchange of electronic business documents.
終わりまでのプロトコル(Pc)はUAEsの間で使用されます。 電子メールに関しては、X.400(84)はInterPersonalメッセージサービス(IPMS)の一部とプロトコルP2を定義します。 多分他のUALプロトコルは定義されるかもしれなくて、例えば、サポートへのプロトコルは電子業務用書類の交換です。
--------------------------------------------------------------
----- -----
UA layer |UAE|<----- P2, Pc ----------->|UAE|
----- -----
--------------------------------------------------------------
------ ------ -----
MTA layer |MTAE|<-- P1 -->|MTAE|<-- P3-->|SDE|
------ ------ -----
--------------------------------------------------------------
xxxE = xxx Entity ; SDE = Submission & Delivery Entity
--------------------------------------------------------------
Fig. 1.2. X.400 Protocols
-------------------------------------------------------------- ----- ----- UA層|UAE| <、-、-、-、-- P2、Pc----------->|UAE| ----- ----- -------------------------------------------------------------- ------ ------ ----- MTA層|MTAE| <-- P1-->|MTAE| <-- P3-->|SDE| ------ ------ ----- -------------------------------------------------------------- xxxEはxxx Entityと等しいです。 SDE=服従と配送実体-------------------------------------------------------------- 図1.2。 X.400プロトコル
The structure of an InterPersonal Message (IPM) can be visualised as in Figure 1.3. (Note that the envelope is not a part of the IPM; it is generated by the MTL).
図1.3のようにInterPersonal Message(IPM)の構造を想像できます。 (封筒がIPMの一部でないことに注意してください; それはMTLによって発生します。)
Forwarded
Message IP-message
- ---------- --- ---------- -
| message- |envelope| / | PDI | |
| content IPM ---------- / ---------- |
| - - ---------- / ---------- |
| | | IPM- |heading | / |heading | |
| | | body ---------- / ---------- |
| | | - ----------/ ---------- |
| | | | |bodypart| |bodypart| |
| | | | ----------\ ---------- |
| | | | ---------- \ ---------- |
| | | | |bodypart| \ |bodypart| |
| | | | ---------- \ ---------- |
| | | | . \ |
| | | | . \ |
| | | | ---------- \ ---------- |
| | | | |bodypart| \ |bodypart| |
- - - - ---------- - ---------- -
(PDI = Previous Delivery Info.)
Fig. 1.3. X.400 message structure
転送されたメッセージIP-メッセージ、----------- --- ---------- - | メッセージ|封筒| / | PDI| | | 内容IPM---------- / ---------- | | - - ---------- / ---------- | | | | IPM|見出し| / |見出し| | | | | ボディー---------- / ---------- | | | | - ----------/ ---------- | | | | | |bodypart| |bodypart| | | | | | ----------\ ---------- | | | | | ---------- \ ---------- | | | | | |bodypart| \ |bodypart| | | | | | ---------- \ ---------- | | | | | . \ | | | | | . \ | | | | | ---------- \ ---------- | | | | | |bodypart| \ |bodypart| | - - - - ---------- - ---------- - (PDIは前の配送インフォメーションと等しいです。) 図1.3。 X.400メッセージ構造
An IPM heading contains information that is specific for an interpersonal message like 'originator', 'subject', etc. Each bodypart can contain one information type, text, voice or as a
IPM見出しは'創始者'、'対象'などのような個人間のメッセージに、特定の情報を含んでいます。 各bodypartは声かaとしてある情報タイプ、テキストを含むことができます。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 7] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[7ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
special case, a forwarded message. A forwarded message consists of the original message together with Previous Delivery Information (PDI), which is drawn from the original delivery envelope.
特別なケース、転送されたメッセージ。 転送されたメッセージはPrevious Delivery情報(PDI)と共にオリジナルのメッセージから成ります。(それは、オリジナルの配送封筒から得られます)。
Early experience with X.400(84) showed that the standard had various shortcomings. Therefore CCITT, in parallel with ISO, corrected and extended the specification during its 1984 to 1988 study period and produced a revised standard [17], which was accepted at the 1988 CCITT Plenary Meeting [10]. Amongst others, X.400(88) differs from X.400(84) in that it defines a Message Store (MS), which can be seen as a kind of database for messages. An MS enables the end-user to run a UA locally, e.g., on a PC, whilst the messages are stored in the MS, which is co-located with the MTA. The MTA can thus always deliver incoming messages to the MS instead of to the UA. The MS can even automatically file incoming messages according to certain criteria. Other enhancements in the 88 version concern security and distribution lists.
X.400(84)の早めの経験は、様々な短所が規格にあったのを示しました。 したがって、CCITTは、1984年から1988研究期間の間、ISOと平行して仕様を修正して、広げて、改訂された規格[17]を生産しました。(それは、1988CCITT Plenary Meeting[10]で受け入れられました)。 他のものでは、X.400(88)はメッセージのための一種のデータベースと考えることができるMessageストア(MS)を定義するという点においてX.400(84)と異なっています。 MSは、エンドユーザがUAを局所的に走らせるのを可能にします、例えば、PCの上で、メッセージがMS(MTAと共に共同見つけられている)に格納されますが。 MTAはその結果、UAの代わりにいつも入力メッセージをMSに届けることができます。 ある評価基準に従って、MSは自動的に入力メッセージをファイルさえできます。 88バージョンにおける他の増進はセキュリティと発送先リストに関係があります。
1.2. What is an RFC ?
1.2. RFCは何ですか?
The Internet, a loosely-organised international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards. There are also many isolated internets, i.e., sets of interconnected networks, that are not connected to the Internet but use the Internet Standards. The architecture and technical specifications of the Internet are the result of numerous research and development activities conducted over a period of two decades, performed by the network R&D community, by service and equipment vendors, and by government agencies around the world.
インターネット(自治の、そして、インタコネクトされたネットワークの緩く組織化された国際協力)は、インターネットStandardsによって定義されたプロトコルと手順を開くために自発的の固守でホスト間通信を支持します。 また、多くの孤立しているインターネット、すなわち、インターネットに関連づけられませんが、インターネットStandardsを使用する相互接続ネットワークのセットがあります。 インターネットに関する構造と技術仕様書はネットワーク研究開発共同体によって実行された20年間の期間にわたってサービスと設備業者、および世界中の政府機関によって行われた頻繁な研究開発活動の結果です。
In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with operational experience, enjoys significant public support, and is recognisably useful in some or all parts of the Internet.
一般に、インターネットStandardは安定した仕様であり、よく分かって、技術的に有能であり、運用経験による複数の、そして、独立していて、共同利用できる実現を持って、重要な公的支援を楽しんで、インターネットのいくつかかすべての地域で役に立つrecognisablyです。
The principal set of Internet Standards is commonly known as the "TCP/IP protocol suite". As the Internet evolves, new protocols and services, in particular those for Open Systems Interconnection (OSI), have been and will be deployed in traditional TCP/IP environments, leading to an Internet that supports multiple protocol suites.
インターネットStandardsの主要なセットは「TCP/IPプロトコル群」として一般的に知られています。 インターネットが発展するとき、新しいプロトコルとサービス(オープン・システム・インターコネクション(OSI)のための特にそれら)は、あって、伝統的なTCP/IP環境で配備されるでしょう、複数のプロトコル群を支えるインターネットに通じて。
The following organisations are involved in setting Internet standards.
以下の機構はインターネット標準を設定するのにかかわります。
Internet standardisation is an organised activity of the Internet
インターネット規格化はインターネットの組織化された活動です。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 8] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[8ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
Society (ISOC). The ISOC is a professional society that is concerned with the growth and evolution of the world-wide Internet, with the way in which the Internet is and can be used, and with the social, political, and technical issues that arise as a result.
社会(ISOC)。 ISOCは世界的なインターネットの成長と発展、インターネットはあって、使用できる方法、およびその結果起こる社会的で、政治上の、そして、技術的な問題に関するプロの社会です。
The Internet Engineering Task Force (IETF) is the primary body developing new Internet Standard specifications. The IETF is composed of many Working Groups, which are organised into areas, each of which is co-ordinated by one or more Area Directors.
インターネット・エンジニアリング・タスク・フォース(IETF)は第一のボディー展開している新しいインターネットStandard仕様です。 IETFは多くのWorking Groupsで構成されます。(Working Groupsは領域に構成されています)。それは1人以上のAreaディレクターによってそれぞれ調整されます。
The Internet Engineering Steering Group (IESG) is responsible for technical management of IETF activities and the approval of Internet standards specifications, using well-defined rules. The IESG is composed of the IETF Area Directors, some at-large members, and the chairperson of the IESG/IETF.
インターネットEngineering Steering Group(IESG)はIETF活動の技術管理とインターネット標準仕様の承認に責任があります、明確な規則を使用して。 IESGはIETF Areaディレクター、多大における何人かのメンバー、およびIESG/IETFの議長で構成されます。
The Internet Architecture Board (IAB) has been chartered by the Internet Society Board of Trustees to provide quality control and process appeals for the standards process, as well as external technical liaison, organizational oversight, and long-term architectural planning and research.
インターネット・アーキテクチャ委員会(IAB)は、標準化過程、外部の技術連絡、組織的な見落とし、および長期の建築計画に品質管理と過程上告を提供して、研究するためにTrusteesのインターネット協会Boardによってチャーターされました。
Any individual or group (e.g., an IETF or RARE working group) can submit a document as a so-called Internet Draft. After the document is proven stable, the IESG may turn the Internet-Draft into a "Requests For Comments" (RFC). RFCs cover a wide range of topics, from early discussion of new research concepts to status memos about the Internet. All Internet Standards (STDs) are published as RFCs, but not all RFCs specify standards. Another sub-series of the RFCs are the RARE Technical Reports (RTRs).
どんな個人やグループ(例えば、IETFかRAREワーキンググループ)もいわゆるインターネットDraftとしてドキュメントを提出できます。 ドキュメントが安定していると立証された後に、IESGはインターネット草稿を「コメントを求める要求」(RFC)に変えるかもしれません。 RFCsは新しい研究概念の早めの議論からインターネットに関する状態メモまでさまざまな話題をカバーしています。 すべてのRFCsではなく、RFCsが規格を指定するとき、すべてのインターネットStandards(STDs)が発行されます。 RFCsの別のサブシリーズはRARE Technical Reports(RTRs)です。
As an example, this tutorial also started out as an Internet-Draft. After almost one year of discussions and revisions it was approved by the IESG as an Informational RFC.
また、例として、このチュートリアルはインターネット草稿として始めました。 およそ1年間の議論と改正の後に、それはInformational RFCとしてIESGによって承認されました。
Once a document is assigned an RFC number and published, that RFC is never revised or re-issued with the same number. Instead, a revision will lead to the document being re-issued with a higher number indicating that an older one is obsoleted.
ドキュメントがいったんRFC番号が割り当てられて、発表されると、そのRFCは同じ数で改訂されるか、または決して再発行されません。 代わりに、改正は、より大きい数が、より古いものが時代遅れにされるのを示していて再発行されるドキュメントにつながるでしょう。
1.3. What is RFC 822 ?
1.3. RFC822は何ですか?
STD 11, RFC 822 defines a standard for the format of Internet text messages. Messages consist of lines of text. No special provisions are made for encoding drawings, facsimile, speech, or structured text. No significant consideration has been given to questions of data compression or to transmission and storage efficiency, and the standard tends to be free with the number of bits consumed. For
STD11、RFC822はインターネット・テキスト・メッセージの形式の規格を定義します。 メッセージはテキストの線から成ります。 特別条項は、全く図面、ファクシミリ、スピーチ、または構造化されたテキストをコード化するために作られていません。 データ圧縮の質問、または、トランスミッションと充てん率に対してどんな重要な考慮も払っていません、そして、規格はビットの数が消費されている状態で自由である傾向があります。 for
RARE Working Group on Mail and Messaging (WG-MSG) [Page 9] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[9ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
example, field names are specified as free text, rather than special terse codes.
例、フィールド名は特別な簡潔なコードよりむしろ無料のテキストとして指定されます。
A general "memo" framework is used. That is, a message consists of some information in a rigid format (the 'headers'), followed by the main part of the message (the 'body'), with a format that is not specified in STD 11, RFC 822. It does define the syntax of several fields of the headers section; some of these fields must be included in all messages.
一般的な「メモ」枠組みは使用されています。 すなわち、メッセージはSTD11(RFC822)で指定されない形式でメッセージ('ボディー')の主部があとに続いた堅い形式('ヘッダー')で何らかの情報から成ります。 それはヘッダー部分のいくつかの分野の構文を定義します。 すべてのメッセージにこれらの分野のいくつかを含まなければなりません。
STD 11, RFC 822 is used in conjunction with a number of different message transfer protocol environments (822-MTSs).
STD11、RFC822は多くの異なったメッセージ転送プロトコル環境(822-MTSs)に関連して使用されます。
- SMTP Networks: On the Internet and other TCP/IP networks,
STD 11, RFC 822 is used in conjunction with two other
standards: STD 10, RFC 821, also known as Simple Mail
Transfer Protocol (SMTP) [1], and RFCs 1034 and 1035
which specify the Domain Name System [3].
- SMTPネットワーク: STD11、インターネットと他のTCP/IPネットワークでは、RFC822は他の2つの規格に関連して使用されます: STD10、また、シンプルメールトランスファプロトコル(SMTP)[1]として知られているRFC821、およびドメインネームシステム[3]を指定するRFCs1034と1035。
- UUCP Networks: UUCP is the UNIX to UNIX CoPy protocol, which
is usually used over dialup telephone networks to provide a
simple message transfer mechanism.
- UUCPネットワーク: UUCPはUNIX CoPyプロトコルへのUNIXです。(通常、そのUNIXは、簡単なメッセージトランスファ・メカニズムを提供するのにダイアルアップ電話網の上で使用されます)。
- BITNET: Some parts of Bitnet and related networks use STD
11, RFC 822 related protocols, with EBCDIC encoding.
- Bitnet: Bitnetと関連するネットワークのいくつかの部分がSTD11を使用して、RFC822はEBCDICコード化でプロトコルを関係づけました。
- JNT Mail Networks: A number of X.25 networks, particularly
those associated with the UK Academic Community, use the JNT
(Joint Network Team) Mail Protocol, also known as Greybook.
- JNTはネットワークに郵送します: 多くのX.25ネットワーク(特にイギリスのAcademic Communityに関連づけられたもの)がまた、Greybookとして知られているJNT(共同Network Team)メールプロトコルを使用します。
STD 11, RFC 822 is based on the assumption that there is an underlying service, which in RFC 1327 is called the 822-MTS service. The 822-MTS service provides three basic functions:
STD11、RFC822はRFC1327に822-MTSサービスと呼ばれる基本的なサービスがあるという仮定に基づいています。 822-MTSサービスは3つの基本機能を提供します:
1. Identification of a list of recipients.
2. Identification of an error return address.
3. Transfer of an RFC 822 message.
1. 受取人のリストの識別。 2. 誤り返送先の識別。 3. RFC822メッセージの転送。
It is possible to achieve 2) within the RFC 822 header. Some 822- MTS protocols, in particular SMTP, can provide additional functionality, but as these are neither mandatory in SMTP, nor available in other 822-MTS protocols, they are not considered here. Details of aspects specific to two 822-MTS protocols are given in Appendices B and C of RFC 1327. An RFC 822 message consists of a header, and content which is uninterpreted ASCII text. The header is divided into fields, which are the protocol elements. Most of these fields are analogous to P2 heading fields, although some are analogous to MTS Service Elements.
RFC822ヘッダーの中に2を)達成するのは可能です。 およそ822MTSプロトコル(特にSMTP)がこれらとして追加機能性を提供できますが、SMTPで義務的でなくて、また他の822-MTSプロトコルでは利用可能でない、それらはここで考えられません。 2つの822-MTSプロトコルに特定の局面の詳細はAppendices BとCのRFC1327で明らかにされます。 RFC822メッセージは非解釈されたASCIIテキストであるヘッダー、および内容から成ります。 ヘッダーは分野に分割されます。(分野はプロトコル要素です)。 これらの分野の大部分は、或るものがMTS Service Elementsに類似していますが、P2見出し分野に類似しています。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 10] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[10ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
1.4. What is RFC 1327 ?
1.4. RFC1327は何ですか?
There is a large community using STD 11, RFC 822 based protocols for mail services, who will wish to communicate with users of the InterPersonal Messaging Service (IPMS) provided by X.400 systems, and the other way around. This will also be a requirement in cases where RFC 822 communities intend to make a transition to use X.400 (or the other way around, which also happens), as conversion will be needed to ensure a smooth service transition.
STD11を使用する大きい共同体があって、RFC822はメールサービスのためのプロトコルを基礎づけて、だれがInterPersonalメッセージサービス(IPMS)のユーザとコミュニケートしたくなるかがX.400システム、および逆で提供しました。 また、これはRFC822共同体がX.400(また、逆に、どれが起こる)を使用するために変遷をするつもりであるケースの中で要件になるでしょう、変換が滑らかなサービス変遷を確実にするのに必要であるときに。
The basic function of a mail gateway can be described as follows: receive a mail from one mail world, translate it into the formats of the other mail world and send it out again using the routing rules and protocols of that other world.
以下の通りメール・ゲートウェイの基本機能について説明できます: 1つのメール世界から郵便を受け取ってください、そして、もう片方のメール世界の形式にそれを翻訳してください、そして、再びその他の世界のルーティング規則とプロトコルを使用することでそれを出してください。
Especially if a message crosses more than one gateway, it is important that all gateways have the same understanding of how things should be mapped. A simple example of what could go wrong otherwise is the following: A sends a message to B through a gateway and B's reply to A is being routed through another gateway.
特にメッセージが1門以上を越えるなら、すべてのゲートウェイにはものがどう写像されるべきであるかに関する同じ理解があるのは、重要です。 そうでなければ、何が支障をきたすことができたかに関する簡単な例は以下です: Aはゲートウェイを通してメッセージをBに送ります、そして、Aに関するビーズの回答はもう1門を通して発送されています。
If the two gateways don't use the same mappings, it can be expected that the From and To addresses in the original mail and in the answer don't match, which is, to say the least, very confusing for the end- users (consider what happens if automated processes communicate via mail). More serious things can happen to addresses if a message crosses more than one gateway on its way from the originator to the recipient. As a real-life example, consider receiving a message from:
2門が同じマッピングを使用しないなら、オリジナルのメールと答えにおけるFromとToアドレスが合っていないと予想できます(終わりのユーザには、非常に控えめに言っても紛らわしいです)(自動化された過程がメールで交信するなら何が起こるか考えてください)。 メッセージが創始者から受取人への途中に1門以上を越えるなら、より重大なことはアドレスに起こることができます。 現実の例として、以下からメッセージを受け取ると考えてください。
Mary Plork <MMP_+a_ARG_+lMary_Plork+r%MHS+d_A0CD8A2B01F54FDC-
A0CB9A2B03F53FDC%ARG_Incorporated@argmail.com>
_メアリPlork<MMP_+a_ARG_+lMary_Plork+r%MHS+d A0CD8A2B01F54FDC- A0CB9A2B03F53FDC%ARG_Incorporated@argmail.com 、gt。
This is not what you would call user-friendly addressing.... RFC 1327 describes a set of mappings that will enable a more transparent interworking between systems operating X.400 (both 84 and 88) and systems using RFC 822, or protocols derived from STD 11, RFC 822.
これはあなたがユーザフレンドリーなアドレシングと呼ぶものではありません… RFC1327はRFC822を使用することでX.400(84と両方88)とシステムを操作しながらシステムの間で、より透明な織り込むことを可能にする1セットのマッピング、またはSTD11(RFC822)から得られたプロトコルについて説明します。
RFC 1327 describes all mappings in term of X.400(88). It defines how these mappings should be applied to X.400(84) systems in its Appendix G.
RFC1327はX.400(88)の用語によるすべてのマッピングについて説明します。 それはこれらのマッピングがどうAppendix GのX.400(84)システムに適用されるべきであるかを定義します。
Some words about the history of RFC 1327: It started out in June 1986, when RFC 987 defined for X.400(84) what RFC 1327 defines for X.400(84 and 88). RFC 1026 specified a number of additions and corrections to RFC 987. In December 1989, RFC 1138, which had a very short lifetime, was the first one to deal with X.400(88). It was obsoleted by RFC 1148 in March 1990. Finally, in May 1992, RFC 1327 obsoleted all of its ancestors.
RFC1327の歴史に関するいくつかの単語: それは1986年6月に始めました。(その時、RFC987はX.400(84)のために、自分1327がX.400(84と88)のために定義することを定義しました)。 RFC1026は多くの追加と修正をRFC987に指定しました。 1989年12月に、RFC1138(非常に短い生涯を持っていました)はX.400(88)に対処する最初のものでした。 それは1990年3月にRFC1148によって時代遅れにされました。 最終的に、1992年5月に、RFC1327は先祖のすべてを時代遅れにしました。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 11] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[11ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
2. Service Elements
2. サービス要素
Both RFC 822 and X.400 messages consist of certain service elements (such as 'originator' and 'subject'). As long as a message stays within its own world, the behaviour of such service elements is well defined. An important goal for a gateway is to maintain the highest possible service level when a message crosses the boundary between the two mail worlds.
RFC822とX.400メッセージの両方が、あるサービス要素('創始者'や'対象'などの)から成ります。 メッセージがそれ自身の世界の範囲内にとどまる限り、そのようなサービス要素のふるまいはよく定義されます。 ゲートウェイの重要な目標はメッセージが2つのメール世界の間の境界に交差するとき、可能な限り高いサービスレベルを維持することです。
When a user originates a message, a number of services are available. RFC 1327 describes, for each service elements, to what extent it is supported for a recipient accessed through a gateway. There are three levels of support:
ユーザがメッセージを溯源するとき、多くのサービスが利用可能です。 RFC1327は各サービスのためにゲートウェイを通してアクセスされた受取人のためにそれがどんな範囲であるかに支えられた要素について説明します。 サポートの3つのレベルがあります:
- Supported: Some of the mappings are quite straight-forward,
such as '822.Subject:' <-> 'IPMS.Subject'.
- 支持される: マッピングのいくつかが'822.Subject:'<->'IPMS.Subject'などのようにかなり簡単です。
- Not supported: There may be a complete mismatch: certain
service elements exist only in one of the two worlds (e.g.,
interpersonal notifications).
- 支持されません: 完全なミスマッチがあるかもしれません: あるサービス要素は2つの世界(例えば、個人間の通知)の1つだけに存在しています。
- Partially supported: When similar service elements exist in
both worlds, but with slightly different interpretations,
some tricks may be needed to provide the service over the
gateway border.
- 部分的に支持されています: 同様のサービス要素が両方の世界に存在していますが、わずかに異なった解釈で存在するとき、いくつかのトリックが、ゲートウェイ境界をサービスオーバーに提供するのに必要であるかもしれません。
Apart from mapping between the service elements, a gateway must also map the types and values assigned to these service elements. Again, this may in certain cases be very simple, e.g., 'IA5 -> ASCII'. The most complicated example is mapping address spaces. The problem is that address spaces are not something static that can be defined within RFC 1327. Address spaces change continuously, and they are defined by certain addressing authorities, which are not always parallel in the RFC 822 and the X.400 world. A valid mapping between two addresses assumes however that there is 'administrative equivalence' between the two domains in which the addresses exist (see also [13]).
また、サービス要素の間のマッピングは別として、ゲートウェイはこれらのサービス要素に選任されたタイプと値を写像しなければなりません。 一方、ある場合には、これは例えば非常に簡単であるかもしれません。'IA5->ASCII'。 最も複雑な例はアドレス空間を写像しています。 問題はアドレス空間がRFC1327の中で定義できることでないこと静的なものということです。 アドレス空間は絶え間なく変化します、そして、それらは確信しているアドレシング当局によって定義されます。(その当局は、RFC822とX.400世界でいつも平行であるというわけではありません)。 しかしながら、2つのアドレスの間の有効なマッピングは、アドレスが存在する2つのドメインの間には、'管理等価性'があると仮定します。(また、[13])を見てください。
The following basic mappings are defined in RFC 1327. When going from RFC 822 to X.400, an RFC 822 message and the associated 822- MTS information is always mapped into an IPM (MTA, MTS, and IPMS Services). Going from X.400 to RFC 822, an RFC 822 message and the associated 822-MTS information may be derived from:
以下の基本のマッピングはRFC1327で定義されます。 RFC822からX.400まで行くとき、RFC822メッセージと関連822MTS情報はいつもIPM(MTA、MTS、およびIPMS Services)に写像されます。 RFC822、RFC822メッセージ、およびX.400から関連822-MTS情報まで行くのは以下から引き出されるかもしれません。
- A Report (MTA, and MTS Services)
- レポート(MTA、およびMTSサービス)
- An InterPersonal Notification (IPN) (MTA, MTS, and IPMS
services)
- 個人間の通知(IPN)(MTA、MTS、およびIPMSサービス)
RARE Working Group on Mail and Messaging (WG-MSG) [Page 12] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[12ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
- An InterPersonal Message (IPM) (MTA, MTS, and IPMS services)
- 個人間のメッセージ(IPM)(MTA、MTS、およびIPMSサービス)
Probes (MTA Service) have no equivalent in STD 10, RFC 821 or STD 11, RFC 822 and are thus handled by the gateway. The gateway's Probe confirmation should be interpreted as if the gateway were the final MTA to which the Probe was sent. Optionally, if the gateway uses RFC 821 as an 822-MTS, it may use the results of the 'VRFY' command to test whether it would be able to deliver (or forward) mail to the mailbox under probe.
探測装置(MTA Service)は、STD10、RFC821またはSTD11で同等物がない、RFC822を持って、ゲートウェイによってこのようにして扱われます。 ゲートウェイのProbe確認はまるでゲートウェイがProbeが送られた最終的なMTAであるかのように解釈されるべきです。 任意に、ゲートウェイが822-MTSとしてRFC821を使用するなら、それはそれが配送できて(前進)のメールであるだろうか否かに関係なく、テストする'VRFY'コマンドの結果を徹底的調査でメールボックスに使用するかもしれません。
MTS Messages containing Content Types other than those defined by the IPMS are not mapped by the gateway, and should be rejected at the gateway.
IPMSによって定義されたもの以外のContent Typesを含むMTS Messagesはゲートウェイによって写像されないで、ゲートウェイで拒絶されるべきです。
Some basic examples of mappings between service elements are listed below.
サービス要素の間のマッピングのいくつかの基本の例が以下にリストアップされています。
Service elements:
要素を調整してください:
RFC 822 X.400
------------------------------------------------
Reply-To: IPMS.Heading.reply-recipients
Subject: IPMS.Heading.subject
In-Reply-To: IPMS.Heading.replied-to-ipm
References: IPMS.Heading.related-IPMs
To: IPMS.Heading.primary-recipients
Cc: IPMS.Heading.copy-recipients
RFC822X.400------------------------------------------------ Reply-To IPMS.Heading.reply-受取人Subject: 以下に対してIPMS.Heading.subject IPMS.Heading.repliedからipmへの参照: IPMS.Heading.related-IPMs To: IPMS.Heading.primary-受取人Cc: IPMS.Heading.copy-recipients
Service element types:
要素型にサービスを提供してください:
RFC 822 X.400
------------------------------------------------
ASCII PrintableString
Boolean Boolean
RFC822X.400------------------------------------------------ ASCIIのPrintableStringのブール論理演算子
Service element values:
要素値を修理してください:
RFC 822 X.400
------------------------------------------------
oh_dear oh(u)dear
False 00000000
RFC822X.400------------------------------------------------ おお、_(u) おお、大事に、False00000000様
There are some mappings between service elements that are rather tricky and important enough to mention in this tutorial. These are the mappings of origination-related headers and some envelope fields:
このチュートリアルで言及できるくらいかなり精巧で重要なサービス要素の間には、いくつかのマッピングがあります。 これらは創作関連のヘッダーといくつかの封筒分野に関するマッピングです:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 13] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[13ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
RFC 822 -> X.400:
RFC822->X.400:
- If Sender: is present, Sender: is mapped to
IPMS.Heading.originator, and From: is mapped to
IPMS.Heading.authorizing-users. If not, From: is mapped to
IPMS.Heading.originator.
- 送付者であるなら: プレゼント、Senderです: IPMS.Heading.originator、およびFrom:に写像されます。 IPMS.Heading.authorizing-ユーザに写像されます。 そうでなければ、From: IPMS.Heading.originatorに写像されます。
X.400 -> RFC 822
X.400->RFC822
- If IPMS.Heading.authorizing-users is present,
IPMS.Heading.originator is mapped to Sender:, and
IPMS.Heading.authorizing-users is mapped to From: . If not,
IPMS.Heading.originator is mapped to From:.
- IPMS.Heading.authorizing-ユーザが出席しているなら、IPMS.Heading.originatorによるSenderに写像されて、: IPMS.Heading.authorizing-ユーザがFrom:に写像されるということです。 . そうでなければ、IPMS.Heading.originatorはFrom:に写像されます。
Envelope attributes
封筒属性
- RFC 1327 doesn't define how to map the MTS.OriginatorName and
the MTS.RecipientName (often referred to as the P1.originator
and P1.recipient), since this depends on which underlying 822-
MTS is used. In the very common case that RFC 821 (SMTP) is
used for this purpose, the mapping is normally as follows:
- RFC1327はMTS.OriginatorNameとMTS.RecipientName(しばしばP1.originatorとP1.recipientと呼ばれる)を写像する方法を定義しません、これがどの基本的な822MTSが使用されているかによるので。 非常に一般的な場合では、そのRFC821(SMTP)はこのために使用されて、通常、マッピングは以下の通りです:
MTS.Originator-name <-> MAIL FROM:
MTS.Recipient-name <-> RCPT TO:
MTS.Originator-名前<->メールFROM: MTS.Recipient-名前<->RCPT TO:
For more details, refer to RFC 1327, chapters 2.2 and 2.3.
その他の詳細について、第2.2章とRFC1327、第2.3章を参照してください。
3. Address mapping
3. アドレス・マッピング
As address mapping is often considered the most complicated part of mapping between service element values, this subject is given a separate chapter in this tutorial.
サービス要素値の間のマッピングの最も複雑な部分であるとアドレス・マッピングをしばしば考えるとき、このチュートリアルの別々の章にこの対象を与えます。
Both RFC 822 and X.400 have their own specific address formats. RFC 822 addresses are text strings (e.g., "plork@tlec.nl"), whereas X.400 addresses are binary encoded sets of attributes with values. Such binary addresses can be made readable for a human user by a number of notations; for instance:
RFC822とX.400の両方には、それら自身の特定のアドレス形式があります。 RFC822アドレスはテキスト文字列(例えば、" plork@tlec.nl ")ですが、X.400アドレスは値がある2進のコード化されたセットの属性です。 そのような2進のアドレスを人間のユーザにとって多くの記法で読み込み可能にすることができます。 例えば:
C=zz
ADMD=ade
PRMD=fhbo
O=a bank
S=plork
G=mary
Cはzz ADMD=ade PRMD=fhbo O=a銀行S=plork G=maryと等しいです。
The rest of this chapter deals with addressing issues and mappings between the two address forms in more detail.
本章の残りはさらに詳細に2つの呼びかけの形式の間の問題提示とマッピングに対処します。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 14] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[14ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
3.1. X.400 addresses
3.1. X.400アドレス
As already stated above, an X.400 address is modelled as a set of attributes. Some of these attributes are mandatory, others are optional. Each attribute has a type and a value, e.g., the Surname attribute has type IA5text, and an instance of this attribute could have the value 'Kille'. Attributes are divided into Standard Attributes (SAs) and Domain Defined Attributes (DDAs).
前述のとおり上では、X.400アドレスが1セットの属性としてモデル化されます。 これらの属性のいくつかが義務的である、他のものは任意です。 各属性に、タイプと値があります、そして、例えば、Surname属性にタイプIA5textがあります、そして、この属性の例には、値の'Kille'があるかもしれません。 属性はStandard Attributes(SAs)とDomain Defined Attributes(DDAs)に分割されます。
X.400 defines four basic forms of addresses ([17], 18.5), of which the 'Mnemonic O/R Address' is the form that is most used, and is the only form that is dealt with in this tutorial. This is roughly the same address format as what in the 84 version was known as 'O/R names: form 1, variant 1' ([16] 3.3.2).
X.400は4つの基本的なフォームのアドレスを定義します。([17]、18.5) '簡略記憶O/R Address'が最も使用されるフォームであり、このチュートリアルで対処している唯一のフォームである。 これはおよそ'O/Rは以下を命名する'とき何が84バージョンで知られていたかと同じアドレス形式です。 '1、異形1'([16]3.3.2を)形成してください。
3.1.1. Standard Attributes
3.1.1. 標準の属性
Standard Attributes (SAs) are attributes that all X.400 installations are supposed to 'understand' (i.e., use for routing), for example: 'country name', 'given name' or 'organizational unit'. The most commonly used SAs in X.400(84) are:
例えば、標準のAttributes(SAs)はすべてのX.400インストールが'理解するべきである'属性(すなわち、ルーティングの使用)です: '国の名'、'名'または'組織的なユニット'。 X.400(84)の最も一般的に使用されたSAsは以下の通りです。
surName (S)
givenName (G)
initials (I*) (Zero or more)
generationQualifier (GQ)
OrganizationalUnits (OU1 OU2 OU3 OU4)
OrganizationName (O)
PrivateDomainName (PRMD)
AdministrationDomainName (ADMD)
CountryName (C)
surName(S)givenName(G)はgenerationQualifier(GQ)OrganizationalUnits(OU1 OU2 OU3 OU4)OrganizationName(O)PrivateDomainName(PRMD)AdministrationDomainName(ADMD)CountryNameに頭文字をつけます(I*)(ゼロか以上)。(C)
The combination of S, G, I* and GQ is often referred to as the PersonalName (PN).
S、G、I*、およびGQの組み合わせはしばしばPersonalName(PN)と呼ばれます。
Although there is no hierarchy (of addressing authorities) defined by the standards, the following hierarchy is considered natural:
規格によって定義された階層構造(当局に演説するのについて)が全くありませんが、以下の階層構造は自然であると考えられます:
PersonalName < OU4 < OU3 < OU2 < OU1 < O < P < A < C
PersonalName<OU4<OU3<OU2<OU1<O<P<は<Cです。
In addition to the SAs listed above, X.400(88) defines some extra attributes, the most important of which is
上に記載されたSAsに加えて、どれがあるかについてX.400(88)はいくつかの余分な属性、最も重要であるのを定義します。
Common Name (CN)
俗称(CN)
CN can be used instead of or even together with PN. The problem in X.400(84) was that PN (S G I* GQ) was well suited to represent persons, but not roles and abstract objects, such as distribution
PNかPNがあってもCNを使用できます。 X.400(84)の問題はPN(S G I*GQ)が役割と抽象的な物ではなく、人々の代理をするためによく合ったということでした、分配などのように
RARE Working Group on Mail and Messaging (WG-MSG) [Page 15] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[15ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
lists. Even though postmaster clearly is a role, not someone's real surname, it is quite usual in X.400(84) to address a postmaster with S=postmaster. In X.400(88), the same postmaster would be addressed with CN=postmaster .
リスト。 郵便局長はだれかの本当の姓ではなく、明確に役割ですが、S=郵便局長と共に郵便局長について話すのはX.400(84)でかなり普通です。 X.400(88)では、同じ郵便局長はCN=郵便局長と共に宛てられるでしょう。
The attributes C and ADMD are mandatory (i.e., they must be present), and may not be empty. At least one of the attributes PRMD, O, OU, PN and CN must be present.
属性のCとADMDは義務的であり(すなわち、それらは存在していなければなりません)、空でないかもしれません。 少なくとも属性のPRMD、O、OU、PN、およびCNの1つは存在していなければなりません。
PRMD and ADMD are often felt to be routing attributes that don't really belong in addresses. As an example of how such address attributes can be used for the purpose of routing, consider two special values for ADMD:
PRMDとADMDはアドレスには本当にないルーティング属性であるとしばしば感じられます。 ルーティングの目的にどうそのようなアドレス属性を使用できるかに関する例と、ADMDのために2つの特別な値を考えてください:
- ADMD=0; (zero) should be interpreted as 'the PRMD in this
address is not connected to any ADMD'
- ADMD=0。 (ゼロ) 'このアドレスのPRMDはどんなADMDにも接続されない'とき、解釈されるべきです。
- ADMD= ; (single SPACE) should be interpreted as 'the PRMD in
this address is reachable via any ADMD in this country'. It
is expected that ISO will express this 'any' value by means
of a missing ADMD attribute in future versions of MOTIS.
This representation can uniquely identify the meaning 'any',
as a missing or empty ADMD field as such is not allowed.
- ADMD=。 (シングルスペース) 'このアドレスのPRMDはこの国のどんなADMDを通しても届く'ので、解釈されるべきです。 ISOがMOTISの将来のバージョンのなくなったADMD属性によって'いくらか'というこの値を言い表すと予想されます。 なくなったか人影のないADMD分野がそういうものとして許容されていないとき、この表現は唯一意味している'いずれも'を特定できます。
Addresses are defined in X.400 using the Abstract Syntax Notation One (ASN.1). X.409 defines how definitions in ASN.1 should be encoded into binary format. Note that the meaning, and thus the ASN.1 encoding, of a missing attribute is not the same as that of an empty attribute. In addressing, this difference is often represented as follows:
アドレスは、X.400で抽象的なSyntax Notation One(ASN.1)を使用することで定義されます。 X.409はASN.1との定義がどうバイナリフォーマットにコード化されるべきであるかを定義します。 意味、およびその結果、なくなった属性のASN.1コード化がある空の属性のものと同じくらいではなく、注意。 アドレシングで、この違いは以下の通りしばしば表されます:
- PRMD=; means that this attribute is present in the address,
but its value is empty. Since this is not very useful, it's
hardly ever used. The only examples the author knows of
were caused by mail managers who should have had this
tutorial before they started defining their addresses :-)
- PRMD=。 この属性がアドレスに存在していますが、値が空であることを意味します。 これがそれほど役に立たないので、それはほとんど決して使用されません。 作者が知っている唯一の例が彼らが自分達のアドレスを定義し始める前にこのチュートリアルを持つべきであったメールマネージャによって引き起こされました(^o^)
- PRMD=@; means that this attribute is not present in the
address. {NB. This is only necessary if an address notation
(see 3.1.3) requires that every single attribute in the
hierarchy is somehow listed. Otherwise, a missing attribute
can of course be represented by simply not mentioning it.
This means that this syntax is mostly used in mapping rules,
not by end users.}
- PRMDは@と等しいです。 この属性がアドレスに存在していないことを意味します。 {ネブラスカ。 これがアドレス記法である場合にだけ必要である、(見る、3.1、.3、)、階層構造のあらゆる属性がどうにか記載されているのが必要です。 さもなければ、もちろんそれについて絶対に言及しないことによって、なくなった属性を表すことができます。 これは、この構文がエンドユーザに使用されるのではなく、配置規則にほとんど使用されることを意味します。}
Addresses that only contain SAs are often referred to as Standard Attribute Addresses (SAAs).
SAsを含むだけであるアドレスがしばしばStandard Attribute Addresses(SAA)と呼ばれます。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 16] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[16ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
3.1.2. Domain Defined Attributes
3.1.2. ドメインの定義された属性
Domain Defined Attributes (DDAs) can be used in addition to Standard Attributes. An instance of a DDA consists of a type and a value. DDAs are meant to have a meaning only within a certain context (originally this was supposed to be the context of a certain management domain, hence the name DDA), such as a company context.
Standard Attributesに加えてドメインDefined Attributes(DDAs)を使用できます。 DDAの例はタイプと価値から成ります。 DDAsはある文脈だけの中に意味を持つことになっています(元々、これはしたがって、ある一定の管理ドメイン、名前DDAの文脈であるべきでした)、会社の文脈のように。
As an example, a company might want to define a DDA for describing internal telephone numbers: DDA type=phone value=9571.
例として、会社は内線電話番号について説明するためにDDAを定義したがっているかもしれません: DDAは=電話価値=9571をタイプします。
A bit tricky is the use of DDAs to encode service element types or values that are only available on one side of a service gateway. The most important examples of such usage are defined in:
少し扱いにくいのは、サービスゲートウェイの半面の上でサービス要素型か手があくだけである値をコード化するDDAsの使用です。 そのような用法の最も重要な例は以下で定義されます。
RFC 1327 (e.g., DDA type=RFC-822 value=u(u)ser(a)isode.com)
RFC1327(RFC-822例えば、DDAタイプ=値=u(u)ser(a)isode.com)
RFC 1328 (e.g., DDA type=CommonName value=mhs-discussion-list)
RFC1328(mhs-議論CommonName例えば、DDAタイプ=値=リスト)
Addresses that contain both SAs and DDAs are often referred to as DDA addresses.
SAsとDDAsの両方を含むアドレスがしばしばDDAアドレスと呼ばれます。
3.1.3. X.400 address notation
3.1.3. X.400アドレス記法
X.400 only prescribes the binary encoding of addresses, it doesn't standardise how such addresses should be written on paper or what they should look like in a user interface on a computer screen. There exist a number of recommendations for X.400 address representation though.
X.400はアドレスの2進のコード化を処方するだけであり、それはコンピュータ・スクリーンでそのようなアドレスがどう紙上で書かれているべきであるか、そして、それらがユーザーインタフェースで似るべきであることを標準化しません。 もっとも、X.400アドレス表現のための多くの推薦が存在しています。
- JTC proposed an annex to CCITT Rec. F.401 and ISO/IEC 10021-2,
called 'Representation of O/R addresses for human usage'. According
to this proposal, an X.400 address would look as follows:
- JTCはCCITT Recに別館を提案しました。 '人間の用法のためのO/Rアドレスの表現'と呼ばれるF.401とISO/IEC10021-2。 この提案によると、X.400アドレスは以下の通りに見えるでしょう:
G=jo; S=plork; O=a bank; OU1=owe; OU2=you; P=fhbo; A=ade; C=zz
Gは杖と等しいです。 S=plork。 O=aは銀行と取引します。 =が負っているOU1。 OU2はあなたと等しいです。 P=fhbo。 A=ade。 Cはzzと等しいです。
Note that in this format, the order of O and the OUs is exactly
the opposite of what one would expect intuitively (the attribute
hierarchy is increasing from left to right, except for the O and
OUs, where it's right to left. The reasoning behind this is that
this sequence is following the example of a postal address). This
proposal has been added (as a recommendation) to the 1992 version
of the standards.
この形式において、OとOUsの注文がまさにものが直観的に予想することの正反対であることに注意してください。(属性階層構造は左からOを除いた右とOUsから左に増えています。(そこでは、それが正しいです)。 これの後ろの推理はこの系列が郵便の宛先に関する例に倣っているということです。). 1992年の規格のバージョンにこの提案を追加してあります(推薦として)。
- Following what was originally used in the DFN-EAN software, most
EAN versions today use an address representation similar to the JTC
proposal, with a few differences:
- 元々DFN-EANソフトウェアで使用されたことに続いて、ほとんどのEANバージョンが今日JTC提案と同様のアドレス表現を使用します、いくつかの違いで:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 17] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[17ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
- natural ordering for O and OUs
- no numbering of OUs.
- allows writing ADMD and PRMD instead of A and P
- OとOUsのための自然な注文--OUsの付番しないこと。 - AとPの代わりにADMDとPRMDに書くのを許容します。
The address in the example above could, in EAN, be represented as:
EANでは、以下として上記の例のアドレスを表すことができました。
G=jo; S=plork; OU=you; OU=owe; O=a bank; PRMD=fhbo; ADMD=ade; C=zz
Gは杖と等しいです。 S=plork。 OUはあなたと等しいです。 =が負っているOU。 O=aは銀行と取引します。 PRMD=fhbo。 ADMD=ade。 Cはzzと等しいです。
This DFN-EAN format is still often referred to as _the_ 'readable
format'.
このDFN-EAN書式はまだ__'読み込み可能な形式'としばしば呼ばれています。
- The RARE Working Group on Mail and Messaging, WG-MSG, has made a
recommendation that is very similar to the DFN-EAN format, but with
the hierarchy reversed. Further, ADMD and PRMD are used instead of
A and P. This results in the address above being represented as:
- メールとMessagingの上のRARE作業部会(WG-MSG)はDFN-EAN形式と非常に同様ですが、階層構造が逆にされている状態で同様である推薦状をしました。 さらに、ADMDとPRMDはAとP.This結果の代わりに以下として表される上でアドレスで使用されます。
C=zz; ADMD=ade; PRMD=fhbo; O=a bank; OU=owe; OU=you; S=plork; G=jo
Cはzzと等しいです。 ADMD=ade。 PRMD=fhbo。 O=aは銀行と取引します。 =が負っているOU。 OUはあなたと等しいです。 S=plork。 Gは杖と等しいです。
This format is recognised by most versions of the EAN software. In
the R&D community, this is one of the most popular address
representations for business cards, letter heads, etc. It is also
the format that will be used for the examples in this tutorial.
(NB. The syntax used here for describing DDAs is as follows:
DD.'type'='value', e.g., DD.phone=9571)
この形式はEANソフトウェアのほとんどのバージョンによって認識されます。 研究開発共同体では、これは名刺、レターヘッドなどの最もポピュラーなアドレス表現の1つです。 また、それはこのチュートリアルの例に使用される形式です。 (ネブラスカ。 DDAsについて説明するのにここで使用された構文は以下の通りです: DD'タイプ'は'値'、例えば、DD.phone=9571と等しいです。)
- RFC 1327 defines a slash separated address representation:
- RFC1327はスラッシュの切り離されたアドレス表現を定義します:
/G=jo/S=plork/OU=you/OU=owe/O=a bank/P=fhbo/A=ade/C=zz/
/Gが杖/S=plork/OU=あなたと等しい、/OU=は/O=a銀行/P=fhbo/A=ade/C=zz/に負っています。
Not only is this format used by the PP software, it is also
widespread for business cards and letter heads in the R&D
community.
名刺とレターヘッドにとって、また、この形式がPPソフトウェアによって使用されるだけではなく、それも研究開発共同体で広範囲です。
- RFC 1327 finally defines yet another format for X.400 _domains_
(not for human users):
- RFC1327はX.400_ドメイン_(人間のユーザでない)のために最終的にさらに別の書式を定義します:
OU$you.OU$owe.O$a bank.P$fhbo.A$ade.C$zz
OU$you.OU$owe.O$a bank.P$fhbo.A$ade.C$zz
The main advantage of this format is that it is better machine-
parseble than the others, which also immediately implies its main
disadvantage: it is barely readable for humans. Every attribute
within the hierarchy should be listed, thus a missing attribute
must be represented by the '@' sign
(e.g., $a bank.P$@.A$ade.C$zz).
この形式の主な利点はそれが他のものより良いマシンparsebleであるということです(また、すぐに、主な不都合を含意します): 人間には、それはほとんど読み込み可能ではありません。 階層構造の中のあらゆる属性が記載されているべきです、その結果、'@'サイン(例えば、$a bank.P$@.A$ade.C$zz )でなくなった属性を表さなければなりません。
- Paul-Andre Pays (INRIA) has proposed a format that combines the
readability of the JTC format with the parsebility of the RFC 1327
domain format. Although a number of operational tools within the GO-
- ポール-アンドレPays(INRIA)は1327年のRFCドメイン形式のparsebilityにJTC形式の読み易さを結合する形式を提案しました。 操作上の数はGOの中でツーリングされますが
RARE Working Group on Mail and Messaging (WG-MSG) [Page 18] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[18ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
MHS community are already based on (variants of) this proposal, its
future is still uncertain.
MHS共同体が既に基づいている、(異形、)、この提案であり、未来はまだ不確実です。
3.2. RFC 822 addresses
3.2. RFC822アドレス
An RFC 822 address is an ASCII string of the following form:
RFC822アドレスは以下の形式のASCIIストリングです:
localpart@domainpart
localpart@domainpart
"domainpart" is sub-divided into
"domainpart"に細分されます。
domainpart = sdom(n).sdom(n-1)....sdom(2).sdom(1).dom
domainpartはsdom(n).sdom(n-1)と等しいです…sdom(2).sdom(1).dom
"sdom" stands for "subdomain", "dom" stands for "top-level-domain".
"sdom"は「サブドメイン」を表して、"dom"は「トップ・レベル・ドメイン」を表します。
"localpart" ;is normally a login name, and thus typically is a
surname or an abbreviation for this. It can also designate a local
distribution list.
"localpart";、その結果、通常、通常ログイン名であり、姓かこれのための略語です。 また、それは局所分布リストを指定できます。
The hierarchy (of addressing authorities) in an RFC 822 address is
as follows:
RFC822アドレスの階層構造(当局に演説するのについて)は以下の通りです:
localpart < sdom(n) < sdom(n-1) <...< dom
localpart<sdom(n)<sdom(n-1)<…<dom
Some virtual real-life examples:
いくつかの仮想の現実の例:
joemp@tlec.nl
tsjaka.kahn@walhalla.diku.dk
a13_vk@cs.rochester.edu
joemp@tlec.nl tsjaka.kahn@walhalla.diku.dk a13_vk@cs.rochester.edu
In the above examples, 'nl', 'dk', and 'edu' are valid,
registered, top level domains. Note that some networks that have
their own addressing schemes are also reachable by way of 'RFC
822-like' addressing. Consider the following addresses:
上記の例では、'nl'、'dk'、および'edu'は有効で、登録されたトップ・レベル・ドメインです。 また、それら自身のに計画を記述させるいくつかのネットワークも'RFCの822のような'アドレシングを通して届いていることに注意してください。 以下のアドレスを考えてください:
oops!user (a UUCP address)
V13ENZACC@CZKETH5A (a BITNET address)
おっと、ユーザ(UUCPアドレス) V13ENZACC@CZKETH5A (Bitnetアドレス)
These addresses can be expressed in RFC 822 format:
RFC822形式でこれらのアドレスを表すことができます:
user@oops.uucp
V13ENZACC@CZKETH5A.BITNET
user@oops.uucp V13ENZACC@CZKETH5A.Bitnet
Note that the domains '.uucp' and '.bitnet' have no registered Internet routing. Such addresses must always be routed to a gateway (how this is done is outside the scope of this tutorial).
ドメインの'.uucp'と'.bitnet'には登録されたインターネット・ルーティングが全くないことに注意してください。 いつもそのようなアドレスをゲートウェイに発送しなければなりません(このチュートリアルの範囲の外にこれがどう完了しているかがあります)。
As for mapping such addresses to X.400, there is no direct mapping
そのようなアドレスをX.400に写像することに関して、どんなダイレクトマッピングもありません。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 19] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[19ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
defined between X.400 on the one hand and UUCP and BITNET on the other, so they are normally mapped to RFC 822 style first, and then to X.400 if needed.
そして、一方では、間にX.400を定義する、通常、それらが最初にRFC822スタイルに写像されて、そして、X.400に他にもかかわらず、必要のUUCPとBitnet。
3.3. RFC 1327 address mapping
3.3. RFC1327アドレス・マッピング
Despite the difference in address formats, the address spaces defined by RFC 822 and X.400 are quite similar. The most important parallels are:
アドレス形式の違いにもかかわらず、RFC822とX.400によって定義されたアドレス空間は全く同様です。 最も重要な類似は以下の通りです。
- both address spaces are hierarchical
- top level domains and country codes are often the same
- localparts and surnames are often the same
- 両方のアドレス空間は階層的です--トップ・レベル・ドメインと国名略号はしばしば同じです--localpartsと姓はしばしば同じです。
This similarity can of course be exploited in address mapping algorithms. This is also done in RFC 1327 (NB only in the exception mapping algorithm. See chapter 3.3.2).
もちろんアドレス・マッピングアルゴリズムでこの類似性を利用できます。また、RFC1327でこれをします。(単に例外マッピングアルゴリズムによるネブラスカ。 第3.3章.2を見てください。).
Note that the actual mapping algorithm is much more complicated than shown below. For details, see RFC 1327, chapter 4.
実際のマッピングアルゴリズムが以下に示されるよりはるかに複雑にされることに注意してください。 詳細に関しては、RFC1327、第4章を見てください。
3.3.1. Default mapping
3.3.1. デフォルトマッピング
The default RFC 1327 address mapping can be visualised as a function with input and output parameters:
入出力パラメタがある機能としてデフォルトRFC1327アドレス・マッピングを想像できます:
address information of the gateway performing the mapping
|
v
+-----------------+
RFC 822 address <--->| address mapping | <---> X.400 address
+-----------------+
マッピングを実行するゲートウェイに関するアドレス情報| +に対して-----------------+ RFC822アドレス<。--->| アドレス・マッピング| <-->X.400アドレス+-----------------+
I.e., to map an address from X.400 to RFC 822 or vice versa, the only extra input needed is the address information of the local gateway.
すなわち、逆もまた同様です、RFC822かX.400から余分な唯一の入力までアドレスを写像するために、必要であるのは、地方のゲートウェイに関するアドレス情報です。
3.3.1.1. X.400 -> RFC 822
3.3.1.1. X.400->RFC822
There are two kinds of default address mapping from X.400 to RFC 822: one to map a real X.400 address to RFC 822, and another to decode an RFC 822 address that was mapped to X.400 (i.e., to reverse the default RFC 822 -> X.400 mapping).
X.400からRFC822まで2種類のデフォルトアドレス・マッピングがあります: 本当のX.400アドレスをRFC822に写像して、写像されたRFC822アドレスを解読する別のものをX.400に写像する1(すなわち、デフォルトRFC822->X.400マッピングを逆にする)。
To map a real X.400 address to RFC 822, the slash separated notation of the X.400 address (see chapter 3.1.) is mapped to 'localpart', and the local RFC 822 domain of the gateway that performs the mapping is used as the domain part. As an example, the gateway 'gw.switch.ch' would perform the following mappings:
本当のX.400アドレスをRFC822、スラッシュに写像するために、X.400アドレス(第3.1章を見る)の切り離された記法は'localpart'に写像されます、そして、マッピングを実行するゲートウェイの地方のRFC822ドメインはドメイン部分として使用されます。 例として、ゲートウェイ'gw.switch.ch'は以下のマッピングを実行するでしょう:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 20] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[20ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; ->
/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch
Cはzzと等しいです。 ADMD=ade。 PRMD=fhbo。 O=tlec。 S=plork。 ->/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/Sは plork/@gw.switch.ch と等しいです。
C=zz; ADMD=ade; PRMD=fhbo; O=a bank; S=plork->
"/C=zz/ADMD=ade/PRMD=fhbo/O=a bank/S=plork/"@gw.switch.ch
Cはzzと等しいです。 ADMD=ade。 PRMD=fhbo。 O=aは銀行と取引します。 「S=plork->」/Cがzz/ADMD=ade/PRMD=fhbo/O=a bank/S=plork/と等しい、」 @gw.switch.ch
The quotes in the second example are mandatory if the X.400 address contains spaces, otherwise the syntax rules for the RFC 822 localpart would be violated.
X.400アドレスが空間を含んでいるなら2番目の例の引用文が義務的である、さもなければ、RFC822localpartのためのシンタックス・ルールは違反されるでしょう。
This default mapping algorithm is generally referred to as 'left- hand-side encoding'.
一般に、このデフォルトマッピングアルゴリズムは'左の手サイドコード化'と呼ばれます。
To reverse the default RFC 822 -> X.400 mapping (see chapter 3.3.1.2): if the X.400 address contains a DDA of the type RFC-822, the SAs can be discarded, and the value of this DDA is the desired RFC 822 address (NB. Some characters in the DDA value must be decoded first. See chapter 3.3.1.2.). For example, the gateway
デフォルトRFC822->X.400マッピングを逆にする、(第3.3章.1を見てください、.2): X.400アドレスがタイプRFC-822のDDAを含んでいて、SAsを捨てることができて、このDDAの値が必要なRFC822アドレスであるなら(ネブラスカ。 DDA値におけるキャラクタの中には最初に解読する人もいなければなりません。 .2に第3.3章.1を見てください。). 例えば、ゲートウェイ
DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
->
bush@dole.us
DD.RFC-822=bush(a)dole.us。 Cはnlと等しいです。 ADMD=tlec。 PRMD=GW-> bush@dole.us
3.3.1.2. RFC 822 -> X.400
3.3.1.2. RFC822->X.400
There are also two kinds of default address mapping from RFC 822 to X.400: one to map a real RFC 822 address to X.400, and another to decode an X.400 address that was mapped to RFC 822 (i.e., to reverse the default X.400 -> RFC 822 mapping).
また、RFC822からX.400まで2種類のデフォルトアドレス・マッピングがあります: 本当のRFC822アドレスをX.400に写像する1、およびRFC822に写像されたX.400アドレスを解読する別(すなわち、デフォルトX.400->RFC822マッピングを逆にする)。
To map a real RFC 822 address to X.400, the RFC 822 address is encoded in a DDA of type RFC-822 , and the SAs of the local gateway performing the mapping are added to form the complete X.400 address. This mapping is generally referred to as 'DDA mapping'. As an example, the gateway 'C=nl; ADMD=tlec; PRMD=GW' would perform the following mapping:
本当のRFC822アドレスをX.400に写像するために、RFC822アドレスはタイプRFC-822のDDAでコード化されます、そして、マッピングを実行する地方のゲートウェイのSAsは完全なX.400アドレスを形成するために加えられます。 一般に、このマッピングは'DDAマッピング'と呼ばれます。 例、ゲートウェイ'C=nl'として。 ADMD=tlec。 'PRMD=GW'は以下のマッピングを実行するでしょう:
bush@dole.us ->
DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
bush@dole.us --、gt;、DD.RFC-822=bush(a)dole.us。 Cはnlと等しいです。 ADMD=tlec。 PRMD=GW
As for the encoding/decoding of RFC 822 addresses in DDAs, it is noted that RFC 822 addresses may contain characters (@ ! % etc.) that cannot directly be represented in a DDA. DDAs are of the restricted character set type 'PrintableString', which is a subset of IA5 (=ASCII). Characters not in this set need a special encoding. Some examples (For details, refer to RFC 1327, chapter 3.4.):
DDAsでのRFC822アドレスのコード化/解読に関して、RFC822アドレスがDDAで直接代理をされることができないキャラクタ(@!%など)を含むかもしれないことに注意されます。 DDAsはタイプ'PrintableString'という制限された文字の組のものです。(それは、IA5(ASCIIと等しい)の部分集合です)。 キャラクターはこのセットで特別なコード化を必要としません。 いくつかの例(詳細について、RFC1327、第3.4章を参照してください):
RARE Working Group on Mail and Messaging (WG-MSG) [Page 21] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[21ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
100%name@address -> DD.RFC-822;=100(p)name(a)address
u_ser!name@address -> DD.RFC-822;=u(u)ser(b)name(a)address
100%name@address --、gt;、DD.RFC-822(=100(p)name(a)address u_ser!name@address )、gt;、DD.RFC-822; u(u)ser(b)name(a)addressと等しいです。
To decode an X.400 address that was mapped to RFC 822: if the RFC 822 address has a slash separated representation of a complete X.400 mnemonic O/R address in its localpart, that address is the result of the mapping. As an example, the gateway 'gw.switch.ch' would perform the following mapping:
X.400アドレスを解読するために、それはRFC822に写像されました: RFC822アドレスがそうしたなら、スラッシュはlocalpartの完全なX.400簡略記憶O/Rアドレスの表現を切り離して、そのアドレスはマッピングの結果です。 例として、ゲートウェイ'gw.switch.ch'は以下のマッピングを実行するでしょう:
/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/G=mary/@gw.switch.ch
->
C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; G=mary
/Cはzz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/G= mary/@gw.switch.ch と等しいです--、gt;、Cはzzと等しいです。 ADMD=ade。 PRMD=fhbo。 O=tlec。 S=plork。 G=mary
3.3.2. Exception mapping according to mapping tables
3.3.2. マッピングによると、テーブルを写像する例外
Chapter 3.3.1. showed that it is theoretically possible to use RFC 1327 with default mapping only. Although this provides a very simple, straightforward way to map addresses, there are some very good reasons not to use RFC 1327 this way:
第3.3章 .1 デフォルトマッピングだけがあるRFC1327を使用するのが理論的に可能であることを示しました。 これはアドレスを写像する非常に簡単で、簡単な方法を提供しますが、RFC1327を使用しないいくつかの非常に十分な理由がこのようにあります:
- RFC 822 users are used to writing simple addresses of the
form 'localpart@domainpart'. They often consider X.400
addresses, and thus also the left-hand-side encoded
equivalents, as unnecessarily long and complicated. They
would rather be able to address an X.400 user as if she had a
'normal' RFC 822 address. For example, take the mapping
- RFC822ユーザはフォーム' localpart@domainpart 'の簡単なアドレスを書くのに慣れています。 彼らはしばしばX.400アドレスを考えます、そして、その結果、また、左側は不必要に長く複雑であるとして同等物をコード化しました。 まるで彼女には'正常な'RFC822アドレスがあるかのように彼らはX.400ユーザに演説できる方がましです。 例えば、マッピングを取ってください。
C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; ->
/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch
Cはzzと等しいです。 ADMD=ade。 PRMD=fhbo。 O=tlec。 S=plork。 ->/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/Sは plork/@gw.switch.ch と等しいです。
from chapter 3.3.1.1. RFC 822 users would find it much more
'natural' if this address could be expressed in RFC 822 as:
第3.3章 .1 .1。 RFC、以下としてRFC822にこのアドレスを表すことができるなら、822人のユーザが、それがはるかに'自然であること'がわかるでしょうに。
plork@tlec.fhbo.ade.nl
plork@tlec.fhbo.ade.nl
- X.400 users are used to using X.400 addresses with SAs only.
They often consider DDA addresses as complicated, especially
if they have to encode the special characters, @ % ! etc,
manually. They would rather be able to address an RFC 822
user as if he had a 'normal' X.400 address. For example, take
the mapping
- X.400ユーザはSAsだけとのX.400アドレスを使用するのに慣れています。 彼らは、手動で@ %!などを特に特殊文字をコード化しなければならないなら複雑にするので、しばしばDDAアドレスを考えます。 まるで彼には'正常な'X.400アドレスがあるかのように彼らはRFC822ユーザに演説できる方がましです。 例えば、マッピングを取ってください。
bush@dole.us
->
DD.RFC-822=bush(a)dole.us;
C=nl; ADMD= ; PRMD=tlec; O=gateway
bush@dole.us --、gt;、DD.RFC-822=bush(a)dole.us。 Cはnlと等しいです。 ADMD=。 PRMD=tlec。 Oはゲートウェイと等しいです。
from chapter 3.3.1.2. X.400 users would find it much more
第3.3章 .1 .2。 X.400ユーザはそれを非常にさらに見つけるでしょう。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 22] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[22ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
'natural' if this address could be expressed in X.400 as:
'自然'アドレスがこれであるならX.400に表されるかもしれないのを:
C=us; ADMD=dole; S=bush
Cは私たちと等しいです。 ADMDは分配物と等しいです。 S=低木
- Many organisations are using both RFC 822 and X.400
internally, and still want all their users to have a simple,
unique address in both mail worlds. Note that in the default
mapping, the mapped form of an address completely depends on
which gateway performed the mapping. This also results in a
complication of a more technical nature:
- 多くの機構が、内部的にRFC822とX.400の両方を使用していて、まだ彼らのすべてのユーザが両方のメール世界に簡単で、ユニークなアドレスを持つ必要があります。 デフォルトマッピングでは、アドレスの写像しているフォームをどのゲートウェイがマッピングを実行したかに完全に依存することに注意してください。 また、これは、より技術的な自然の複雑さをもたらします:
- The tricky 'third party problem'. This problem need not
necessarily be understood to read the rest of this chapter.
If it looks too complicated, please feel free to skip it
until you are more familiar with the basics.
- 油断のならない'第三者問題'。 この問題が本章の残りを読むのが必ず理解されなければならないというわけではありません。 複雑に見え過ぎるなら、遠慮なく基礎によりなじみ深くなるまでそれをスキップしてください。
The third party problem is a routing problem caused by
mapping. As an example for DDA mappings (the example holds
just as well for left-hand-side encoding), consider the
following situation (see Fig. 3.1.): RFC 822 user X in
country A sends a message to two recipients: RFC 822 user Y,
and X.400 user Z, both in country B:
第三者問題はマッピングによって引き起こされたルーティング問題です。 DDAマッピング(また、ちょうど例は左側コード化を保持する)のための例と、以下の状況を考えてください(図3.1を参照してください): 国AのRFC822ユーザXは2人の受取人にメッセージを送ります: RFC822ユーザY、およびともに国BのX.400ユーザZ:
From: X@A
To: Y@B ,
/C=B/.../S=Z/@GW.A
From: X@A To: Y@B 、/CはB/と等しいです…/Sは Z/@GW.A と等しいです。
Since the gateway in country A maps all addresses in the
message, Z will see both X's and Y's address as DDA-encoded
RFC 822 addresses, with the SAs of the gateway in country A:
国Aのゲートウェイがメッセージのすべてのアドレスを写像するので、Zは、XとYの両方がDDAによってコード化されたRFCとして822のアドレスを記述するのを見るでしょう、国A:のゲートウェイのSAsと共に
From: DD.RFC-822=X(a)A; C=A;....;O=GW
To: DD.RFC-822=Y(a)B; C=A;....;O=GW ,
C=B;...;S=Z
From: DD.RFC-822=X(a)A。 CはAと等しいです。; O=GW To: DD.RFC-822=Y(a)B。 CはAと等しいです。; O=GW、CはBと等しいです。; S=Z
RARE Working Group on Mail and Messaging (WG-MSG) [Page 23] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[23ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
| ------------ ---------
| |X: RFC 822|<------->|gateway|
| ------------ ---------
| A | ^
\ | |
\---------------------------------------------
| |
/---------------------------------------------
/ | |
| B | v
| | -----------
| | |Z: X.400 |
| | -----------
| | .
| | .
| | .
| | .
| | .
| v v
| ------------ ---------
| |Y: RFC 822|<........|gateway|
| ------------ ---------
| ------------ --------- | |X: RFC822| <、-、-、-、-、-、--、>|ゲートウェイ| | ------------ --------- | A| ^ \ | | \--------------------------------------------- | | /--------------------------------------------- / | | | B| v| | ----------- | | |Z: X.400| | | ----------- | | . | | . | | . | | . | | . | vに対して| ------------ --------- | |Y: RFC822|<…|ゲートウェイ| | ------------ ---------
Fig. 3.1 The third party problem
図3.1 第三者問題
Now if Z wants to 'group reply' to both X and Y, his reply to Y
will be routed over the gateway in country A, even though Y is
located in the same country:
現在、ZがXとYの両方に'回答を分類したい'なら、Yに関する彼の回答は国Aでゲートウェイの上に発送されるでしょう、Yが同じ国に位置していますが:
From: C=B;...;S=Z
To: DD.RFC-822=Y(a)B; C=A;....;O=GW ,
DD.RFC-822=X(a)A; C=A;....;O=GW
From: CはBと等しいです。; S=Z To: DD.RFC-822=Y(a)B。 CはAと等しいです。; O=GW、DD.RFC-822=X(a)A。 CはAと等しいです。; O=GW
The best way to travel for a message from Z to Y would of
course have been over the gateway in country B:
メッセージのためにZからYまで旅行する最も良い方法がもちろん国Bにゲートウェイの上にあったでしょう:
From: C=B;...;S=Z
To: DD.RFC-822=Y(a)B; C=B;....;O=GW ,
DD.RFC-822=X(a)A; C=A;....;O=GW
From: CはBと等しいです。; S=Z To: DD.RFC-822=Y(a)B。 CはBと等しいです。; O=GW、DD.RFC-822=X(a)A。 CはAと等しいです。; O=GW
The third party problem is caused by the fact that routing
information is mapped into addresses.
ルーティング情報がアドレスに写像されるという事実によって第三者問題は引き起こされます。
Ideally, the third party problem shouldn't exist. After all,
address mapping affects addresses, and an address is not a
route.... The reality is different however. For instance, very
理想的に、第三者問題は存在するべきではありません。 結局、アドレス・マッピングはアドレスに影響します、そして、アドレスはルートではありません… しかしながら、現実が異なっている、例えば、まさしくその
RARE Working Group on Mail and Messaging (WG-MSG) [Page 24] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[24ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
few X.400 products are capable to route messages on the
contents of a DDA (actually, only RFC 1327 gateways will be
able to interpret this type of DDA, and who says that the reply
will pass a local gateway on its route back?). Similar
limitations hold for the other direction: an RFC 822 based
mailer is not even allowed (see [5]) to make routing decisions
of the content of a left-hand-side encoded X.400 address if the
domain part is not its own. So in practice, addressing and
(thus also mapping) will very well affect routing.
わずかなX.400製品しかDDA(実際に、RFC1327ゲートウェイだけがDDAのこのタイプを解釈できて、だれが、回答がルートの上の地方のゲートウェイを戻すと言いますか?)のコンテンツに関するメッセージを発送できません。 同様の制限はもう片方の指示に当てはまります: RFC822に基づいている郵送者は許容されてさえいません。(ドメイン部分がそれ自身でないなら[5])を見て、左側の内容の決定がコード化したルーティングをX.400アドレスにしてください。 それで、実際には、アドレシングと(その結果、マッピングも)はルーティングに非常によく影響するでしょう。
To make mapping between addresses more user friendly, and to avoid the problems shown above, RFC 1327 allows for overruling the default left-hand-side encoding and DDA mapping algorithms. This is done by specifying associations (mapping rules) between certain domainparts and X.400 domains. An X.400 domain (for our purposes; CCITT has a narrower definition...) consists of the domain-related SAs of a Mnemonic O/R address (i.e., all SAs except PN and CN). The idea is to use the similarities between both address spaces, and directly map similar address parts onto each other. If, for the domain in the address to be mapped, an explicit mapping rule can be found, the mapping is performed between:
アドレスの間で以上を写像するのをユーザフレンドリーにして、上に示された問題を避けるために、RFC1327は、アルゴリズムを写像するデフォルト左側のコード化とDDAを却下すると考慮します。これは、あるdomainpartsとX.400ドメインとの協会(配置規則)を指定することによって、終わっています。 X.400ドメイン(私たちの目的のために; CCITTには、より狭い定義が…ある)はMnemonic O/Rアドレス(PNとCN以外のすなわちすべてのSAs)のドメイン関連のSAsから成ります。 考えは、両方のアドレス空間の間で類似性を使用して、直接同様のアドレス部を互いに写像することです。 住所のドメインが写像されるために明白な配置規則を見つけることができるなら、マッピングは以下の間で実行されます。
localpart <-> PersonalName
domainpart <-> X.400 domain
localpart<->PersonalName domainpart<->X.400ドメイン
The address information of the gateway is only used as an input parameter if no mapping rule can be found, i.e., if the address mapping must fall back to its default algorithm.
配置規則を全く見つけることができない場合にだけ、ゲートウェイに関するアドレス情報は入力パラメタとして使用されます、すなわち、アドレス・マッピングがデフォルトアルゴリズムへ後ろへ下がらなければならないなら。
The complete mapping function can thus be visualised as follows:
その結果、以下の通り完全なマッピング機能を想像できます:
address information of the gateway performing the mapping
|
v
+-----------------+
RFC 822 address <--->| address mapping | <---> X.400 address
+-----------------+
^
|
domain associations (mapping rules)
マッピングを実行するゲートウェイに関するアドレス情報| +に対して-----------------+ RFC822アドレス<。--->| アドレス・マッピング| <-->X.400アドレス+-----------------+ ^ | ドメイン協会(配置規則)
3.3.2.1. PersonalName and localpart mapping
3.3.2.1. PersonalNameとlocalpartマッピング
Since the mapping between these address parts is independent of the mapping rules that are used, and because it follows a simple, two- way algorithmic approach, this subject is discussed in a separate sub-chapter first.
これらのアドレス部の間のマッピングが使用された配置規則から独立していて、それが簡単で、2道のアルゴリズムのアプローチに続くので、最初に、別々のサブチャプターでこの問題について議論します。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 25] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[25ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
The X.400 PersonalName consists of givenName, initials, and surName. RFC 1327 assumes that generationQualifier is not used.
X.400 PersonalNameはgivenName、イニシャル、およびsurNameから成ります。 RFC1327は、generationQualifierが使用されていないと仮定します。
To map a localpart to an X.400 PN, the localpart is scanned for dots, which are considered delimiters between the components of PN, and also between single initials. In order not to put too much detail in this tutorial, only a few examples are shown here. For the detailed algorithm, see RFC 1327, chapter 4.2.1.
localpartをX.400 PNに写像するために、localpartはドットのためにスキャンされます。(ドットはPNの部品と、そして、ただ一つのイニシャルの間でもデリミタであると考えられます)。 あまりに多くの詳細をこのチュートリアルに入れない命令では、ほんのいくつかの例がここに示されます。 詳細なアルゴリズムに関しては、RFC1327、第4.2章.1を見てください。
Marshall.Rose <-> G=Marshall;S=Rose
M.T.Rose <-> I=MT;S=Rose
Marshall.M.T.Rose <-> G=Marshall;I=MT;S=Rose
Marshall.Rose<->Gはマーシャルと等しいです; バラM.T.バラ<->S=IはMTと等しいです; バラMarshall.M.T.バラ<->S=Gはマーシャルと等しいです; 私はMTと等しいです; S=は上昇しました。
To map an X.400 PN to an RFC 822 localpart, take the non-empty PN attributes, put them into their hierarchical order (G I* S), and connect them with periods.
RFC822localpartにX.400 PNを写像するために、非空のPN属性を取ってください、そして、彼らの階層的順序(G I*S)にそれらを入れてください、そして、それらを期間に接続してください。
Some exceptions are caused by the fact that left-hand-side encoding can also be mixed with exception mapping. This is shown in more detail in the following sub-chapters.
また、左側コード化を例外マッピングに混ぜることができるという事実によっていくつかの例外が引き起こされます。 これはさらに詳細に以下のサブチャプターで示されます。
3.3.2.2. X.400 domain and domainpart mapping
3.3.2.2. X.400ドメインとdomainpartマッピング
A mapping rule associates two domains: an X.400 domain and an RFC 822 domain. The X.400 domain is written in the RFC 1327 domain notation (See 3.1.3.), so that both domains have the same hierarchical order. The domains are written on one line, separated by a '#' sign. For instance:
配置規則は2つのドメインを関連づけます: X.400ドメインとRFC822ドメイン。 X.400ドメインがRFC1327ドメイン記法で書かれている、(見る、3.1、.3、)、両方のドメインには同じ階層的順序があるように。 ドメインは'#'サインによって切り離された1つの線に書かれています。 例えば:
arcom.ch#ADMD$arcom.C$ch#
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
arcom.ch#ADMD$arcom.C$ch#PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
A mapping rule must at least contain a top level domain and a country code. If an address must be mapped, a mapping rule with the longest domain match is sought. The associated domain in the mapping rule is used as the domain of the mapped address. The remaining domains are mapped one by one following the natural hierarchy. Concrete examples are shown in the following subchapters.
配置規則はトップ・レベル・ドメインと国名略号を少なくとも含まなければなりません。 アドレスを写像しなければならないなら、最も長いドメインマッチがある配置規則は求められます。 配置規則の関連ドメインは写像しているアドレスのドメインとして使用されます。 自然な階層構造にひとつずつ従って、残っているドメインは写像されます。 具体的な実例は以下のサブチャプターで示されます。
3.3.2.2.1. X.400 -> RFC 822
3.3.2.2.1. X.400->RFC822
As an example, assume the following mapping rule is defined:
例として、以下の配置規則が定義されると仮定してください:
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
RARE Working Group on Mail and Messaging (WG-MSG) [Page 26] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[26ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
Then the address C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork
次に、アドレスCはnlと等しいです。 ADMD=ade。 PRMD=tlec。 Oはあなたと等しいです。 =が負っているOU。 S=plork
S OU O PRMD ADMD Country
| | | | | |
plork owe you tlec ade nl
S OU O PRMD ADMD国| | | | | | plorkはあなたにtlec ade nlを負っています。
would be mapped as follows. The Surname 'plork' is mapped to the localpart 'plork', see chapter 3.3.2.1. The domain
以下の通り写像されるでしょう。 第3.3章.2は、Surname'plork'がlocalpart'plork'に写像されるのを.1に見ます。 ドメイン
localpart
| sdom3
| | sdom2
| | | sdom1
| | | | top-level-domain
| | | | |
plork@ tlec.nl
localpart| sdom3| | sdom2| | | sdom1| | | | トップ・レベル・ドメイン| | | | | plork@tlec.nl
The remaining SAs (O and one OU) are mapped one by one following the natural hierarchy: O is mapped to sdom2, OU is mapped to sdom3:
自然な階層構造にひとつずつ従って、残っているSAs(Oと1OU)は写像されます: Oはsdom2に写像されて、OUはsdom3に写像されます:
localpart
| sdom3
| | sdom2
| | | sdom1
| | | | top-level-domain
| | | | |
plork@owe.you.tlec.nl
localpart| sdom3| | sdom2| | | sdom1| | | | トップ・レベル・ドメイン| | | | | plork@owe.you.tlec.nl
Thus the mapped address is:
したがって、写像しているアドレスは以下の通りです。
plork@owe.you.tlec.nl
plork@owe.you.tlec.nl
The table containing the listing of all such mapping rules, which is distributed to all gateways world-wide, is normally referred to as 'mapping table 1'. Other commonly used filenames (also depending on which software your are using) are:
通常、世界中のすべてのゲートウェイに配布されるそのようなすべての配置規則のリストを含むテーブルは'テーブル1を写像します'と呼ばれます。 他の一般的に使用されたファイル名、(また、どのソフトウェアによるか、あなた、使用) あります:
'or2rfc'
'mapping 1'
'map1'
'table 1'
'X2R'
'or2rfc''マッピング1''map1''テーブル1''X2R'
As already announced, there is an exceptional case were localpart and PN are not directly mapped onto each other: sometimes it is necessary to use the localpart for other purposes. If the X.400 address contains attributes that would not allow for the simple mapping:
あると既に発表するので、例外的なケースはlocalpartです、そして、PNは直接互いに写像されません: 時々、他の目的にlocalpartを使用するのが必要です。 X.400アドレスが属性を含んでいるなら、それは簡単なマッピングを考慮しないでしょう:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 27] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[27ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
localpart <-> PersonalName
domainpart <-> X.400 domain
localpart<->PersonalName domainpart<->X.400ドメイン
(e.g., spaces are not allowed in an RFC 822 domain, GQ and CN cannot be directly mapped into localpart, DDAs of another type than RFC- 822), such attributes, together with the PN, are left-hand-side encoded. The domainpart must still be mapped according to the mapping rule as far as possible. This probably needs some examples:
(GQ、例えば空間はRFC822ドメインに許容されていなくて、別のもののDDAsは、RFC822)より直接CNをlocalpartに写像できないのをタイプして、PNと共にそのような属性はコード化された左側です。 配置規則によると、domainpartをまだできるだけ写像しなければなりません。 これはたぶんいくつかの例を必要とします:
C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=you; S=plork; GQ=jr
->
/S=plork/GQ=jr/@you.owe.tlec.nl
Cはnlと等しいです。 ADMD=ade。 PRMD=tlec。 =が負っている○。 OUはあなたと等しいです。 S=plork。 GQ=jr->/S=plork/GQは jr/@you.owe.tlec.nl と等しいです。
C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=spc ctr; OU=u; S=plork
->
"/S=plork/OU=u/OU=spc ctr/"@owe.tlec.nl
Cはnlと等しいです。 ADMD=ade。 PRMD=tlec。 =が負っている○。 OU=spc ctr。 OU=u。 S=plork->"/S=plork/OU=u/OU=spc ctr/"@owe.tlec.nl
Note that in the second example, 'O=owe' is still mapped to a subdomain following the natural hierarchy. The problems start with the space in 'OU=spc ctr'.
2番目の例では、'=が負っている○'がまだ自然な階層構造に従うサブドメインに写像されていることに注意してください。 問題は'OU=spc ctr'のスペースから始まります。
3.3.2.2.2. RFC 822 -> X.400
3.3.2.2.2. RFC822->X.400
As an example, assume the following mapping rule is defined:
例として、以下の配置規則が定義されると仮定してください:
tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
Then the address 'plork@owe.you.tlec.nl' :
次に、アドレス' plork@owe.you.tlec.nl ':
localpart
| sdom3
| | sdom2
| | | sdom1
| | | | top-level-domain
| | | | |
plork@owe.you.tlec.nl
localpart| sdom3| | sdom2| | | sdom1| | | | トップ・レベル・ドメイン| | | | | plork@owe.you.tlec.nl
would be mapped as follows.
以下の通り写像されるでしょう。
The localpart 'plork' is mapped to 'S=plork', see chapter 3.3.2.1.
第3.3章.2は、''plork'が写像されるlocalpartはplorkと等しいことです'と.1に見ます。
The domain 'tlec.nl' is mapped according to the mapping rule:
配置規則によると、ドメイン'tlec.nl'は写像されます:
S OU OU O PRMD ADMD Country
| | | |
plork tlec ade nl
S OU OU O PRMD ADMD国| | | | plork tlec ade nl
The remaining domains (owe.you) are mapped one by one following the
続いて、残っているドメイン(owe.you)はひとつずつ写像されます。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 28] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[28ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
natural hierarchy: sdom2 is mapped to O, sdom3 is mapped to OU:
自然な階層構造: sdom2はOに写像されて、sdom3はOUに写像されます:
S OU OU O PRMD ADMD Country
| | | | | |
plork | | tlec ade nl
owe you
S OU OU O PRMD ADMD国| | | | | | plork| | tlec ade nlはあなたに負っています。
Thus the mapped address is (in a readable notation):
したがって、写像しているアドレスはこと(読み込み可能な記法で)です:
C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork
Cはnlと等しいです。 ADMD=ade。 PRMD=tlec。 Oはあなたと等しいです。 =が負っているOU。 S=plork
Had there been any left-hand-side encoded SAs in the localpart that didn't represent a complete mnemonic O/R address, the localpart would be mapped to those SAs. E.g.,
何か完全な簡略記憶O/Rアドレスを表さなかったlocalpartの左側のコード化されたSAsがあったなら、localpartはそれらのSAsに写像されるでしょう。 例えば
"/S=plork/GQ=jr/OU=u/OU=spc ctr/"@owe.tlec.nl
->
C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=space ctr;
OU=u; S=plork; GQ=jr
"/S=plork/GQ=jr/OU=u/OU=spc ctr/"@owe.tlec.nl->Cはnlと等しいです。 ADMD=ade。 PRMD=tlec。 =が負っている○。 OUはスペースctrと等しいです。 OU=u。 S=plork。 GQ=jr
This is necessary to reverse the special use of localpart to left- hand-side encode certain attributes. See 3.3.2.2.1.
これが、属性に左で手でエンコード確かな状態で面があるためにlocalpartの特別な使用を逆にするのに必要です。 見てください。3.3 .2 .2 .1。
You might ask yourself by now why such rules are needed at all. Why don't we just use map1 in the other direction? The problem is that a symmetric mapping function (a bijection) would indeed be ideal, but it's not feasible. Asymmetric mappings exist for a number of reasons:
あなたは、今ごろ、そのような規則がなぜいったい必要であるかを自分に尋ねるかもしれません。 ただ、もう片方の方向にmap1を使用しましょう。 問題は左右対称のマッピング機能(全単射)が本当に理想的でしょうが、それが可能でないということです。 非対称のマッピングは様々な意味で存在しています:
- To make sure that uucp addresses etc. get routed over local
gateways.
- 念のためアドレスなどが手に入れるそのuucpは地方のゲートウェイの上で掘られました。
- Preferring certain address forms, while still not forbidding
others to use another form. Examples of such reasons are:
- 他のものが別のフォームを使用するのをまだ禁じていない間、あるアドレスを好むのは形成されます。 そのような理由に関する例は以下の通りです。
- Phasing out old address forms.
- 旧住所を段階的に廃止するのは形成されます。
- If an RFC 822 address is mapped to ADMD= ; it means that
the X.400 mail can be routed over any ADMD in that
country. One single ADMD may of course send out an
address containing: ADMD=ade; . It must also be possible
to map such an address back.
- RFC822アドレスがADMD=に写像されるなら。 それは、その国のどんなADMDの上にもX.400メールを発送できることを意味します。 1独身のADMDがもちろん以下を含むアドレスを出すかもしれません。 ADMD=ade。 . また、そのようなアドレスを写像し返すのも可能であるに違いありません。
So we do need mapping rules from RFC 822 to X.400 too. The table containing the listing of all such mapping rules, which is distributed to all gateways world-wide, is normally referred to as on which software your are using) are:
それで、私たちはRFC822からX.400までも配置規則を必要とします。 通常、世界中のすべてのゲートウェイに配布されるそのようなすべての配置規則のリストを含むのがどのソフトウェアの上で呼ばれるテーブル、あなた、使用) あります:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 29] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[29ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
'rfc2or'
'mapping 2'
'map2'
'table 2'
'R2X'
'rfc2or''マッピング2''map2''テーブル2''R2X'
If the RFC 822 localpart and/or domainpart contain characters that would not immediately fit in the value of a PN attribute (! % _), the mapping algorithm falls back to DDA mapping. In this case, the SAs that will be used are still determined by mapping the domainpart according to the mapping rule. In our case:
If the RFC 822 localpart and/or domainpart contain characters that would not immediately fit in the value of a PN attribute (! % _), the mapping algorithm falls back to DDA mapping. この場合、使用されるSAsは、配置規則によると、domainpartを写像することによって、まだ決定しています。 私たちの場合で:
100%user@work.tlec.nl
->
DD.RFC-822=100(p)user(a)work.tlec.nl;
C=nl; ADMD=ade; PRMD=tlec; O=work
100%user@work.tlec.nl --、gt;、DD.RFC-822=100(p)user(a)work.tlec.nl。 Cはnlと等しいです。 ADMD=ade。 PRMD=tlec。 Oは仕事と等しいです。
If no map2 rule can be found, a third table of rules is scanned: the gateway table. This table has the same syntax as mapping table 2, but its semantics are different. First of all, a domain that only has an entry in the gateway table is always mapped into an RFC 822 DDA. For a domain that is purely RFC 822 based, but whose mail may be relayed over an X.400 network, the gateway table associates with such a domain the SAs of the gateway to which the X.400 message should be routed. That gateway will then be responsible for gatewaying the message back into the RFC 822 world. E.g., if we have the gateway table entry:
map2規則を全く見つけることができないなら、規則の第3のテーブルはスキャンされます: ゲートウェイテーブル。 このテーブルには、テーブル2を写像するのと同じ構文がありますが、意味論は異なっています。 まず、ゲートウェイテーブルにエントリーを持っているだけであるドメインはいつもRFC822DDAに写像されます。 純粋にベースのRFC822ですが、メールがX.400ネットワークの上でリレーされるかもしれないドメインのために、ゲートウェイテーブルはX.400メッセージが発送されるべきであるゲートウェイのSAsをそのようなドメインに関連づけます。 そのゲートウェイはその時、RFC822世界にメッセージをgatewayingして戻すのに原因となるようになるでしょう。 例えば、私たちがゲートウェイを持っているなら、エントリーをテーブルの上に置いてください:
gov#PRMD$gateway.ADMD$Internet.C$us#
gov#PRMD$gateway.ADMD$Internet.C$、私たち、#
(and we assume that no overruling map2 rule for the top level domain 'gov' exists), this would force all gateways to perform the following mapping:
(私たちは、トップ・レベル・ドメイン'gov'へのmap2規則を却下しないのが存在すると思います)、これによって、すべてのゲートウェイがやむを得ず以下のマッピングを実行するでしょう:
bush@dole.gov
->
DD.RFC-822=bush(a)dole.gov;
C=us; ADMD=Internet; PRMD=gateway
bush@dole.gov --、gt;、DD.RFC-822=bush(a)dole.gov。 Cは私たちと等しいです。 ADMDはインターネットと等しいです。 PRMDはゲートウェイと等しいです。
This is very similar to the default DDA mapping, except the SAs are those of a gateway that has declared to be responsible for a certain RFC 822 domain, not those of the local gateway. And thus, this mechanism helps avoid the third party problem discussed in chapter 3.2.2.
これはデフォルトDDAマッピングと非常に同様です、そして、SAsは地方のゲートウェイのものではなく、ある一定のRFC822ドメインに責任があると宣言したゲートウェイのものです。 そして、その結果、このメカニズムは、第3.2章.2で議論した第三者問題を避けるのを助けます。
The table containing the listing of all such gateway rules, which is distributed to all gateways world-wide, is normally referred to as the 'gateway table'. Other commonly used filenames (also depending on
通常、世界中のすべてのゲートウェイに配布されるそのようなすべてのゲートウェイ規則のリストを含むテーブルは'ゲートウェイテーブル'と呼ばれます。 他の一般的に使用されたファイル名、(また、よります。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 30] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[30ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
which software your are using) are:
どのソフトウェア、あなた、使用) あります:
'rfc1148gate' {From the predecessor of RFC 1327, RFC 1148}
'gate table'
'GW'
''RFC1327、RFC1148年の前任者'のrfc1148gateゲートテーブル''GW'
Only when no rule at all (map2 or gateway rule) is defined for a domain, the algorithm falls back to the default DDA mapping as described in 3.3.1.2.
全く、(map2かゲートウェイ規則)がドメインと定義されるというどんな規則、アルゴリズムがいつ説明されるようにデフォルトDDAマッピングへ後ろへ下がるだけではないか、も3.3、.1、.2
3.4. Table co-ordination
3.4. テーブルコーディネーション
As already stated, the use of mapping tables will only function smoothly if all gateways in the world use the same tables. On the global level, the collection and distribution of RFC 1327 address mapping tables is co-ordinated by the MHS Co-ordination Service:
前述のとおり、世界のすべてのゲートウェイが同じテーブルを使用する場合にだけ、マッピングテーブルの使用はスムーズに機能するでしょう。 グローバルなレベルでは、RFC1327アドレス変換テーブルの集散はMHS Co-叙階式Serviceによって調整されます:
SWITCH Head Office
MHS Co-ordination Service
Limmatquai 138
CH-8001 Zurich, Europe
Tel. +41 1 268 1550
Fax. +41 1 268 1568
1550がファックスで送る本社MHSコーディネーションサービスLimmatquai138CH-8001チューリッヒ、ヨーロッパTel.+41 1 268を切り換えてください。 +41 1 268 1568
RFC 822: project-team@switch.ch
X.400: C=ch;ADMD=arcom;PRMD=switch;O=switch;S=project-team;
RFC822: project-team@switch.ch X.400: C=ch; ADMD=arcom; PRMD=は切り替わります; ○ = 切り替わってください; Sはプロジェクト・チームと等しいです。
The procedures for collection and distribution of mapping rules can be found on the MHS Co-ordination Server, in the directory "/procedures". Appendix D describes how this server can be accessed.
「MHS Co-叙階式Serverで配置規則の集散のための手順を見つけることができます、ディレクトリで」/手順、」 付録Dはどうこのサーバにアクセスできるかを説明します。
If you want to define mapping rules for your own local domain, you can find the right contact person in your country or network (the gateway manager) on the same server, in the directory "/mhs- services".
「あなた自身の局所領域と配置規則を定義したいなら、あなたは同じサーバのあなたの国かネットワーク(ゲートウェイマネージャ)、ディレクトリ」 /mhsの正しい連絡窓口のためにサービスを見つけることができます。」
3.5. Local additions
3.5. 地方の追加
Since certain networks want to define rules that should only be used within their networks, such rules should not be distributed world- wide. Consider two networks that both want to reach the old top- level-domain 'arpa' over their local gateway. They would both like to use a mapping 2 rule for this purpose:
あるネットワークがそれらのネットワークの中で使用されるだけであるべきである規則を定義したがっているので、世界的で広い状態でそのような規則を分配するべきではありません。 地元のゲートウェイの上でともに古い先端平らなドメイン'アルパ'に達したがっている2つのネットワークを考えてください。 彼らはともにこのためにマッピング2規則を使用したがっています:
TLec in NL: arpa#PRMD$gateway.ADMD$tlec.C$nl#
NLのTLec: アルパ#PRMD$gateway.ADMD$tlec.C$nl#
SWITCH in CH: arpa#PRMD$gateway.ADMD$switch.C$ch#
CHで切り替わってください: アルパ#PRMD$gateway.ADMD$switch.C$ch#
RARE Working Group on Mail and Messaging (WG-MSG) [Page 31] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[31ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
(You may have noticed correctly that they should have defined such rules in the gateway table, but for the sake of the example, we assume they defined it in mapping table 2. This was the way things were done in the days of RFC 987, and many networks are still doing it this way these days.)
あなたは、彼らがゲートウェイテーブルのそのような規則を定義するべきであるのに正しく気付いたかもしれませんが、例のために私たちは、それらがテーブル2を写像する際にそれを定義したと思います。(これはRFC987の数日にことをして、多くのネットワークが最近このようにまだそれをしている方法でした。)
Since a mapping table cannot contain two mapping rules with the same domain on the left hand side, such 'local mappings' are not distributed globally. There exists a RARE draft proposal [13] which defines a mechanism for allowing and automatically dealing with conflicting mapping rules, but this mechanism has not been implemented as to date. After having received the global mapping tables from the MHS Co-ordination Service, many networks add 'local' rules to map2 and the gateway table before installing them on their gateways. Note that the reverse mapping 2 rules for such local mappings _are_ globally unique, and can thus be distributed world- wide. This is even necessary, because addresses that were mapped with a local mapping rule may leak out to other networks (here comes the third party problem again...). Such other networks should at least be given the possibility to map the addresses back. So the global mapping table 1 would in this case contain the two rules:
マッピングテーブルが同じドメインが左側にある2つの配置規則を含むことができないので、そのような'ローカルのマッピング'はグローバルに分配されません。 闘争配置規則を許容して、自動的に対処するためにメカニズムを定義するRARE試案[13]は存在していますが、このメカニズムはこれまでとして実行されていません。 MHS Co-叙階式Serviceからグローバルなマッピングテーブルを受けた後に、それらのゲートウェイの上にそれらをインストールする前に、多くのネットワークが'地方'の規則をmap2とゲートウェイテーブルに加えます。 2を写像する逆がそのようなローカルのマッピングのために統治されることに注意してください。__はグローバルにユニークです、そして、その結果、世界的で広い状態で分配できます。 これが必要でさえあります、ローカルの配置規則で写像されたアドレスが他のネットワークに漏れるかもしれないので(第三者問題は再びここに来ます…)。 アドレスを写像し返す可能性をそのような他のネットワークに少なくとも与えるべきです。 それで、グローバルなマッピングテーブル1はこの場合2つの規則を含むでしょう:
PRMD$gateway.ADMD$tlec.C$nl#arpa#
PRMD$gateway.ADMD$switch.C$ch#arpa#
PRMD$gateway.ADMD$tlec.C$nl#アルパ#PRMD$gateway.ADMD$switch.C$ch#アルパ#
Note that if such rules would have been defined as local gate table entries instead of map2 entries, there would have been no need to distribute the reverse mappings world-wide (the reverse mapping of a DDA encoded RFC 822 address is simply done by stripping the SAs, see 3.3.1.1.).
そのような規則がmap2エントリーの代わりに地方のゲートテーブル項目と定義されたなら、世界中で逆のマッピングを分配する必要は全くなかったことに注意してください(SAsを剥取ることによって、単にDDAコード化されたRFC822アドレスの逆のマッピングをして、3.3に.1に.1を見てください)。
3.6. Product specific formats
3.6. 製品の特定の形式
Not all software uses the RFC 1327 format of the mapping tables internally. Almost all formats allow comments on a line starting with a # sign. Some examples of different formats:
すべてのソフトウェアが内部的にマッピングテーブルのRFC1327形式を使用するというわけではありません。 #サインから始まって、ほとんどすべての形式が線の上にコメントを許容します。 異なった形式に関するいくつかの例:
RARE Working Group on Mail and Messaging (WG-MSG) [Page 32] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[32ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
RFC 1327
RFC1327
# This is pure RFC 1327 format
# table 1: X.400 -> RFC 822
#
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
# etc.
# これは純粋なRFC1327形式#テーブル1です: X.400->RFC822#PRMD$tlec.ADMD$ade.C$nl#tlec.nl##など
# table 2: RFC 822 -> X.400
#
arcom.ch#ADMD$arcom.C$ch#
# etc.
# テーブル2: RFC822->X.400#arcom.ch#ADMD$arcom.C$ch##など
EAN
EAN
# This is EAN format
# It uses the readable format for X.400 domains and TABs
# to make a 'readable mapping table format'.
# table 1: X.400 -> RFC 822
#
P=tlec; A=ade; C=nl; # tlec.nl
# etc.
# これはX.400ドメインとTABs#が'読み込み可能なマッピングテーブル形式'を作るのにItが読み込み可能な形式を使用するEAN形式#です。 # テーブル1: X.400->RFC822#P=tlec。 A=ade。 Cはnlと等しいです。 # tlec.nl#など
# table 2: RFC 822 -> X.400
#
arcom.ch # A=arcom; C=ch;
# etc.
# テーブル2: RFC822->X.400#arcom.ch#A=arcom。 Cはchと等しいです。 # など
PP
pp
# This is PP format
# table 1: X.400 -> RFC 822
#
PRMD$tlec.ADMD$ade.C$nl:tlec.nl
# etc.
# これはPP形式#テーブル1です: X.400->RFC822#PRMD$tlec.ADMD$ade.C$nl: tlec.nl#など
# table 2: RFC 822 -> X.400
#
arcom.ch:ADMD$arcom.C$ch
# etc.
# テーブル2: RFC822->X.400#arcom.ch: #ADMD$arcom.C$chななど
Most R&D networks have tools to automatically generate these formats from the original RFC 1327 tables;, some even distribute the tables within their networks in several formats. If you need mapping tables in a specific format, please contact your national or R&D network's gateway manager. See chapter 3.4.
ほとんどの研究開発ネットワークには、オリジナルのRFC1327テーブルからこれらの形式を自動的に発生させるツールがあります;、或るものはそれらのネットワークの中でいくつかの形式でテーブルを分配さえします。 特定の形式でテーブルを写像する必要があるなら、国家か研究開発ネットワークのゲートウェイマネージャに連絡してください。 第3.4章を見てください。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 33] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[33ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
3.7. Guidelines for mapping rule definition
3.7. 配置規則定義のためのガイドライン
Beware that defining mapping rules without knowing what you are doing can be disastrous not only for your network, but also for others. You should be rather safe if you follow at least these rules:
他のものにとっても、あなたが何をしているかを知らない配置規則を定義するのがあなたのネットワークだけに悲惨であるのではなく、悲惨である場合があるのに注意してください。 少なくともこれらの規則に従うなら、あなたはかなり安全であるべきです:
- First of all, read this tutorial;.
- まず、このチュートリアルを読んでください。
- Avoid local mappings; prefer gate table entries. (See chapter
3.5)
- ローカルのマッピングを避けてください。 ゲートテーブル項目を好んでください。 (第3.5章を見ます)
- Make sure any domain you map to can also be mapped back;.
- 確実にあなたが缶に写像するあらゆるドメインを作ってください、そして、また、写像し返されてください、。
- Aim for symmetry.
- 対称を目指してください。
- Don't define a gateway table entry if the same domain already
has a map2 entry. Such a rule would be redundant.
- 同じドメインにmap2エントリーが既にあるなら、ゲートウェイテーブル項目を定義しないでください。 そのような規則は余分でしょう。
- Map to "ADMD=0;" if you will not be connected to any ADMD for
the time being.
- "ADMD=0"への地図。 あなたが当分の間どんなADMDにも接続されないなら。
- Only map to "ADMD= ;" if you are indeed reachable through
_any_ ADMD in your country.
- 「ADMD=」への地図だけ。 あなたが本当にあなたの国で__いずれかADMDを通して届くなら。
- Mind the difference between "PRMD=;" and "PRMD=@;" and make
sure which one you need. (Try to avoid empty or unused
attributes in the O/R address hierarchy from the beginning!)
- 「PRMD=」の違いを気にしてください。 そして、「PRMDは@と等しいです」。 そして、どれを必要とするかを確実にしてください。 (始めからO/Rアドレス階層構造で空の、または、未使用の属性を避けるようにしてください!)
- Don't define mappings for domains over which you have no
naming authority.
- あなたが命名権威を全く持っていないドメインのためのマッピングを定義しないでください。
- Before defining a mapping rule, make sure you have the
permission from the naming authority of the domain you want
to map to. Normally, this should be the same organisation as
the mapping authority of the domain in the left hand side of
the mapping rule. This principle is called 'administrative
equivalence'.
- 配置規則を定義する前に、あなたが写像したいドメインの命名権威からの許可を必ず持ってください。 通常、これは配置規則の左側のドメインのマッピング権威と同じ機構であるはずです。 この原則は'管理等価性'と呼ばれます。
- Avoid redundant mappings. E.g., if all domains under 'tlec.nl'
are in your control, don't define:
- 余分なマッピングを避けてください。 例えば、'tlec.nl'の下のすべてのドメインがコントロール中であるなら、以下を定義しないでください。
first.tlec.nl#O$first.PRMD$tlec.ADMD$ade.C$nl#
last.tlec.nl#O$last.PRMD$tlec.ADMD$ade.C$nl#
always.tlec.nl#O$always.PRMD$tlec.ADMD$ade.C$nl#
最初.tlec.nl#Oの$最初の.PRMD$のtlec.ADMD$ade.C$nl#last.tlec.nl#O$last.PRMD$tlec.ADMD$ade.C$nl#always.tlec.nl#O$always.PRMD$tlec.ADMD$ade.C$nl#
but rather have only one mapping rule:
しかし、むしろ1つの配置規則しか持たないでください:
tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
RARE Working Group on Mail and Messaging (WG-MSG) [Page 34] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[34ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
- Before introducing a new mapped version of a domain, make
sure the world can route to that mapped domain;.
- ドメインの新しい写像しているバージョンを紹介する前に、世界がその写像しているドメインに発送できるのを確実にしてください。
E.g., If you are operating a PRMD: C=zz; ADMD=ade; PRMD=ergo;
and you want to define the mapping rules:
例えば、If、あなたはPRMDを操作しています: Cはzzと等しいです。 ADMD=ade。 PRMD、= この故に。 そして、あなたは配置規則を定義したがっています:
map1: PRMD$ergo.ADMD$ade.C$zz#ergo.zz#
map2: ergo.zz#PRMD$ergo.ADMD$ade.C$zz#
map1: PRMD$ergo.ADMD$ade.C$zz#ergo.zz#map2: ergo.zz#PRMD$ergo.ADMD$ade.C$zz#
Make sure that ergo.zz (or at least all of its subdomains) is
DNS routeable (register an MX or A record) and will be routed
to a gateway that agreed to route the messages from the
Internet to you over X.400.
ergo.zz(または、少なくともサブドメインのすべて)がDNS routeable(MXかA記録を登録する)であり、それが同意したゲートウェイに発送されるのをX.400の上にメッセージを必ず発送してください。
In the other direction, if you are operating the Internet
domain cs.woodstock.edu, and you want to define a mapping for
that domain:
もう片方の指示、あなたがインターネットドメインcs.woodstock.eduを操作していて、そのドメインのためのマッピングを定義したいなら:
map2: cs.woodstock.edu#O$cs.PRMD$woodstock.ADMD$ .C$us#
map1: O$cs.PRMD$woodstock.ADMD$ .C$us#cs.woodstock.edu#
map2: cs.woodstock.edu#O$cs.PRMD$woodstock.ADMD$.C$、私たち、#map1: O$cs.PRMD$woodstock.ADMD$.C$、私たち、#cs.woodstock.edu#
Make sure that C=us; ADMD= ; PRMD=woodstock; O=cs; (or at
least all of its subdomains) is routeable in the X.400 world,
and will be routed to a gateway that agreed to route the
messages from X.400 to your RFC 822 domain over SMTP. Within
the GO-MHS community, this would be done by registering a
line in a so-called domain document, which will state to
which mail relay this domain should be routed.
Cが私たちと等しいのを確実にしてください。 ADMD=。 PRMD=woodstock。 OはCsと等しいです。 (または、少なくともサブドメインのすべて) X.400世界で「ルート-可能」で、X.400からあなたのRFC822ドメインまでSMTPの上にメッセージを発送するのに同意したゲートウェイに発送されるでしょう。 GO-MHS共同体の中では、いわゆるドメインドキュメントに線を示すことによって、これをするでしょう。(ドキュメントは、このドメインがどのメール中継に発送されるべきであるかを述べるでしょう)。
Co-ordinate any such actions with your national or MHS'
gateway manager. See chapter 3.4.
同胞かMHSのゲートウェイマネージャと共にあらゆるそのような動作を調整してください。 第3.4章を見てください。
4. Conclusion
4. 結論
Mail gatewaying remains a complicated subject. If after reading this tutorial, you feel you understand the basics, try solving some real- life problems. This is indeed a very rewarding area to work in: even after having worked with it for many years, you can make amazing discoveries every other week........
メールgatewayingは複雑な対象のままで残っています。 このチュートリアルを読んだ後に基礎を理解していると感じるなら、いくつかの本当の人生問題を解決してみてください。本当に、これは働いている非常に価値ある領域です: 何年間もそれで働く後にさえ、あなたは隔週に驚くべき発見をすることができます…
RARE Working Group on Mail and Messaging (WG-MSG) [Page 35] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[35ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
Appendix A. References
付録A.参照
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学(1982年8月)。
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", and
"Domain Names - Implementation and Specification", STD 13, RFCs
1034 and 1035, USC/Information Sciences Institute, November
1987.
[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、「ドメイン名--、実現と仕様、」、STD13とRFCs1034と1035、USC/情報科学研究所(1987年11月)
[4] Kille, S., "Mapping Between X.400 and RFC 822", RFC 987, UK
Academic Community Report (MG.19), UCL, June 1986.
[4]Kille、S.、「X.400とRFC822インチ、RFC987、イギリスの学界レポートの間で(mg.19)、UCL、6月1986日を写像すること。
[5] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
[5] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123(科学が1989年10月に設けるUSC/情報)
[6] Postel, J., Editor, "Internet Official Protocol Standards", STD
1, RFC 1500, USC/Information Sciences Institute, August 1993.
[6] ポステル、J.、エディタ、「インターネット公式プロトコル標準」、STD1、USC/情報科学が1993年8月に設けるRFC1500。
[7] Chapin, L., Chair, "The Internet Standards Process", RFC 1310,
Internet Activities Board, March 1992.
[7] チェーピン、L.、議長、「インターネット標準化過程」、RFC1310、インターネット活動は1992年3月に入ります。
[8] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
822", RFC 1327 / RARE RTR 2, University College London, May
1992.
[8]Kille、S.、「X.400(1988)/ISO10021とRFC822インチ(RFC1327/まれなRTR2、ユニバーシティ・カレッジロンドン1992年5月)の間の写像
[9] Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328 / RARE RTR
3, University College London, May 1992.
[9]Kille、S.、「X.400 1988年から1984格下げ」、RFC1328 / RARE RTR3、ユニバーシティ・カレッジロンドン1992年5月。
[10] Plattner, B., and H. Lubich, "Electronic Mail Systems and
Protocols Overview and Case Study", Proceedings of the IFIP WG
6.5 International working conference on message handling systems
and distributed applications; Costa Mesa 1988; North-Holland,
1989.
[10] Plattner、B.、H.ルビック、および「電子メール・システム、プロトコル概観、およびケーススタディ」、メッセージハンドリングシステムと分配されたアプリケーションのIFIP WGの6.5の国際働く会議のProceedings。 コスタメサ1988。 北のオランダ、1989。
[11] Houttuin, J., "@route:100%name@address, a practical guide to MHS
configuration", Top-Level EC, 1993, (not yet published).
「[11]Houttuin、J.」、@route: 100%name@address 、MHS構成への実用的なガイド、」、EC、1993(まだ発行されていない)をTop平らにしてください。
[12] Alvestrand, H., "Frequently asked questions on X.400", regularly
posted on USEnet in newsgroup comp.protocols.iso.x400.
[12] Alvestrand(「X.400の質問が頻繁に行われた」H.)はUSEnetにニュースグループでcomp.protocols.iso.x400を定期的に掲示しました。
[13] Houttuin, J., Hansen, K., and S. Aumont, "RFC 1327 Address
Mapping Authorities", RARE WG-MSG Working Draft, Work in
Progress, May 1993.
[13] Houttuin、J.、ハンセン、K.、およびS.オーモン、「RFC1327アドレス・マッピング当局」、まれなWG-MSG作業草案は進行中(1993年5月)で働いています。
RARE Working Group on Mail and Messaging (WG-MSG) [Page 36] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[36ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
[14] "COSINE MHS Pocket User Guide", COSINE MHS Project Team 1992.
Also available in several languages from the MHS Co-ordination
Server:/user-guides. See Appendix D.
[14] 「コサインMHSポケットユーザガイド」、コサインMHSはチーム1992を映し出します。 また、MHS Co-叙階式Server: /ユーザガイドから多言語で利用可能です。 付録Dを見てください。
[15] Grimm, R., and S. Haug, "A Minimum Profile for RFC 987", GMD,
November 1987; RARE MHS Project Team; July 1990. Also available
from the MHS Co-ordination Server:/procedures/min-rfc987-
profile. See Appendix D.
[15] グリム、R.とS.ハウク、「RFC987に、最小のプロフィール」GMD、1987年11月。 まれなMHSプロジェクト・チーム。 1990年7月。 また、MHS Co-叙階式Server: /procedures/min-rfc987プロフィールから、利用可能です。 付録Dを見てください。
[16] CCITT Recommendations X.400 - X.430. Data Communication
Networks: Message Handling Systems. CCITT Red Book, Vol. VIII -
Fasc. VIII.7, Malaga-Torremolinos 1984.
[16]CCITT推薦X.400--X.430。 データ通信ネットワーク: メッセージハンドリングシステムCCITT職員録、Vol.VIII--Fasc。 VIII.7、マラガ-トレモリノス1984。
[17] CCITT Recommendations X.400 - X.420. Data Communication
Networks: Message Handling Systems. CCITT Blue Book, Vol. VIII
- Fasc. VIII.7, Melbourne 1988.
[17]CCITT推薦X.400--X.420。 データ通信ネットワーク: メッセージハンドリングシステムCCITT紳士録、Vol.VIII--Fasc。 VIII.7、メルボルン1988。
Appendix B. Index
付録B.インデックス
<<Only available in the Postscript version>>
補遣版>>の利用可能なだけの<<。
Appendix C. Abbreviations
付録C.略語
ADMD Administration Management Domain
ARPA Advanced Research Projects Agency
ASCII American Standard Code for Information Exchange
ASN.1 Abstract Syntax Notation One
BCD Binary-Coded Decimal
BITNET Because It's Time NETwork
CCITT Comite Consultatif International de Telegraphique et
Telephonique
COSINE Co-operation for OSI networking in Europe
DFN Deutsches Forschungsnetz
DL Distribution List
DNS Domain Name System
DoD Department of Defense
EBCDIC Extended BCD Interchange Code
IAB Internet Architecture Board
IEC International Electrotechnical Commission
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IP Internet Protocol
IPM Inter-Personal Message
IPMS Inter-Personal Messaging Service
IPN Inter-Personal Notification
ISO International Organisation for Standardisation
ISOC Internet Society
ADMD政権管理ドメインアルパ先端研究プロジェクト政府機関ASCIIアメリカン・スタンダードは情報交換のためにASNをコード化します; 1 ヨーロッパDFN Deutsches Forschungsnetz DL Distribution List DNSでドメインネームシステムDoD国防総省EBCDIC Extended BCD Interchange CodeをネットワークでつなぐOSIのための抽象的なSyntax Notation One BCD2進化10進法Bitnet Because ItのTime NETworkのCCITTのComite Consultatifの国際de Telegraphique et Telephonique COSINE Co-事業; 規格化ISOCインターネット協会のための相互個人的なIABのメッセージサービスIPN相互個人的な通知ISOインターネット・アーキテクチャ委員会IEC国際電気標準化会議IESGインターネット工学運営グループIETFインターネット・エンジニアリング・タスク・フォースIPインターネットプロトコルIPM相互親書IPMS国際機関
RARE Working Group on Mail and Messaging (WG-MSG) [Page 37] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[37ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
ISODE ISO Development Environment
JNT Joint Network Team (UK)
JTC Joint Technical Committee (ISO/IEC)
MHS Message Handling System
MOTIS Message-Oriented Text Interchange Systems
MTA Message Transfer Agent
MTL Message Transfer Layer
MTS Message Transfer System
MX Mail eXchanger
OSI Open Systems Interconnection
OU(s) Organizational Unit(s)
PP Mail gatewaying software (not an abbreviation)
PRMD Private Management Domain
RARE Reseaux Associes pour la Recherche Europeenne
RFC Request for comments
RTC RARE Technical Committee
RTR RARE Technical Report
SMTP simple mail transfer protocol
STD Internet Standard
TCP Transmission Control Protocol
UUCP Unix to Unix CoPy
メッセージ指向のISODE ISOの開発の環境のJNTの共同ネットワークチーム(イギリス)のJTCの共同専門委員会(ISO/IEC)のMTLメッセージ転送層のMTSメッセージ転送システムMHSメッセージハンドリングシステムMOTISテキスト置き換えシステムMTAメッセージ転送エージェントMXは交換器OSI開放型システム間相互接続OU(s)に組織的な状態で郵送します; ユニットPPメールgatewayingソフトウェア(略語でない)PRMD兵士のManagement Domain RARE Reseaux AssociesはコメントRTC RARE Technical Committee RTR RARE Technical Report SMTP SMTP STDインターネットStandard TCP通信制御プロトコルUUCP UnixのためにUnix CoPyにla Recherche Europeenne RFC Requestを注ぎます。
Appendix D. How to access the MHS Co-ordination Server
MHS Co-叙階式Serverにアクセスする付録D.How
Here is an at-a-glance sheet on the access possibilities of the MHS Co-ordination server:
ここに、一目における、MHS Co-叙階式サーバのアクセスの可能性のシートがあります:
E-mail
メール
address:
アドレス:
RFC822: mhs-server@nic.switch.ch
X.400: S=mhs-server; OU1=nic; O=switch; P=switch; A=arcom;
C=CH
RFC822: mhs-server@nic.switch.ch X.400: S=mhs-サーバ。 OU1=nic。 ○ = 切り替わってください。 Pはスイッチと等しいです。 A=arcom。 CはCHと等しいです。
body
ボディー
help # you receive this document
index ['directory'] # you receive a directory listing
send 'directory''filename' # you receive the specified file
「あなたが受ける#、がリストが'ディレクトリ」ファイル名を送るあなたが受ける['ディレクトリ']#aディレクトリに索引をつけるのをこれが、ドキュメントである助けてください'というあなたが受ける#、指定されたファイル
FTP
FTP
address: Internet: nic.switch.ch
account: cosine
password: 'your email address'
アドレス: インターネット: nic.switch.chアカウント: コサインパスワード: 'あなたのEメールアドレス'
RARE Working Group on Mail and Messaging (WG-MSG) [Page 38] RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
メールと1993年8月に(WG-MSG)[38ページ]RFC1506X.400-インターネットメールGatewayingチュートリアルを通信させるときのまれな作業部会
Interactive
インタラクティブ
address: Internet: nic.switch.ch
address: PSPDN: +22847971014540
address: EMPB/IXI: 20432840100540
account: info
directory: e-mail/COSINE-MHS/
アドレス: インターネット: nic.switch.chアドレス: PSPDN: +22847971014540 アドレス: EMPB/IXI: 20432840100540は説明されます: インフォメーションディレクトリ: コサインメール/MHS/
FTAM
FTAM
address: Internet: nic.switch.ch
address: PSPDN : +22847971014540
address: EMPB/IXI: 20432840100540
address: ISO CLNS: NSAP=39756f11112222223333aa0004000ae100,
TSEL=0103Hex
account: ANON
アドレス: インターネット: nic.switch.chアドレス: PSPDN: +22847971014540 アドレス: EMPB/IXI: 20432840100540 アドレス: ISO CLNS: NSAP=39756f11112222223333aa0004000ae100、TSEL=0103Hexは説明します: やがて
gopher
リス
address: Internet: nic.switch.ch
アドレス: インターネット: nic.switch.ch
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Jeroen Houttuin RARE Secretariat Singel 466-468 NL-1017 AW Amsterdam Europe
ジョロエン・Houttuinのまれな事務局Singel466-468NL-1017 AWアムステルダムヨーロッパ
Tel. +31 20 6391131 Fax. +31 20 6393289 RFC 822: houttuin@rare.nl X.400: C=nl;ADMD=400net;PRMD=surf;O=rare;S=houttuin
Tel.+31 20 6391131ファックス。 +31 20 6393289RFC822: houttuin@rare.nl X.400: nl; ADMD=400net; PRMD=サーフ;O=まれ;のC=S=houttuin
RARE Working Group on Mail and Messaging (WG-MSG) [Page 39]
メールとメッセージング(WG-MSG)のまれな作業部会[39ページ]
一覧
スポンサーリンク
