RFC1405 日本語訳
1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail). C.Allocchio. January 1993. (Format: TXT=33885 bytes) (Obsoleted by RFC2162) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Allocchio
Request for Comments: 1405 I.N.F.N. - Italy
January 1993
Allocchioがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1405 イタリア1993年I.N.F.N.--1月
Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
X.400(1984/1988)とメール-11の間のマッピング(DECnetメール)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.
このドキュメントはMessage Handling SystemsでCCITT X.400( 1984 / 1988 )推薦を操作するシステムと、メール-11(また、DECnetメールとして、知られている)プロトコルを走らせるシステムの間の間の運用を可能にする1セットのマッピングについて説明します。 仕様はDECnet Phase IVアドレシングとルーティング計画の中で有効です。
The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
また、X.400/RFC822/メール-11の完全なシナリオは考えられます、複数のゲートウェイ翻訳に起こる可能な複雑なケースをカバーするために。
This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.
このドキュメントはO/RアドレスをDECnetに主に/からアドレス・マッピング(逆もまた同様である)までカバーしています。 他のマッピングはRFC1327とその最後の将来のアップデートに基づいています。
This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group.
これはCOSINE S2.2、RARE MSG作業部会、およびIETF X.400 Ops作業部会の協力です。
Chapter 1 - Introduction
第1章--序論
1.1. X.400
1.1. X.400
The standard referred shortly into this document as "X.400" relates to the CCITT 1984 and 1988 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only.
"X.400"がCCITT1984に関連して、規格はすぐこのドキュメントに参照されました、そして、メッセージをカバーする1988のX.400シリーズ推薦がテキスト置き換えサービス(MOTIS)を適応させました。 このドキュメントはInterパーソナルMessaging System(IPMS)だけを覆っています。
1.2. Mail-11
1.2. メール-11
Mail-11, also known as DECnet mail and often improperly referred as VMSmail, is the proprietary protocol implemented by Digital Equipment Corporation (DEC) to establish a real-time text messaging system
また、DECnetメールとして知られていて、VMSmailとしてしばしば不適切に参照されたメール-11は、リアルタイムのテキスト・メッセージングシステムを証明するためにDEC(12月)によって実行された固有のプロトコルです。
Allocchio [Page 1] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[1ページ]RFC1405メール-11
among systems implementing the DECnet Phase IV networking protocols.
DECnet Phase IVネットワーク・プロトコルを実行するシステムの中で。
1.3. RFC822
1.3. RFC822
RFC822 was defined as a standard for personal messaging systems within the DARPA Internet and is now diffused on top of many different message transfer protocols, like SMTP, UUCP, BITNET, JNT Grey Book, CSnet. Its mapping with X.400 is fully described in RFC1327. In this document we will try to consider its relations with Mail-11, too.
RFC822はDARPAインターネットの中で個人的なメッセージシステムの規格と定義されて、現在多くの異なったメッセージ転送プロトコルの上で拡散します、SMTPのように、UUCP、Bitnet、JNT Grey Book、CSnet。 X.400があるマッピングはRFC1327で完全に説明されます。 本書では私たちはメール-11とも関係を考えようとするでしょう。
1.4. The user community
1.4. ユーザーコミュニティ
The community using X.400 messaging system is currently growing in the whole world, but there is still a number of very large communities using Mail-11 based messaging systems willing to communicate easily with X.400 based Message Handling Systems. Among these large DECnet based networks we can include the High Energy Physics network (HEPnet) and the Space Physics Analysis Network (SPAN).
あります、そして、X.400メッセージシステムを使用する共同体は現在、全世界で発展していますが、それでも、容易にX.400のベースのMessage Handling Systems Amongと私たちが伝えることができるこれらの大きいDECnetベースのネットワークを伝えても構わないと思っているシステムを通信させながら基づくメール-11を使用する多くの非常に大きい共同体がHigh Energy Physicsネットワーク(HEPnet)とSpace Physics Analysis Network(SPAN)を含めます。
These DECnet communities will in the future possibly migrate to DECnet Phase V (DECnet-OSI) protocols, converting thus their messaging systems to OSI specifications, i.e., merging into the X.400 MHS; however the transition period could be long, and there could always be some DECnet Phase IV communities around.
これらのDECnet共同体は将来ことによるとDECnet Phase V(DECnet-OSI)プロトコルにわたるでしょう、その結果、すなわち、X.400 MHSに溶け込みながら、それらのメッセージシステムをOSI仕様に変換します。 しかしながら、過渡期は長いかもしれません、そして、いくつかのDECnet Phase IV共同体が周囲にいつもあるかもしれません。
For these reasons a set of mapping rules covering conversion between Mail-11 and X.400 is described in this document.
これらの理由で、メール-11とX.400の間の変換をカバーする1セットの配置規則が本書では説明されます。
This document also covers the case of Mail-11 systems implementing the "foreign mail protocol" allowing Mail-11 to interface other mail systems, including RFC822 based system.
また、このドキュメントはメール-11が他のメールシステムを連結するのを許容しながら「外国メールプロトコル」を実行するメール-11台のシステムに関するケースをカバーしています、RFC822のベースのシステムを含んでいて。
Chapter 2 - Message Elements
第2章--Message Elements
2.1. Service Elements
2.1. サービス要素
Mail-11 protocol offers a very restricted set of elements composing a Inter Personal Message (IPM), whereas X.400 specifications support a complex and large amount of service elements. Considering the case where a message is relayed between two X.400 MHS via a DECnet network this could result in a nearly complete loss of information. To minimise this inconvenience most of X.400 service elements will be mapped into Mail-11 text body parts. To consider also the case when a message originates from a network implementing RFC822 protocols and is relayed via Mail-11 to and X.400 MHS, the applied mapping from X.400 service elements into Mail-11 text body part the rules
メール-11プロトコルはInterパーソナルMessage(IPM)を構成する非常に制限されたセットの要素を提供しますが、X.400仕様は複雑で多量のサービス要素を支えます。 これは情報のほとんど完全な損失をもたらして、メッセージがDECnetネットワークを通して2X.400 MHSの間でリレーされるケースを考えるかもしれません。 この不便を最小とならせるように、X.400サービス要素の大部分はメール-11のテキスト身体の部分に写像されるでしょう。 また、ケースがメッセージがいつまでRFC822プロトコルを実行するネットワークから発して、メール-11でリレーされるか、そして、X.400 MHS、X.400サービス要素からの適用されたマッピングであるとメール-11テキスト本文と考えるには、規則を分けてください。
Allocchio [Page 2] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[2ページ]RFC1405メール-11
specified in RFC1327 and their updates will be used, producing an RFC822-like header.
RFC1327と彼らのアップデートで指定されて、RFC822のようなヘッダーを作り出して、使用されるでしょう。
2.2. Mail-11 service elements
2.2. メール-11のサービス要素
All envelope (P1) and header (P2) Mail-11 service elements are supported in the conversion to X.400. Note that Mail-11 P1 is solely composed by P1.From and P1.To, and any other Mail-11 element belongs to Mail-11 P2:
すべての封筒(P1)とメール-11のヘッダー(P2)サービス要素が変換でX.400に支えられます。 メール-11P1がP1.FromとP1.Toによって唯一構成されることに注意してください。そうすれば、いかなる他のメール-11要素もメール-11P2に属します:
- P1.From
maps to P1.Originator
- P1.OriginatorへのP1.From地図
- P1.To
maps to P1.Primary Recipient
- P1.Primary RecipientへのP1.To地図
- P2.From
maps to P2.Originator
- P2.OriginatorへのP2.From地図
- P2.To
maps to P2.Primary Recipient
- P2.Primary RecipientへのP2.To地図
- Cc
maps to P2.Copy Recipient
- P2.Copy Recipientへのcc地図
- Date
maps to Submission Time Stamp
- Submission Time Stampへの日付の地図
- Subj
maps to Subject
- Subjectへの首題地図
Any eventual RFC822-like text header in Mail-11 body part will be interpreted as specified into RFC1327 and its updates.
メール-11身体の部分のどんな最後のRFC822のようなテキストヘッダーもRFC1327とそのアップデートに指定されるように解釈されるでしょう。
2.3. X.400 service elements
2.3. X.400サービス要素
The following X.400 service elements are supported directly into Mail-11 conversion:
以下のX.400サービス要素は直接メール-11変換するのに支えられます:
- P1.Originator
maps to P1.'From'
- P1.'From'へのP1.Originator地図
- P1.Primary Recipients
maps to P1.'To'
- P1.'To'へのP1.Primary Recipients地図
- P2.Originator
maps to P2.'From'
- P2.'From'へのP2.Originator地図
Allocchio [Page 3] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[3ページ]RFC1405メール-11
- P2.Primary Recipients
maps to P2.'To'
- P2.'To'へのP2.Primary Recipients地図
- Copy Recipients
maps to 'Cc'
- 'cc'へのコピーRecipients地図
- Submission Time Stamp
maps to 'date'
- '日付を入れる'服従Time Stamp地図
- Subject
maps to 'Subj'
- '首題'への対象の地図
The following X.400 service element is partially supported into Mail-11 conversion:
以下のX.400サービス要素はメール-11変換に部分的に支えられます:
- Blind Copy Recipient
to ensure the required privacy, when a message contains
a BCC address, the following actions occurs:
- a new message is created, containing the body parts;
- a new envelope is added to the new message, containing
the originator and the BCC recipient addresses only;
- a note is added to the message informing the BCC
recipient about the fact that the message was a BCC;
- the new message is delivered separately;
- a note is added to the message delivered to TO and CC
recipients informing them about the fact that there
were some BCC recipients, too.
- メッセージがBCCアドレスを含むときの以下の動作を必要なプライバシーに確実にする盲目のCopy Recipientは起こります: - 身体の部分を含んでいて、新しいメッセージは作成されます。 - 創始者とBCC受取人アドレスだけを含んでいて、新しい封筒は新しいメッセージに追加されます。 - 注意はメッセージがBCCであったという事実に関してBCC受取人に知らせるメッセージに追加されます。 - 別々に新しいメッセージを送ります。 - 注意は何人かのBCC受取人もいたという事実に関してTOに渡されたメッセージと彼らを知らせるCC受取人に追加されます。
Any other X.400 service element support is done accordingly to RFC1327 including the mapped element into the RFC822-like header into Mail-11 body part.
それに従って、メール-11身体の部分へのRFC822のようなヘッダーに写像している要素を含むRFC1327にいかなる他のX.400サービス要素サポートもします。
Chapter 3 - Basic Mappings
第3章--基本のマッピング
The basic mappings indicated in RFC1327 and its updates should be fully used.
RFC1327で示された基本のマッピングとそのアップデートは完全に使用されるべきです。
Chapter 4 - Addressing
第4章--アドレシング
4.1. Mail-11 addressing
4.1. メール-11アドレシング
Mail-11 addressing can vary from a very simple case up to complex ones, if there are other Mail-11 to "something-else" gateways involved. In any case a Mail-11 address is an ASCII string composed of different elements.
メール-11アドレシングは非常に簡単なケースと複雑なものまで異なることができます、ゲートウェイがかかわった「他の何か」への他のメール-11があれば。 どのような場合でも、メール-11アドレスは異なった要素で構成されたASCIIストリングです。
Allocchio [Page 4] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[4ページ]RFC1405メール-11
4.2. X.400 addressing
4.2. X.400アドレシング
On the other hand, An X.400 O/R address is a collection of attributes, which can anyway be presented as an IA5 textual representation as defined in chapter 4 of RFC1327.
他方では、An X.400O/Rアドレスは属性の収集です。(とにかく、RFC1327の支部4で定義されるIA5の原文の表現として属性を提示できます)。
4.3. Mail-11 address components
4.3. メール-11個のアドレス構成要素
Let us start defining the different parts composing a Mail-11 address. We can consider any Mail-11 address as composed by 3 parts:
メール-11アドレスを構成する異なった部品を定義し始めましょう。 私たちは、3つの部品によって構成されるようにどんなメール-11もアドレスであると考えることができます:
[[route]::] [[node]::] local-part
[発送します]:、:、]、[ノード]:、:、]、地方の部分
where 'route' and 'node' are optional and only 'local-part' is compulsory.
どこで、'ルート'と'ノード'が任意、そして、'地方の部分'であるだけであるかは、義務です。
Here comes a strict definition of these elements
これらの要素の厳しい定義はここに来ます。
node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT
「ノード=*(アルファー/DIGIT)/*DIGIT/*DIGIT」、」 *ケタ
route = *(node "::")
ルート=*「(ノード、」、:、:、」、)
local-part = username / nickname / for-protocol
地方の部分=ユーザ名/あだ名/プロトコルです。
username = *(ALPHA/DIGIT)
ユーザ名=*(アルファー/ケタ)
nickname = <printablestring - <" " and HTAB>>
「=<printablestringを愛称で呼んでください--<」、「HTAB>>」
for-protocol = (f-pref f-sep <">f-address<">)
プロトコルのための=(f-pref f-sep<、「>f-アドレス<、「>)」
f-pref = *(ALPHA/DIGIT)
f-prefは*と等しいです。(アルファー/ケタ)
f-sep = "%" / "::"
「f-sepは「%」/と等しい」:、:、」
f-address = printablestring / RFC822-address / X400-text-address
f-アドレスはX400テキストprintablestring / RFC822-アドレス/アドレスと等しいです。
X400-text-address = <textual representation of an X.400 O/R addr>
X400テキストアドレスはX.400O/R addr>の<の原文の表現と等しいです。
Please note that in x-text-address both the ";" notation and the "/" notation are equivalent and allowed (see examples in different sect.)
「アドレスのxテキスト両方でそれに注意してください、」、;、」 そして、「記法、」 /、」 記法は同等で許容されています。(異なったセクトで例を見てください。)
Allocchio [Page 5] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[5ページ]RFC1405メール-11
Some examples:
いくつかの例:
route node local-part
-----------------------------------------------------------
USER47
MYNODE::BETTY
BOSTON::CLUS02::GOOFY1::MARY34
IN%"M.P.Tracy@Dicdum.cc.edu"
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
MIAMI2::George.Rosenthal
CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
MAINVX::IN%"path1!path2!user%dom"
GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
smtp%"postmast@nodeb.bitnet"
MICKEY::PRFGAT::profs%"NANCY@IBMB"
edu%"HU427BD%CSUNIB@abc.acme.edu"
ノードの地方の一部を発送してください。----------------------------------------------------------- USER47 MYNODE:、:ベティ・ボストン:、:CLUS02:、:GOOFY1:、:MARY34インチ" M.P.Tracy@Dicdum.cc.edu "UCLA13:、:MVAX93:、:「MRGATE:、:、」MBOX1:、:MBX34:、:MYC3:、:「ボブ」MIAMI2:、:George.Rosenthal CCUBVX:、:VS3100:、:「Jnet%" IAB3425@IBAX23L "MRGATE:、:、」C=は以下をxxします:A=bbb:、:Pはpppと等しいです:、:「Sはジョーと等しく」MAINVX:、:「インチ」 path1!path2!ユーザ%dom」GWX400:、:gw%、「C=xx; ADMD=aaa; PRMDはpppと等しいです; Sはリーと等しいです」。 GX409A::「x400%」/Cはppp/S=xx/A=aaa/P=陰」 smtp%" postmast@nodeb.bitnet "ミッキーと等しいです:、:PRFGAT:、:profs%" NANCY@IBMB "edu%" HU427BD%CSUNIB@abc.acme.edu "
Chapter 5 - Mapping
第5章--マッピング
5.1. Mapping scheme
5.1. マッピング計画
DECnet address field is somehow a 'flat land' with some obliged routes to reach some hidden areas. Thus a truly hierarchical mapping scheme using mapping tables as suitable for RFC822 is not the appropriate solution. A fixed set of rules using DDAs support is defined in order to define the mapping.
DECnetアドレス・フィールドはどうにかいくつかの隠された領域に達するいくつかの強いられたルートがある'平坦な土地'です。 したがって、RFC822に適当であるとしてマッピングテーブルを使用する本当に階層的なマッピング計画は適切な解決策ではありません。 DDAsサポートを使用する固定セットの規則は、マッピングを定義するために定義されます。
Another important aspect of the problem is the coexistence of many disjoint DECnet networks, using the same DECnet address space, i.e., common X.400 and/or RFC822 mailing system acting as glue to connect different isolated Mail-11 islands. Thus, to identify uniquely each DECnet network we must also introduce the concept of 'DECnet network name', which we will refer shortly as 'net' from now onwards. We define as 'net' a unique ASCII string identifying the DECnet network we are connected to. To be more specific, the 'net' element will identify the DECnet community being served, i.e., it could also differ from the actual official network name. Aliases are allowed for the
問題の別の重要な一面は多くの共存がDECnetネットワーク、同じDECnetアドレス空間、すなわち、一般的なX.400を使用する、そして/または、異なった孤立しているメール-11の島をつなげるために接着剤としてシステム芝居を郵送するRFC822をばらばらにならせるということです。 したがって、また、唯一それぞれのDECnetネットワークを特定するために、私たちは私たちがまもなく'ネット'として現在前方へ参照するつもりである'DECnetネットワーク名'の概念を紹介しなければなりません。 私たちは私たちが接続されるDECnetネットワークを特定するユニークなASCIIストリングを'ネット'と定義します。 'ネット'の要素は、より特有に、なるように役立たれているDECnet共同体を特定するでしょう、また、すなわち、それが実際の公式のネットワーク名と異なるかもしれません。 別名は考慮されます。
net = 'HEPnet' the High Energy Physics DECnet network
net = 'SPAN' the Space Physics Analysis Network
net = 'Enet' the Digital Equipment Corporate Network
ネットの='HEPnet'Space Physics Analysis Networkネットの=High Energy Physics DECnetネットワークネット='SPAN''Enet'デジタル・イクイップメントCorporate Network
The need of labelling each DECnet network with its name comes also from the requirement to implement the 'intelligent' gateway, i.e., the gateway which is able to understand its ability to connect
また、名前でそれぞれのDECnetネットワークをラベルする必要性は'知的な'ゲートウェイを実行するという要件から来ます、すなわち、接続する性能を理解できるゲートウェイ
Allocchio [Page 6] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[6ページ]RFC1405メール-11
directly to the specified DECnet network, even if the O/R address specify a path to a different gateway. A more detailed discussion of the problem is in 5.3 and 5.5.
直接O/Rアドレスが異なったゲートウェイに経路を指定してもDECnetがネットワークでつなぐ指定に。 5.3と5.5には問題の、より詳細な議論があります。
A registry of 'net' attributes and their correspondent gateways must also be implemented to insure uniqueness of names. A simple table coupling 'net' and the gateway address is used, in a syntax similar to the 'gate' table used in RFC1327. An example:
また、名前のユニークさを保障するために'ネット'の属性とそれらの通信員ゲートウェイの登録を実行しなければなりません。 カップリング'ネット'という単純分類表とゲートウェイアドレスはRFC1327で使用される'ゲート'テーブルと同様の構文で使用されます。 例:
HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
Ambiguous left entries are allowed. Gateway implementations could simply choose among one of them, or try them all in cyclic order to obtain better performances.
左のあいまいなエントリーは許容されています。 ゲートウェイ実現は、それらの1つの中で単に選ぶか、または、より良い性能を得る周期的な命令でそれらを皆、試みるかもしれません。
In order to keep the mapping rules very simple, avoiding the need to analyse Mail-11 addresses to distinguish the 'route', 'node' and needed to cover the mapping problem.
非常に簡単に配置規則を保って、必要性を避けて、'ノード'の、そして、必要な'ルート'を区別するメール-11のアドレスを分析するために、マッピング問題をカバーしてください。
5.2. Mail-11 --> X.400
5.2. メール-11-->X.400
We define the following Domain Defined Attributes to map a Mail-11
address:
私たちはメール-11アドレスを写像するために以下のDomain Defined Attributesを定義します:
DD.Dnet
DD.Mail-11
DD.Dnet DD.Mail-11
We thus define the mapping rule
その結果、私たちは配置規則を定義します。
route::node::localpart
以下を発送してください:ノード:、:localpart
maps into
地図
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart;
Cはxxと等しいです。 ADMD=yyy。 PRMDはグーグーグーと等しいです。 O=ooo。 OU=uuu。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下を発送します:ノード:、:localpart。
with
with
xx = country code of the gateway performing the conversion
yyy = Admd of the gateway performing the conversion
zzz = Prmd of the gateway performing the conversion
ooo = Organisation of the gateway performing the conversion
uuu = Org. Unit(s) of the gateway performing the conversion
net = name of the DECnet network (e.g., HEPnet, SPAN,...)
xxは変換uuu=Orgを実行するゲートウェイの変換ooo=機構を実行するゲートウェイの変換グーグーグー=Prmdを実行するゲートウェイの変換yyy=Admdを実行するゲートウェイの国名略号と等しいです。 DECnetネットワークの変換ネットの=名を実行するゲートウェイのユニット(例えば、HEPnet、わたってください…)
('zzz','ooo','uuu' being used or dropped appropriately in order to
('グーグーグー'、'ooo'、適切に使用されているか、または落とされた'uuu'
Allocchio [Page 7] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[7ページ]RFC1405メール-11
identify uniquely within the X.400 MHS the gateway performing the conversion).
特定、唯一X.400 MHSの中で変換を実行するゲートウェイ)
The following defaults also apply:
また、以下のデフォルトは適用されます:
if 'node' is missing and we are mapping the Mail-11 originator (From) then 'node' defaults to the DECnet node name of the gateway (gwnode);
'ノード'がなくなって、私たちがメール-11創始者(From)を写像しているなら、'ノード'はゲートウェイ(gwnode)のDECnetノード名をデフォルトとします。
if 'node' is missing and we are mapping the Mail-11 recipient (To, Cc) then 'node' defaults to the DECnet node name of the 'From' address.
'ノード'がなくなって、私たちがメール-11受取人を写像している、(Cc) そして、'ノード'は'From'アドレスのDECnetノード名をデフォルトとします。
if 'DD.Dnet=net' is missing, then it defaults to a value defined locally by the gateway: if the gateway is connected to one DECnet network only, then 'net' will be the name of this unique network; if the gateway is connected to more than one DECnet network, then the gateway will establish a 'first choice' DECnet network, and 'net' will default to this value.
'DD.Dnetはネットと等しいこと'がなくなるなら、ゲートウェイによって局所的に定義された値をデフォルトとします: ゲートウェイが1つのDECnetネットワークだけに接続されると、'ネット'はこのユニークなネットワークの名前になるでしょう。 ゲートウェイが1つ以上のDECnetネットワークに接続されると、ゲートウェイは'最初に、選択'DECnetネットワークを設立するでしょう、そして、'ネット'はこの値をデフォルトとするでしょう。
In case 'local-part' contains 'x400-text-address' see also section 6.4.3;
'地方の部分はx400テキストアドレスを'含むといけない'ので、また、セクション6.4.3を見てください。
In case 'local-part' contains 'RFC822-address' see also section 6.4.4.
'地方の部分はRFC822-アドレスを'含むといけない'ので、また、セクション6.4.4を見てください。
5.2.1. Examples
5.2.1. 例
Let us suppose that:
以下のことと思いましょう。
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr'
(and these two fields are enough to identify uniquely the gateway
within the X.400 MHS).
DECnetネットワーク名(ネットの)は'HEP'です。 ゲートウェイ(gwnode)のDECnetノード名は'X4TDEC'です。 ゲートウェイのCountry Codeは'IT'です、そして、ADMDは'garr'(これらの2つの分野がX.400 MHSの中で唯一ゲートウェイを特定するために十分である)です。
USER47
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47;
USER47Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=X4TDEC:、:USER47。
MYNODE::BETTY
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY;
MYNODE:、:ベティCはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=MYNODE:、:ベティ。
BOSTON::CLUS02::GOOFY1::MARY34
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34;
ボストン:、:CLUS02:、:GOOFY1:、:MARY34Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11はボストンと等しいです:、:GOOFY1:、:MARY34。
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)
UCLA13:、:MVAX93:、:「MRGATE:、:、」MBOX1:、:MBX34: MYC3:、:「ボブ」Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=UCLA13:、:MVAX93:、:MRGATE:、:(q)MBOX1:、:MBX34:、:MYC3:、:ボブ(q)
Allocchio [Page 8] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[8ページ]RFC1405メール-11
MIAMI2::George.Rosenthal
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal;
MIAMI2:、:George.Rosenthal Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=MIAMI2:、:George.Rosenthal。
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)
「MRGATE:、:、」C=は以下をxxします:A=bbb:、:Pはpppと等しいです:、:「S=ジョー」Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=X4TDEC:、:MRGATE:、:(q)C=は以下をxxします:A=bbb:、:Pはpppと等しいです:、:Sはジョーと等しいです。(q)
MAINVX::In%"path1!path2!user%dom"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)
MAINVX:、:「インチ」 path1!path2!ユーザ%dom」Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=MAINVX:、:In(p)(q)path1(b)path2(b)user(p)dom(q)
5.3. X.400 encoding of Mail-11 --> Mail-11
5.3. メール-11のX.400コード化-->メール-11
In order to assure path reversibility in case of multiple Mail- 11/X.400 gateway crossing we must distinguish two cases:
複数のメール11/X.400ゲートウェイ交差点の場合に経路リバーシブルを保証するために、私たちは2つのケースを区別しなければなりません:
- DD.Dnet=net is known to the gateway as one of the DECnet networks
it is connected to. In this case the mapping is trivial:
- DD.Dnet=ネットはそれが関連づけられるDECnetネットワークの1つとしてゲートウェイに知られています。 この場合、マッピングは些細です:
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart;
Cはxxと等しいです。 ADMD=yyy。 PRMDはグーグーグーと等しいです。 O=ooo。 OU=uuu。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下を発送します:ノード:、:localpart。
(see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net')
(セクトを見てください。 5.2 'xx'、'yyy''グーグーグー'、'ooo'、'uuu''ネット'の解説のために)
maps into
地図
route::node::localpart
以下を発送してください:ノード:、:localpart
- DD.Dnet=net is NOT known to the gateway as one of the DECnet
networks it is connected to. In this case the mapping rule
described into section 5.4 apply:
- DD.Dnet=ネットはそれが関連づけられるDECnetネットワークの1つとしてゲートウェイに知られていません。 この場合、セクション5.4に説明された配置規則は適用されます:
C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
DD.Mail-11=route::node::localpart;
Cはxxと等しいです。 ADMD=yyy。 PRMD=www。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下を発送します:ノード:、:localpart。
maps into
地図
gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
DD.Mail-11=route::node::localpart;"
gwnode:、:「C=xx; ADMD=yyy; PRMD=www; DD.Dnet=は網で覆う」gw%。 DD.Mail-11=は以下を発送します:ノード:、:"localpart"。
5.3.1. Examples
5.3.1. 例
Let us suppose that:
以下のことと思いましょう。
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr';
(and these two fields are enough to identify uniquely the gateway
DECnetネットワーク名(ネットの)は'HEP'です。 ゲートウェイ(gwnode)のDECnetノード名は'X4TDEC'です。 ゲートウェイのCountry Codeは'IT'です、そして、ADMDは'garr'です。 (これらの2つの分野が、唯一ゲートウェイを特定するために十分です。
Allocchio [Page 9] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[9ページ]RFC1405メール-11
within the X.400 MHS).
中、X.400 MHS)
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"
Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=X4TDEC:、:MRGATE:、:(q)Cは腹筋と等しいです:、:A=dsa:、:P=qwty:、:OU=mie:、:「S=Cly(q) MRGATE:、:、」Cは腹筋と等しいです:、:A=dsa:、:P=qwty:、:OU=mie:、:"S=Cly"
C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;
X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET;
DD.Mail-11=ROM01::CARLO;"
Cはそれと等しいです。 ADMD=garr。 DD.Dnet=EASYNET。 DD.Mail-11=ROM01:、:カルロ。 X4TDEC:、:gw%「C=それ; ADMD=garr; DD.Dnet=EASYNET」。 DD.Mail-11=ROM01:、:「カルロ」。
(in the above example 'EASYNET' is supposed to be not connected to our gateway located on X4TDEC DECnet node).
(上記の例では、'EASYNET'によってX4TDEC DECnetノードの上に位置する私たちのゲートウェイに接続されるべきではありません。)
5.4. X.400 --> Mail-11
5.4. X.400-->メール-11
The mapping of an X.400 O/R address into Mail-11 is done encoding the various attributes into the X400-text-address as defined in chapter 4 of RFC1327, and including this as 'f-address'. A 'f-pref' and a the DECnet node name of the gateway.
RFC1327の支部4で定義されて、'f-アドレス'としてこれを含んでいるとしてX400テキストアドレスに様々な属性をコード化しながら、メール-11へのX.400O/Rアドレスに関するマッピングをします。 'f-pref'とノードが命名するゲートウェイのDECnet。
Thus
このようにして
x400-text-address
x400テキストアドレス
will be encoded like
コード化された同類であるために望んでください。
gwnode::gw%"x400-text-address"
gwnode:、:gw%、「x400テキストアドレス」
having spaces dividing attributes as optional.
任意であるとして属性を分割する空間を持っています。
5.4.1. Example
5.4.1. 例
Let us suppose that:
以下のことと思いましょう。
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
ゲートウェイ(gwnode)のDECnetノード名は'X4TDEC'です。
Thus
このようにして
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Jim; S=Clay;
Cはgbと等しいです。 ADMDは金400と等しいです。 PRMD=AC.UK。 O=ucl。 OUはCsと等しいです。 Gはジムと等しいです。 Sは粘土と等しいです。
will be encoded like
コード化された同類であるために望んでください。
X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Jim/S=Clay"
X4TDEC:、:gb/A=「gw%」/C=金400/P=AC.UK/O=ucl/OUがジム/S=Cs/G=粘土と等しい、」
or its equivalent with the ";" notation
「それが同等である、」、;、」 記法
X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Jim;S=Clay;"
X4TDEC:、:gw%、「Cはgbと等しいです; ADMDは金400と等しいです; PRMD=AC.UK; O=ucl; OUはCsと等しいです; Gはジムと等しいです; Sは粘土と等しいです」。
Allocchio [Page 10] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[10ページ]RFC1405メール-11
5.5. Mail-11 encoding of X.400 --> X.400
5.5. X.400のメール-11コード化-->X.400
It can happened that Mail-11 is used to relay messages between X.400 systems; this will mean multiple X.400/Mail-11 gateway crossing and we will encounter Mail-11 addresses containing embedded X.400 informations. In order to assure path reversibility we must then distinguish two cases:
缶は起こりました。それ、そのメール-11はX.400システムの間のメッセージをリレーするのに使用されます。 これは複数のメール-11X.400/ゲートウェイ交差点を意味するでしょう、そして、私たちは埋め込まれたX.400情報を含むメール-11のアドレスに遭遇するつもりです。 次に、経路リバーシブルを保証するために、私たちは2つのケースを区別しなければなりません:
- the embedded X.400 address belongs to a domain whose naming and
routing rules are known to the global X.400 MHS. In this case the
mapping is trivial:
- 埋め込まれたX.400アドレスは命名とルーティング規則がグローバルなX.400 MHSにおいて知られているドメインに属します。 この場合、マッピングは些細です:
route::gwnode::gw%"x400-text-address"
以下を発送してください:gwnode:、:gw%、「x400テキストアドレス」
maps into
地図
x400-text-address
x400テキストアドレス
'route' and 'gwnode' are mapped into X.400 Trace service elements.
'ルート'と'gwnode'はX.400 Traceサービス要素に写像されます。
- the encoded X.400 domain does not belong to the global X.400 name
space. In this case the mapping rule described into section 5.2
apply:
- コード化されたX.400ドメインはスペースというグローバルなX.400名に属しません。 この場合、セクション5.2に説明された配置規則は適用されます:
route::gwnode::gw%"x400-text-address"
以下を発送してください:gwnode:、:gw%、「x400テキストアドレス」
maps into
地図
C=xx; ADMD=yyy; DD.Dnet=net;
DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);
Cはxxと等しいです。 ADMD=yyy。 DD.Dnetはネットと等しいです。 DD.Mail-11=は以下を発送します:gwnode:、:gw(p)(q)x400-テキストアドレス(q)。
The latter case is deprecated and must be regarded as a possible temporary solution only, while waiting to include into the global X.400 MHS also this domain.
グローバルなX.400 MHSにもこのドメインを含めるのを待っている間、後者のケースを推奨しなく、可能な一時的な解決だけと見なさなければなりません。
5.5.1. Examples
5.5.1. 例
Let us suppose that:
以下のことと思いましょう。
the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr';
(and these two fields are enough to identify uniquely the gateway
within the X.400 MHS).
DECnetネットワーク名(ネットの)は'HEP'です。 ゲートウェイ(gwnode)のDECnetノード名は'X4TDEC'です。 ゲートウェイのCountry Codeは'IT'です、そして、ADMDは'garr'です。 (これらの2つの分野がX.400 MHSの中で唯一ゲートウェイを特定するために十分です。)
X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;"
C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;
X4TDEC:、:gw%、「Cはfrと等しいです; ADMDが地図帳; PRMD=ifip; O=と等しい、ポリー、;、Sがモローと等しい 」、。 Cはfrと等しいです。 ADMDは地図帳と等しいです。 PRMD=ifip。 Oが等しい、ポリー、。 Sはモローと等しいです。
Allocchio [Page 11] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[11ページ]RFC1405メール-11
X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ;
PRMD=Botwa;O=Miner;S=Chiuaw;(q)
X4TDEC:、:gw%「C=zz; ADMD=; PRMD=Botwa; ○ =坑夫; S=Chiuaw」。 Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=X4TDEC:、:gw(p)(q)Cはzzと等しいです; ADMD= PRMD=Botwa; Oは坑夫と等しいです; S=Chiuaw(q)
(in the above example C=zz is unknown to the global X.400 MHS)
(上記の例Cでは、グローバルなX.400 MHSにおいて、=zzは未知です)
Chapter 6 - Complex mapping
第6章--複雑なマッピング
6.1. The protocol triangle
6.1. プロトコル三角形
The bilateral mappings described in chapter 5 must be extended in order to cover also the case in which also RFC822 addressing is involved, and the following triangular situation occurs:
また、また、RFC822アドレシングがかかわる場合をカバーするために第5章で説明された双方のマッピングを広げなければなりません、そして、以下の三者間の状況は起こります:
x.400
/ \
/ \
/ \
Mail-11----RFC822
/\/\メール-11x.400/円----RFC822
The X.400 - RFC822 side is fully covered by RFC1327, and the previous chapters in this document cover the Mail-11 - X.400 side.
X.400--前の章は本書ではメール-11をカバーしています--RFC822側はRFC1327で完全にカバーされていて、X.400は面があります。
Currently a number of implementations also perform the mapping along the Mail-11 - RFC822 side. The most important among these de facto standards are discussed in Appendix A, jointly with a Mail-11 - RFC822 mapping scheme which covers this side of the triangle.
また、現在多くの実現がメール-11に沿ってマッピングを実行します--RFC822は面があります。 Appendix Aでこれらのデファクトスタンダードの中で最も重要であるのについて議論します、メール-11と一緒に--三角形の手前を覆う計画を写像するRFC822。
6.2. RFC822 mapped in Mail-11
6.2. メール-11で写像されたRFC822
The 'RFC822-address' is usually included in 'local-part' as
通常、'RFC822-アドレス'は'地方の部分'に含まれています。
route::gwnode::gw%"rfc822-address"
以下を発送してください:gwnode:、:%が「rfc822記述する」gw
an example
例
NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"
NVXA23:、:SMTPGW:、:インチ" M.T.Rose@CS.UCLA.edu "
6.3. Mail-11 mapped in RFC822
6.3. RFC822で写像されたメール-11
There are different styles in mapping a Mail-11 address in RFC822; let's have a short summary.
メール-11アドレスを写像するのにおいて異なったスタイルがRFC822にあります。 要約を持ちましょう。
- Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822
address, using "%" syntax or "::" syntax;
- または、「「%」構文を使用して、メール-11アドレスが「左側」でRFC822アドレスの(LHS)をコード化した、」、:、:、」 構文。
route::node::localpart
以下を発送してください:ノード:、:localpart
Allocchio [Page 12] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[12ページ]RFC1405メール-11
maps to
地図
localpart%node%route@gw-domains
localpart%node%route@gw-domains
or
または
"route::node::localpart"@gw-domains
「以下を発送してください」ノード:、:"localpart"@gwドメイン
where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.
'gw-ドメイン'が唯一メール-11 / RFC822ゲートウェイを特定するところ。
- Mail-11 address maps partly to LHS and partly to 'domain' part of
RFC822 address:
- メール-11は地図を一部LHSと一部RFC822アドレスの'ドメイン'部分まで記述します:
node::localpart
ノード:、:localpart
maps to
地図
localpart@node.gw-domains
localpart@node.gw-domains
- Mail-11 address is completely hidden by a mapping table / directory
and the resultant RFC822 address contains no trace at all of the
original address.
- メール-11アドレスはマッピングテーブル/ディレクトリに完全に隠れています、そして、結果のRFC822アドレスはオリジナルのアドレスのすべてに跡を全く含んでいません。
As you could notice, in any of the quoted cases the resultant RFC822 address is not distinguishable from a genuine RFC822 address.
あなたが気付くことができた引用された場合のいずれではも、結果のRFC822アドレスは本物のRFC822アドレスから区別可能ではありません。
6.4. Multiple conversions
6.4. 複数の変換
Let us now examine briefly the possible situations which involve multiple conversions, having one protocol as a relay between the other two. This summary suggest some possible enhanced solutions to avoid heavy and unduly mappings, but the 'step by step' approach, considering blindly one conversion as disjointed to the other, as described in the previous sections, can always be used.
現在簡潔に複数の変換にかかわる可能な状況を調べましょう、リレーとして他の2の間に1つのプロトコルを持っていて。 この概要は悪党を避けるためにいくつかの可能な高められた解決策を示します、そして、過度に、しかし、マッピング、'段階的'にアプローチします、そして、前項で説明されるように1つがもう片方にばらばらになっている変換であると盲目的に考えるのはいつも使用できます。
6.4.1. X.400 --> RFC822 --> Mail-11
6.4.1. X.400-->RFC822-->メール-11
We apply the RFC1327 rules to the first step, obtaining an RFC822 address which can be mapped in Mail-11 using the 'f-address' field, as described in section 6.2.
私たちはRFC1327規則を第一歩に適用します、メール-11で'f-アドレス'分野を使用することで写像できるRFC822アドレスを得て、セクション6.2で説明されるように。
an example:
例:
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
Cはgbと等しいです。 ADMDは金400と等しいです。 PRMD=AC.UK。 O=UCL。 OUはCsと等しいです。 Gはジムと等しいです。 Sは粘土と等しいです。
maps accordingly to RFC1327 to
それに従って、RFC1327への写像
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
Allocchio [Page 13] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[13ページ]RFC1405メール-11
and finally becomes
最終的に、なります。
SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
SMTPGW:、:インチ" Jim.Clay@cs.UCL.AC.UK "
where 'SMTPGW' is the DECnet node name of the machine running the RFC822 to Mail-11 gateway.
'SMTPGW'がメール-11ゲートウェイへRFC822を走らせるマシンのDECnetノード名であるところ。
6.4.2. Mail-11 --> RFC822 --> X.400
6.4.2. メール-11-->RFC822-->X.400
Some of the possible mapping described in section 6.3 apply to the Mail-11 address, hiding completely its origin. The RFC1327 apply on the last step.
完全に正体を隠して、セクション6.3で説明された可能なマッピングのいくつかがメール-11アドレスに適用されます。 RFC1327は最後のステップのときに適用します。
an example:
例:
RELAY::MYNODE::BETTY
以下をリレーしてください:MYNODE:、:ベティ
could map into RFC822 as
RFC822に写像できました。
BETTY%MYNODE@RELAY.dnet.gw1.it
BETTY%MYNODE@RELAY.dnet.gw1.it
and accordingly to RFC1327
それに従って、RFC1327
C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;
Cはそれと等しいです。 A=garr。 P=dom1。 O=gw1。 OUはリレーと等しいです。 S=BETTY(p)MYNODE。
where 'dnet.gw1.it' is the domain of the machine running the Mail-11 to RFC822 gateway.
'dnet.gw1.it'がメール-11をRFC822ゲートウェイへ走らせるマシンのドメインであるところ。
6.4.3. X.400 --> Mail-11 --> RFC822
6.4.3. X.400-->メール-11-->RFC822
The X.400 address is stored into Mail-11 'f-address' element as described in sections 5.3 and 5.4; then if the Mail-11 to RFC822 gateway is able to understand the presence of a 'x400-text-address' into the Mail-11 address, then it applies RFC1327 to it, and encodes header. Otherwise it applies the rules described in 6.3
X.400アドレスはセクション5.3と5.4で説明されるようにメール-11'f-アドレス'要素に格納されます。 次に、RFC822ゲートウェイへのメール-11が'x400テキストアドレス'の存在をメール-11アドレスに理解できるなら、それは、RFC1327をそれに適用して、ヘッダーをコード化します。 さもなければ、それは6.3で説明された規則を適用します。
an example:
例:
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
Cはgbと等しいです。 ADMDは金400と等しいです。 PRMD=AC.UK。 O=UCL。 OUはCsと等しいです。 Gはジムと等しいです。 Sは粘土と等しいです。
will be encoded like
コード化された同類であるために望んでください。
X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
X4TDEC:、:gb/A=「gw%」/C=金400/P=AC.UK/O=UCL/OUがジム/S=Cs/G=粘土と等しい、」
If the Mail-11 to RFC822 gateway recognise the x400-text-address, then the address becomes, accordingly to RFC1327
RFC822ゲートウェイへのメール-11がx400テキストアドレスを認識するなら、アドレスはそれに従って、RFC1327になります。
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
Allocchio [Page 14] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[14ページ]RFC1405メール-11
and the following RFC822 header line is added
そして、以下のRFC822ヘッダー線は加えられます。
Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.
受け取られている: DECnet(メール-11)がxx-xxx-xxxxにあるX4TDECから。
Otherwise one of the dumb rules could produce
さもなければ、馬鹿な規則の1つは生産されることができました。
gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms
「gw%」/Cは」 @X gb/Cs/G=ジム/S==金400/P=AC.UK/O=UCL/OU=粘土4TDEC.domsと等しいです。
6.4.4. RFC822 --> Mail-11 --> X.400
6.4.4. RFC822-->メール-11-->X.400
The RFC822 address is encoded in Mail-11 f-address element as described in sect. 6.2; then if the Mail-11 to X.400 gateway is able to understand the presence of an 'RFC822-address' into the Mail-11 address, then it applies RFC1327 to it, and encodes 'route' and applies the rules described in 5.2 and 5.5.
RFC822アドレスはセクトで説明されるようにメール-11f-アドレス要素でコード化されます。 6.2; 次に、X.400ゲートウェイへのメール-11が'RFC822-アドレス'の存在をメール-11アドレスに理解できるなら、それは、RFC1327をそれに適用して、'ルート'をコード化して、5.2と5.5で説明された規則を適用します。
an example:
例:
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
will be encoded like
コード化された同類であるために望んでください。
SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
SMTPGW:、:インチ" Jim.Clay@cs.UCL.AC.UK "
If the Mail-11 to X.400 gateway recognise the RFC822-address, then the address becomes, accordingly to RFC1327
X.400ゲートウェイへのメール-11がRFC822-アドレスを認識するなら、アドレスはそれに従って、RFC1327になります。
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
Cはgbと等しいです。 ADMDは金400と等しいです。 PRMD=AC.UK。 O=UCL。 OUはCsと等しいです。 Gはジムと等しいです。 Sは粘土と等しいです。
and a 'trace' record is added into the X.400 P1 data, stating that a node named SMTPGW was crossed.
そして、SMTPGWというノードが交差されたと述べて、'跡'記録はX.400 P1データに追加されます。
Otherwise dumb rule produces
そうでなければ、馬鹿な規則は作成されます。
C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)
Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=SMTPGW:、:In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)
6.4.5. RFC822 --> X.400 --> Mail-11
6.4.5. RFC822-->X.400-->メール-11
We apply RFC1327 to the first conversion, obtaining an X.400 address. Then the rules described in sections 5.3 and 5.4 are used to store the X.400 address as 'x400-text-address' into the Mail-11
X.400アドレスを得て、私たちは最初の変換にRFC1327を適用します。 そして、セクション5.3と5.4で説明された規則は、'x400テキストアドレス'としてメール-11にX.400アドレスを格納するのに使用されます。
an example:
例:
Jim.Clay@cs.UCL.AC.UK
Jim.Clay@cs.UCL.AC.UK
maps accordingly to RFC1327 to
それに従って、RFC1327への写像
Allocchio [Page 15] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[15ページ]RFC1405メール-11
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
Cはgbと等しいです。 ADMDは金400と等しいです。 PRMD=AC.UK。 O=UCL。 OUはCsと等しいです。 Gはジムと等しいです。 Sは粘土と等しいです。
and finally becomes
最終的に、なります。
SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
SMTPGW:、:gb/A=「gw%」/C=金400/P=AC.UK/O=UCL/OUがジム/S=Cs/G=粘土と等しい、」
where 'SMTPGW' is the DECnet node name of the machine running the X.400 to Mail-11 gateway.
'SMTPGW'がメール-11ゲートウェイへX.400を走らせるマシンのDECnetノード名であるところ。
6.4.6. Mail-11 --> X.400 --> RFC822
6.4.6. メール-11-->X.400-->RFC822
The Mail-11 address is encoded as specified in sections 5.2 and 5.5; then RFC1327 is used to convert the address in RFC822.
メール-11アドレスはセクション5.2と5.5で指定されるようにコード化されます。 そして、RFC1327は、RFC822のアドレスを変換するのに使用されます。
an example:
例:
RELAY::MYNODE::BETTY
以下をリレーしてください:MYNODE:、:ベティ
maps into X.400 as
X.400への地図
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY::MYNODE::BETTY;
Cはそれと等しいです。 ADMD=garr。 DD.Dnet=事情通。 DD.Mail-11=は以下をリレーします:MYNODE:、:ベティ。
and accordingly to RFC1327
それに従って、RFC1327
"/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it
/Cはそれと等しいです。/A=garr/DD.Dnetは事情通の/DD.Mailと等しいです。「-11 = 以下をリレーしてください:、」MYNODE:、:「ベティ」@gw2.it
where 'gw2.it' is the domain of the machine running the RFC1327 gateway.
'gw2.it'がRFC1327ゲートウェイを動かすマシンのドメインであるところ。
Appendix A Mail-11 - RFC822 mapping
付録Aメール-11--RFC822マッピング
A.1 Introduction
A.1序論
The implementation of a Mail-11 - RFC822 gateway was faced by many software developers independently, and was included in many mail products which were running on both VAX/VMS and UNIX systems. As there was not a unique standard mapping way, the implementations resulted into a number of possible variant methods to map a Mail-11 address into an RFC822 one. Some of these products became then largely widespread, starting to create a number of de facto mapping methods.
RFC822ゲートウェイは、多くのソフトウェア開発者によって独自に面していて、VAX/VMSとUNIXシステムの両方で動いていた多くのメール製品に含まれました。メール-11の実現--道、実現を写像するユニークな規格がなかったとき、結果になられて、メール-11を写像する多くの可能な異形方法がRFC822に1つを記述します。 多くの事実上のマッピング法を作成し始めて、これらのいくつかの製品が次に、主に広範囲になりました。
In this small appendix some sort of standardisation of the mapping problem is considered, trying to be compatible with the existing installed software. We must also remind that, in some cases, only simple Mail-11 addresses could be mapped into RFC822, having complex ones producing all sort of quite strange results.
この小さい付録では、マッピング問題のある種の規格化が考えられます、ソフトをインストールした存在と互換性があるようになろうとして。 また、私たちは、いくつかの場合で簡単なメール-11のアドレスしかRFC822に写像できなかったように思い出させなければなりません、すべての種類のかなり奇妙な結果を生む複雑なものを持っていて。
Allocchio [Page 16] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[16ページ]RFC1405メール-11
On the other hand, the mapping of an RFC822 address in Mail-11 was quite straightforward, resulting in a common definition which uses "Mail-11 foreign mail protocol" to design an RFC822 address:
他方では、メール-11におけるRFC822アドレスのマッピングはかなり簡単でした、RFC822アドレスを設計するのに「メール-11の外国メールプロトコル」を使用する一般的な定義をもたらして:
[[node::][node::]...]prot%"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、prot%、「rfc822アドレス」
or
または
[node::][node::]...]::"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、…]::"「rfc822アドレス」
A.2 De facto implementations
A.2の事実上の実現
A considerable number of de-facto implementations of Mail-11/RFC822 gateways is existing. As said in the introduction, the mapping of RFC822 addresses in Mail-11 is accomplished using the foreign mail protocol syntax and is thus unique.
メール-11/RFC822ゲートウェイの多数のデファクト実現が存在しています。 序論で言われているように、メール-11におけるRFC822アドレスのマッピングは、外国メールプロトコル構文を使用するのに優れて、その結果、ユニークです。
On the other hand, Mail-11 addresses are encoded in RFC822 syntax in various ways. Here are the most common ones:
他方では、メール-11のアドレスがRFC822構文でいろいろコード化されます。 ここに、最も一般的なものがあります:
a) "node::user"@gateway-address
b) user%node@gateway-address
c) user@node.decnet.domains
d) user%node.dnet@gateway-address
a) 「ノード:、:、」「ユーザ」@gatewayアドレスb) user%node@gateway-address c)ユーザ@node.decnet.domains d) user%node.dnet@gateway-address
Let's have a quick look to these different choices.
これらの異なった選択にクイック・ルックを持ちましょう。
a - This form simply encloses as quoted Left Hand Side string the
original Mail-11 address into the RFC822 address of the
Mail-11/RFC822 gateway. This method is fully conformant with
RFC822 syntax, and the Mail-11 address is left untouched; thus
no encoding rules need to applied to it.
a--このフォームは引用されたLeft Hand Sideストリングとして単にメール-11/RFC822ゲートウェイのRFC822アドレスにオリジナルのメール-11アドレスを同封します。 この方法はRFC822構文で完全にconformantです、そして、メール-11アドレスは触れない状態で残されます。 したがって、どんな符号化規則も、それに適用されていた状態で必要がありません。
b - As one will immediately notice, this form has nothing in it
indicating the address is a Mail-11 one; this makes the encoding
indistinguishable from a similar encoding of RSCS (BITnet)
addresses used by some IBM VM Mailer systems. It should thus be
deprecated.
b--人がすぐに気付くように、このフォームには、何もアドレスがメール-11 1つであることを示すそれのことがありません。 これで、コード化はいくつかのIBM VMメイラーシステムによって使用されるRSCS(BITnet)アドレスの同様のコード化から区別がつかなくなります。その結果、それは非難されるべきです。
c - In this case a sort of 'reserved word' (decnet) embedded into
the address itself identifies the presence of a Mail-11 original
address preceding it. The decoding is possible, dropping
'domains' and extracting 'user' and 'node' parts. However complex
Mail-11 addresses cannot be mapped properly in this syntax, and
there is no specific rule for adding the 'domains' part of the
address.
c--この場合、アドレス自体に埋め込まれた一種の'リザーブドワード'(decnet)がそれに先行するメール-11のオリジナルのアドレスの存在を特定します。 'ドメイン'を落として、'ユーザ'と'ノード'の部品を抽出して、解読は可能です。 しかしながら、この構文で適切に複雑なメール-11のアドレスを写像できません、そして、アドレスの'ドメイン'部分を加えるためのどんな特定の規則もありません。
Allocchio [Page 17] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[17ページ]RFC1405メール-11
d - In this case again there is a 'reserved word' (dnet) which make
possible the identification of the original Mail-11 address;
'gateway-address' points to the Mail-11/RFC822 gateway and 'node'
and 'user' information can be easily drawn from the address.
However complex Mail-11 addresses cannot be embedded easily into
this syntax.
d--この場合、オリジナルのメール-11アドレスの識別を可能にする'リザーブドワード'(dnet)が再びあります。 'ゲートウェイアドレス'はメール-11/RFC822ゲートウェイを示します、そして、アドレスから'ノード'と'ユーザ'情報を容易に得ることができます。 しかしながら、容易に複雑なメール-11のアドレスをこの構文に埋め込むことができません。
A.3 Recommended mappings
A.3のお勧めのマッピング
From the examples seen in the previous paragraphs we can derive a canonical form for representing the mapping between Mail-11 and RFC822.
前のパラグラフで見られた例から、私たちは、メール-11とRFC822の間のマッピングを表すために標準形を引き出すことができます。
A3.1 RFC822 mapped in Mail-11
メール-11で写像されたA3.1 RFC822
The mapping of an RFC822 address in Mail-11 is straightforward, using the "Mail-11 foreign mail protocol" syntax. The two possible variants are:
「メール-11の外国メールプロトコル」構文を使用して、メール-11におけるRFC822アドレスのマッピングは簡単です。 2つの可能な異形は以下の通りです。
[[node::][node::]...]prot%"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、prot%、「rfc822アドレス」
or
または
[node::][node::]...]::"rfc-822-address"
[ノード:、:、]、[ノード:、:、]、…]::"「rfc822アドレス」
A3.2 Mail-11 mapped in RFC822
RFC822で写像されたA3.2メール-11
RFC822 foresee a canonical form for representing non-RFC822 addresses: put the foreign address in local part (Left Hand Side, LHS) is a form as similar as possible to its original syntax. Thus the suggested mapping is:
RFC822は非RFC822アドレスを表すために標準形について見通します: 置かれて、地方の部分(Hand Side、LHSに残される)の外国アドレスはできるだけオリジナルの構文と同様のフォームです。 したがって、提案されたマッピングは以下の通りです。
"Mail-11-address"@gateway-address
「メール11アドレス」@gatewayアドレス
This format assures also the return path via the appropriate gateway.
また、この形式は適切なゲートウェイを通してリターンパスを保証します。
A.4 Conclusions
A.4結論
A standard way of mapping Mail-11 addresses into RFC822 and vice versa is feasible. A suggestion is thus made to unify all existing and future implementations. It should be noted, however, that there is no way to specify in these mappings the name of the decnet community owning the encoded address, as it was done for X.400, thus the implementation of the 'intelligent' gateway in this case is impossible.
メール-11のアドレスをRFC822に写像する標準の方法は逆もまた同様に可能です。 すべての存在と今後の実現を統一するのを提案をこのようにしてします。 しかしながら、コード化されたアドレスを所有しながらこれらのマッピングでdecnet共同体の名前を指定する方法が全くないことに注意されるべきであり、その結果、この場合、'知的な'ゲートウェイの実現はX.400のためにそれをしたように不可能です。
Allocchio [Page 18] RFC 1405 Mail-11 Mapping January 1993
1993年1月を写像するAllocchio[18ページ]RFC1405メール-11
Acknowledgements
承認
I wish to thank all those people who read the first draft and contributed a lot with their useful suggestions to the revision of this document, in particular RARE WG1 and IETF X.400 ops group members and S. Hardcastle-Kille.
最初の草稿を読み込んで、彼らの役に立つ提案でこのドキュメントの改正に大いに貢献したすべての人々に感謝申し上げます、IETF X.400オプアートの特定のRARE WG1、グループのメンバー、およびS.Hardcastle-Killeで。
References
参照
[1] CCITT, "CCITT Recommendations X.400-X.430", Message Handling
Systems: Red Book, October 1984.
[1]CCITT、「CCITT推薦X.400-X.430」メッセージハンドリングシステム: 1984年10月の職員録。
[2] CCITT, "CCITT Recommendations X.400-X.420", Message Handling
Systems: Blue Book, November 1988.
[2]CCITT、「CCITT推薦X.400-X.420」メッセージハンドリングシステム: 1988年11月の紳士録。
[3] Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDel, August 1982.
[3] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDel、1982年8月。
[4] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic
Community Report (MG.19) / RFC 987, June 1986.
[4]Kille、S.、「X.400とRFC822の間のマッピング」、イギリス学界レポート(mg.19)/RFC987、1986年6月。
[5] Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822", RFC 1327, March 1992.
[5]Kille、S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1327、3月1992日
[6] Digital Equipment Corp.;, "VAX/VMS Mail Utility".
[6]ディジタル・イクイップメント社; 「VAX/VMSメール実用的です」。
[7] Joiner Associates Inc., "Jnet User's Manual".
[7] Joinerは株式会社、「Jnetユーザマニュアル」を関連づけます。
[8] PMDF User's Guide.
[8] PMDF使用手引書。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Claudio Allocchio Cosine S2.2 Sincrotrone Trieste Area di Ricerca Padriciano 99 I 34012 Trieste Italy
クラウディオAllocchio Cosine S2.2 SincrotroneトリエステAreaディRicerca Padriciano99I34012トリエステイタリア
Phone: +39 40 3758523
Fax: +39 40 226338
EMail: Claudio.Allocchio@elettra.Trieste.it
C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;
以下に電話をしてください。 +39 40 3758523、Fax: +39 40 226338はメールされます: Claudio.Allocchio@elettra.Trieste.it Cはそれと等しいです。 A=garr。 Pはトリエステと等しいです。 Oはエレットラと等しいです。 S=Allocchio。 Gはクラウディオと等しいです。
Allocchio [Page 19]
Allocchio[19ページ]
一覧
スポンサーリンク
